Before preparing for a startup's interview loop, how do you find out which rounds it actually contains?
answer
- Do not guess the syllabus, request it
- One short message, four questions
- Stages, people, practical component, decision
- Ask for their how-we-hire write-up by name
- Then reallocate the preparation hours
basics
~10 sAsk the founder or hiring manager, in writing, what each conversation is, who is in it, whether there is a practical or trial component, and what decides the outcome. Then prepare against that list.
solid answer
~50 sStartup loops are not standardised, so the stage list is information you have to request rather than assume. Before the first conversation, ask the founder or hiring manager four things in one short message: what the conversations are and in what order, who is in each one, whether there is a take-home, paired session or trial project, and what they are deciding on at the end. Many small companies keep a one-page `how we hire` note and will simply send it. If none exists, the answers you get in reply become your map. Then prepare against that map: study the product and the problem space when the loop is a founder chat plus a paired session, and spend your time differently when a design conversation is on the list. The expensive mistake is drilling algorithm puzzles for a loop that never asks one.
go deeper
Be ready to say that you ask what the conversations are before you prepare, rather than assuming a standard sequence. Know the four things worth asking: stages, people, practical component, and how the decision gets made.
Explain how each answer changes your preparation: a paired session on live code, a take-home, and a design conversation demand three different kinds of practice. Be able to describe the written one-page hiring note and how to request it.
Demonstrate that you re-ask when the loop changes mid-process, and that you read the quality of the answer as information about the company, not just as scheduling detail. Show that you can plan around a one-to-two-week decision window.
Own the judgment call about how much process to demand from a small team. Pushing for written structure can be right, and it can also cost you a fast-moving company's goodwill; be able to say where you draw that line and why.
## Why this is a real skill and not just admin In a standardised loop the stages are published, so preparation is a syllabus problem. In a startup loop the stages are a company-specific decision, sometimes made the week you applied. If you do not ask, you will prepare from a mental template built out of other people's interview stories, and that template is usually a big-company one: automated assessment, algorithm screens, a design round, a behavioural round. A three-conversation seed-stage loop contains none of those, and the hours you spent are gone. ## The four questions that convert an unknown loop into a known one Send them as one short, low-friction message, before or right after the first scheduling email: 1. **What are the conversations, and in what order?** You are asking for the stage list, not a promise. 2. **Who is in each one?** A founder, an engineer you would work with, a non-engineering co-founder and a prospective peer all evaluate different things and can answer different questions of yours. 3. **Is there a practical component, and what shape?** A scoped take-home, a paired session on live code, or a longer trial engagement are three very different asks on your time. 4. **What are you deciding at the end?** This surfaces whether there is a written rubric, an advisory team round, or one person's judgment. A fifth, when the loop is long or you have competing timelines: **what is the expected end-to-end duration?** At seed stage the honest answer is usually one to two weeks. ## The artefact to ask for by name Many small companies write a one-page note for candidates: the stage list, roughly what each round involves, sometimes the trial-project brief attached. Asking "do you have a short write-up of how you hire that I could read first?" is normal, costs the founder nothing, and gets you a document rather than a paraphrase. Two useful side effects: a company that has one has thought about fairness, and a company that cannot describe its own loop has told you something worth knowing. ## Reading the map correctly The answers change what you do with your preparation hours: | What the map says | What to spend the hours on | |---|---| | Founder chat plus paired session on live code | The product, its domain, how you would scope work in it; get fluent reading unfamiliar code quickly | | Take-home plus a walkthrough conversation | Scoping, finishing, and being able to defend your choices out loud | | Trial engagement of a few days | Terms and logistics first, then the work itself | | Team round with the two existing engineers | Concrete examples of how you work with others, and questions of your own | | A design or architecture conversation added | Structured practice at explaining tradeoffs at the scale that company actually operates | ## A worked example A candidate is talking to a nine-person seed-stage company about a full-stack role. They ask for the *how we hire* note before scheduling. It comes back as one page: a forty-minute founder call, a paired session on a real bug from the product queue, a half-hour with the two engineers on the team, eleven days from first call to decision, founder decides. Nothing on that page is an algorithm round. The candidate reallocates: two evenings reading the public product and writing down what they do not understand about the domain, one evening practising reading unfamiliar code under time pressure, and a list of questions for the founder about ownership and roadmap. Their friend, interviewing at a similar company the same month, spent three weeks on puzzle drills instead and walked into a paired session cold. Same market, same seniority, opposite return on the hours. ## When the map turns out to be wrong Unstandardised loops flex, and a stage may be added mid-process. Treat that as normal, and re-ask: "happy to do that; what will that conversation cover and who is in it?" It becomes a genuine concern only when the additions keep growing the unpaid work, or when nobody will say what the added round is for. ## The failure this prevents The single most common wasted preparation in small-company hiring is drilling algorithm puzzles for a loop that never asks one. It feels like diligent work because it is measurable and gamified, and it is the wrong syllabus. The four questions above cost one message and remove the guess.
- Does asking for the stage list up front make you look high-maintenance?In practice it reads as professional. You are asking so you can arrive prepared and so you can plan around other commitments, and most founders answer in two lines. Keep it short, ask once, and bundle the questions into a single message rather than trickling them out across a week.
- What if the founder replies that the process is flexible and they will see how it goes?Take that as the answer and narrow it: ask what the next conversation covers and who is in it, then repeat before each stage. You have learned something real, namely that no written stage list exists, which tells you the decision will rest on impressions rather than recorded evidence.
- How do you prepare when the loop's only technical round is a paired session on their live code?Practise the skills that round actually tests: reading unfamiliar code quickly, asking clarifying questions out loud, narrating your reasoning, and making small safe changes with tests. Study the product itself so the domain is not also unfamiliar. Puzzle drills do not transfer to this format.
saying these in an interview costs you the question
- Preparing only algorithm drills without asking what the rounds contain
- Never asking whether a written how-we-hire summary exists
- Assuming a startup's stage list matches a big-company template
- Asking about the process only after the practical round is over
- Treating a mid-loop added conversation as automatically a bad sign