This post part of a series I'm writing on better technical interviews. I'd love your feedback in the comments!

I have a certain approach to technical interviews that I’ve cultivated over the years. It’s a sensitive subject, so I’m attempting to write that approach down here, both to get feedback and to see if it resonates.

About This Series

Why I’m Writing This Series

I’m often frustrated by the conversation I see around technical interviews. The suggested approaches I’ve seen – coding competitions, white-board coding, rapid fire panel interviews, brain teasers – don’t seem to foster the kind of environment that I think makes for a highly functioning team.
I see a lot of discussion around interviews that either argues against these points, or touches on some of them in isolation. It seems that folks might benefit from seeing thoughts on the whole process in one place.
I firmly believe that the interview process makes or breaks the success of any company in the long term.

Quick Note: This is going to be a series with a lot of edits.

I have continuously found myself saying “oooh, one more thing!” while I’ve written this series. I’m looking forward to editing it based on feedback, and to expanding on certain points. This series probably won’t stay static.

What are my Qualifications?

I’ve served as a technical leader in several contexts and organizations. I’m a trainer and facilitator, and people generally don’t seem to speak too much ill of me – that I’m aware of. :)

Which is to say…not a whole lot of qualifications by the book I guess. I encourage you to look at the following ideas in terms of whether they work for you in your current context, and not to think I’m attempting to say these are the only way to have a successful technical interview. This is a heuristic approach, not something that claims to be the only way forward.

I’ve gotten very positive feedback from multiple interviewees on the interviews I’ve conducted – both those that we’ve moved forward with and those that we haven’t. Also, I feel like I’ve hired some really great people who’ve gone on to do great things as colleagues. So that’s the experience I’m working with.

What are the goals of a technical interview?

Let’s jump in, because the stakes are high!

If a technical interview goes well, you’ll have a new teammate and/or colleague who can contribute to both your code and your team/org culture.

I would argue that an additional goal of a technical interview is to ensure that the team doesn’t move backwards in any significant way. By this, I mean that if you don’t optimize for the whole experience of your team, you could wind up with someone who improves your codebase but at the cost of demoralizing your whole team. If a technical interview goes poorly, you could accidentally introduce toxic elements that stifle your teams and the important work they’re doing.

So for me, the point of a technical interview is to 1) add a great new colleague to a technical team and 2) avoid adding a colleague that would stifle my eisting colleagues.

Overall Approach to Interviewing

You should be rooting for the interviewee. You should want them to succeed. There is no point to running your interview process like a gauntlet that someone has to get through. That’s just hazing. You should believe that this person has the potential to add something to your team. If you don’t, don’t schedule the interview, or figure out a less costly way to determine that.
You are showcasing your company’s values. You should be introducing them to your org’s culture by living it. You want to make sure the employee thinks they’ll have a great environment. What better way to do that than to…give them a great environment from the interview onward!
You should be having a conversation. The process is allowed to be human, it’s allowed to be a space for connection, and it’s allowed to feel natural. There’s no reason it has to feel like a pop quiz or an inquisition. Aim to have a conversation with folks you interview. We’ll discuss how to balance this conversational technique with the need to obtain the important information about a candidate.

Thinking Before You Begin

I find this to be an important step no matter who you are in the interview process, and one that has made the difference for me between interviews I felt I did well and ones I didn’t.

Think: what kind of person are you looking for?

I think this often informs the process incorrectly so many times because companies think they’re looking for a certain type of person. This not only comes with its own bias which is an issue, but it also sets up the interview process to unsuccessfully weed out good candidates.

“We’re looking for someone who can code.”

Is that all? My guess is you’re looking for someone who can learn, adapt, communicate with stakeholders.

“We need someone to be productive.”

You probably also need someone to be collaborative, and to be productive long-term, which is different than banging away at a keyboard for many hours a day.

“We need someone proficient in specific technology x.”

I would argue that this trips up companies so much of the time. Look for someone who has a handle on x technology or something related to it. Don’t be the company that expects 5 years of experience in a framework that is 4 years old. Factor in a learning culture to whoever you bring on. (and if you don’t have that, maybe fix that before hiring a bunch of folks.)

“We need someone to fit our culture.”

Record-scratch noise. This is where a lot of bias creeps in. You want someone to add to your culture; you don’t want someone to only conform to it.

Think: Where do you want your team to go next?

I think this is an important conversation to have – at least with yourself – prior to conducting an interview. What does the team or org need? In what ways does it need to evolve? This helps you understand the context you’re operating the interview in.

Conversational Interviewing

Another piece of my overall recommended approach to interviewing is to make a shift to, or invest more heavily in, conversational interviewing. What I mean by this is the art of engaging with someone in a way that isn’t rigily defined (e.g. solving problems on a white board, coding a problem, etc.) and instead delving into the nebulous world of conversational interviewing, with open-ended questions, follow-up, and the time well-managed. We’ll talk more about this in future posts and I’ll make specific recommendations.

Are you ready to interview this way? Is your team ready?

Adopting an interview style along these lines assumes some things about your team:

They are open to giving and receiving feedback, and to mentoring/coaching. If they aren’t open to giving each other feedback, it will be harder for someone to adapt, and therefore you may need to be a bit more rigid in your interviewing. If you have this problem, I suggest working on that before seeking to hire someone new.
You’re not looking for someone to lead an overall practice. In this case, you may need someone with truly verified technical abilities and I’d recommend extending the interview to a more involved process that includes some hands-on collaboration with folks.

Interviewing Well is a Commitment

The suggestions I’m going to make in this series take time. Most of it is about preparation, research, and up-front thought. When executed well, it’s more like a carefully choreographed improv show. (hopefully not a comedy!)

Let’s Do This!

Okay, dear reader – buckle up! We’re headed toward a better interview process.

Better Technical Interviews: Part 1 – What’s the point?