Problem-solving interview guide
Reasoning, not memorised architecture. Every question carries the situation behind it, what it is actually testing, what a strong answer sounds like, and the flags on both sides. The red flags are what a confident, fluent candidate really does — a framework named before an actor, an estimate given before a decomposition, generated code they cannot explain.
The shape of a strong answer
The seven steps an interviewer listens for, in the order they should appear.
The candidate restates what is being asked in their own words, as a problem with a gap, before proposing anything. "Build a store" becomes "a customer can find a product, pay, and be told it worked; an admin can list products".
listen for Nouns and verbs, not technologies. A restatement the interviewer would correct if it were wrong — which means it says something. A goal separated from any implementation already smuggled into the brief.
The candidate asks what the brief did not say, and prioritises the questions whose answers change the design — who uses it, how many, what must never happen, what is outside the system — over the ones that change a detail.
listen for Questions with a decision behind them: "may a customer check out without an account?" changes the data model; "which cloud?" does not. A candidate who asks nothing has assumed everything; one who asks everything cannot tell which questions matter.
The candidate states, unprompted, what they are taking as true — one currency, one warehouse, accounts required — and marks the assumptions that would invalidate the design if wrong.
listen for The word "assuming" followed by something specific, and a note of which assumptions are dangerous. Assumptions stated after being asked count for less than assumptions volunteered.
The candidate breaks the problem into pieces that can each be understood and tested on their own — by capability, not by layer — and shows the dependencies between them.
listen for Leaves that can pass or fail. A tree whose children are "frontend, backend, database" is the shape of every application; one whose children are "browse, cart, checkout, orders, payments" is the shape of this one.
For each decision, the candidate names the dimensions it moves — simplicity, performance, reliability, cost, security, time, maintainability — and what the chosen option costs, not only what it gains.
listen for "This is simpler and it means X will not work" rather than "this is better". Reversible decisions taken quickly and irreversible ones held to more evidence. The simpler thing named and rejected for a reason, or accepted.
The candidate says what they would build first and why — a slice through every layer, then the riskiest unknown — and what each step proves.
listen for An order justified by dependency and risk, not by comfort. A walking skeleton with an honest "this proves the layers connect and nothing else". Complexity added only against a named requirement or measurement.
After the happy path, the candidate asks what happens when payment fails, the request repeats, a dependency times out, the browser closes — and distinguishes a failure the system knows about from one it does not.
listen for "Declined", "timed out" and "sent twice" treated as three different problems. A timeout described as "unknown", not "failed". An idempotency key that comes from somewhere specific.
Green flags and red flags
Both columns are about reasoning, not vocabulary. Saying 'MVP' is not a green flag; saying what cannot be simplified is.
- Clarifies ambiguous goals before proposing anything, and restates the problem in a form the stakeholder could correct.From a Vague Goal to an Explicit Problem
- Identifies invariants — what must never break — and can say how each would be checked.What Must Never Break
- States assumptions unprompted and marks which ones are dangerous.Making Assumptions Explicit
- Separates what is known from what is unknown and turns each unknown into a question with an experiment.Known and Unknown
- Decomposes by capability into pieces that can each pass or fail on their own.What Makes a Good Subproblem
- Proposes vertical slices and is honest about what a passing slice does not prove.Vertical Slices
- Uses concrete examples — three units, two buyers — to find edge cases and to test a proposed fix.Example-Driven Thinking
- Forms a hypothesis before touching anything and predicts what an observation will show.Predict Before You Look
- Seeks evidence — a trace, a log line, a measurement — before a diagnosis or a component.Logs Are Evidence, Not Thinking
- Prefers reversible decisions and raises the evidence bar for irreversible ones.Reversible vs Irreversible Decisions
- Avoids premature complexity and can say which requirement or reading would justify each component.Add Complexity Only When Required
- Explains trade-offs as costs, not only benefits, and names the simpler thing.Trade-Off Thinking
- Knows when more information is needed, and asks for it in a form that can be answered in a line.Asking People
- Uses tools — documentation, search, AI — without surrendering ownership; can explain every line they submit.What You Still Own
- Immediately picks technologies — a framework, a database, a queue — before the problem has been stated.Technology-First Thinking
- Codes before understanding: opens an editor while the actors, workflow and invariants are still unknown.Problem Before Technology
- Copies an architecture from a well-known system without the requirements that produced it.Before You Copy Code
- Cannot explain their own code — a branch, a lock, a retry — because a tool or a tutorial wrote it.Understanding Is Not Delegable
- Adds scale before load: caches, replicas and queues with no measured bottleneck behind them.The Complexity Ledger
- Asks an AI for the full implementation as the first move, then reviews code for a problem they have not framed.If You Are Nothing Without the LLM
- Changes random things while debugging — restarts, config, timeouts — and observes nothing between changes.Do Not Randomly Change Things
- Treats unfamiliarity as a blocker: "I don't know payments, so I cannot start."An Unknown Is Not a Blocker
- Ignores failure cases: the happy path is the design, and "handle errors" is a trailing comment.Failure Path Second
- Refuses to simplify: every feature on the list is in V1 and every component is "needed eventually".What Is Not V1
- Assumes tutorials represent production: the tutorial's shortcuts become the design's decisions.Tutorial Dependency
Questions
A founder in a kickoff call: "We need an online store for our products — nothing fancy, we just need to sell online by the end of the quarter. Can you build it?" There is no document. The founder has a spreadsheet of about forty products (illustrative) and a Stripe account somebody opened last year. You have forty-five minutes with them.
A product lead drops a ticket titled "Make checkout better" into your queue. The body says: "Customers complain. Conversion is lower than we want. Please look into it." There is a dashboard nobody trusts and a support inbox nobody reads.
A brief for a file-upload service: "Users upload documents from the web app; other users download them. Max file size is 50 MB (illustrative). Use S3 or similar." That is the whole brief. You are asked to estimate it by Friday.
You join a three-person team building an analytics dashboard for an internal sales team. The tech lead shows you a diagram with a stream processor, a columnar warehouse and a caching layer, and asks you to "review the architecture". Nobody has told you how many users, how much data or how soon.
A payments engineer is leaving and you inherit checkout for the online store. In the handover they say "it mostly works, there are some edge cases". There are no tests for checkout. You have a week before a marketing campaign doubles traffic (illustrative).
Midway through a design discussion for a URL shortener, the interviewer stops you and asks: "Everything you have said so far rests on assumptions you have not stated. Name them." You have been describing a hash-based key, a single table and a redirect endpoint.
A junior engineer on your team has been assigned the checkout payment step. Two days in, they say: "I don't understand payments. I think we need someone with payments experience before I can continue." They have read the provider's documentation home page and watched a video.
You are on an interview panel. A previous interviewer asked the candidate to decompose "build a chat app" and pinned the result to the shared doc. You have ten minutes to assess it and decide what to ask next.
In a design review for the online store, a senior colleague says checkout should publish an event to Kafka so that email, analytics and the warehouse can consume it. The store currently sends the confirmation email inside the checkout request and has a few hundred orders a day (illustrative). The colleague has run Kafka before and is confident.
The admin of the online store edits a product's price from 20 to 25. A customer has that product in their cart; another customer bought it yesterday and is about to request a refund; the analytics dashboard shows revenue for last week. The interviewer asks: "What should each of those see, and where should the price live?"
Support reports that checkout "feels slow". An engineer has already opened a profiler on the database server and is reading disk-latency graphs. The interviewer asks: "Is that the right level, and how would you decide?"
Your team of three has two weeks (illustrative) before a demo of the online store to an investor. The tech lead proposes: week one, the data model and all migrations; week two, the API; the frontend "when we get to it". You are asked whether you agree.
A stakeholder for the online store says "let's do an MVP" and then lists twelve features. A developer says "MVP means we can skip tests and security for now." The interviewer asks you to draw the line.
The interviewer gives you one sentence — "a customer places an order containing several products, pays for it and may later return some of them" — and a whiteboard. "Find the data. Do not draw a schema yet."
In the online store, checkout calls the payment provider, the inventory service, the email sender and the analytics collector. A slow email API took checkout down last week (illustrative). The interviewer asks: "Which of these is a boundary, which must answer before the user sees a confirmation, and how would you treat the rest?"
The online store's orders table has a free-text `status` column. Values seen in production include "paid", "PAID", "shipped", "cancelled", "refunded", "paid-then-cancelled" and "". A support engineer asks whether a shipped order can be cancelled. Nobody knows.
A candidate has just walked through checkout for the online store: cart → create order → charge card → mark paid → send email. The interviewer says "good — now the card is declined. Then the provider times out. Then the customer double-clicks Pay."
The interviewer hands you a marker: "Write the server side of 'Pay' for the store in pseudocode — inputs, outputs, state, branches and failures. Not a language, not a framework. Then tell me what you learned by writing it."
You are asked to explain, on a whiteboard, what should happen and what will happen in the online store when two customers buy more than the remaining stock at the same moment. The current code reads stock, checks it, and writes stock minus quantity.
A teammate proposes "a two-week prototype of the AI assistant over our documentation, to see if it works". The interviewer asks you what you would say in the planning meeting.
A production alert: some checkouts in the online store return "Payment failed" although the customer's bank shows a charge. An engineer's terminal history from the last hour is pinned to the incident channel. You are asked to review it and say what to do next.
A bug report: "Search results sometimes show products that are out of stock." The product search service was written by a team that no longer exists. It has about a thousand files (illustrative), no README worth the name, and a passing test suite. You have a day.
The chat app's product owner wants video calls. Nobody on the team has touched WebRTC. You are given a day to "look into it" and report back. The interviewer asks what your report will contain and what it will not.
A teammate posts in the team channel: "How do payments work?" Nobody answers. The interviewer asks you to rewrite the question three times, each better than the last, and to say what the best version makes answerable.
A tech lead has to choose the store's primary database this week and asks two engineers for a recommendation. One says Postgres, one says MongoDB, both with conviction. The interviewer asks how you would settle it without a fight.
In sprint planning, an engineer estimates the online store's "returns and refunds" feature at two weeks. The product manager writes it in the roadmap. The interviewer hands you the estimate and asks what is wrong with it and what you would do instead.
The online store's search is a SQL `LIKE` query and customers complain they cannot find things. A hosted search vendor has quoted a monthly fee; an engineer wants to run an open-source search engine; another says a Postgres full-text index would do. The interviewer asks how you would decide.
A candidate was asked to design a todo app for one user — themselves — and pinned their proposed architecture to the doc. You are the next interviewer and have the list in front of you.
A take-home submission for the online store includes a `processCheckout` function that is clean, commented and passes the provided tests. In the follow-up call the candidate cannot say what one of the branches does or why a particular lock is taken. They admit an AI assistant wrote most of it. The interviewer asks how you assess this.
A learner has completed the store's cart — add, remove, change quantity, total — with an assistant writing most of it. The interviewer asks: "Rebuild it from memory, no tools, and mark every place you hesitate. Then tell me what the hesitations mean."
The online store's PM asks for "recommendations, like Amazon". You have built the store and never trained a model. The interviewer asks what your first hour looks like and whether it is different from the first hour on checkout.
The interviewer gives you the classic: "Design a URL shortener." Then adds: "Most candidates draw a distributed system in five minutes. I want you to start from one sentence and add each component only when a requirement forces it. Tell me when you stop."