« A Personal Retrospective | Main | All I want for Christmas is Oracle Lite »
December 03, 2005
The paradox of the TW code review
ThoughtWorks in Australia is undergoing a fairly aggressive recruiting program at the moment. We're looking for people at all levels of experience, from graduate to PM. A key component of the TW recruitment process is the Code Review, a mandatory step for all people looking for a technical career at ThoughtWorks. In short, the candidate is given a choice of technical problems, a period of a couple of days to complete and submit a solution, and then the recruitment process is continued or terminated based on a review of the submission.
Now although none of the review problems are intended to be technically challenging, many candidates fall at this hurdle based on the quality of their submission alone. I don't think I'm giving the game away by saying that the intention of the code review is to ensure people are at least capable of completing an assigned task in a reasonable period of time, and that their general level of development skills (at least what is apparent through perusal of their submission) is of a level sufficiently high to consider continuing the recruitment process.
But the twist in the tail of the code review is how people interpret the seemingly hidden requirements for submitting code to a company like ThoughtWorks. Most candidates have done the minimum amount of research to know that TW is a company happily-disposed to Agile development in some form, particularly biaised towards XP. And based on research into Agile/XP methods, many are also aware of the Do the simplest thing that could possibly work mantra...
So, as a potential ThoughtWorker working on a code review, how do you reconcile the orthogonal desires of impressing the mystery reviewer with your coding "chops", whilst at the same time paying heed to a core TW cultural value of simplicity at all costs? Which is more important? Pour the entire contents of the GoF into your code to amaze us with your pattern mastery? Or eschew all such adornments and submit a code so simple it is almost Zen-like in it's brevity?
Not surprisingly, there is no correct answer. We've had successful and unsuccessful applications with code reviews from both ends of the spectrum. From the candidates perspective, having the courage of your convictions (whichever approach you've taken) is required. And from an interview perspective, interesting questions can often be asked on how to refactor the submitted solution to a simpler or more "complex" design.
Possibly the worst solution is to not be aware of the paradox at all, which would show a lack of research into the values of the potential employer.
Posted by Andy Marks at December 3, 2005 10:49 AM
Comments
It's funny you know coz when I did my code review, I submitted the (now defunct) date problem. I think that was an order of maginatude (if not more) easier than any other problem however it was--at least when I was there--also the least attempted.
I'm not sure if that makes me dumb or smart hehehe but I suspect many people attempt the seemingly more difficult problem(s) because they feel the simpler one(s) won't prove their skills.
I took the approach that, well, screw it, my time is valuable (and I've never liked "tests" anyway) so I'm going to do the simplest one they have :)
Posted by: Simon Harris at December 3, 2005 12:30 PM
> ...from graduate to PM...
Interesting choices. Does PM == highly experienced?
Posted by: Dave Hoover at December 4, 2005 03:07 AM
You're right Dave, I didn't mean to imply that a PM role was the other end of the spectrum to a graduate, but I do believe you need a reasonable level of experience before you assume that role.
Posted by: Andy at December 5, 2005 10:19 PM
Andy,
I think that whatever path is taken, accompanying notes can be used for explanation.
This helps review enormously, so that those who provide simple yet elegant solutions can note that "although not used in this sample, the features of X pattern would be beneficial because of ABC". Or, "with more time, architectural layers Y and Z would be interleaved to allow for non-functional requirements DEF".
The corollary is that if the code comes in with lots of bells and whistles (it must have been coded at "Tirsen Factor 9") then the reviewer would benefit from having some notes on how the code evolved to that point, and the design forces considered for those decisions to have been made.
Posted by: Josh Graham at December 8, 2005 12:36 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)