Just posted a new article on my blog: What if your interview coding challenge would be completely different? This is a (very) shortened version to get other developer's opinion on this.
Instead of the boring FizzBuzz, the annoying whiteboard, the mental dry-runs of code from a paper page, and all the other coding challenges we all so love to hate - what if we had something like this instead?
A coding challenge that is comprised of a few small parts, each designed to give the interviewer insight of a different aspect of the capabilities of the candidate.
These mini challenges should be as close as possible to your development team member’s day-to-day job, and combined, should take no longer than what you would normally expect the coding challenge part of the interview:
- Reading a small codebase
- Simple debugging
- Actual problem solving
- Finding and fixing logical problems in a codebase
- Simple code design
- Handle specification changes
So, what say you?
Top comments (5)
I'd like that. It'd give me more input about what would wait for me and the potential employer input, how I would perform with the existing code base. Even if there are only parts of it there and it will surely be artificial, I think this will benefit both.
You could also add having team members ready to be asked questions or bounce ideas back and forth. So you could also evaluate the team spirit and or chemistry between the new one and the existing team.
I actually had my last interview with the team present and we were mostly talking to each other instead of questions from an interviewer. That was 4 years ago, when I was joining the team as an external consultant. Two years later I became part of the team.
Having the dev team in the interview is a great idea, and I have to say I thought about it when writing this post, but then I though to myself that from the employer's point of view, the entire team shouldn't "waist" their time on interviews. However, the way you describe it makes me thing that this would give the employer a much better picture of the candidate than any one-on-one interview - and will give the candidate a good understanding on what it would be like working for that employer. Would you mind if I quote you on that in my blog?
You would not need the whole team, especially when it is a big one. Take a few, the new one will be most likely to work with, but then the whole sub team or at least 3-5 people from it. Some with experience in your code examples, to answer questions .... and if they are not the same, some that are "representative" for the team.
And yes, you may quote me... and you may also put my name on it, as well.
It is already on the internet with my name attached :)
Thanks for your input!