In defense of coding interviews

The problem is that these problems are not even whiteboard problems anymore. They’re often strictly timed coding exercises on Coderpad or Karat with actual mock IDEs and REPLs expecting running code under strict expectations.

The more casual, flexible, subjective coding interview described by the OP is not the prevalent form of whiteboarding interviews, which has been superseded by the weeder version.

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting.

I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

> I think many employers want the crème of such devs who are also good at algos

I think that many employers don’t have a clue what makes a good dev, in general, or in the positions they’re trying to fill.

Very well written article despite the fact that I completely disagree with the conclusions logic of the author. I'm on the "reading code" and having a more personal connection side of the road. Partially on the debugging aspect for some cases. Pretty much the process explained here: https://talktotheduck.dev/debugging-the-technical-interview-...

The "write code" types of interviews fit for juniors who might not know how to even write code properly. If a person doesn't know how to do that and is a junior they usually have the right energy and can put 100% into the job to adapt/learn. I hired such juniors who had no experience in the languages/platforms and were productive within a month. They had good character and discipline.

Distilling a question like that for an advanced coder is impossible. No wonder the article didn't provide any sample of a "good interview". We'd all burn him at the stake because we'd all hate it. There's no such piece of code that would provide a valuable data point about a candidate. So this is a waste of your time when dealing with a junior and with an advanced coder.

Coding interviews are difficult. You will make mistakes, this is unavoidable. I think the best mistakes to make are the ones where you hire people who are part of your team and can grow with it. Even if they aren't the best coders around, being part of the team will help them hone those skills and evolve. If I had to pick a 10/10 coder or a team player I'd pick the latter every time.

I usually give a data structure coding interview:

Here's some data models, and here's how you can reference eachother by properties. Cool. Let's do 3 levels of nested loops to extract the relationships and map them. That's like 99% of what they'll be doing.

The signals I'd look for are "do they start the entire thing by looking at structures or not", etc.

But unfortunately this breaks down when you're interviewing 10-year+ candidates. It doesn't yield anything useful. So sticking for those positions with a really really basic problem and pseudocoding it, and using the remaining time to instead have them map out solutions they did in the past seems to be useful.

Most things leet code interviews screen is "does this person know how to cram" because I tell you, everyone I know who aced leet code interviews crammed for 3 months and literally knew any one you can think of, and every variation. Juniors tend to do better in those, ironically enough.