I've interviewed a few dozen developers in the course of my career and I've finally settled on a few questions that I'm almost certain I'll ask. If I'm going to interview you, consider this a study guide. If you're going to interview someone else, feel free to use the questions as you see fit. If you're going to interview with someone else, you might prep answers to these questions and find a way to slip them in even if the questions aren't asked.
1. Have you ever seen software written well?
I've come to believe that it's difficult to write software well unless you've seen it done well. But be forewarned, this is not a question you can simply answer "yes" to, even though some candidates have tried to do as such. If you tell me "yes", and leave it at that, the follow up will be "What did that look like? What made you feel it was done well?", or any number of variants See, I'm not just looking to find out if you've seen software written well, I'm looking for a sign that you noticed what made it good. People who have noticed good things will also notice the absence of good things. The first time I test drove this question I had a candidate named Khurram whose eyes absolutely lit up as he said, "Oh yes! I was on a project where . . ." and he went on for 5 or 10 minutes about all of the things he'd seen and why they were great and how they helped later. It was an interviewer's dream come true and cemented this as a permanent question on the list.
2. Have you ever been on a bad project?
Once again, you can try to answer "yes", but I'll ask very similar follow up questions: "What were the symptoms? What were the causes? When did you know that things were going South?" and one of my favorites: "What did you do about it?" Chances are you've been on a bad project, but did you pay attention to what was going on around you, or did you mindlessly write code and close tickets? People who have noticed what causes projects to fail are more valuable than those who haven't because they'll recognize the signs of a project that's going in the wrong direction. Even more valuable is having built up a collection of countermeasures, but if you have those then you probably won't be interviewing very often because there'll be a list of people who are trying to hire you.
3. Have you used branches in version control?
I'll admit that I'm a little . . . um . . . hyper-focused on branching and version control. But here's the thing: I can tell so much about where you've worked and how you've worked from this one question. If you say that you have used branches, I'll ask you about your branching strategy and start to learn about how you work by seeing what you protect yourself against. NOTE: Never, ever, try to fake having branched. There are all kinds of problems that are both solved and caused by branching and if you try to fake it, you'll get caught quickly. If you haven't worked in a group that uses branches, then I instantly know that you've never seen a good build process either. I'll know that you either haven't worked on parallel features/fixes or haven't done it safely. Another note: when I get on my branching soap box, it is a prime opportunity to talk about process, but a surprisingly bad time to talk about technology. I'm trying to open the door for you to discuss things being done quickly, safely, and thoughtfully. If you take this opportunity and use it to talk about the latest distributed version control system and how cool it is, you'll hear that door slam closed very quickly.
That's it. Those are the 3 questions I ask in every interview now. Notice that there are no right or wrong answers. There is literally no honest answer that you can give that would cause me to not hire you, although I will use the answers to qualify your experience level. Junior developers can answer "no" to all of the above and still get hired because this may be their first or second gig. Mids need to answer "yes" to at least one, but preferably two of the above. If you call yourself "senior" and can't answer "yes" to all of the above (and preferably have multiple examples) then you're kidding yourself. I don't mind that you're not senior, but I mind a lot that you're kidding yourself. Also note that there are no technical questions on the list. This is for 2 reasons: Technology changes often enough and is specific enough to the project that it doesn't make sense to me to have permanent tech questions. Secondly, and probably most importantly, I tend to work with programmers that are better than me and they usually have the tech portion of the interview covered really well.
As a final thought, keep in mind what an interview is. An interview is a chance to make people want to give you the opportunity to work with them. No one is really going to know what it's like to work with you until you're in the trenches together for a couple of weeks. If you go into an interview with a story to tell and make life easy on the interviewer by answering their questions in long form, with some examples, then they're going to like you. You will give the impression of someone who takes initiative and shares the workload. On the other hand, if information has to be dragged out of you or your answers are unclear then you're going to give the impression of someone who has to be spoon fed tasks and even then not necessarily deliver.
Feel free to add your own favorite interview questions (or the worst ones you've heard) in the comments!
Comments