[ ].blue

On Interviewing for Developer Culture

August 28, 2012


When a developer goes in for an interview, there are typically three perspectives from which they are interviewed:

  • Technical
  • Developer Culture
  • Employment Capability

Technical assessment is primarily for determining "can you do this job?" and is traditionally performed by the VP of Engineering, CTO, or hiring manager. Employee assessment is for determining the typical holding-down-a-job types of things and, as expected, usually done by HR. And then there's developer culture assessment, which more often than not results in a random developer being thrown in the room with the candidate to see if that candidate would "fit on the team".

That was me, two years ago. I started out not having a clue. If you're reading this, perhaps that's you too. However, each time I'd interview someone, I'd keep some questions the same and try out new ones. Over time I began to find a toolbox of questions and strategies for asking them which helped me better understand someone outside of if they know X fact about technology or Y new shiny framework.

The following is primarily intended as a guide for developers interviewing potential teammates for cultural fit.

On Interviewing Developers

One of the most important things to realize is that before ever going into the room to interview someone, you need to decide beforehand what you want to know. Remember, you're not focused on if this person is technically capable or if they show up for work on time. You're interested in if they would make a good addition to the team, from a culture standpoint.

Developer Dimensions

Probably one of the best ways to figure out what you want to know is to make a map of developer dimensions and determine which are the most important to your team. Here are some that I find valuable:

  • Self-awareness -- Do they seem to have a concept of being aware of what they are doing as they are doing it or are they just blindy repeating the one thing they know works? Self-awareness might show, for example, by a gradual refinement of tools, processes, or efficiency over time.

  • Adaptability -- Do they seem like the kind of person that could easily switch source control tools, languages, or editors and be able to cope with it? Technology is always changing -- how do they appear to deal with that?

  • Teachability (Inbound) -- Have they got an attitude of having everything figured out or could they take feedback or training from their peers?

  • Teachability (Outbound) -- Do they seem like the kind of person willing to help others and distribute information, either in an informal one-on-one situation or in a more formal presentation format?

  • Craftsmanship -- Do they care about what they are doing? Does it show?

  • Priorities -- Do they seem to share similar goals as the rest of the development team in terms of what defines a good product and how they know they've been successful as a developer?

Asking Questions

The challenge, of course, is to find ways to ask about the above without directly coming out and asking about them. Probably 75% or more of questions have an "obvious" answer; or at least an answer that the candidate thinks you want to hear. In my experience, the best questions are ones in which the answer is unique to the person being interviewed. The side bonus of asking questions for which this is true, is that at the end of the day your time spent interviewing candidates will be focused on what differentiates them, instead of getting all the same answer all day long.

The way questions are phrased is important. Here's an example. Let's say we wanted to determine the adaptability of a candidate and we specifically want to measure if they are interested in and following the trends within programming. Here are some questions we'd not want to ask:

BAD: Do you read blogs or follow people on twitter (of course they're going to say yes)

BAD: What do you do to keep up with the latest in programming? (of course they're going to say blogs/twitter)

BAD: What programming blogs do you regularly read (any fool with half a brain can rattle off a half dozen, doesn't mean they read them)

BETTER: What was a recent book or blog post about programming that when you read it you were impressed/stunned/excited about and what was it?

Questions like the above (better) actually allow an interviewer to map multiple dimensions, because it lets allows the interviewer to see how far on the "cutting edge" curve they are (if they talk about something new or something a year or two old), and it also lets us see what they're reading about which hints at either craftsmanship, adaptability, teachability, and priorities.

It's worth nothing that sometimes it's also necessary to do "set up" questions, ones in which you use their answer to ask a second question. The first question would be bad by itself, but it's main purpose is to be a stepping stone to where you're going. Having these is good because it also gives some "mental breathing room" to the candidate and letting them have that opportunity for an "easy question" I think makes them feel more confident as the interview proceeds.

Toolbox of Questions

I've been refining my question set for the past 2 years, and here are my "developer culture" questions. Some of these I've been asked in interviews before (thanks!), others are derivatives of questions I've been asked, and still others are questions that I came up with myself based on what I found successful. You're free to use any of these as you interview potential teammates.

  • Every developer who interviews here says they are a "Front/back end programmer who is passionate about writing robust/testable/amazing/high-quality software." Let's break down what this means for you.

  • Do you consider yourself specifically a front or back end programmer or an "OO programmer" or a "[technology X] programmer" and why?

  • "Passionate" can mean a lot of different things. What are some things in your experience thus far that you can point to and say "this is me being passionate about programming".

  • To you, what is high quality software? If you were to look at any program you could point to this and use it as an indicator if the software was high quality or not. What is that?

Depending on how in depth they go on the high-quality software question, this is a follow-up if needed:

  • Which is more important to you (and why): building the right thing or building the thing the right way?

  • How many people are on the team you currently work on?

  • What would you say your circle of influence or leadership on the team is? As in, how much have you contributed to shaping it's direction. (Primarily looking for examples here)

  • I'm assuming that for one reason or another you're not happy on that team. You don't need to tell me why. However, if the boss of the company came to you and said, "We're going to double your salary and your new job is to turn this team around and making it running at 110%". How many of those people would you keep? Don't mention names, just a number.

  • What would be the criteria that you'd use to determine who you kept and who you replaced?

  • What about for the positions you'd replace. How would you determine who the right replacements would be?

  • Let's go back farther. How did you get started in programming?

  • Why have you stuck with it to this point?

  • Let's go back even father. Programming is a relatively new thing in the scope of human history. If you were born in the 17th, 18th or 19th century, what career/job do you think you would have been doing instead?

  • Have you ever thought about starting your own company where you were the lead programmer on whatever product was that company was selling? You don't need to tell me what the company would be selling. I'm only interested in your thoughts about it.

  • Why have or haven't you attempted this yet? Why do you what to work for us instead?

  • Have you ever thought about creating your own programming language? Tell me about what made it unique.

  • How comfortable are you with changing technologies frequently? If you were to be hired, and we were to tell you, we're going to start writing all of our javascript in Kotlin instead, then compiling it to JS as a build step; Or perhaps we might drop git and instead use bazaar. What would be your thoughts on that (I'm not saying we are, I'm just interested in your thoughts about it)?

  • Have you had this happen to you in the past? What did you do to learn that new technology, and how long did it take?

  • If we were to hire you, and say on your first day, "OK, pick one new technology and we're going to have you be the expert on this!", what would that technology be and how would you feel about that?

Wrapping Up

Remember that, at the end of the day your purpose in interviewing for developer culture isn't to pelt the candidate with questions to seem tough -- it's to give them a chance to showcase themselves. Many people are talented but in asking the typical questions that talent won't come out on it's own. Try out some of the questions above, especially the ones which seem silly at first, and you'll see that often times these questions allow people to bring out what's unique about them and hopefully you'll feel like you got to know them better as a result.

And above all, continue to refine what questions you ask, keeping the ones which help you understand people the most, and dropping those which don't.