Fundamentals

The vocabulary a coding round assumes you already have: complexity stated precisely, what each structure costs, the technique families and the signal that selects each one, and the handful of implementation details interviewers reliably probe. Fifty-four items, thirteen worked with code or a diagram.

The vocabulary a design round assumes: what each building block costs, the consistency terms used precisely, estimation done aloud, the failure modes that decide follow-up questions, and how the round itself is scored. Sixty items, twelve worked through with numbers, a schema or a diagram.

What encapsulation is actually protecting, each SOLID letter stated as a consequence rather than a slogan, the patterns worth naming and the ones worth refusing, and how a live parking-lot question is scored. Sixty items, sixteen worked through with code, a table or a diagram.

What the operating system, the network stack and the number line are actually doing underneath your code, plus the cryptography vocabulary a screen uses as a filter. Fifty-nine items, fourteen worked through with the bits, a trace or a diagram.

What an API contract commits you to, what a JWT genuinely cannot do, where a thread pool goes when a dependency slows down, and the operational details — shutdown, health checks, correlation ids — that only matter once something is on fire. Fifty-six items, twelve worked through with code or a diagram.

What the browser does between HTML and pixels, the JavaScript semantics behind the classic bugs, why a React re-render happens, what actually moves each Core Web Vital, and the accessibility facts that are requirements rather than polish. Fifty-seven items, twelve worked through with code or a diagram.

What an index actually is, what each isolation level lets through, why a query is slow and how you prove it, and the operational facts — locks, pools, migrations — that only appear in production. Fifty-eight items, twelve worked through with a plan, a schema or a diagram.

What a container actually is, why a pod gets killed, what Terraform state is for, where a cloud bill really comes from, and the practices — promotion, rollback, postmortems, restore rehearsals — that decide whether any of it survives a bad day. Fifty-seven items, twelve worked through.

What a test actually buys you, why the pyramid is argued about, the five test doubles and when each is right, what makes a suite flaky, and how non-functional testing is read. Fifty-nine items, fifteen worked through with code, a result table or a diagram.

What a pipeline must guarantee before it can be re-run, how a warehouse is modelled, where streaming earns its complexity, which model metric is honest on imbalanced data, and what a retrieval system actually gets wrong. Fifty-eight items, sixteen worked through with a schema, arithmetic or a diagram.

The answers a Java interviewer works through before the hard questions start: language semantics, collections, concurrency, the JVM and Spring behaviour. Seventy-five items, seventeen of them worked through with code or a diagram.

The answers a Python interviewer works through before the hard questions start: the data model, scope and closures, the built-in structures, generators, the interpreter lock, memory, and the packaging and typing that dominate real work. Sixty items, sixteen worked through with code or a diagram.

Where the event loop actually spends its time, what blocks it and what does not, how the two module systems collide, what TypeScript's type system does and does not check at runtime, and the packaging details that only break in production. Fifty-seven items, twelve worked through with code or a diagram.

The answers a .NET interviewer works through before the hard questions start: the memory model, the type system, LINQ execution, async, ASP.NET Core wiring and the allocation-free types. Fifty-eight items, fourteen of them worked through with code, a table or a diagram.

The answers a Go interviewer works through before the hard questions start: the type system and embedding, slice and map internals, interface values, the scheduler, channels and context, and errors as values. Sixty items, nineteen of them worked through with code or a diagram.

Architecture as a practice rather than a diagram: which decisions are expensive to reverse, how to elicit an attribute nobody stated, where a boundary belongs, and how a migration is sequenced. Fifty-six items, thirteen worked through with an ADR, a table or a diagram.

The answers an EM loop is built from: what changes when you stop being the best engineer in the room, feedback that lands, what a level actually means, how a forecast is stated honestly, and where metrics get gamed. Fifty-eight items, fifteen worked through with an agenda, a ladder, a script or a diagram.

The answers a scrum master or delivery manager loop assumes: what each ceremony is for and how it fails, points as relative size, velocity as a forecast not a score, and dependencies reduced rather than managed. Fifty-nine items, sixteen worked through with a table, a forecast or a diagram.

The vocabulary a business analysis interview uses as a filter: what the role owns, which elicitation technique fits which unknown, requirements a tester can fail, the models that expose a broken process, and how scope is defended. Fifty-eight items, eighteen worked with a matrix, a model or a diagram.

The answers a PM loop is built from: what the role actually decides, evidence that survives scrutiny, prioritisation defended rather than recited, metrics read correctly, and the traps in a product sense round. Sixty items, thirteen worked through with a table, a calculation or a diagram.

The answers a presales loop is built from: what a solution architect owns in a deal, how an opportunity is qualified or walked away from, discovery that finds the real driver, designing to a budget you were handed, and who carries the risk under each commercial model. Fifty-seven items, fifteen worked.

The answers a behavioural round is built from: what past behaviour is used to predict, why hypotheticals score badly, STAR and the frames that fix it, a story portfolio, a failure answer with the omitted part put back, and the phrases that cost offers. Fifty-nine items, sixteen worked.

The part of the loop candidates improvise and lose money on: what a screen filters for, the current-salary question, what equity is actually worth, how a counter is written, and how two offers compare once base is not the headline. Sixty items, fifteen worked with a table, a script or a diagram.

How an engineer acquires a business rather than absorbing it: what a company buys when it hires for domain experience, the thirty-day plan, ubiquitous language, where business rules hide, and why the legacy behaviour is a requirement. Fifty-seven items, fifteen worked through with a plan, a schema or a diagram.

What a bank looks like from the inside: the append-only ledger and its four balances, the rails money moves over and what finality costs, cards and disputes, credit decisioning, and the controls wrapped around all of it. Sixty items, fourteen worked through with ledger rows, arithmetic or a diagram.

The vocabulary a capital markets interview uses as a filter: what each asset class forces a system to model, the order book and the order lifecycle, where the microseconds go, and the post-trade machinery that turns a fill into ownership. Fifty-nine items, fourteen worked through.

The vocabulary an insurance interview uses as a filter: what a cover, a peril and an excess actually are, why a policy system is temporal rather than current-state, how a claim is calculated and reserved, and which regulation reaches the schema. Fifty-eight items, thirteen worked through.

The vocabulary a clinical interview assumes: identity that is probabilistic, two interoperability standards that both persist, codes that lose meaning when mapped, consent as data rather than a flag. Fifty-nine items, thirteen worked through.

What a retailer looks like from the inside: the catalogue and its read path, inventory as a number that is always slightly wrong, the checkout funnel, promotions that fight each other, the order state machine, and what a marketplace adds. Fifty-eight items, thirteen worked through with schemas, arithmetic or a diagram.

The vocabulary a logistics interview uses as a filter: what a shipment, a consignment and a handling unit each are, how a pick path and a route are actually optimised, what an ETA can honestly promise, and why recorded stock diverges from the shelf. Fifty-nine items, sixteen worked through.

The vocabulary an operator interview uses as a filter: what is actually sold and why the catalogue sits at the centre, which identifier names what, where BSS stops and OSS begins, how usage becomes money, and what each network generation demanded of the systems around it. Fifty-nine items, thirteen worked through.

The vocabulary a plant interview assumes: the bill of materials and the work order, what each layer from PLC to ERP is actually authoritative for, why OT prizes availability over confidentiality, and the metrics a factory is run on. Fifty-eight items, thirteen worked through with arithmetic, a table or a diagram.

What the named regulations actually force into a design: lawful basis and erasure, audit records that survive a challenge, segregation of duties, and why a regulated environment forbids the direct production change. Fifty-eight items, thirteen worked through with a control trace, a retention schedule or a diagram.