Better Technical Interviews: Part 4 – My Opinions on Various Techniques

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

• Part 1 - What’s the Point?
• Part 2 - Preparation
• Part 3 - The Actual Interview
• Part 4 - My Opinion on Various Techniques
• Part 5 - Common Interview Questions

My Opinions on Certain Interview Practices

These are my personal opinions with some reasoning behind them.

Should candidates code during the interview?

I say: No. If I am able, through conversation, to determine that this person has the fundamentals both conceptually and in terms of being a colleague, and is an open-minded, collaborative person that wants to improve, I usually don’t need to watch them code. Everyone has different styles, and I expect us all to be learning together anyway.

To whiteboard or not to whiteboard?

I believe white-boarding for conceptual / architectural explanations is a helpful tool. It helps me see how a person uses that space to see and explain things, like how they would potentially approach a problem. I have not found that I get much out of code in whiteboard format. It will at best be pseudo-code, and to expect more than that is unfair in my opinion.

Should I push the interviewees buttons to see how they respond?

Absolutely not. Would you do this to them in the real world? I should certainly hope not. If a client or coworker were to do this in some situation and someone handled it poorly, hopefully you’d be mentoring and coaching someone on how to improve, and also advocating for them in an instance where someone was treating them poorly.

We’ll be doing coding; should they use Google?

If you ask someone to code, I’d suggest that you should treat it like you’re pairing with a teammate.

• It should be collaborative
• Tooling and resources should be available
• They should be able to use the machine / development environment of their choice

Otherwise, what’s the point? Pretending that devs don’t use tools or Google things just shows an interviewee that the exercise is pointless.

What about having the candidate solve FizzBuzz?

If you’re bringing someone into a technical interview and don’t know whether or not they’d pass a problem like FizzBuzz, I think that’s the real problem.

Shift that process to the left and answer those questions earlier on. Ask a few screening questions. Run a small coding exam with something like http://coderpad.io, but don’t make it something so overdone. Put a little thought in. Be creative and clear.

We came up with a pretty intricate problem we’re proud of. We think it’ll be a good litmus test.

Great. You should ask everyone on your team – particularly less senior developers – to complete that problem. And then you should adjust that problem based on what you will inevitably learn. And then you should think about how cloudy someone’s brain is when they feel under pressure.

Should I have someone balance a B-tree, do factorial calculations, etc.?

Only if someone on your team has had to do something similar to that in the past year.

Otherwise you’re optimizing for the wrong-thing. I don’t need an algorithm wiz to write a great line-of-business app; I need someone who cares about a domain, collaborates with stakeholders, and is invested in improving as they go.

If you ask how someone would implement a fast-sorting algorithm and their answer is “first, I’d understand what we’re trying to optimize for, and then I’d open Google and research about different types of sorting algorithms” – I’d say that’s a solid answer.

Should We use HackerRank, etc.?

No. At least not unless you’re utilizing the pairing functionality.

• These tools feed into the idea that if someone can solve a coding problem, they’ll be a good fit for a team.
• These tools risk dropping some senior folks from the funnel who avoid the sort of algorithmic minutiae that this article recommends against.
• In my opinion, broadly speaking, these tools are reductive and commoditize the skillset you’re looking for and the notion of the work we do.

I can’t really tell so much from conversation as what you’re expecting. Is that a problem?

I’d say yes. If you can’t have a conversation and determine whether this is the sort of person who will make the impact you need at your team / company, I would argue that you may not be the best person to give the interview.

What about half-day / whole day interviews?

My opinion:

• If you’re scheduling a long interview because everyone needs to take a turn with an interviewee, I would argue that your interview process may be broken. Figure out who are the people to trust, and make the interview with them. At my current company we’ve had fantastic success with a 1-1.5 hour interview with two folks from a practice area, and a 30 minute conversation with one of our executives.
• If you bring someone in for a half day technical interview, it should be to work on a real style problem in a pairing or team setting, as close to an actual work day setup as possible. They should have access to tools, google, OSS, etc. during the process.
• If you’re having someone join an actual team for a half or full day session to work on actual client or product work, you need to compensate them for their time. Agree on an hourly rate that shows someone you respect their time and effort. Pay them for their time even if the interview ends early. Are you worried they’ll only last an hour? Do more prep and screening work up front.