In defense of coding interviews

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly.

Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to leverage when, of course, but not to the extent that it's typically prioritized in the typical interview.

I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output), but I've never had somebody crush the coding portion (implement very fast and proficiently), and perform poorly on the job

You have a task to implement a new product feature and it takes you 1 week instead of 1 day.

In an interview context, I've seen cases where somebody fully understands the logic underlying the solution, yet it takes them 30m to write it, while another person can do it in 5m or less.

Essentially how long it takes to translate from mental understanding to working code

It is nice to hear a defense of this style since there’s often so much complaining about it, and the tips to mitigate the downsides are useful.

Personally I don’t mind a whiteboard session or two during a loop but what’s wild to me is how, especially at big companies, you’re expected to do four or five of these to get an offer.

How often do these companies decide “well they understand when to use DFS and they can merge-sort a linked-list and they knew to use dynamic programming but we can’t hire them because they couldn’t remember how to implement a heap”?

Instead of endlessly rehashing the controversy of coding interviews, has anyone considered just how engineers are expected to be able to understand the material on the interviews?

Should it be from university CS programs? Which are supposed not to be vocational? And would discriminate against those who are not degree holders?

Should it be from internships, which are nowadays subject to the same Leetcode examinations as actual work?

Should it be from junior developer roles, which are an endangered species, as every business in desperate need for seniors, and lack the patience to train?

Maybe open source can be a sort of free apprenticeship to teach developers these good practices?

Or maybe grinding away at Leetcode, Project Euler, and arbitrary coding puzzles is really the only pedagogical solution.

Perhaps I’m biased as someone with a better than average sense of algorithms and discrete math, but I think such interview questions have a lot of utility, provided the job will require some analysis of algorithms, eg you’re working on the platform, or a solver/optimizer.

Obviously it’s pants on head stupid to do that if you want a web dev to make a pretty app, tie frameworks together and liaise with 3rd party integrators. However, I think many employers want the crème of such devs who are also good at algos.