coding in the rain

By Andrew Carter

State of the Technical Interview

I’ve been spending a huge amount of time and energy lately on the interview process. My team has way more work than people. We are definitely resource constrained. We need developers. The problem is how do we fill those positions?

I’ve done a lot of interviews over the years - both as interviewer and interviewee. I think I’ve seen both good and bad. Unfortunately, I think the technical interview process is broken.

What’s Broken

Over the years, a playbook has emerged on how to do technical interviews. I think the big companies have led the way. Everyone seems to use it despite their size. It’s a factory approach that is highly impersonal and results in an unpleasant experience overall for both candidate and interviewer. No one likes the process.


Everyone seems to have a screening process. Typically, companies use dedicated recruiting staff to filter candidates. The worst of them use tools like LinkedIn to do nothing more than keyword searches. You see this all the time. I’ve been doing development for 15 years and I still get targeted with job descriptions for positions requiring “1 to 5 years experience”. It seems that there is no real analysis of the candidate’s history. Clearly I’m not going to be interested in a job that is a junior position. I’d probably be overqualified and be unsatisfied.

The other problem is total disregard for the candidate’s history. If I have done my entire career in Seattle, what are the odds that I’m interested in moving to Virginia or New Jersey? Likely very low. Also, I’d clearly be a much more expensive hire since you would have to move me (and probably a family) across the country. On the other hand, if I moved from Seattle to Chicago to New York to Los Angeles over the course of ten years, I’d be far more likely to consider a job in Texas.

The next problem is that the recruiter is often not qualified to adequately screen the candidate. If the recruiter can not intelligently discuss technical specifics or even understand the actual job, how can they accurately assess a candidate? The result here is that recruiters do not filter out candidates for fear of missing the right person.


I detest the current standard developer whiteboard session. It is nothing more than a brutal interrogation. No one writes code on the whiteboard. No one writes code without having their favorite editor or their web browser to look things up. No one (should) code alone. Yet all of this happens in the whiteboard interview.

Ignoring Previous Work

I’ve been the victim of this many times. This is the case where despite years of experience writing code in a language and shipping products, the candidate is put through coding trivia on the whiteboard. The better approach is to determine how accurate the resume entry is for the previous code. The more you trust that they have shipped or written the code before, the less time you need to waste on determining what is already true.

Fear of Missing the One

Among the worst problems is the fear that you are missing “the One”. No one wants to be the one that drafts Sam Bowie instead of Michael Jordan. So the tendency is to doubt your instincts or ignore warning signs.

There is nothing wrong with giving candidates the benefit of the doubt. However, you have to decide. You will miss a good candidate. It will happen. But you are far more likely to hire a bad candidate because you put something in them that isn’t there.

The other form of this is when the interviewers don’t make a clear Hire vs. No Hire decision. There is no in-between. The job is to decide. Either you hire them or you don’t.

Hiring Just In Case

Despite evidence to the contrary, companies always seem to think the solution is to hire more. Adding more people means you can do more. Right? As the Mythical Man-Month showed, adding more doesn’t make you necessarily do more. For every engineer you add, you increase the cost in multiple dimensions. Another hidden cost is that every hour I spend interviewing candidates or reading resumes is an hour I can’t write code. For every person you hire, that’s more time I have to spend managing instead of working on code. Every person you hire changes your team dynamic. The team needs to absorb the change. Adding many new people at once is akin to starting over. All the dynamics are reset and have to stabilize. The more you add the harder it is.

Putting on a Facade

We all love our company. At least that’s what we always say. We are all world class and hire only the best. We all have the smartest management. The best resources and processes.

That’s a lie.

Pretending your company is something it is not just means your new hires will figure it out a month or two into the job and be very bitter.

What Works

It’s not all bad. There are good things that can be done and work.

Multiple Opinions

Most companies get this one right. It is good to have more than one person evaluate candidates. Consensus on hiring is a good thing since it impacts the team. It is easy to miss traits or flaws. Interviewers project all the time and see themselves in the candidate.

Candidate Presentations

Having the candidate do a presentation on themselves is a great way to get to know them. We hired our designers totally different than our software engineers. The designer candidate would do a 30 minute presentation to the hiring team then do 30 minutes with each interviewer (3 of us).

This was a great way to get to know the candidate. They have to prepare, tell you a story, and highlight their strengths. They should be able to put their best foot forward. A lackluster presentation shows you a lot about the candidate.


Reviewing a body of work is a great way to get to know what a candidate can do. GitHub allows any developer to have a portfolio of source code that can be reviewed. This is so much more valuable than an arbitrary trivia question on the white board.

Pair Programming

I’ve never done this but I’ve read about the technique. The idea is to have a candidate work with the interviewer on a problem or task using pair programming. It could be a real work assignment. I guarantee you will have a strong opinion one way or the other after working with someone like this.

It seems to me a better way to do the code review would be to sit down at a computer and build something via pair programming. Maybe organize the candidate interviews over the course of the day to pair with 4 people and build a complete thing. A real world scenario like this should be much more like reality and let you intimately see how they work.


The best candidates are people someone on your team has directly worked with and vouches for. No question. The good and bad is already known. The personality is a known quantity. These should always be your first choice. Beyond that, follow the graph. You are still much better off one or two levels removed from your employees than scanning LinkedIn.

Telling the Truth

Everyone lies.

So just tell the truth instead. Don’t present your company as something it is not. I do this a lot. Right now, our office is very much a startup. We have technical difficulties, we are remote from the main office, you wear lots of hats and change tasks frequently. I never hide that fact. Because if that’s uncomfortable, you won’t succeed here.

Hiring on Need

Hiring when in pain is good. Hiring just enough is best. So don’t try to hire four more engineers. Hire just one. Spend the time to find just that one more person. If that’s not enough, do it again. One at a time until you don’t need another.