In this article
Before you start
This page belongs to the machine coding and industry coding guide, which covers the neighbouring round formats.
Why interviewers ask this
A build-something round shows whether you can turn a loose request into running software within a fixed time, a skill a puzzle round never tests. The variant called machine coding round is reported to run 60 to 120 minutes, typically 90, keep data in memory and end with a code review. Integration variants reported for Stripe are open-book: a repository, API documentation and internet access, with errors, pagination and changing requirements (DesignGurus, Exponent). These are candidate accounts, not company statements, and they disagree on length, so confirm the format with your recruiter. Candidates also report todo-list, traffic-signal and service-building tasks in this family.
A weak candidate shows a diagram and half-working code. A strong one shows a small program that runs, handles bad input and explains its trade-offs. A Staff-level candidate also names what was left out and why.
Build-something rounds from first principles
- Build-something round
- A build-something round is a timed coding interview that asks you to produce small software that runs, such as a todo app, a service with a few endpoints or a client for an existing web interface, and then to explain your choices to the interviewer in a short discussion or code review.
- Idempotent method
- An idempotent method is an HTTP request type for which several identical requests leave the server in the same state as one request would, so a client unsure whether a call arrived can send it again without doubling the effect.
In plain words
Imagine a client who asks a carpenter for a small shelf and watches the work. A good carpenter first fixes one plank so the shelf stands. Sanding and a second shelf come later, if time remains. The client prefers a standing shelf to a perfect drawing.
The analogy breaks in one place. In an integration round the interviewer may keep adding to the request and listen to your reasoning while you work. In a machine coding round you mostly work on your own and explain afterwards, since one prep guide describes the interaction as minimal.
In one precise sentence, the round grades whether you can deliver a small, correct, running program under time pressure and explain the trade-offs you chose.
Step 1: Clarify the request and list the entities
Clarifying means turning a loose prompt into a short list of entities, operations and assumptions before any code. Input: the prompt, for example a todo list where a user adds, completes, edits and deletes short tasks and sees active and completed ones apart. Output: one entity (task: id, title, done flag) and five operations (add, complete or reopen, edit, delete, list by state).
Say your assumptions aloud: data lives in memory, one user, no login. For a machine coding round, add a quick sketch of the domain model: the entities and the two or three places where behaviour varies. Thita's guide gives this sketch the span from minute 5 to minute 15 of its 90-minute split. In an integration variant, clarifying also means reading the documentation first. A candidate-written guide reports a repository, API documentation and full web access, with AI coding assistants not permitted (Exponent). In the illustrative plan below this step takes 5 of the 90 minutes.1 You now have a contract to build against.
Step 2: Get the smallest working core running first
The smallest working core is the shortest path from input to visible output for the main use case, built on the small domain model from the first step and kept running while you add to it. A prep guide puts it as: "Get the smallest working version of the core flow running early, then improve its structure." For the todo app that is a task record, a dictionary of tasks and add, complete and list functions, run from a few lines that print the result. The same guide says to keep it running at all times.
Thita's guide lists nothing running at the end and over-engineering early as failure modes, and Low Level Design Mastery lists one giant class. A god class is one class that holds most of the program's behaviour. The smallest working core comes before any refactor, because machine coding requires working code, not just design. Input: the contract from the first step. Output: code you can run in front of the interviewer by minute 50 of 90 in the illustrative plan.1
Step 3: Handle bad input, failures and retries
Edge cases and tests come after the core runs. Edge cases are inputs and events the happy path ignores: an empty title, an unknown task id, completing a task twice, deleting one that is already gone. For an integration task they are the API's failures. Check the status code, the number a server returns to say what happened, on every response, and read error messages carefully, because candidate reports say interviewers watch how you behave when something fails on the first try. Pagination is the splitting of a long result list into pages that you fetch one at a time, so loop until the last page.
Retries add one idea. Under Request for Comments (RFC) 9110, section 9.2.2 (Internet Engineering Task Force (IETF) HTTP Working Group), the methods PUT and DELETE and the read-only methods (get, head, options and trace in the standard's list) are idempotent, while POST is not, and the tunnelling method named connect is not either. The plan gives this step 20 minutes.1
Step 4: Refactor lightly, then say what you left out
The last minutes go to structure and to the walkthrough. Move behaviour into a few small classes or modules with one responsibility each, write a short notes file saying how to run the code, and rehearse the explanation. The walkthrough names what was left out and why. The prep guide says that naming what you left out and why "converts an unfinished solution into evidence of judgement."
For the todo app the list of omissions is short. There is no persistence because data lives in memory, no login because there is one user, and no locking because one process serves one user. Input: working, tested code. Output: tidy code and a short spoken tour of the design. The illustrative plan gives refactoring and the walkthrough 10 minutes each.1 Notice that this step only works if the earlier ones left something running.
Step-by-step description
- List entities, operations and assumptions.
- Get the smallest working version running.
- Handle bad input, failures and retries.
- Say what was left out and why.
- The smallest working core comes before any refactor.
- Edge cases and tests come after the core runs.
- The walkthrough names what was left out and why.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take a 90-minute todo round. The plan below is our own illustrative heuristic, not a published rubric. For comparison, Thita's published 90-minute split uses the boundaries 0–5, 5–15, 15–60, 60–75, 75–85 and 85–90 minutes, with the domain-model sketch at minutes 5 to 15. The same guide says correct output is necessary but not sufficient, because a clean domain model and well-placed abstractions are what distinguish a strong submission. In our plan the core flow gets 45 of the 90 minutes, and the code runs end to end by minute 50.1
| Phase | Minutes | Share of 90 | Ends at minute |
|---|---|---|---|
| Clarify and list entities | 5 | 5.6% | 5 |
| Core flow | 45 | 50.0% | 50 |
| Edge cases and tests | 20 | 22.2% | 70 |
| Refactor and notes | 10 | 11.1% | 80 |
| Walkthrough preparation | 10 | 11.1% | 90 |
Text description of the diagram
- The core flow gets 45 of the 90 minutes.
- Clarifying takes 5 minutes and the walkthrough preparation takes 10.
Now trace the app. Six hand-made operations (three adds, completing task two, editing task one, deleting task three) leave one active and one completed task.1 Deleting task three a second time changes nothing, which is the idempotent effect on the data even if the second call reports not found.1
| Step | Operation | Active | Completed |
|---|---|---|---|
| 1 | add "write notes" | 1 | 0 |
| 2 | add "email recruiter" | 2 | 0 |
| 3 | add "book room" | 3 | 0 |
| 4 | complete task 2 | 2 | 1 |
| 5 | edit task 1 | 2 | 1 |
| 6 | delete task 3 | 1 | 1 |
Last, a retry simulation. Three identical create requests without a key store 3 records, while the same three with one idempotency key store 1.1 Reusing the key with different parameters returns a conflict and stores nothing new.1 Stripe's layer behaves the same way: it errors if the parameters differ from the original request. A hand-built key store might choose 409 Conflict for that case; it is one of the status codes in RFC 9110 section 15.
Last, the todo service as an API. The status codes below are the ones defined in RFC 9110 section 15.
| Endpoint | Success | Failure |
|---|---|---|
POST /tasks | 201 Created | 400 on an empty title |
GET /tasks?state=active | 200 OK | none expected |
PATCH /tasks/{id} | 200 OK | 404 for an unknown id |
DELETE /tasks/{id} | 204 No Content | 404 on a repeat delete |
Trade-offs and edge cases
Build rounds trade depth for runnability. Machine coding stores data in memory, while integration rounds call an external API. User interface (UI) component rounds are reported by candidates to grade testing and accessibility.
Text description of the diagram
- Machine coding stores data in memory, while integration rounds call an external API.
- UI component rounds are reported to grade testing and accessibility.
The core-first rule bends in open-book rounds. If the task is to wire a feature to an API, spend the first minutes reading the documentation, because a wrong endpoint costs more than reading does. Extensibility is a second balance. Separate responsibilities where the prompt hints at change, but do not add an interface for every noun, since over-abstraction reads as pattern application without judgement.
In-memory rounds often reduce to data-structure choices, as in an least recently used (LRU) cache implementation in Python or the CodeSignal in-memory database levels. For a UI task, see the frontend interview questions. For design vocabulary, the low level design questions cover class structure.
What is an idempotency key, and does a build round need one?
An idempotency key makes a create request safe to retry. Stripe's reference says the client generates a unique key and the server uses it to recognise retries of the same request. Keys are up to 255 characters long and all POST requests accept them in API version 1. Sending one on GET or DELETE has no effect, and keys may be removed automatically once they are at least 24 hours old. Results are saved only after the endpoint begins to execute, so validation failures and concurrent-request conflicts are not saved and can be retried.
You rarely build a key store in a round. One sentence about it shows you know why retrying a POST can create duplicates, a theme also found in the hotel reservation double-booking problem. Retries against a failing service are bounded by the circuit breaker pattern.
How to answer it in an interview
How would you approach a build-something round?
I spend the first few minutes clarifying the request and listing the entities and operations, and I read any API documentation before writing code. Then I build the smallest end-to-end version that runs, with data in memory, before I touch structure. Next I handle bad input, errors and retries, and I add tests for the cases I can name. Last I tidy the code and tell you what I left out and why, for example persistence or authentication, so you can see my judgement even where the code is incomplete.
The spoken structure: clarify, get the core running, harden it, then name the omissions.
Common mistakes
- "I'll spend the first half hour on a full class hierarchy before anything runs." (wrong) A hierarchy without running code fails a round that expects working software. (right) "I'll sketch the entities in a few minutes, get the core flow running and keep it running."
- "I'll start typing at minute 0 with no plan." (wrong) Low Level Design Mastery lists jumping straight to code with no plan as a deadly mistake. (right) "I'll sketch the domain model first, then build on it."
- "I'll put an interface on everything so it is extensible." (wrong) Over-abstraction reads as pattern use without judgement. (right) "I'll add an interface only where the prompt hints that behaviour will change."
- "I should not look at the documentation; it looks weak." (wrong) Integration rounds are open-book, and reading closely is part of the grade. (right) "Let me read the endpoint documentation before I choose one."
- "
POSTis idempotent, so retries are safe." (wrong)POSTis not idempotent by default. (right) "I'd attach an idempotency key so a retry returns the first result." - "I ran out of time, so I have nothing to explain." (wrong) Unexplained gaps look like blind spots. (right) "I did not build persistence; here is how I would add it."
Follow-up questions
What is a machine coding round?
A machine coding round is a timed task that asks for runnable, well-structured code, with data usually in memory and a code review at the end. Reported lengths range from 60 to 120 minutes (Low Level Design Mastery).
How long is a build-something round?
The format decides it. Machine coding is reported at 60 to 120 minutes, typically 90, while candidate accounts of integration rounds disagree, so ask your recruiter and plan from the stated time.
Can you use the internet in an integration round?
Candidate reports describe full internet access for syntax and library lookups, plus API documentation (DesignGurus). One candidate-written guide adds that AI coding assistants are not permitted in that round (Exponent). Confirm the rules for your round, and show how you use the documentation.
How is a build-something round different from a LeetCode round?
A puzzle round grades an algorithm on a small input. A build round grades running software, structure, error handling and your explanation. Both are covered in the industry coding guide.
What do interviewers look for in a machine coding round?
A strong answer shows readable code, separated responsibilities, room to extend it and correct behaviour on edge cases. It also shows a working core early and a clear account of what was left out.
How would you productionise it?
Persistence comes first: replace the in-memory dictionary with a database so data survives a restart. Then add authentication so each user sees only their own tasks, guard concurrent updates with transactions or locks, and log each request so failures can be traced.
- A build-something round grades running software plus your explanation, not a puzzle answer.
- Clarify, build the smallest working core, harden it, then name what you left out.
- In open-book rounds, read the documentation first and check every status code.
POSTis not idempotent by default; an idempotency key makes retries safe.- Over-engineering early and nothing running at the end are the failure modes to avoid.
Sources
- Idempotent requests - Stripe API Reference — Stripe documentation (live page, undated; access date given), 26 Oct 2026
- RFC 9110: HTTP Semantics — IETF HTTP Working Group, 6 Jun 2022
- Stripe Software Engineer Interview Guide — Exponent (candidate-reported; access date given), 26 Oct 2026
- What Is the Stripe Interview Process Like? (Round by Round) — DesignGurus (candidate-reported; access date given), 26 Oct 2026
- Machine Coding Round: The Complete Interview Preparation Guide — Low Level Design Mastery (access date given), 26 Oct 2026
- Flipkart Machine Coding Round: The 90-Minute Test — Thita (access date given), 26 Oct 2026
