Up to this point, the backend has been held together by contractors, a founder who learned just enough Python to be dangerous, or whoever was cheapest and available. It worked, more or less. The moment that stops being enough, the temptation is to hire the way you've hired for everything else — post the role, screen for the résumé, pick whoever interviews best. That approach breaks here in a way it doesn't for most other roles, because this is the first hire whose mistakes don't show up for months, and by the time they do, they're expensive to undo.
What actually changes with this hire
A contractor optimizes for finishing the ticket. A real backend engineer, the kind worth calling your "first," optimizes for what happens to the system after the ticket's closed — because they're the one who'll be paged when it breaks, and they know it. That difference shows up in decisions nobody's watching them make: whether they add the database index now or leave a comment for later, whether they write the migration in a way that's reversible, whether "it works on my machine" is good enough to merge. A contractor with no stake in month six has no reason to weigh those the same way.
That's the actual thing you're hiring for. Not raw ability to write code — plenty of people clear that bar. The judgment about what corners are safe to cut and which ones come back to bite you, and enough conviction to say "this needs another day" to a founder who wants it done today.
What the interview should actually test
Whiteboard algorithm questions test whether someone's recently studied algorithm questions. They don't test the thing that actually matters at this stage: can this person walk into a messy, half-documented system and make a reasonable call about what to touch and what to leave alone. A far better signal is a real, small piece of your actual codebase — with the mess left in, not cleaned up for the interview — and a conversation about what they'd do with it, what they'd ask before touching it, and where they'd push back on a deadline.
Watch for how they talk about tradeoffs, not just whether they land on the "right" answer. Someone who says "it depends" and then actually explains what it depends on is giving you more signal than someone confidently certain in a interview about a system they've known for forty-five minutes.
What to have ready before they start
The biggest mistake founders make with this hire isn't picking the wrong person. It's handing them a system with no map and calling the resulting three weeks of archaeology "onboarding." Before this person's first day, they need actual access — not "I'll add you once you need it" — and some honest account of what's fragile: which parts of the system nobody fully understands anymore, which decisions were made under deadline pressure and never revisited, where the bodies are buried. A founder who can't answer that yet is handing their new hire the job of finding out the hard way, which is a worse use of their first month than almost anything else they could be doing.
The mistake that costs the most
Founders under pressure to ship often hire the person who can start fastest, because the backlog is real and the pressure is real. That's usually the expensive choice in disguise. The engineer who asks uncomfortable questions in week one — why is this built this way, what happens if this call fails, who owns this decision — is doing exactly the job you're hiring for, even when it feels like friction instead of progress. The one who says yes to everything without asking is either exactly what a founder wants to hear, or the reason the founder ends up hiring a second backend engineer eight months from now just to fix what the first one didn't think to question.