How does a seed-stage startup's hiring loop differ in stages and timeline from a big-company loop?

## What "unstandardised" actually means A large company's loop is a product: it has named stages, a written rubric per stage, interviewers trained to that rubric, and a review body that reads the written evidence and decides. A seed-stage startup has none of that machinery. Ten or fifteen people are trying to hire their next engineer while shipping, and the hiring process is whatever the founder decided it should be, usually captured in a one-page note titled something like *how we hire*. That note is the closest thing to a rubric that exists, and it is often shared with candidates on request. The practical consequence: **the stage list is a property of that company, not of the industry**. Two startups at the same funding stage may run completely different loops, and the same company may run a different loop for its next hire than it ran for you. ## The stages you usually see 1. **A founder or hiring-manager conversation.** Frequently the first contact, not a screen delegated to a recruiter. It is a decision round, not a warm-up, and it runs in both directions: the founder is also selling. 2. **A practical round on real work.** Either a scoped take-home, or a session where you work alongside an engineer on something close to the live product. Small companies weight "can you ship something in our actual environment" far above puzzle solving. 3. **A team or values conversation.** One or two of the people you would sit next to, testing how you scope ambiguous work, how you handle disagreement, and whether they want you in the room every day. 4. **Sometimes a paid trial engagement** instead of, or on top of, the practical round. What you usually do *not* see: a timed automated assessment, a separate recruiter screen, four back-to-back interviews in one day, a reviewer from an unrelated team, or a committee reading write-ups from people who never met you. ## The timeline One to two weeks end to end is the register here. Scheduling is the bottleneck at a big company; at a startup the bottleneck is the founder's calendar, and founders can clear it. Compression cuts both ways: you get a decision fast, and you also get very little contact time in which to evaluate them. ## Who decides, and on what Usually one person, occasionally two, and often on impressions rather than written evidence. There may be a shared document with a paragraph per conversation, or there may be a five-minute hallway conversation and a yes. This is why a strong impression in the founder conversation carries disproportionate weight, and why a weak practical round is harder to recover from than in a loop with six independent signals. ## A worked example A nine-person seed-stage company is hiring its fourth full-stack engineer. Its one-page *how we hire* note lists three conversations across eleven calendar days: a forty-minute founder call, a paired session on a real bug in the product queue, and a half-hour with the two engineers already on the team. The note names the founder as the decision-maker and says the team round is advisory. A candidate who read that note prepared by studying the product, sketching how they would scope the kind of work in the queue, and writing questions for the founder. A candidate who did not read it spent the eleven days drilling algorithm puzzles for a round that this loop never contained, then found the paired session unfamiliar because they had prepared for a different loop entirely. ## Scale-ups sit in between Once a company is past its early rounds and hiring steadily, structure appears: a real recruiter, a written stage list that mostly holds, sometimes a design or architecture round, and a debrief with more than one voice. Timelines stretch toward two or three weeks. Treat "startup" as a spectrum from *the founder decides on Friday* to *a small but genuine process*, and calibrate by asking rather than by headcount alone. ## What to do with this Ask, early and in writing, what the conversations are, who is in each one, whether there is a practical component, and what decides yes or no. That single question converts an unstandardised loop into a known one, and it is the difference between preparing for the loop you are in and preparing for a loop you once read about.