We're Looking at Developer Interviews Wrong / by Owein Reese

The problem with hiring in software is that most interviews focus on writing code and "culture fit" instead of focusing on the daily tasks which occupy a developer's time.

The five primary responsibilities or duties that are commonly assigned to software developers from my experience are:

  1. Write code/produce a dataset

  2. Review another developer's PR

  3. Triage a production incident

  4. Review a technical design doc

  5. Review a product requirements doc

So why is it that most work involves reading and understanding other people's work while the hurdle to joining a company is about demonstrating that you can produce work? Seems backwards if you ask me. Maybe a better question is, why don’t more companies interview for all the tasks they ask developers instead of code generation tasks?

First, shifting the focus away from writing code requires preparation and work from the hiring company. Most times when someone needs to be hired, they need to be hired ASAP! There isn’t time to do the work needed to round out the interview.

Second, every role at a company handles different systems. Triaging a problem with Airflow is very different from triaging a problem with a RESTful API or a Kubernetes Pod. This would mean every team couldn’t use a standardized interview set up at a “triage” portion of the interview. Again, more work.

Finally, looking at the spectrum of experience, Jr developers shouldn’t be expected to do a critical assessment of a technical design document. So there would need to be some tailoring to help them with this stage (or skip it altogether.) Again, yet more work for the hiring team.

Thus, the problem with hiring is that we, as an industry, are emphasizing the tasks which are easiest for the hiring team to consume and judge while diminishing the evaluation of any task which would require effort from us.