How We Hire Engineers
No algorithm was whiteboarded in the making of this interview.
We've hired engineers the wrong way more than once.
Early Norveon, we did what everyone does. Post a job, collect CVs, send a take-home assignment, do a technical interview, make an offer. Standard process. Felt professional.
And then we'd hire someone and realize within a month they weren't the right fit. Or we'd lose a good candidate who took a job somewhere else because we moved too slow.
We changed things. Here's what we do now.
Why We Stopped Sending Take-Home Assignments
The candidates we most wanted to hire had the least time to do them. Senior engineers with jobs, families, side projects. They'd get our assignment and weigh it against three others they'd received that week.
We also noticed the quality of submissions had nothing to do with job performance. We hired people who turned in polished work and struggled when things got messy. We passed on people whose submissions were rough but who turned out to be excellent when we later crossed paths with them elsewhere.
The signal was bad. The cost to candidates was high. We dropped them.
What We Do Instead
Three steps.
A short call. Thirty minutes. We want to know what the person has built, what they're looking for, and whether there's an obvious mismatch. We're also selling ourselves, a lot of good candidates have options and won't take the next step if they don't like us after thirty minutes.
A working session. Two hours. We pick something real, an actual bug from our codebase, a slow endpoint we've been meaning to fix, or messy code we want a second opinion on. We work through it together, one of us pairing with the candidate the whole time.
We pay for this. It's two hours of someone's time and we're asking them to actually work.
A short reference check and offer. If the session went well, we move fast. We've lost candidates by going dark for two weeks after a good interview.
What We're Actually Looking For
Not a correct answer. Not a clean solution.
We're watching how someone thinks out loud. Do they ask questions before diving in? Do they read the code before changing it? Do they panic when something doesn't work, or do they get methodical?
What they do when they hit something they don't know matters most. Good engineers say "I'd normally Google this, mind if I do that?" or "I'm not familiar with this part of the stack, can you give me context?" That tells us more than whether they can reverse a binary tree.
The Honest Tradeoff
This takes more time from our team than sending a take-home assignment.
Two hours of someone's calendar, plus prep, plus follow-up. We can't run five of these in a week without it affecting other work. So we're more selective about who we invite to a session, and we spend more time on that first call making sure it makes sense.
We're fourteen people. We don't hire often. When we do, getting it right matters more than moving fast.
Four engineers hired this way. Three are still with us. One moved cities and we couldn't make remote work for their situation. No dramatic bad-hire stories, but also none of the "looked great on paper, completely different in practice" stories that used to happen.
If you're hiring fifty engineers a year, this probably doesn't scale. If you're hiring five, think about whether the time investment is actually that different from reviewing twenty take-home assignments.
Currently running one of these sessions this week. Ask us in a month whether we made an offer.
