I hired the first engineers at Zatiq and later inherited-then-rebuilt a team at Relaxy, and the pattern held both times: the first three engineers set the culture more firmly than any document, value statement or founder speech ever will. Whatever those three people do when nobody is watching — how they test, how they disagree, what they let slide — becomes "how we do things here" by the time employee eight arrives.
That's the stakes. Here's the process I actually run, including the part people push back on most: the take-home is a paid, scoped, real ticket from our real backlog.
Step 1 — get the order right
The temptation is to hire for the scariest technology first — the payments specialist, the infra person. Resist it. With three seats, every specialist you hire is a generalist you didn't, and at this stage the product changes shape monthly.
- First hire: a generalist who finishes things. Not the smartest candidate — the one with a trail of completed work. At this stage, an engineer who ships a decent solution this week beats one who ships a brilliant solution next month, every single time.
- Second hire: someone whose strengths embarrass the first hire's gaps. If your first is a product-minded frontend-leaning generalist, the second should be the one who cares about data models and failure modes. I look for the pair to disagree in the interview debrief — politely, but genuinely.
- Third hire: the multiplier. By now there's a codebase with habits. The third engineer either raises the bar — better tests, better reviews, better questions — or quietly ratifies every shortcut the first two took under deadline. Hire the bar-raiser, even if a flashier candidate is available.
What I deliberately do not hire in the first three: anyone who needs the problem pre-chewed, however strong their raw ability. There is no one here to chew it.
Step 2 — the funnel, honestly sized
For one early hire at Zatiq, the numbers looked like this, and they've stayed roughly proportional since:
The application screen looks at one thing: evidence of shipped work. A Play Store link, a live site, a real repository, a thing that exists. I stopped reading CV skill lists years ago — everyone's says the same twelve technologies, and none of them say whether the person finishes.
The 45-minute conversation is not a quiz. We talk through one thing they built: what they'd redo, where it broke, what they cut to hit the date. Someone who shipped anything real has scars and opinions; someone who can't name a single regret about their own project either didn't build it or doesn't reflect — both disqualifying at this stage.
Step 3 — the paid, scoped, real ticket
No whiteboard algorithms, no invented todo-app. The finalists get an actual ticket from our backlog, chosen to be low-risk and self-contained, against a slice of the real codebase. It looks like this:
TICKET-2141 — Merchant can't reorder product photos
Scope: drag-to-reorder in the product editor, persist the order.
The API endpoint already exists (PATCH /products/:id/media).
Out of scope: uploads, deletion, the mobile app.
Timebox: 3 hours, paid at your normal rate. Stop at the timebox —
unfinished with good commits beats finished and silent.
We evaluate: the questions you ask before starting, your commits,
and your PR description. Not lines of code.Why paid? Partly respect — three hours of a professional's time has a price, and a company that takes it free is telling you how it values engineering before you've even joined. But it's also selfish: paying converts the exercise from a favour into a job, and people behave like employees when treated like them. You learn what they're actually like to work with, which is the only question that matters.
Why real? Because invented exercises measure exercise-taking. A real ticket in a real codebase measures the actual job: navigating code you didn't write, asking about conventions instead of guessing, noticing that the "simple" endpoint has a quirk. The candidates who ask two sharp questions before writing a line have told me nearly everything. In one memorable case, a candidate's clarifying question exposed a genuine bug in the endpoint the ticket depended on — that was the fastest yes I have ever sent.
The review of their PR is the technical interview: an hour walking through their choices, including one respectful challenge to see how they hold a position, and one place where they're right and I concede — because how a person receives being right matters too.
Step 4 — references that actually say something
Standard reference calls are pleasant and useless; nobody offers a referee who'll sink them. Two questions cut through the varnish:
- "Would you hire them again, and for what exactly?" The gap between an instant "yes, tomorrow, for anything" and a diplomatic pause is the entire signal. Listen for the for what — "great executor once the design exists" is valuable and honest, and it's also a different job than first hire.
- "What did their teammates have to compensate for?" Everyone makes their team compensate for something. A referee with a real answer worked with them for real; a referee with no answer is reading a script.
Step 5 — the first two weeks decide the next two years
The offer isn't the finish line. Two rules for onboarding the first hires: they ship to production inside week one — something small, but real, with their name on the deploy — and they review someone else's code by week two, because review is where culture actually transmits. An engineer who spends their first month "reading the codebase" is learning that shipping here is slow; that lesson, taught first, never fully unlearns.
Signals I've learned to ignore
Brand names on the CV — big-company engineers can be superb, but the skill of operating inside a machine with a platform team is not the skill of being employee two. Competitive-programming rankings — orthogonal at best to finishing ambiguous product work. Fluent interview polish — weakly correlated with everything; some of the best engineers I've hired interviewed awkwardly in a second language, then out-shipped everyone.
The first three engineers aren't early employees. They're co-authors of what the company is like. Hire them with the seriousness that implies, pay for their interview time, and let the real work — theirs and yours — be the thing that decides.