How I Interview Developers

Posted on

I'd like to talk about interviewing.

I know what you're thinking:

Another blog post about hiring developers? Don't we have enough of those already?

We probably do, but I've spent a lot of time on both sides of the interview table lately and I get asked about interviewing often enough that I thought I should try to consolidate some of my thoughts and share them here.

Disclaimer: This post only reflects my personal approach to interviewing and does not necessarily reflect the thoughts of any past, present, or future employers.

Why Might You Consider Listening to Me?

If you don't know me (thanks for reading this, internet stranger!), you're probably also wondering why I think I'm qualified to talk about this subject.

Note: If you don't care about any of that and just want to see what questions I ask, you can skip to My Interview Questions.

I have interviewed well over a thousand developers for front end and full stack positions in my last few roles - one role in particular involved over 500 interviews over the course of a year for positions across various front end teams and physical locations - 60 of those were in a single week during a "hiring blitz."

As much time as I've spent interviewing candidates, I've spent even more time reading about interviews; talking about interviews with other developers, recruiters, managers (pretty much anyone who will talk with me about them); and refining my approach. Several of my employers have also had extensive interview training related to behavioral interviewing and inclusive interviewing, though I am by no means an expert in either.

At this point in my career, I feel confident saying that I am a good interviewer. Candidates seem to have a good experience - so much so that I've even received thank you messages from candidates that we didn't end up hiring.

Here's an actual message I received from a candidate we did not hire after an interview in 2018:

Hey! Thanks for the swell interview experience the other day! :)

I share all of this with you not to inflate my own ego, but to hopefully establish some credibility with you and show you that I've been putting in the work when it comes to interviews.

If you still aren't sure about me, that's cool - I get it. I have provided some links to great posts from lots of other people you might want to listen to instead in Further Reading.

Disclaimer: I do have to confess that I wasn't always a good interviewer. In fact, I started out as a pretty bad one who fumbled through dozens of interviews before starting to understand there was a problem and wanting to fix it. If you're one of those unlucky candidates I interviewed early on, I'm sorry - hit me up if you ever want help preparing for another interview, a resume review, or just to tell me how bad I was at it. If I have interviewed you recently and you want to refute my assertions that I'm a good interviewer, feel encouraged to reach out - I genuinely want to hear from you.

The Interview

I prefer to schedule one hour if the candidate has that much time free, but this same interview can be performed in 45ish minutes with some practice on knowing how long you can let a candidate take to answer and how long you can take to respond to questions, but you may have to cut out a few things.

This can also be condensed to 30ish minutes once you've got a really good feel for the timing of everything, but it leaves significantly less time for conversation and for the interviewee to ask questions, and ultimately provides a less optimal experience for everyone involved. Shorter interview windows generally leave the candidate with less time to ask their own questions. I always prefer to schedule a longer interview and end early if we're both out of questions than to schedule a short one and end with either of us having unanswered questions.

While this isn't necessarily always the order or the exact wording of the questions I ask, what I'm outlining below is pretty close to the interview experience that every developer should have with me.

Some roles or candidates involve digging into other topics a little more deeply or a candidate's answer may provide an interesting segue to learn more about them or may answer another question I was going to ask, etc. This means things change in small ways here and there, but the goal is to give everyone a similar experience that helps enable them to feel comfortable and present the best version of themselves. Interviews are already stressful situations (even for experienced interviewees) so there's no need to push anyone towards a panic attack.

Aside: I did actually have a candidate start to have a mild panic attack once - it was during that "hiring blitz" I mentioned earlier. It all turned out okay, but it really solidified for me just how stressful these things can be.

While you can't always avoid it, I try not to take too many notes during the discussion. Just some high-level bits and then I flesh them out after. You really want to engage with the candidate as another human being and that requires listening and actively participating in the conversation. If something feels really important and you want to make sure you capture it, ask the candidate if they are okay pausing for a few seconds so you can write it down correctly and then get back to the conversation.

My Interview Questions

I break a basic interview into roughly 6 parts:

  1. Introduction (1-2 minutes): set expectations

    • Make sure it's still a good time and the candidate is free for the scheduled duration. You should also find out if they have a hard stop at the end and let them know if you do - sometimes interview discussions go out of the original timebox and that's okay if it's a good conversation and interviewer and interviewee are equally engaged.
    • Basic introduction: just your name, role, and how long you've been with the company; anything more is wasting time - the candidate can ask if they are curious.
    • This will be a conversational interview; questions, follow-up questions, and back and forth discussion are all encouraged - due to time constraints, we may need to move on from a topic, but we can circle back or follow up in email.
    • There are no right or wrong answers.
    • There will be time for their questions near the halfway point and again at the end.
    • Don't hesitate to ask for clarification or more explanation.
    • Protip: Let them know upfront if you might have to mute a bunch because your dog somehow knows when you're interviewing and sometimes decides to be as annoying as possible during interviews

  2. Interviewer Questions Round 1 (15-30 minutes): This section has some easy getting started questions and then some specific behavioral interview questions.

    1. Tell me briefly about a project you've been working on in the last 6-12 months. What tech stack have you been using?

      • There's no need to get into everything a candidate has done throughout their career - you've seen their resume and/or LinkedIn, right? - just get into what they've been doing lately as that's generally the most relevant.
      • Protip: You may need to stop the candidate if they go too long on this one; about 5 minutes should be the upper bound, but 2-3 minutes is ideal.

    2. What kind of role are you looking for? Are there any other experiences you'd like to highlight that you think would make you successful in that role?

      • This gives them a chance to describe what they are looking to do in their next role and also gives you a deeper dive into any other experience they have that might be relevant.

    3. What technologies are you looking to work with? Are there any you would specifically like to avoid working?

      • Avoiding some tech is totally okay. Sometimes a specific language, framework, etc. just isn't our thing. I avoid Java and Ember because I just don't really like or fully grok them.

    4. Tell me about a project where you feel like you really succeeded. What about your contribution to that project made it so successful?

      • Let them tell you about that time they totally crushed it. This is a chance to ask more questions and dig deeper into what they did, how they did it, and what they feel they are bringing to the table.

    5. Tell me about a project where you feel like you failed. What happened? What, if anything, would you do differently now?

      • Everyone has struggled on a project at some point. It's okay to fail as long as you learn something from it. (Ask me how I know you always need to back up the production database.) This is a chance for the candidate to be a little vulnerable, show how they take (or shift) responsibility, and how they've learned from past mistakes.
      • Some people won't feel comfortable talking about failure, so if someone gives you a non-commital answer you may need to probe deeper for an actual real-world example. Be sure to let them know that failure is a thing that happens to all of us and they don't have to incriminate themselves for taking down us-east-1, but we want to hear about a situation where they learned from a mistake.

    6. Tell me about a conflict you had with a coworker, stakeholder, customer, etc. What happened? How did you resolve it? In hindsight, would you approach it differently?

      • How do they approach conflicts? What do they do when they can't come to an agreement? No one wants conflict at work, but there are lots of times that we might disagree about how to approach solving some problem, how some business request degrades user experience, or how some user request is not possible given our current resources.
      • Protip: This could be a good time to reflect on how your current team approaches conflict and maybe briefly discuss it with the candidate in relation to their answer.

  3. Candidate Questions Round 1 (5-10 minutes): This is a good time to shift gears and let the candidate ask some questions - remember this is as much a chance for them to interview the company as it is for the company to interview them.

    • Engage as openly and honestly with the candidate as you can. Try not to ramble and to answer questions concisely. After you've done a lot of interviews, you'll start to refine the answers to certain questions and find that you've got certain responses ready.
    • Protip: To avoid rambling, sometimes I start a stopwatch and glance at it every so often while answering a question so I know how long I've been talking. Remember, this is the candidate's time to learn about the company, and the longer you spend answering one question the less time they have to ask other questions.

  4. Interviewer Questions Round 2 (10-15 minutes): This section gets into some more technical interview questions and also allows you a chance to dig deeper into any follow-up questions you want to ask based on anything that's been talked about so far.

    1. Tell me about an interesting or particularly challenging problem you solved in the last 3-6 months. What made this problem interesting? How did you approach solving it?

      • This gives the candidate another chance to show off their skillset and talk about it passionately. You can probe deeper into any specifics around this and just sort of talk about it with them a bit.

    2. Tell me about a tradeoff you had to make in the last 6-12 months. What were the options? How did you choose between them?

      • A lot of what we do involves managing tradeoffs: performance vs readability, faster delivery vs future maintainability, abstraction vs repetition, etc. This is a chance to dig into how the candidate thinks about these things and how they navigate the often nebulous waters around this kind of decision-making.

    3. Follow-Up Questions: if you have anything you want to expand on based on your conversation with the candidate so far, this is the time for that. Want to hear more about how they used AWS for a project? Did they mention navigating a rewrite at a large company and you want to hear more about the planning and execution? Dig in a little.

    4. For Senior-ish Roles: Pretend that I'm a junior developer without much context and explain [insert topic here] to me.

    5. For Junior-ish Roles: What language, library, framework, etc. are you looking forward to learning and working with in the near future? What tech is exciting to you right now?

  5. Candidate Questions Round 2 (remaining time minus 30 seconds to a minute)

  6. Wrap Up (30 seconds-1 minute)

    1. Inform the candidate of the process from here and about how long they should expect to wait before hearing back. I also always let them know that if there is a bottleneck in the process, it is almost certainly my fault and not the fault of our internal recruiters.
    2. Let them know that they can email you (or their recruiting contact) if they think of any more questions.
    3. Thank them for their time.
    4. Protip: Take a few minutes after the interview to compile your initial thoughts and shoot them over to your recruiting partner. If you need to think on it a little more, save that email as a Draft and set a reminder for a couple of hours - hiring is crazy right now, if you wait too long, you could easily lose that candidate.

Why This Approach

There are several benefits to this approach:

  • Human-Centered: It treats candidates as humans, and as equal participants in a conversation.
  • Hard to Game: There isn't really any coaching that can prepare someone for this interview. I've worked with a lot of recruiters and consulting firms over the years and sharing knowledge about interview questions always comes up when you're the interviewee. With these questions, you could do something like publish them on the Internet for everyone to see, and it would have no effect on the efficacy of the interview.
  • Enjoyable: I might be personally biased on this one, but as the interviewer, I enjoy this kind of conversation a lot more than pop quiz style interviews I've been asked to conduct in the past. As I mentioned already, candidates seem to enjoy this interview process, too.

There are some possible drawbacks, too:

  • Time-Consuming: If you are in a high-throughput recruiting situation (at one point I was reviewing 30-40 resumes a day for dozens of open positions), you won't have the time to engage with each person at this level and might need to introduce something that creates a quicker filter before this kind of interview. You might also want to work on improving the quality of your filter at the application stage, resume review stage, and any initial recruiter call that might happen after a resume has been reviewed.
  • Not Directly Technical: You only learn as much about a candidate's technical ability as you are comfortable digging into during the discussion. Some people will maintain that you need to put a candidate through some kind of whiteboard question where they are put on the spot to write code in a context that is entirely unlike their normal work, and they could be right.

Further Reading

Here are some articles about interviewing that I've found insightful and some that have challenged my beliefs about interviewing, too.