Hiring software developers is a difficult endeavor. Good developers are hard to source and they’re hard to interview. I have zero advice on the former, but plenty of experience with the latter.
When I first started interviewing developers, I had no idea where to start. The only advice I received was “Try to determine if you would like to work with the person.” How do I find out if I would like to work with someone after an hour or two? The easiest thing to do was to copy what was done whenever I was interviewed: make the candidate implement some tricky algorithms on a whiteboard.
I did this for about a year or two and eventually interviewed a candidate that created a better solution than anyone else on the team, including myself, had come up with. Clearly a great hire, right? If he could make a better solution than us, then he would be able to teach us plenty of stuff and help us become better developers.
Things didn’t quite turn out that way. This developer was definitely very smart, but he had the wrong skill set for what we were doing. His ability to do computer science was well beyond ours, but most of our work wasn’t computer science. Most of our work was database design, software architecture, managing distributed systems, making sure we had adequate logging for debugging customer issues, etc. This guy was great at complex algorithms, but wasn’t so great at any of the things we actually needed him to do.
Apparently, the most important skill set is the one you actually use. Go figure.
I’ve found that the best way to test the actual skill set needed for the job is to take something that already exists in the product and ask a candidate to implement it. It’s convenient because you don’t need to create content for the question, it already exists. You don’t need to learn the solution for a new problem in order to ask it in an interview, you already are an expert on the problem. Most importantly, if someone can adequately build something they would have been asked to build had they had the job in the past, then they can probably do the job in the future.
The hard part is narrowing down the question. If you spent 2 weeks, or even 2 days building something, you can’t reasonably expect someone to build it in a 2 hour interview.
But while 2 hours isn’t enough time for a candidate to build out a complex system, it is more than enough time to create a spec of the system with the interviewer. What are the major things the system needs to do? What are the main components? How do they interact? How do we prevent failure? How do we recover from failure?
These are all things a development team would discuss normally before they started writing code. Having the same discussion with a candidate is a fairly accurate representation of what working with them in this setting would actually be like. I ask myself “Would the project have been easier if we had this person with us at the time we had to build it?” If the answer is yes, then the answer to “should we hire this person?” is also probably yes.
I’ve always thrown some coding questions in this interview, but that’s only because it seemed like the thing to do. Who hires a developer without asking them to code?
I’m no longer convinced that it’s necessary. The nice thing about having a candidate design a system I have already built is that I know all the details about it. If I feel the candidate is being vague with an answer, I can ask questions and get them to clarify about those details.
I haven’t yet met anyone who could answer complex technical questions well who hasn’t had experience building a similar type of system. If they can answer those questions well, then they have most likely built a complex system before. If they also have good answers to preventing and handling failures, then they have probably built that system well (or know how to build it well given another chance). That’s probably a better indicator that they can write code in real situations than asking them to write out some algorithm on a whiteboard on the spot.
Top comments (0)