Senior Developers Don't Do Six-Round Interviews
The hiring market for senior developers right now is the hottest I’ve ever seen. Every company is hiring, salaries keep going up, and every senior engineer I know has more inbound messages than they can read.
And yet, a surprising number of companies are still running an interview process designed for 2015, when candidates were plentiful and companies could afford to be picky. Recruiter screen. Hiring-manager screen. Take-home assignment. Live coding. System design. “Culture fit” with the team. Final with the VP. Six to eight rounds, spread over a month.
Here’s what actually happens: the best candidates drop out. Not because they fail, but because somebody else made them an offer in week two.
Who survives a long process?
Think about who is willing to spend 15-20 hours over a month interviewing with you:
- People who aren’t currently employed, or are very unhappy.
- People who aren’t getting other offers.
- People who interview as a hobby.
Some of them are great. But the senior developer who is good, busy, and casually open to a move? She has three other conversations going, two of which will take a week. You’ve filtered her out before you ever saw her code.
A slow process doesn’t select for the best candidates. It selects for the most available ones.
The take-home problem
I’ll be blunt about take-home assignments for senior roles: they are disrespectful of people’s time. “It should only take 3-4 hours” means a weekend, because a serious candidate is going to polish it. And you’re asking them to do this unpaid, before you’ve committed anything on your side.
There are better ways to see someone’s work:
- Look at what they’ve already built. Open-source code, side projects, a past product, a blog. Most senior developers have something.
- Talk through a real system they built. Ask about the tradeoffs, what went wrong, what they’d change. You learn more from 45 minutes of this than from any toy assignment. People who actually built things can go deep; people who were adjacent to things can’t.
- Pair on a real, small problem from your codebase, for an hour, together. You also get to see how they collaborate, which is half the job.
- If you really need a take-home, pay for it. That changes the dynamic immediately.
What a good senior process looks like
I wrote a long post on recruiting engineers years ago and most of it still holds. For senior hires today, I’d boil it down to:
- One conversation with the person they’d actually work for, about the work. Not a screen, a conversation.
- One deep technical session (past systems + a bit of pairing), with one or two engineers from the team.
- References, if you need them.
- An offer within a week of first contact. Seriously. A week.
That’s it. Three steps. If you can’t tell whether a senior engineer is good after three hours of honest conversation about engineering, more rounds won’t fix it - and you might want to look at who’s doing the interviewing.
Selling, not just filtering
The other thing companies forget: in this market, the interview is a sales process, and you’re the one selling. Every touchpoint tells the candidate what it’s like to work with you. A disorganized, slow, impersonal process says “we’re disorganized, slow and impersonal.” A fast, thoughtful, respectful one says the opposite.
Tell them about the actual work. Introduce them to the team. Be honest about the problems. Move fast. Make a clear offer.
Or don’t hire full-time
Also worth considering: maybe you don’t need another full-time hire right now. If you need a feature built well and quickly, an experienced independent developer can often start next week, without a two-month hiring process and a three-month ramp-up. I’m biased, obviously. But a lot of companies I talk to are spending a quarter trying to hire someone to do work that could have been finished in that quarter.
The best developers have options. Act like it.
