I've been finding my next job. I've looked at literally hundreds of listings and been on several interviews. Over my career, I've interviewed a lot. Today, software engineer interviews work mostly like this:

  1. Screening interview ("do we want to proceed with you?")
  2. Development Manager interview ("do I want to work with you?")
  3. Technical interview or assessment ("can you do the job?")
  4. Other Management interviews ("do we have any objections?")

There can be as low as three (rarely two) steps. I've literally seen it up to six. A six-step interview!

One intended goal for this process, I think, is to reduce the amount of time taken by management and developers for interviews so they can focus on coding. Another reason--again, my opinion--is there's a belief that management can screen out for fit early.

Fit matters. I care a lot about whether I'll fit in with a prospective employer. But, after quite a few recent interviews and really pondering and reading about hiring, I think the typical process is backward, biased, onerous, and ineffective.

A Better Way

Here are the steps I'd like to see.

  1. Initial, online technical assessment using real-world coding. No FizzBuzz, no "reverse this string the hard way."1
  2. Work with the team.
  3. Development Manager interview.

1. Online Assessment

I've been skeptical of online skill assessments in the past, but a recent experience has warmed me to them. While still not as good as working with one's daily tools such as Visual Studio, the online interface was very good. So, why should companies start with (and pay for!) this assessment?

  • Many candidates will drop out because they know they're not ready. This reduces the pool that the development team needs to assess. It's self-selection.
  • The remaining results will be reasonably apples-to-apples.
  • What matters first is "can you do the job."

The skills assessment can be tailored, so junior devs are assessed differently than seniors and architects. And the goal is to gain information, not punish people for not having arcane knowledge. "The basics" (you know, bubble sorting) really don't apply day-to-day. Let me show you I can write testable, clean, object-oriented code!

A fair, online assessment reduces lots of bias. A candidate shouldn't be disregarded out of the gate just because a hiring manager or the candidate hasn't had lunch yet. This is more common than people want to admit.2

2. Team Work

With the assessment results and resumes in hand, the development team can--with coaching from management and HR--decide who they want to meet. Let me say that again. The developers choose. You can bet they'll be careful with their time. In my view, they should ideally work on some code together, or do something that shows the candidate how life will really be. In a word, collaborate. This shouldn't be a "let's talk" meeting. Pull an item from the backlog, discuss how it might be approached, do some pair programming or even mob programming.3

The candidate will be working mostly with developers. They have the biggest stake, so they should have the biggest say in hiring. This is even more important if you claim to be an Agile shop. If you aren't letting developers self-manage their teams, you may still be a top-down bureaucracy.

3. Management Blessing

Someone's going to chafe at my suggestion that the final step is only with the development manager; that is, the person who will be the candidate's direct supervisor, or at most one level above that. But why have you promoted people to management/leadership positions if you're not going to trust their judgement? By now in the process, the only candidates who talk to the manager have been pre-approved by the development team she'll be working with. There's really no reason to bring in other managers, except to stroke their egos and forestall "why wasn't I consulted?" comments later.

Besides, most managers complain they're too busy with endless meetings. This reduces meetings.

Other managers and execs should certainly introduce themselves after the hiring. But if a qualified developer who is liked by the people she'll be working with doesn't get a job because the CEO or president has a "gut feeling," and needs to "meet everyone who's going to work here," a disservice has been done to the entire organization. It signals that people's careers are at the mercy of caprice.

Change Your Ways, It'll Save You Money and Improve Your Culture

Companies spend a lot of money on recruiters, time spent reviewing resumes, time spent in interviews. But have they really evaluated whether that money is being well-spent? Have they applied research and evidence, or are they interviewing software engineers the same way they always have?

This article proposes the answer is, generally, no. We're hiring developers using a traditional model. And we're getting traditionally chancy results.

I learned decades ago to look for these qualities as part of hiring, and they still apply.

  1. Can the person do the job?
  2. Will the person do the job?
  3. Does the person fit?

The principles I've outlined above boil down to.

  • Reduce initial bias
  • Let developers hire developers (with help)
  • Trust your colleagues

I'm no expert, but I think we can hire better.4

References

  1. FizzBuzz can have value if done as pair-programming, but requires a different skill set on the part of the interviewer.

    As far as the "find substrings in a string" tradition, in my opinion, it's outdated and useless. The technical interviews where a couple of developers assign a seemingly trivial task and watch in silence while the candidate tries to work it out is just terrible. It's completely removed from the reality of the job (I hope!), and puts useless pressure on the candidate.

    It isn't an assessment. It's a hazing.↩

  2. As discussed by Daniel Kahneman in his book Noise, and reported on in this article.↩

  3. This was one of my favorite interview experiences.↩

  4. To be intellectually fair, I really haven't found out what research there's been on effective developer hiring practices. I'm just voicing a slightly educated opinion that may be dead wrong.↩