How I Interview Developers

Somehow I have a reputation of being a really hard interviewer (okay there was that one time someone cried in an interview, but I think he was just having a rather bad day). But the one thing those who have sat in on me have said, there isn’t a single question I ask that you can study for. So for the very rare developer who actually googles my name before I interview them, this isn’t going to prepare you :)

I personally detest those interviews where you are kept being asked obscure piece of syntax upon syntax, until the interviewer finally stumps you. Anything you can Google in 5 seconds, shouldn’t be asked!

My main goal in saying yes is if I think they are someone who enjoys what they do and a “Smart person who gets shit done.” Then targeted for their role. E.g. A Developer needs to know how to write code. A javascript developer needs to understand what DOM is. A Senior Developer needs to know how train and lead Junior Developers, etc. Then the most important question, “Do I want to work with this person for 40 hours a week?”.

In short:

• Passion
• Problem Solving/Can they actually code?
• Can I work with them?

I conduct interviews in a behavioral style. That is past behavior is a prediction of future behavior. I never ask hypothetical questions. Every question I ask, I drill down to get a specific example of when that happened and how they did it. You know they are telling you the truth when they use the word “I”. If they use the word “we” a lot, it may not be them that did it, but a colleague. It’s easy enough with practice to work out what’s going on and what they actually did.

For a developer, no matter their level, this is my usual style of interviewing. Each question is a base, I ask a lot more questions from there:

• Introduction of who I am and what I do here
• Ask them to tell me about themselves
• Draw up your last project architecture on the whiteboard
• What was the last bug that you swore at?
• Tell me about a time you had a technical disagreement with someone — If they won the argument then I find out “Tell me about a time you lost a technical discussion with someone”
• Greatest technical achievement or best project
• Get them to write code (normally fizz buzz)
• Role Specific Questions
• Sell the Company (even if they have failed the interview). Explain projects, processes, etc
• Let them ask questions
• If I really like them, I walk them around, selling the Company to them as we go. If I really, really like them I even show them code.

5 minute introduction of who I am and what I do here & Ask them to tell me about themselves

Relaxes and starts flow of conversation. What they decide to tell you about themselves is not that important. But it will show one thing, what they care about the most with their job and what they want to do. Good developers enjoy being developers.

Draw up your last project architecture

Don’t care how junior they are. They should understand how their project works. At least the components they worked on. Very quickly this question tells you how senior they are.

The follow up questions I normally ask:

• What worked?
• What were the pain points?
• What would you change if you were in charge/do it again?

The pain points questions is a trick one. No architecture is perfect. Software Architecture is trading a bunch of business requirements against each. Plus sometimes things get hacked to get it out the door. It’s a fun chat to see if they know how software works.

Plus remember the point of needing to work with them? If they can’t explain something they’ve spent probably over a year working on, how are you going to have a chat with them about systems you are designing, building or maintaining?

For graduates I normally skip this question, as they haven’t worked on a big project yet.

What was the last bug that you swore at? Or the favourite bug you fixed?

This tells you almost all you need to know if they are a proper developer. Any developer has a bug in the last few weeks they swore at. Few things I look for here. Problem solving ability is the main one. Bad developers will say “I got stuck, so asked my senior”. A good developer likes to solve problems. The example they use is important, again it’s what they struggled with.

There are instances where I’ve hired developers who went to their senior developer. An example was where a developer was on a team which had a 2 hour rule. If you’re stuck after 2 hours you ask someone to help you. She ran through how she got to that point and what she learnt from working with the senior developer.

One brilliant answer. Described the bug. Found it was a problem in the Framework. Fixed the bug in the Opensource Framework, then submitted the bug fix into the Project so everyone else got the fix. (These developers are rarer than hens teeth).

Another brilliant answer would be the following:http://www.quora.com/Whats-the-hardest-bug-youve-debugged/answer/Dave-Baggett

Tell me about a time you had a technical disagreement with someone

Developers like to argue. They like to build stuff that works. This tells you 2 things, they are passionate about what they do and they will fight for it. Check that they can argue like adults and handle losing an argument. Or like in a former team mates case waiting 9 months until he won the argument.

Greatest technical achievement, best project you have created

The only time I code in my spare time is when I don’t code at work (which is pretty much all the time now). This tells you straight away if they are developers or not. Developers like to code.

This article sums this question up.

http://www.nicolasbize.com/blog/how-i-ended-up-conducting-the-most-successful-technical-interviews-with-a-single-question/

Get them to write code (normally fizz buzz)

80% of people I interview can’t write a bloody for loop with an if statement. But this is not all fizz buzz checks. It also tells me if I can give someone instructions and they can follow it out. I tend to give guidance and then let the team do the work, without me having to follow up. Smart people who get shit done! And any good developer can rattle this solution out in under 5 minutes.

Role Specific Questions

Just checking they can do whatever role they are coming in for (e.g. Javas, HTML/CSS, Senior)

Sell The Company

The industry is small. You will end up crossing paths with this person again. Maybe as a client. Project, processes and code normally leads into fun question and answers about how we work.

Let them ask questions

I don’t care if they don’t ask anything. It’s just giving them a chance to ask whatever they want.

Walk Around

I tend to only work at awesome companies. There is normally a buzz going on in the tech team with people working together. It’s also a check to see if they will enjoy working here.

Conclusion

That’s it. At least some of my tricks. My favourite feedback I get from interviewees is when they don’t think they were actually drilled down into any tech stuff and we were just having a casual chat. When you get interviewees to swear in an interview as well, it’s also a damn good sign they were that relaxed they completely dropped their guard (and nope, I never swear in interviews).

Last point. Interviewing is 20% science, 80% art. Most of the time you’ve got to go with instinct. And experience. It’s like management, a lot of it is learning as you go from your own experience.

Interviewing for contractors is pretty much the same, although I spend a bit more time asking a few more tech stack specific questions. My goal with a permie is “smart person who gets shit done”. I can learn a new language/framework/app server in a few weeks. I expect those I hire to be able to do the same, plus it’s easy enough to train up a proper developer.