How to build an engineering interview process from scratch

A startup needs four interview stages, not seven: a recruiter or founder screen, a technical phone screen, a focused work sample, and an onsite of two or three back-to-back sessions. Anything more is borrowed from companies with thousands of engineers and a brand that survives a slow process. You do not have that brand yet, so your process has to win on speed and clarity instead. This post is the build order: what each stage decides, who runs it, and how to keep the full loop from first reply to offer under 10 business days.

If you are hiring your first one or two engineers, the calculus shifts further and is worth its own read in first engineering hires after a seed round. Everything below assumes you are building a repeatable loop you will run more than twice.

What stages does a startup interview process actually need?

Each stage exists to answer one question and reject on one thing. If a stage cannot tell you who to reject, it is a meeting, not a stage. Here is the minimum viable loop and the single decision each stage owns.

Notice what is not here: no take-home that eats a candidate's weekend, no fifth round, no panel of six. The work sample is paid or capped at 90 minutes. We weigh that tradeoff in are take-home assignments worth it. The principle is that every stage you add costs you candidates, because every stage is another chance for a faster company to close them first.

How do you design the screen so it does real work?

The screen is not a formality. It is the cheapest place to reject, so it should reject hard on the things that are non-negotiable: level, location and work authorization, comp range, and genuine interest in what you are building. Put the comp range on the table in this call. If your band is $160,000 to $190,000 plus 0.4 to 0.8 percent (illustrative, not advice) and the candidate needs $230,000 cash, you both just saved four hours.

• State the comp band out loud. Hiding it until the offer wastes everyone's time and tanks your close rate.
• Confirm location and visa needs. If you cannot sponsor, say so now. See visa sponsorship for startup engineers.
• Ask one motivation question. Why a startup, why this one, why now. Vague answers here predict slow closes later.
• Sell for five minutes. The screen is bidirectional. The candidate is screening you on funding, runway, and the bet.

A founder should run the screen for the first dozen hires. You are the best salesperson for the company, and you learn what candidates actually ask, which sharpens your job posts and your pitch.

How do you design the technical phone screen?

The phone screen tests one thing: can this person reason about a real problem out loud while another engineer watches. It is not a puzzle round and it is not a trivia quiz. Give a small, concrete problem in your actual domain, let them use their own editor, and pay attention to how they ask clarifying questions, not just whether they reach the answer.

Pick a problem you can run identically with 20 candidates, because consistency is what makes the scores comparable. A good shape is a 30-minute coding problem plus 10 minutes of follow-up on how they would extend it, plus 5 minutes for their questions. Our deeper guide is how to run a technical phone screen.

If two interviewers cannot run your phone screen and reach the same verdict on the same candidate, you do not have a phone screen. You have a vibe check.

How do you design the work sample without scaring people off?

The work sample is the stage that most predicts on-the-job performance, and the one most often built badly. The failure mode is a multi-day take-home that filters for people with free time rather than people who can do the job. Cap it. A 90-minute live pairing session on a stripped-down version of a real ticket beats a 12-hour homework assignment on every axis that matters: signal, fairness, and how it makes the candidate feel about you.

1. 01Use a real but bounded task. A bug in a small repo, a feature on a toy API, a query that needs optimizing.
2. 02Pair, do not abandon. An engineer sits in, answers questions, and watches the working style. That is the signal.
3. 03If it is async, pay for it. A 3-hour paid sample respects the candidate's time and widens your pool to people who already have jobs.
4. 04Score against a rubric you wrote first. Decide what 'strong' looks like before the candidate starts, not after.

How do you keep the onsite focused?

The onsite is two or three back-to-back sessions, not a full day. For most startup roles that means: one system design session, one collaboration or code-reading session, and a founder conversation on values and the bet. Each interviewer owns a distinct area so you are not testing the same thing three times. For the design session, our prep guide for the other side of the table is startup system design interview prep, and it tells you what good answers look like too.

• Assign areas in advance. Write down who covers design, who covers collaboration, who covers values. Overlap is wasted signal.
• Brief every interviewer. Share the resume, the role, and the one thing their session must decide. Five minutes of prep prevents a wasted hour.
• Debrief same day. Memory decays fast. Collect written scores before anyone talks, then discuss. This is the heart of structured interviews and scorecards.

Who runs what, and how do you not burn your engineers?

Every onsite hour costs you two engineer-hours once you count prep and debrief. A team of five running a four-stage loop on 8 candidates a month is spending real time. The fix is not to skip stages. It is to assign owners, rotate the load, and pull people out of the loop the moment their scores stop adding signal.

Founders should stay in the loop on the screen and the final values conversation. Engineers run the technical phone screen, the work sample, and the design session. A coordinator (an EA, an ops hire, or a recruiting partner) owns scheduling, because a candidate waiting three days for a calendar invite is a candidate you are losing. Speed is itself a hiring advantage, and we make the full case in how to run a fast engineering interview loop.

How do you keep the process fair?

Fair and fast are the same project. Both come from consistency: the same questions, the same rubric, the same stages for every candidate for a given role. When interviewers freestyle, two things happen at once. Your signal gets noisier, and your process drifts toward hiring people who remind interviewers of themselves. A written scorecard fixes both. It forces interviewers to judge against the job instead of a gut feeling, and it gives you a paper trail when you compare candidates.

• Write the rubric before you interview anyone. Define what strong, mixed, and weak look like for each area.
• Collect independent scores before the debrief. No anchoring on the loudest voice in the room.
• Use the same loop for every candidate at a level. Skipping a stage for one person breaks comparability and invites bias.
• Keep reference checks structured too. See how to do engineering reference checks.

How do you iterate the process with data?

A process you never measure quietly rots. Track four numbers per stage and review them every quarter. The point is not a dashboard for its own sake. It is to find the stage that is rejecting good people or passing bad ones, and fix that one stage.

One concrete example. If your work sample passes 90 percent of people but a third of your hires struggle in their first quarter, the work sample is not testing the job. Rewrite it against a real ticket and re-baseline. If your offer accept rate is 50 percent, the leak is usually comp or speed, and the playbook is how to make a startup offer candidates accept.

Build the four stages, write the rubric, assign the owners, and measure quarterly. That is the whole job. The companies that win senior engineers are rarely the ones with the cleverest questions. They are the ones whose process is fast, consistent, and respectful of a candidate's time.