Casey Muratori: I can always tell a good programmer in an interview

One problem with this is that it presupposes that the interviewer is skilled enough to spot problems, ask the right probing questions, etc. Casey is definitely skilled enough. I can’t say that’s universal.

Another problem, which TFA hints at, is bias. System Design interviews are often terrible for this reason. If you present me with some scenario that I know is trivial to handle with a single server, I’m going to want to discuss that, but you are probably expecting me to talk about a message queue, a caching layer, etc. Both are valid depending on the situation, but if you’ve only ever known one type, you may dismiss others out of hand.

I can probably go into great detail if we're talking about a project I worked on in the past 3-6 months. But beyond that, the details of past work start to become fuzzier. So if I encounter an interviewer like this, I'd better hope that my most recent project fits the bill, because I'd probably stumble through it for earlier projects.

That’s absolutely right, but there’s another issue with the LeetCode-style interview that hasn’t been getting much attention lately, including in this article. My company is hiring right now, and we’ve shifted all of our initial interviews to Zoom, where we include a brief coding task. However, it’s becoming more and more clear that many applicants are using LLMs to produce their code. It’s reached the point where it feels almost impossible to assess whether someone can actually code on their own in these remote settings. On the other hand, it’s much harder to lean on an LLM in a more open-ended, conversational interview without it feeling unnatural. That, I think, is one of the biggest flaws in the current remote coding interview setup.

I like this approach. The only problem (or at least one of the problems) is that many people do not have suitable personal projects, as in they might be 10 years old. If one of the goals is to filter out people that don't work on projects in their free time, then this works, but I know many good programmers who don't, or at least they don't anymore due to having kids and other responsibilities outside of work.

As this article touches on, I'm big into pair programming interviews. I was part of the pair programming step at a past company and we'd always use StringCalc [0]. It's starts out super easy and gets gently progressively harder. The goal isn't to finish but to just to see how people think. We would do pretty legit pairing where we'd help if they got stuck on anything or thought we had a better solution. This shows so much about how someone thinks, collaborates, and responds to feedback. Often within 10 mins I could tell how it was going to go. We always had to finish, though, just in case.

Of course it depends on what type of app you have and how your company works and so on and so forth.

[0] https://github.com/MokshankSoni/StringCalc_TDD

1) If they are competent programmers.

2) Whether they will be productive at your company/project.

this is exactly what I do

also, if an interviewee doesn't know something that I think they should, I help them learn it

enough interviewers make the process unpleasant

I try to do the opposite

Some engineers do not have personal projects to show. Only work projects that can’t be shown.

And junior developers who have personal or university projects it’s sometimes too shallow for this check described in this article.

There are three competing factors at play: minimising false hires, minimising false no-hire, salary.

Presumably I couldn't hire Casey for a team lead position paying £120k per year. Equally, I don't want to miss out on talent by trying to catch every edge case and making an interview process 3 weeks long.

I hired a very technically strong candidate once, he loved optimising games as a hobby. Unfortunately we were a SaaS startup and he seemed to be allergic to using prebuilt components (think SQS) because "we could build them more efficiently". It's impossible to catch every foible like this in an interview scenario.

For these reasons, ultimately there will be bad hires. The biggest mistake is leaders not being willing to fire people. Sometimes this is for fear of reducing head count, because it makes them feel like an arsehole or they aren't themselves capable/invested enough to care. It's painful but I've found it always better to fire fast.

> Chooses a project the candidate has worked on.

> Asks questions with the goal of having the candidate teach him about his project.

I really like this. Asking candidates about their PhD thesis has not gone as well as I hoped, there's usually an increasing level of panic as they realise I read it before the interview. Asking about patches they've written to open source has the same effect.

Asking about something I can't verify changes the stress profile on it a lot. Going to change to this strategy. Thank you HN :)

As a 60+ year old guy who has been at the same employer for the past 20 years, I thankfully evaded all that leetcode crap. My interview style has always been of the sort described -- ask in depth questions about something they have worked on.

The telltale sign of a padded resume is when the person acts like a cork -- you try to push down deeper and they always pop back up to surface level answers. Some give up the game quickly and admit that they were on the team that did the thing in question, despite their resume saying they did the thing. Other people are very practiced and unflappable and just bob back up over and over without shame.

For new engineers with say three years of experience or less, I can forgive the overstating their experience and I'll shift to asking them to describe their part of that project. But for the people with a few years on their resume, then that behavior is definitely a deal breaker.

Another line of questioning I take for people with experience are questions like: what are the tradeoffs of directed testing vs random testing? When do you have enough confidence in your testing that you say the product is ready to ship? What are some examples of where bugs made it out the door, and what was your process after that happened? What are some reasons why every part of a design might pass their unit tests, but the total design has failures?

These should be easy to discuss for anyone with experience, but there are a surprising number of people who fall flat. Similarly, I am shocked at how often I ask someone to write some code in any language they want to, even pseudocode, for a simple problem and are unable to do it. Eg, given a stream of numbers, maintain the largest two numbers seen so far.

When doing technical interviewing I look for 3 things:

1) Can this person do stuff.

2) Can they learn stuff.

3) Are they interested in learning and doing the things we need them to.

The authors approach of going deep in one area is good for determining #1. You weed out all the people who "were on the team that..." or similar work-adjacent activities and find those that actually did the work / wrote the code / designed the thing / did the testing. Anyone with several years should have worked on more than one thing. Variety of things they actually did indicates an ability to learn which is #2 above. Finally you'll have to gauge how well they'll take to whatever it is you need them to work on, and that's a toss-up. This is where going to a big-name school can be useful since a big part of college is pushing through shit you don't care about for courses that aren't your thing. Otherwise a real interest in your project/product should be enough to motivate the learning and doing if they're capable.

The rest of the "team fit" stuff... You can figure out what they're like on the side while doing an hour long technical interview.

And that's my take on interviewing. I find it quite effective at finding good engineers.

> If they can answer your questions, and their answers come from solid foundations

I am currently a cloud architect, but generally speaking when I've interviewed candidates, I prefer this approach.

If you can't answer detailed questions about something you've allegedly done, you're cooked. In real life, you're not going into a situation where you can't use reference information to help you remember all the details.

> [Linear] mentioned that this approach is working very well for them, and they have achieved, at the time of writing, 96% retention.

Is this evidence that their hiring process is sound, and is it more a consequence of Linear being a rocketship? Perhaps if their retention number includes when a bad hire is let go, this is more believable that they are meeting their standards.

I’ve only worked at small startups, but usually “retention” means that no one has left for somewhere better.