Interview fundamentals sheets

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 vocabulary a platform-engineering round assumes: what a platform team is for, how a portal and a CI system earn their keep, the guardrails that replace a review step, and the fleet-level costs nobody puts on a roadmap slide.

The vocabulary a security round assumes: the OWASP Top 10 by mechanism, the auth flows and where JWTs go wrong, cryptography an engineer must get right without inventing it, STRIDE and attack trees, detection and incident response, and cloud boundaries. Fifty-eight items, worked through with code, tables and diagrams.

The vocabulary a TPM loop assumes: what a program is and where its boundary with engineering management sits, critical path and float used precisely, risks written so a decision can be made about them, status that survives a hostile read, and escalation that produces an answer rather than an audience.

The vocabulary a Web3 interview assumes: what consensus is deciding, what a contract can and cannot do, why storage is the expensive resource, the vulnerability classes by name, how keys and nonces behave, and what an RPC node is actually promising you.

The vocabulary a multiplayer interview assumes: what a tick is and what raising it costs, the three state-synchronisation models and when each is affordable, prediction and reconciliation and rollback described precisely, how lag compensation moves unfairness rather than removing it, and where trust has to sit.

The vocabulary an embedded round assumes: what the constraints actually are, where RAM goes when there is no operating system, how interrupts and shared state interact, the protocols on the board, the arithmetic behind a battery budget, and how firmware is debugged when there is nowhere to print to.

The vocabulary an ASIC or FPGA round assumes you already have: what synthesis really produces, why a latch appears where you wanted a wire, what setup and hold each ask for, the crossings that need a synchroniser, and how a design gets from RTL to a manufactured part.

The vocabulary a low-latency round assumes: where time goes in the memory hierarchy, what coherence does to your data layout, lock-free primitives and what they really promise, what kernel bypass removes and costs, how a limit order book is built, and why the mean is the wrong statistic.

The vocabulary of building for iOS and Android: platform lifecycles, SwiftUI and Compose state models, coroutines and structured concurrency, offline sync, and the specific things that go wrong under memory pressure and on a real network.

The vocabulary a headset-rendering interview assumes: the matrix chain a vertex travels, what each pipeline stage costs on mobile-class hardware, why the frame budget is a comfort requirement, how tracking and gaze feed the renderer, and how to profile something you can only feel with the headset on.

The vocabulary a DevRel loop assumes: what advocacy is and is not, how a content portfolio is shaped, why communities decay, what time-to-first-call measures, which metrics survive a finance review, and how the live-talk stage is graded.

The vocabulary a design or design-engineering loop assumes: what UX and UI each mean, how a design system and its tokens are built and governed, the accessibility rules that are non-negotiable, research methods and what each can prove, and how a design reaches production without being reinterpreted.

The vocabulary a documentation interview assumes: what docs-as-code changes about a writing job, how a reference page differs from a tutorial and why the difference is structural, what a spec can and cannot express, how a docs review is triaged, and which quality signals mean anything.

What a coaching interview assumes you can already discuss: the stances and when to drop them, what each scaling framework adds and removes, dependency reduction as distinct from dependency tracking, facilitating a room of a hundred people, and which programme measures survive being made targets.

The vocabulary a customer success loop is built from: what retention and churn actually measure, what onboarding owes a customer, why adoption stalls and what fixes it, how to run a technical escalation across an integration boundary, and how a renewal is won or lost twelve months before its date.

The vocabulary a forward deployed engineering loop is built from: what the role is and is not, how to work inside an organisation you have no authority in, profiling data nobody documented, scoping a vague problem into something shippable, and handing over a system so it survives your departure.

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.

What a language model is doing when it answers, where the context window and the bill actually go, how to get structured output you can parse, what fine-tuning buys over prompting, and the evaluation, latency and injection questions that decide whether an LLM feature survives production.

What retrieval actually fixes and what it leaves untouched, why chunking and parsing set the ceiling on everything downstream, how a hybrid index recovers the exact matches embeddings lose, how to prove whether retrieval or generation failed, and where an agent earns its step budget.

When a problem is not a modelling problem, which model family the data actually calls for, where a feature quietly contains the label, which metric stays honest at a one-in-five-hundred base rate, and what the threshold you ship costs the business that has to run it.

What stands between a model that works in a notebook and one a business depends on: reproducible runs, point-in-time correct training data, a registry with real promotion gates, serving that meets a latency budget, drift you can tell apart from a broken feed, and a cost per prediction you can actually state.

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 answers a director, VP or CTO loop is built from: a strategy that makes choices, an organisation whose ownership is legible, AI adoption with evidence, build versus buy on total cost, budgets and cuts, incident leadership, and the plans, panels and take-homes these loops use.

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.

The rounds a student or new graduate meets before a first job, wherever they apply: timed coding assessments and hidden tests, aptitude arithmetic done fast and checked, internships and co-ops, assessment centres, campus and off-campus routes, a first resume, and a first offer read properly.

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.