Designing a technical interview process for a team of ten

Ten people means one bad hire is ten percent of the company. That ratio should sit behind every decision in your interview process: how many stages you run, whose calendar you raid to run them, and how much risk you're willing to eat to fill the seat a week sooner. A process copied from a two-hundred-person company solves a different problem than the one you have.

What's different about hiring at this size

You don't have a recruiter. Someone on the team, usually you, sources candidates, screens resumes, schedules calls, and delivers the news at the end. That work doesn't disappear because nobody has the title for it. It lands on people who owe the roadmap a feature this quarter.

Every interview hour is an engineering hour. A company with a recruiting function spends someone else's time on volume: the first call, the logistics, half the screening. You spend your own team's time on all of it. A phone screen, a pairing session, and a debrief for one candidate cost close to half a day of engineering time that ships nothing. Multiply that by everyone who doesn't get an offer, and hiring is one of the more expensive things a ten-person team does.

The cost of getting it wrong is higher than the arithmetic suggests. At a large company, a weak hire is a performance plan and a quiet exit six months later, absorbed by a team of forty. At ten people, a weak hire is a tenth of your engineering capacity, plus the time spent training, correcting, and eventually replacing them. That's the trade you're managing: less time per candidate than a company with a recruiting team, and less room for a mistake once someone starts.

A four-stage process

The sequence below fits a ten-person team with no dedicated recruiter. Treat the pass rates as what to expect, not a target. If your numbers look very different at every stage, the stage before it isn't filtering anything.

Stage 1: Resume and a short async screen

• Purpose: cut candidates who don't meet the baseline. You don't have enough information yet to rank anyone.
• Duration: about fifteen minutes of reading per resume, then thirty to forty-five minutes of candidate time on a short exercise for those who clear it.
• Who runs it: the hiring manager. There's no recruiter to hand it to, and this is the person who lives with the result.
• Pass rate: roughly a quarter to a third of resumes earn the exercise, and about half of those clear it.

Stage 2: A role-specific technical assessment

• Purpose: find out whether the candidate can do the actual work: read code they didn't write, fix something broken, explain a choice.
• Duration: sixty to ninety minutes of candidate time. Grading it against a written rubric costs you fifteen to twenty minutes per submission.
• Who runs it: whoever wrote the rubric, ideally rotated, so the bar doesn't quietly become one person's taste.
• Pass rate: call it half of the people who attempt it. A rubric that passes or fails nearly everyone is measuring something other than the job.

Stage 3: A live technical conversation

• Purpose: watch how the candidate thinks about something unscripted, and dig into the parts of the assessment that were interesting or thin.
• Duration: forty-five to sixty minutes, with two engineers if you can spare them.
• Who runs it: two engineers who didn't grade the stage two submission, so you get an independent read.
• Pass rate: roughly two out of three. The earlier stages already did most of the cutting.

Stage 4: A final conversation and reference calls

• Purpose: confirm the candidate wants this job at this company, answer their questions straight, and check references yourself.
• Duration: thirty to forty-five minutes, plus two reference calls at about fifteen minutes each.
• Who runs it: the founder, or whoever the candidate would report to. One person, not a panel.
• Pass rate: most people who reach this stage get an offer, but not all. Scores don't catch everything.

Write the job description so the assessment falls out of it

A job description that says "strong problem solver, excellent communicator, passion for our mission" gives you nothing to build a test from. Every candidate can claim all three, and you'd have no way to check. One that names the actual systems, the actual language, and the actual kind of bug someone will be handed in month one gives you the assessment for free: pull the systems into the reading exercise, pull the failure modes into the debugging exercise.

I built Evaluator around this idea: paste the job description in and it generates a role-specific assessment, covering code reading, code writing, debugging, communication, tradeoffs, and AI collaboration, in about 100 seconds. The discipline doesn't need the tool, though. Write the job description specific enough that a stranger could derive your interview questions from it, and most of stage two designs itself.

The cost is real: a specific job description takes longer to write than editing last year's template, and it shrinks your applicant pool, because fewer people actually match it. That shrinkage is the point. A hundred vague-match resumes are more work than thirty specific ones, and the specific pile is the one with people who can pass stage two.

What to standardize and what to leave to judgment

Standardize the things that make scores comparable across candidates: the core question or prompt at each stage, the rubric categories, the language of the pass bar, and the scorecard template everyone fills out. If two candidates for the same role answer different questions, you're not comparing them. You're guessing.

Leave room for judgment on the things only a person in the conversation can weigh: which follow-up question to ask, how far down a tangent is worth going, whether a terse answer is confidence or evasion. A rubric that tries to script this turns the interview into something a well-prepared candidate can pattern-match, and the people who prepare hardest aren't always the ones who'll do the job best.

The failure mode on one side is five interviewers running five different interviews under one job title. On the other, a checklist so rigid nobody can act on what the form didn't anticipate. Fix a skeleton, the same core prompt and scorecard categories, and leave the muscle around it to the person in the room.

Deciding in one meeting

Have every interviewer write a scorecard alone, before the meeting and before hearing anyone else's read. The first opinion spoken out loud anchors the room, including people who scored the candidate differently on paper minutes earlier.

Open the meeting with a silent read of the scorecards, not a discussion. State the bar out loud before opinions start: what pattern of scores means yes, what means no, and what happens on a split. Give one person, usually whoever will manage the hire, a real veto instead of averaging every opinion into a number nobody actually believes.

Time-box it to thirty minutes and decide the same day. That's uncomfortable, because a vote feels fairer than a veto and a week of reflection feels more careful than a same-day call. It's also slower, and slow is a decision too: your best candidates have other processes running, and the company that answers first often wins regardless of who scored higher.

Keeping candidates informed

Tell candidates the stages, the rough duration of each, and what happens next before they agree to the first one. Give a real date for the next update instead of "we'll be in touch," and put one name on it so they know who to ask.

Answer inside whatever window you promised, even when the answer is "still deciding." Silence is what candidates remember and repeat to other candidates. When someone doesn't make it past a stage, tell them yourself instead of letting the posting quietly close: it costs you one uncomfortable call, and costs them finding out from a rejection email that took three weeks to arrive.

This is the piece that slips first once the team gets busy, since it has no deadline but the one you set for yourself. Put update dates on a calendar the day you schedule the interview, not on a list you mean to get to.

What to measure after ninety days

Retention at ninety days is the obvious number, but it's a lagging one, and it only catches the hires who failed loudly. Ask the manager directly whether they'd hire this person again knowing what they know now. That question catches the quiet underperformance a retention count misses.

Check whether the interview scores correlated with anything. If your highest scorer is struggling and a borderline hire is thriving, the rubric is measuring something other than the job, and it's worth finding out what before the next ten candidates go through it.

Track the offer-accept rate separately. A process that produces the right yes but loses the candidate before they sign is failing on tone, speed, or communication, not scoring. Add up the actual hours the process costs too: stage durations times the number of people who went through each one. If that number eats a sprint every time you hire, the process is too expensive for the team running it, whatever the quality of the hires it produces.

None of this needs to be complicated, but it does need to be written down before the first candidate arrives, so the second candidate gets the same process as the first. If you want a rubric to start from instead of a blank page, you can generate a role-specific assessment from a pasted job description at tryevaluator.com/try, no signup, and adjust the scorecard from there.