Everything
they ask.

Round names vary; the questions do not. A “pair programming” round is a coding round with a live codebase, a “practical” is a coding round with a debugger, an “architecture” round is system design, and a “values” or “bar raiser” round is a behavioural round run by someone outside the team who has a veto. Ask the recruiter which is which before the loop — that request is normal and the answer is usually detailed.

• Walk me through your last project.whether you can pick the right altitude — the problem, the constraint, your decision, the outcome — without narrating the sprint board.
• What are you looking for in your next role?whether the honest answer is compatible with the job they have open. It is a matching question, not a trap.
• How long do you need for this problem?calibration. Interviewers ask it to see whether you can size work, including your own.

Two mechanics decide what happens to those scores. The first is that interviewers write up independently before seeing each other’s notes, precisely so that one strong opinion cannot anchor the rest — which is why repeating your best point in every round is not repetition, it is coverage. The second is that most rubrics have a veto somewhere: a bar-raiser, a hiring committee, or a manager who can decline a candidate everyone else liked. A single strong no hire usually outweighs three weak yeses.

1. Repeat the problem back in one sentence. Half of all misunderstandings die here, and it costs ten seconds.
2. Ask about scale before you ask about anything else. Ten elements and ten billion elements are different problems, and the interviewer is usually waiting to be asked.
3. Say the brute force out loud, then discard it. It proves you understand the problem and it establishes the baseline the improvement is measured against. Never write it unless asked.
4. Take the hint. A hint is not a penalty; ignoring one is. “Have you thought about sorting first?” means sort first.
5. When stuck, say what you know. “I know it is a graph problem and I know BFS gives shortest edges, but I cannot see what the nodes are” is a scoreable sentence. Staring is not.
6. Never claim something you cannot defend. One unbacked “we used Kafka for exactly-once delivery” can cost more than an unfinished function, because it makes every other claim suspect.

Data structures are asked in three ways: build one, use one to make something faster, or explain what the standard library’s version costs. You need the operations, the complexity of each, and the memory behaviour — a hash map that rehashes and an array that reallocates are the same fact told twice.

Linear and associative

Trees, heaps and search structures

Graphs, sets and probabilistic structures

Algorithms divide into families, and the families are what you memorise — not the problems. A candidate who knows six families and can recognise them beats one who has solved four hundred problems by pattern-matching titles.

Scanning, searching and sorting

Recursion, greedy and dynamic programming

Graph algorithms

Strings, maths and the rest

Two patterns are worth writing out because candidates who know them by name still get the boundaries wrong under pressure. The first is binary search on the answer: when the question asks for the smallest capacity, the minimum speed or the largest minimum, the search space is not the array — it is the range of possible answers, and the array only appears inside a feasibility check that is monotone.

# feasible.py — binary search over the ANSWER, not over the input.
# Cue: "minimum capacity", "smallest k such that ...", "maximum minimum".
def min_capacity(weights: list[int], days: int) -> int:
    def fits(cap: int) -> bool:
        # Greedy is safe here only because fits() is monotone in cap:
        # if a capacity works, every larger capacity works too.
        used, load = 1, 0
        for w in weights:
            if load + w > cap:
                used, load = used + 1, 0
            load += w
        return used <= days

    lo, hi = max(weights), sum(weights)   # lo must itself be feasible-or-not
    while lo < hi:                        # invariant: answer is in [lo, hi]
        mid = lo + (hi - lo) // 2         # never (lo+hi)//2 in a fixed-width int
        if fits(mid):
            hi = mid                      # mid may be the answer — keep it
        else:
            lo = mid + 1                  # mid is definitely not — discard it
    return lo                             # lo == hi, and it is feasible

The second is the monotonic stack, which answers “for each element, where is the next one bigger than it?” in one pass. The trick to state out loud is that each index is pushed once and popped once, so the nested-looking loop is linear, not quadratic — that sentence is the whole complexity argument and interviewers wait for it.

# next_greater.py — one pass, each index pushed once and popped once: O(n).
def next_greater(nums: list[int]) -> list[int]:
    out = [-1] * len(nums)
    stack: list[int] = []              # indices, values strictly decreasing
    for i, v in enumerate(nums):
        # Everything smaller than v has just found its answer.
        while stack and nums[stack[-1]] < v:
            out[stack.pop()] = v
        stack.append(i)
    return out                         # whatever is left never found one: -1

Also fair game

An invariant is a sentence that is true before and after every iteration. Say it out loud and most boundary bugs become impossible to write: “everything left of lo is too small, everything from hi on is a candidate” determines whether the loop is < or <= and whether you assign mid or mid + 1. Guessing at those two decisions is the single most common source of a failed binary search under time pressure.

Then run it. Not “it looks right” — take a small awkward input, put a finger on the first line, and say what every variable holds after each step. Two minutes of this catches more than ten minutes of re-reading, and it is visible work: the interviewer is writing down that you tested unprompted.

# two_sum.py — a dry run is a table, spoken. nums = [2, 1, 2], target = 4
#
#   i   v   need   seen                 action
#   0   2     2    {}                   miss -> seen[2] = 0
#   1   1     3    {2: 0}               miss -> seen[1] = 1
#   2   2     2    {2: 0, 1: 1}         hit  -> return (0, 2)
#
# Two things this catches that re-reading does not: that `seen` is written
# AFTER the lookup (otherwise an element pairs with itself), and that the
# duplicate 2 is fine because the first index is the one still stored.
def two_sum(nums: list[int], target: int) -> tuple[int, int] | None:
    seen: dict[int, int] = {}
    for i, v in enumerate(nums):
        if (need := target - v) in seen:
            return seen[need], i
        seen[v] = i
    return None

• What is the complexity?both dimensions, and whether the bound you quote is worst case or average. Answer before you are asked and it counts for more.
• Can you do it in less space?whether you know the standard trade: rolling arrays for dynamic programming, in-place partitioning, pointers instead of a copy.
• What breaks if the input does not fit in memory?whether you can move from an algorithm to a system: external sort, streaming, sharding by key, a sketch instead of an exact count.
• How would you test this?named categories rather than examples — empty, single, duplicates, sorted, adversarial — plus a property that must hold for any input.

Also fair game

• What happens between typing a command and the program running?fork, exec, the loader, dynamic linking, the entry point — and whether you can stop at the right depth for the role.
• Your service is at 100% CPU but doing no work. What now?a method: is it user or system time, a spin loop, GC, a lock convoy? Naming top, perf and a flame graph is the expected answer.
• Why was the container killed with exit code 137?128 + 9, so SIGKILL, so the memory cgroup limit — and the follow-up about heap versus RSS.
• How does a thread pool of 200 threads behave differently from 20?context switching, memory per stack, and Little’s law: more threads do not create more capacity, they only lengthen the queue.

// race.go — go build -race is the only honest way to find these.
var counter int                       // shared, unprotected

func worker(wg *sync.WaitGroup) {
    defer wg.Done()
    for i := 0; i < 1000; i++ {
        counter++                     // read, add, write: three steps
    }
}

// Three fixes, in increasing order of how much they let you do:

var mu sync.Mutex                     // 1. protects any amount of state
mu.Lock(); counter++; mu.Unlock()

var n atomic.Int64                    // 2. one word, no lock, no waiting
n.Add(1)

for {                                 // 3. read-modify-write on your own terms
    old := n.Load()
    if n.CompareAndSwap(old, old*2) { // fails if anyone else moved it
        break
    }
}

• What happens when you type a URL and press enter?whether you can walk the whole path — cache, DNS, ARP, route, handshake, TLS, request, render — and stop at the depth the role needs.
• The service is fine but users say it is slow. Where do you look?splitting client, network and server time; the words TTFB, round trip and percentile.
• Why would a request succeed from your laptop and fail from the pod?DNS, egress rules, security groups, proxies, certificate trust stores, IPv6 — a list, then a way to bisect it.
• TCP or UDP for this?whether you reason from the requirement (ordering, loss tolerance, latency) rather than from a memorised table.

The one query that shows up most often is “top N per group”, and the good answer uses a window function rather than a correlated subquery. Being able to write it without hesitating is worth more than knowing three ways to do it slowly.

-- top_per_group.sql — the most-asked "senior SQL" shape.
-- "The three most recent orders for every customer, with the running total."
WITH ranked AS (
    SELECT
        o.customer_id,
        o.id,
        o.placed_at,
        o.amount_cents,
        ROW_NUMBER() OVER (PARTITION BY o.customer_id
                           ORDER BY o.placed_at DESC)        AS rn,
        SUM(o.amount_cents) OVER (PARTITION BY o.customer_id
                                  ORDER BY o.placed_at)      AS running_cents
    FROM orders o
    WHERE o.placed_at >= now() - interval '90 days'
)
SELECT customer_id, id, placed_at, amount_cents, running_cents
FROM ranked
WHERE rn <= 3                       -- filter AFTER the window has been computed
ORDER BY customer_id, placed_at DESC;

-- Two things an interviewer listens for:
--   * why the rn filter cannot go in the WHERE of the inner query
--     (window functions run after WHERE, so rn does not exist yet), and
--   * that this reads the 90-day slice once, where a correlated subquery
--     would re-scan per customer.

Then the part candidates get wrong: column order in a composite index. An index on (a, b) serves a lookup on a and on a plus b, but not one on b alone — it is a sorted list keyed left to right, exactly like a phone book sorted by surname then first name. Equality columns come first, the range column last, and anything after a range column cannot be used for seeking.

-- index_order.sql — the phone-book rule, made concrete.
CREATE INDEX idx_events_tenant_type_time
    ON events (tenant_id, event_type, created_at DESC);

-- Uses the index fully: equality, equality, then a range on the last column.
SELECT * FROM events
 WHERE tenant_id = $1 AND event_type = 'login' AND created_at > now() - interval '1 day'
 ORDER BY created_at DESC LIMIT 50;

-- Uses only the first column, then filters the rest by hand.
SELECT * FROM events WHERE tenant_id = $1 AND created_at > $2;

-- Cannot use it at all: the leading column is missing.
SELECT * FROM events WHERE event_type = 'login';

-- A covering index answers from the index alone -- no heap fetch at all:
CREATE INDEX idx_events_cover ON events (tenant_id, created_at DESC) INCLUDE (event_type, payload_id);

Being able to read a plan is what turns “add an index” from a guess into a diagnosis. Read it innermost first, and compare the estimated row count against the actual one before you look at anything else — if those disagree by orders of magnitude, the planner was working from bad statistics and every choice above that line is suspect.

-- plan.sql — EXPLAIN (ANALYZE, BUFFERS) on the query from above.
Limit  (cost=0.56..842.11 rows=50 width=48) (actual time=0.042..0.310 rows=50 loops=1)
  ->  Index Scan using idx_events_tenant_type_time on events
        (cost=0.56..16842.77 rows=1000 width=48)
        (actual time=0.040..0.301 rows=50 loops=1)
        Index Cond: ((tenant_id = $1) AND (event_type = 'login')
                     AND (created_at > (now() - '1 day'::interval)))
        Buffers: shared hit=54
Planning Time: 0.180 ms
Execution Time: 0.338 ms

-- What each line is telling you:
--   Index Scan          the index was used to SEEK, not merely to filter
--   Index Cond          all three predicates went INTO the index -- if one had
--                       appeared as "Filter:" instead, the index stopped being
--                       useful at that column and the rest was checked by hand
--   rows=1000 vs 50     the estimate was 20x out; harmless under a LIMIT, and a
--                       warning sign anywhere a join sits above it
--   Buffers: hit=54     54 pages, all from cache. "read=" would mean real I/O
--   loops=1             on the inner side of a nested loop this is per outer
--                       row, so multiply before believing the actual time

-- The same query with no usable index, on ten million rows:
--   Seq Scan on events  (actual time=0.011..1841.220 rows=50 loops=1)
--     Filter: (...)     Rows Removed by Filter: 9999950   <- the tell

Write skew is worth seeing rather than reading about, because every step in it succeeds. Two transactions read the same rows, each checks a rule that still holds, and each writes a different row — so nothing conflicts, nothing is detected, and the rule is now broken.

-- write_skew.sql — the on-call rule: at least one doctor stays on shift.
-- Both transactions run at REPEATABLE READ (snapshot isolation). Both commit.

-- transaction A (Alice)                  -- transaction B (Bob)
BEGIN;                                    BEGIN;
SELECT count(*) FROM shifts               SELECT count(*) FROM shifts
 WHERE on_call = true;   -- 2              WHERE on_call = true;   -- 2, same snapshot
-- 2 > 1, so it is safe to leave          -- 2 > 1, so it is safe to leave
UPDATE shifts SET on_call = false         UPDATE shifts SET on_call = false
 WHERE doctor = 'alice';                   WHERE doctor = 'bob';
COMMIT;                                   COMMIT;
-- Different rows, so no write conflict. Nobody is on call.

-- Three fixes, in increasing order of cost:
--   1. Lock what you are actually protecting, not what you are writing:
SELECT count(*) FROM shifts WHERE on_call = true FOR UPDATE;   -- serialises them
--   2. Make the invariant a constraint the database can check, so it cannot
--      be violated by any interleaving at all (a materialised counter row
--      with a CHECK, or a single row holding the count).
--   3. SERIALIZABLE, and then handle serialisation_failure by retrying:
BEGIN ISOLATION LEVEL SERIALIZABLE;   -- one of the two will be aborted

• SQL or NoSQL for this?whether you name the access patterns first. The only wrong answer is one given before the queries are known.
• Your read replica is 30 seconds behind. What do users see?concrete symptoms — a profile edit that reverts, a payment that seems to vanish — and then a fix that matches the requirement.
• How would you shard this?a key with even distribution and no cross-shard transactions in the hot path, plus an honest account of the queries it ruins.
• The same query is fast in staging and slow in production. Why?data volume, statistics, plan choice, cache state, contention — and EXPLAIN ANALYZE on both.

1. Functional requirements, written as a list. Three to five bullet points, agreed out loud. “Shorten a URL, resolve one, expire them, count clicks — is analytics in scope?”
2. Non-functional requirements, with numbers. Scale, latency target, availability target, consistency needs, retention, cost sensitivity. Ask for them; invent them if the interviewer will not give them; either way, write them down.
3. Envelope estimates. Requests per second at peak, storage per year, bandwidth. They decide whether one machine or a hundred, and everything after depends on that answer.
4. The interface. The endpoints or the events, with request and response shapes. This is the contract the rest of the design serves.
5. The data model. Tables or documents, the primary key, the access patterns, and the index that supports each one.
6. The diagram, then one request walked through it. Draw it, then narrate a single write and a single read from the client to storage and back.
7. Bottleneck, then scale it. Find the first thing that breaks, fix that one thing, then look again. Scaling everything at once is not a plan.
8. Failure and operations. Each component dies in turn: what does the user see, what recovers it, what do you alert on. Finish here even if you have to cut something else short.

Named patterns worth being able to define

Concurrency belongs in the design, not after it. “Two cars arrive at the same instant” is asked in almost every one of these rounds, and the answer is not a synchronized keyword sprinkled on a method: it is a single atomic claim on a spot, with the search allowed to be racy because a failed claim just retries.

// ParkingLot.java — the interesting three lines of a low-level design round.
public final class ParkingLot {
    private final SpotRepository spots;      // interface: in memory now, a table later
    private final PricingPolicy pricing;     // interface: hourly now, dynamic later
    private final Clock clock;               // injected, so the tests do not sleep

    public Ticket park(Vehicle vehicle) {
        for (Spot candidate : spots.freeSpotsFor(vehicle.size())) {
            // The search may be stale; the claim must not be. One atomic
            // compare-and-set decides the winner, and the loser simply
            // takes the next candidate -- no lock spans the search.
            if (candidate.claim(vehicle)) {
                return new Ticket(candidate.id(), vehicle.plate(), clock.instant());
            }
        }
        throw new LotFullException(vehicle.size());
    }
}

The neighbouring vocabulary

// errors.json — an error body worth defending in an interview. Three
// properties matter:
// a code the client can branch on, a message a human can read, and an id
// that ties this response to the log line that explains it.
{
  "error": {
    "code": "link_code_taken",
    "message": "That short code is already in use.",
    "field": "code",
    "request_id": "01JB8Z0X4K9M2QW7N6R3T5V8Y1",
    "retryable": false
  }
}

// Cursor pagination, because offset pagination shifts under inserts:
// GET /v1/links?limit=50&cursor=eyJpZCI6IjAxSkI4WiJ9
{
  "items": [],
  "next_cursor": "eyJpZCI6IjAxSkI5QSJ9"
}

1. Reproduce it first. A bug you cannot reproduce is a bug you cannot confirm you fixed. Get it failing on demand before you change anything.
2. Read the error. All of it, including the frames in the middle. An astonishing number of debugging rounds are won here and lost by skimming.
3. Say what you expect before you look. “If the parser is at fault, this value will be empty here.” Now the observation means something either way.
4. Bisect. In the code path, in the input, or in history with git bisect. Halving the search space beats inspecting it.
5. Change one thing at a time, and put it back if it was not the cause. A pile of speculative edits destroys the evidence.
6. Find the cause, not the symptom. Then say what class of bug it was and what would have caught it — that sentence is the senior signal in this round.

Review in a fixed order and say the order out loud, because it demonstrates a system rather than a set of reactions: correctness, then security and data safety, then failure behaviour, then tests, then design and naming, then style. Style last, and only where a tool cannot enforce it. Distinguish blocking comments from suggestions explicitly — a reviewer who marks everything as equally important is a reviewer nobody can act on.

1. Stop the bleeding first. Roll back, fail over, shed load, turn the flag off. Understanding can wait; the users cannot.
2. Declare it and take a role. Someone commands, someone communicates, someone investigates. One person doing all three is how incidents get longer.
3. Keep a timeline as you go. Written afterwards it is fiction. Written live it is the postmortem’s spine.
4. Communicate on a fixed cadence, even with nothing new. Silence generates a second incident made of people asking questions.
5. Find the cause afterwards, not during. The pressure to explain while mitigating is what produces the wrong fix.
6. Write it up blamelessly, with contributing factors rather than a culprit, and action items that have owners and dates. A postmortem with no changed defaults changed nothing.

• Tell me about the worst outage you were part of.whether you can separate what you did to stop it from what caused it, and whether you say what you would do differently.
• You are paged at 3am: error rate is 40%. First five minutes?a triage order — what changed, is it all users or some, roll back if a deploy is in the window — not a debugging session.
• How do you decide what to alert on?symptoms over causes, an action per page, and a stated view on alert fatigue.
• What did you change after the last incident?whether the follow-up actually shipped. Most postmortem items do not, and admitting that is more credible than claiming otherwise.

// jwt.json — the two halves anyone holding the token can read.
// Base64url is an encoding, not a cipher. Nothing secret goes in here.
{                                    // header
  "alg": "RS256",                    // what it CLAIMS it was signed with
  "kid": "2026-08",                  // which key in the issuer's JWKS
  "typ": "JWT"
}
{                                    // payload — the registered claims
  "iss": "https://id.example.com",   // who minted it
  "sub": "usr_01JB8Z0X4K9M2QW7N6R3", // who it is about
  "aud": "https://api.example.com",  // who it is FOR — reject if that is not you
  "exp": 1788012000,                 // expires at, epoch seconds
  "nbf": 1788011700,                 // not valid before
  "iat": 1788011700,                 // issued at
  "jti": "01JB8Z1M4N7PQ2RS3TU4",     // unique id: one-time use, deny-lists
  "scope": "links:read links:write", // then whatever else you agreed on
  "tenant": "acme"
}
// signature = RS256( base64url(header) + "." + base64url(payload), private key )

The order of the checks is the security property. Every claim above is attacker-controlled text until the signature has been verified — so anything that reads a claim first, including choosing the algorithm from the header, is deciding on data the attacker wrote.

# verify.py — the whole of JWT verification, and it is all in the arguments.
claims = jwt.decode(
    token,
    key=jwks.key_for(unverified_header(token)["kid"]),  # 1. key named by kid
    algorithms=["RS256"],          # 2. YOUR allow-list, never token["alg"] —
                                   #    that is how alg:none and the RS256->HS256
                                   #    downgrade both get in
    issuer="https://id.example.com",
    audience="https://api.example.com",     # 3. the claim everyone forgets
    leeway=30,                     # seconds of clock skew you will tolerate
    options={"require": ["exp", "iss", "aud", "sub"]},   # absent != valid
)

# 4. Only now is anything in `claims` trustworthy. Authentication is finished;
#    authorisation has not started, and it is a different question:
if "links:write" not in claims["scope"].split():
    raise Forbidden()
link = links.get(link_id, tenant=claims["tenant"])   # and so is this one

// jwt.json — the two halves anyone holding the token can read.
// Base64url is an encoding, not a cipher. Nothing secret goes in here.
{                                    // header
  "alg": "RS256",                    // what it CLAIMS it was signed with
  "kid": "2026-08",                  // which key in the issuer's JWKS
  "typ": "JWT"
}
{                                    // payload — the registered claims
  "iss": "https://id.example.com",   // who minted it
  "sub": "usr_01JB8Z0X4K9M2QW7N6R3", // who it is about
  "aud": "https://api.example.com",  // who it is FOR — reject if that is not you
  "exp": 1788012000,                 // expires at, epoch seconds
  "nbf": 1788011700,                 // not valid before
  "iat": 1788011700,                 // issued at
  "jti": "01JB8Z1M4N7PQ2RS3TU4",     // unique id: one-time use, deny-lists
  "scope": "links:read links:write", // then whatever else you agreed on
  "tenant": "acme"
}
// signature = RS256( base64url(header) + "." + base64url(payload), private key )

The order of the checks is the security property. Every claim above is attacker-controlled text until the signature has been verified — so anything that reads a claim first, including choosing the algorithm from the header, is deciding on data the attacker wrote.

# verify.py — the whole of JWT verification, and it is all in the arguments.
claims = jwt.decode(
    token,
    key=jwks.key_for(unverified_header(token)["kid"]),  # 1. key named by kid
    algorithms=["RS256"],          # 2. YOUR allow-list, never token["alg"] —
                                   #    that is how alg:none and the RS256->HS256
                                   #    downgrade both get in
    issuer="https://id.example.com",
    audience="https://api.example.com",     # 3. the claim everyone forgets
    leeway=30,                     # seconds of clock skew you will tolerate
    options={"require": ["exp", "iss", "aud", "sub"]},   # absent != valid
)

# 4. Only now is anything in `claims` trustworthy. Authentication is finished;
#    authorisation has not started, and it is a different question:
if "links:write" not in claims["scope"].split():
    raise Forbidden()
link = links.get(link_id, tenant=claims["tenant"])   # and so is this one

# The two lines that answer half of an application-security question.

# 1. Never build a query by concatenation. The parameter is data, forever,
#    no matter what it contains.
cur.execute("SELECT id, email FROM users WHERE tenant_id = %s AND email = %s",
            (tenant_id, email))          # not f"... email = '{email}'"

# 2. Authorise the object, not the route. A logged-in user is not the same
#    thing as this user, and the row is where the truth is.
invoice = repo.get(invoice_id)
if invoice is None or invoice.tenant_id != caller.tenant_id:
    raise NotFound()                     # not Forbidden: do not confirm it exists

The vocabulary

• How would you store passwords?a slow hash by name, a per-user salt, and the reason a fast hash fails. Mentioning a pepper or a work factor is a bonus, not the point.
• A user reports seeing another user’s data. What happened?a missing object-level authorisation check, a cache keyed without the tenant, or a connection pool leaking context. All three are worth naming.
• How do you handle secrets in this design?a secret manager, short-lived credentials, rotation, and nothing in the repository or the image.
• What does TLS actually protect against here?the distinction between transport security and everything else. It does not authenticate the user or protect the data once it arrives.

The prompts, in the words they are usually asked

• What is the most impactful thing you have built?whether impact is measured in your answer, and whether you can say who benefited rather than what shipped.
• Tell me about a decision you made that turned out badly.ownership without self-flagellation, and a concrete change afterwards. This is the single highest-signal behavioural question there is.
• How do you decide what to work on?a prioritisation model of any kind, and evidence you have said no to something.
• How would you onboard onto a codebase you have never seen?method: run it, read the tests, trace one request, fix something small, ask specific questions.