The last time I was regularly responsible for hires, I put together a .zip file of about 3 different projects (.NET and Java at the time) and would send the .zip to them with minimal instructions. They were required to look at the first one, and the other two were optional. Other than that, the instructions were, ‘pretend you're now in charge of this code, show me what you'd do.’
The first project was very small and had bugs and was crap. The other two had some more subtle issues (failing unit tests, passing test that shouldn't be passing, a multi-threaded bug, etc)
I'd ask them to send it back to me with changes, then told them I'd review and we'd go another round if they were interested.
Some of my co-workers thought not giving them any instructions wasn't fair, but that many times is the job: here's some code - the last guy who wrote it is gone - you own it now.
Going through a round of review also would show me (a) what they'd do on their own (b) how they respond to criticism (c) and will they bother to address the things in the review.
The downside with this approach is it can be time intensive for a candidate, so I did mention in the note if they wanted to sort of hint at some of the things they'd do in the code, then maybe just describe further ideas for fixes or refactorings, that was cool.
The upside was it was really effective. I don't care if you wrote 2 books - I'm not hiring a tech author, I'm hiring a coder, write some code. Oh look, your code sucks - next.
As far as an interview itself, I don't go in for any of these tricky question nonsense (“how many manhole covers are there in Chicago”) - I'd rather present an open-ended design problem (“design a car pool app that not only tracks history, but decides who's turn it is to drive next.” - the possibilities for criteria for ‘who drives next’ can get interesting). How do you think through a problem**? How many different options do you explore or consider? Do you get stuck on too many options, or do you decide to push on through and chase down one direction so we don't get bogged down in possibilities?
**Which I know is the point of many of the ‘manhole’ type questions - but why can't we just present a realistic design problem instead of getting all wonky with it?
Also like to discuss some aspects of how they interact with people - tell me a time you had to push back on a business request that you felt was unreasonable or not a great idea, that sort of thing.
tags:
ComputersAndTechnology