Land the Tech Job You Love turned out to be a good read full of actionable advice for job seekers who just happen to be techies. It covers everything from creating three versions of your resume to preparing a portfolio of work products to take with you to the interview. All of this is good advice.
The hidden gem in the book is the great guidelines for technical managers on how to conduct the recruiting process:
“A hiring manager who wants to get a real feel for her candidates’ skills will ask for examples of work. When I was hiring programmers, I told every candidate that I called in for a face-to-face interview to bring in code samples, printed on paper, so that we could discuss them during the interview. Unfortunately I was definitely in the minority. Ilya Talman, on o the top technical recruiters in Chicago, to me that he estimates only 15% of hiring managers ask to see samples of work.”
For developers bringing in their code and going over it gives you a much deeper feel for a person’s development skills than any single behavioral question.
Code samples give you a sense of how the developer looks and how important code hygiene is to them. You can ask about decisions as to why they didn’t refactor a longer method or why they named a class a particular way. In many technical interviews you’re never asked to go through code at all.
If you’re not already requiring code samples for prospective developers I’d suggest trying it out at the next opportunity. You’ll be surprised at the insights.
Thanks for the kind comments.
I’ve given my talk “Effective Job Interviewing From Both Sides Of The Desk” twice now, and the idea of code samples turns out to be one that seems to go against standard practice more than anything. The difference between seeing a body of completed work and a sample function created on the spot is huge.
You say “You can ask about decisions as to why they didn’t refactor a longer method or why they named a class a particular way,” and that’s exactly the right idea. That’s why code samples need to be printed on paper, so that you can work across a desk, instead of hunched over a screen.
Another favorite topic of mine when going over code is commenting style. Why is this commented but this isn’t? When do you write your comments: Before, during or after coding? And so on.
I’ve actually had candidates bring in bodies of code from their projects, mostly on laptops. That way you can see a larger swath of their code, but I think it gets at the same idea. Comments are another good idea, and I often focus on how they tested the code and the unit test code itself. If the unit tests are solid and readable I tend to get better confidence that they take their craftsmanship seriously.
I agree that I’m not clear on why this isn’t more common. In my own interviewing experience I’ve only been asked to write code on a whiteboard one time and never been asked to write code or bring code to the interview. Hopefully this will become more of a common experience in the future.
Hi Ed,
Worthwhile advice indeed. We’ve been trialling the use of a pair programming exercise for the first of our interview stages and we’ve had some great feedback both from the candidates, the agencies involved and the people within the team who are conducting the interview. As a hiring manager, I can’t recommend it enough.
Dan
How does this interview technique deal with the fact that most development work is a collective effort and that any sample of code that is brought is the result of a context.
Further it would seem to doom people who were unfortunate enough to work on awful legacy code bases or in obstructive environments.
In addition there are practical obstacles. For my part most of the code I wrote can not be disclosed outside the company it was written at, let alone to a competitor’s representative.
How do you avoid those obstacles ? How is it, in your opinion, superior to a pairing session with a team member ?
Next time I’m in the position to bring in candidates that’s probably something I’ll try out as it gives you a bit more insight. I’m surprised about how rarely I hear of people doing this.
On the coding bit, generally most people have some code they’ve worked on that they can share even if it was hobby stuff they did on the side. Legacy code isn’t such an issue, because you can get a real sense of how they actually deal with legacy code which is crucial in so many shops. I don’t know if it’s superior to a pairing session, I think it often touches on different elements such as how a developer explains there work and code on a larger effort. The pairing effort shows their detailed thinking on a very small problem. I think if you have the time to spend it might be worthwhile to do some of both.