Brent Simmons, who has been building and shipping exceptional software for decades, has been writing about his recent reentry into the job market and practicing for coding skill tests during interviews. I’ve followed Brent’s work for as long as I can remember and his blog is one of my favorites. A few days ago, he described the pain of studying for code interviews:

I don’t have a CS degree, but I have decades of experience — I know what a linked list is, for instance, and could write one by hand easily if called to. In a few different languages, even. I could talk about the trade-offs between a linked list and a contiguous array. Etc. I’ve got all that.

My style of coding is to break problems into steps and make it super-obvious to other people — and future-me — what the code is doing. I like to write code so clear that comments aren’t needed.

He then describes how he approaches problems normally during the course of his work and how that is very different from what these technical interviews are looking for. When I wrote last week about technical recruiting I was thinking about this same problem. This style of technical interview is set up to quiz people on very low-level puzzles and graded on a scale designed for a computer science exam, rather than actual day-to-day aptitude for real job.

Brent followed up yesterday with another post:

There’s a whole small industry to help people prepare for these tests — so it’s not like you’re getting the authentic programmer showing up. You’re getting the person who’s prepared for one of these.

Because of that, an interviewer is even less likely to learn how a candidate approaches solving a problem. Instead, they’ll learn how well the candidate prepared to make a good impression — which tells you nothing about how they’d actually solve a problem.

Daniel Jalkut, on Twitter, reacting to Brent’s posts:

No matter how experienced we are, the prospect of code-related interview questions provoke fear in us. I don’t know if any other industry is like this, where inrterviews are designed as “gotcha” traps, designed to make fools out of geniuses.

I understand the need to see how someone codes before hiring them to join your company. But it shouldn’t be tricky. And it should focus on the actual job itself, which for most of software development, is just solving hard problems. I’d much rather hear about how someone solved a problem than if they know a specific sort algorithm.