How to Freaking Find Great Developers By Having Them Read Code

This resource first appeared in issue #118 on 16 Apr 2022 and has tags Hiring: Other, Technical Leadership: Software Development, Hiring: Interviewing and Evaluating

How to Freaking Find Great Developers By Having Them Read Code - Freaking Rectangle

We know code is read more than it’s written, and that debugging, code maintenance, and incremental addition is more common and time consuming than “green field” code development. And yet, the entire software development community tends to vastly over-value writing code from scratch over understanding existing code. That’s true of research software development, too, which famously almost never starts completely from scratch.

Here the article’s author recommends focusing a “coding” interview on reading code. The article describes a process where the candidate reads increasingly complicated code, predicts the outcome of some commented-out line or routine, and then they check their answer with the opportunity given where necessary to “debug” their initial answer.

I don’t think there’s much doubt that this would be a perfectly good tech screening, be closer aligned to actual work than “reverse a linked list” nonsense, and be less stressful than creating code from scratch. I’ve also seen people start to do “reverse code review” where, e.g., the candidate reviews a PR on a sample code base.

Interestingly I find research systems teams by and large are better than research software teams at focussing on understanding existing stuff. You don’t often see people interviewing potential ops staff with mostly questions like “how would you set up a linux server from scratch to do X, Y, Z”, it’s much more about existing systems and debugging.