How to Interview Engineers 📋
Picking speed vs quality, what skills to select for, and a round-up of the most popular interview styles.
Hey there! This article closes our series on hiring engineers. It’s our third piece — in the first two we covered respectively:
✨ Hiring Principles for 2025 — three ideas that guide the way I think about hiring these days.
🎒 Nailing your Onboarding Developer Experience — a guest article by Dana Lawson, CTO of Netlify, that covers how to write great job descriptions, how to onboard engineers, and how to set up tooling and metrics.
So, today we are wrapping it up by talking about how to interview engineers.
This is an ever-hot topic. People have debated good vs bad interviews for as long as I can remember, but over the past two years things have changed a lot, thanks to a trend you may have heard of: AI.
In fact:
🔍 On a tactical level — AI tools forced hiring managers to rethink the effectiveness of several hiring devices, from take-home assignments to cover letters.
🔭 On a strategic level — AI is shifting the type of skills that truly matter, so you need to ask yourself: what should I select engineers for?
Today we will address both, starting from first principles, and going down to real-world stories of the interview processes run by some of the tech leaders I respect the most.
So here is the agenda:
⚔️ Speed vs Quality — how to navigate the infamous tradeoff.
🪴 Select for the unlearnable skills — mentor what you can; hire what you can’t.
💼 Make interviews mimic real work — how to design interviews that closely resemble your actual environment.
📋 Round-up of interview methods — discussing LeetCodes, take-home’s, case studies, code reviews, and behaviorals!
Let’s dive in!
⚔️ Speed vs quality
When designing your interview process, the obvious tradeoff is between speed and quality, which resembles the one between precision and recall in machine learning.
To get higher precision (== minimize false positives) you need more thorough, and thus slower, interviews, but these will win you less candidates (== lower recall). Conversely, going faster wins more candidates, at the expense of some bad hires. Thorough interviews also require more time and work from your team, so this is a tough tradeoff to navigate.
Where should you settle? Your mileage may vary, but for regular software engineers, my personal target is two weeks from screening to offer.
This is apparently way below the average, which is 24 days for a software engineer in the US 👇
In the internet and tech industry in the US, the average length of the interview process is approximately 24 days, while the recruitment process for a software engineer in the US usually spans about 35 days.
So, if your interviews take more than two weeks, you can diagnose the process. Where is the time going? In my experience, here are the usual suspects:
Is it too many interviews? → Make sure different interviews actually test for different things, and are not only there for consensus — e.g. 3 interviews is a good number.
Is it latency because people have other things to do? → Make sure hiring is top priority, as it should be, and people’s time is allocated accordingly.
Are you waiting for multiple candidates to get to the final stage? → Rookie mistake! You should make an offer as soon as a strong candidate emerges.
Finally, some people just don’t feel comfortable hiring fast. If that’s the case, it’s probably because you feel that false positives pose too much of a risk. Now, bad hiring sucks for everybody, so that’s a fair concern — but it shouldn’t be overly so.
The best way to de-risk bad hires is to make probation do its job. There’s some personal preference in this, but my style of hiring is to keep interviews lean and jump soon into doing real (paid) work together.
That’s because I have found interviews to get into diminishing-returns-land quite fast, so when you are—say—80% sure about a candidate, closing the final 20% costs you just as much as the rest of the process — so better start real work and see how it goes.
The catch is that for this to work your onboarding needs to be snappy, so that during the initial months you can truly evaluate where the collab is going. But fast onboarding, in turn, is good signal about the health of your dev team, so this is a nice flywheel.
That said, what should you use interviews for?
🪴 Select for the unlearnable skills
What you should test engineers on totally depends on the role, but there is a key question you should ask yourself:
What can you mentor people on, vs what should they bring from home?
Most of the times, you should only hire for the latter.
That’s because of two factors:
🎓 Great teams create great mentors — who are happy to pass on knowledge and grow younger folks. We always ask ourselves whether people on our team are learning, but are they teaching, too? Mentoring colleagues is an incredible growth experience.
📈 Smart people learn fast — usually faster than we account for. That’s especially true in the AI age.
This also means that in well-functioning teams, where senior leaders act as mentors and knowledge is transferred efficiently, you can hire mostly junior engineers and get away with it. That’s because of the circle of life™ 👇
Charity Majors wrote an incredible piece in the newsletter two weeks ago, which also discussed this 👇
So, you should hire for skills that are either too hard to learn, or where your team is unable to mentor new hires. In today’s terms, this usually means less memorization and more quality thinking:
📇 Memorization — is specific knowledge about frameworks and languages. With AI, this is devaluing at a pretty fast rate.
🧠 Quality thinking — is system design, product mindset, and good communication. This is timeless and still makes a huge difference.
My hard and fast recipe is: for quality gaps—hard-won experience that your team lacks—hire senior talent; while for pure bandwidth, hire junior talent.
So, now that we've covered what you should test during interviews, how should you run them? 👇