An Employer's Guide To Hiring Developers

hint: programming challenges are a dumb idea

(A shorter version of this article appeared in the Pragmatic Bookshelf newsletter.)

Jan turns up at her 12th interview. The interviewer hands her a marker and points to the whiteboard. "Go ahead and write out the code to calculate the weight of minimum spanning tree of a connected, weighted, and undirected graph." Jan sighs: third time this month. She sets to work.

Photo by charles deluvio on Unsplash

In my opinion, she shouldn't get the job based in this performance, however practiced the answer.

For me, a good candidate would put the pen down and ask, "Could you give me the context for this, because I'd hope you'd want programmers to use an AI (or a library) to handle this kind of problem. I was looking for a job that lets me do things your AIs can't do."

Challenge-based coding interviews were always a bad idea: they put the focus on the least important skill of a potential hire, memory. Let's list some of the more important skills that the challenge interview doesn't test:

• communication skills, including the ability to question authority in a polite, productive way;

• context building skills: framing a problem in its larger setting before blindly coding;

• knowledge of a spectrum of available approaches to solving a problem, and the tradeoffs between them;

• the ability to work in a team;

• and so on.

I’ve never understood why anyone would consider the ability to write down some random algorithm would be a predictor of success in a job. I have a little more sympathy for questions which ask about selecting a good algorithm or data structure, but, even then, why wouldn’t you let the candidate use resources that would be available to them in their when they were working for you?

Ask yourself: who would be a better fit on your team: someone who’d memorized all four volumes of The Art of Computer Programming but who refused to work with other people, or someone who’d cheerily admit they didn’t know something, but who did know how to look it up, and then would happily share what they’d learned with others?

Flip The Interview

Some secondary schools run a flipped curriculum. Rather than learning in the classroom and practicing at home with homework, they ask the student to study the material at home and then come in with questions, prepared to try some examples in class, where help is at hand

That sounds like a great model for job interviews. Send the candidate a real problem that they are likely to encounter in the first six months of their job. Express it in the way that a team member would normally be given a task. Tell them you don't want a solution. Instead, when they come in, they'll be sitting in a room with you and a couple of team members.

Their task is to ask questions that will lead them to enough of an understanding to be able to start attacking the problem. When they are satisfied, ask what their plan would be to implement it. Make sure they're incorporating small steps and feedback. You don’t want them actually to do the implementation, if for no other reason than the problem is likely to be big enough that this wouldn’t be practical. Instead, you’re look for a realistic approach, with small steps and lots of feedback. The first few steps will be fairly specific, but should then quickly become fuzzier and conditional on the results of prior steps.

Finally, tell them that, two weeks into coding, the requirement X has changed to Y. What impact will that have? For more senior candidates, make the requirements change something that is clearly a bad idea and see if they push back.

Hire The Person, Not The Skills

Today, basic coding skills can be recruited by buying more AI tokens. You shouldn't be hiring based on that.

But AI does not (currently) have the higher level, more global skills that people have. An AI is less likely to remember that Joe in fulfillment once mentioned that you should never schedule deliveries to Topeka on a Wednesday, or remember that someone at the local user group mentioned issues they’d had with a library.

Recruiting based on performance executing a challenge is an incredibly Taylorist¹ approach to hiring: it reeks of stopwatches and clipboards. We’ve moved on from that over the last hundred years.

You're hiring a person. Make sure the process you use evaluates the candidates as people, and not as algorithm-writing automata.

1. Scientific Management is an approach to process management in manufacturing pioneered by Frederick Taylor between 1880 and 1915. Each job role was meticulously analyzed, and workers were told the exact steps they should follow to perform optimally. When they did, they were rewarded with higher pay.