Interview Basics · Resources

What to prioritize

A quick snapshot of what tends to come up, and how.

Core round topics

JS, Python, AWS
Your projects + some SQL
SQL & system optimisation
System design — base level, communicate clearly
Live coding → async/await in JS and Python
LeetCode easy ones

Frequently emphasized

Usual JS / Node.js questions
Python: decorators & generators — learn these cold
Same concepts in JS too
SQL + lots of infra questions
Previous-experience-based questions

1JavaScript & Node.js

0/21▶

Usual JS/Node questions, plus async/await, are common live-coding material. This tends to be a strong area for full-stack candidates — aim for zero hesitation.

Core language

Explain the event loop: call stack, microtask queue (promises) vs macrotask queue (timers). Predict the output order of a snippet mixing setTimeout, Promise.then, and sync code.

javascript.info — Event loop — microtasks vs macrotasks with runnable output-order examples; do the tasks at the bottom.

var vs let vs const — hoisting and the temporal dead zone.

javascript.info — The old "var" — function-scope vs block-scope and hoisting, explained by contrast.

Closures: define one, then give a real example (e.g. a counter factory, or how you've used them in debounce/analytics code).

javascript.info — Variable scope, closure — lexical environments first, then the classic counter; the exact framing interviewers want.

How this works — arrow functions vs regular functions, call/apply/bind.

javascript.info — Object methods, "this" — how this is resolved at call time; contrast with arrows (which have no this).

== vs === and type coercion gotchas.

javascript.info — Comparisons — coercion rules plus the weird cases (null vs undefined, NaN).

Prototypal inheritance and what class syntax actually does.

javascript.info — Prototypal inheritance — the prototype chain visually; then skim the "Classes" chapter to connect the sugar to the mechanism.

Write debounce and throttle from scratch — classic live-coding warm-up.

CSS-Tricks — Debouncing & throttling explained — the definitive visual explanation; read it, close it, implement both from memory.

Shallow vs deep copy of objects; spread, structuredClone.

javascript.info — Object references and copying — references vs copies, Object.assign/spread limits, and when you need a deep clone.

ES6+ features you actually use: destructuring, optional chaining, nullish coalescing, modules.

javascript.info — Destructuring — start here, then browse the neighbouring chapters (optional chaining, modules) in the sidebar.

Async — guaranteed live coding

Promises: the three states, chaining, error propagation. Promise.all vs allSettled vs race vs any — when each is right.

javascript.info — Promise basics — states and chaining; then the "Promise API" chapter puts all four combinators side by side.

async/await: what it desugars to, try/catch error handling, and the classic trap — sequential awaits in a loop vs firing in parallel with Promise.all.

javascript.info — Async/await — short chapter with tasks; the loop-of-awaits trap is exactly what live coding tests.

Practice task: fetch 3 URLs in parallel, return results, handle one failing without killing the rest.

MDN — Promise.allSettled — the exact pattern for "some may fail" fan-out; note the status/value/reason result shape.

Practice task: implement sleep(ms), then promisify a callback-style function.

javascript.info — Promisification — wrapping callback APIs in promises; sleep is a one-liner once this clicks.

Practice task: run N async tasks with a concurrency limit of k (comes up more than you'd expect).

GitHub — p-limit — the standard library for this; read its tiny source, then write your own version without looking.

Callbacks → promises → async/await: tell the evolution story in 60 seconds.

javascript.info — Callbacks — the "pyramid of doom" chapter; it opens the async track that ends at async/await, which IS the story.

Node.js specifics

Node's event loop phases; process.nextTick vs setImmediate vs setTimeout(fn, 0).

Node.js docs — Event loop, timers, nextTick — the official deep-dive; the phase diagram answers this question verbatim.

Is Node single-threaded? libuv thread pool, worker_threads, cluster — when CPU-bound work blocks the loop.

Node.js docs — worker_threads — read the intro paragraph: it states exactly when workers help (CPU-bound) and when they don't (I/O).

Express middleware chain, next(), and how error-handling middleware differs.

Express — Using middleware — chain order and next(); then the error-handling guide (4-arg signature) linked at the bottom.

Streams and backpressure — one sentence on why you'd stream a large file instead of reading it into memory.

Node.js docs — Stream — skim the overview + pipe(); backpressure = the consumer controlling the producer's pace.

CommonJS vs ES modules.

Node.js docs — ECMAScript modules — the differences section covers require vs import, sync vs async loading, and interop.

REST API design: proper status codes, idempotency (PUT vs POST), pagination, versioning.

restfulapi.net — concise chapters on resource naming, status codes and idempotency; 30 minutes covers everything they'd ask.

2Python

0/21▶

Decorators and generators are commonly asked in Python rounds — know these cold. Async/await in Python is common for live coding too.

Decorators — frequently asked

Write a decorator from scratch in a plain editor: a @timer that logs how long a function takes. No references.

Real Python — Primer on decorators — the canonical guide; it builds a @timer step by step. Type it out, don't just read.

Explain what a decorator is: a function that takes a function and returns a function. Show the @syntax is just f = deco(f).

Real Python — same primer, "Simple decorators" — that section gives you the one-sentence definition plus the desugared form.

Decorator with arguments (e.g. @retry(times=3)) — the three-layer nesting.

Real Python — primer, "Decorators with arguments" — explains why you need a factory that returns a decorator; write @retry yourself after.

Why functools.wraps matters (preserving __name__/docstring).

Python docs — functools.wraps — official one-paragraph answer; demo it by printing f.__name__ with and without.

Real-world uses you can cite: @app.route in Flask, auth checks, caching with @lru_cache.

Python docs — functools.lru_cache — a stdlib decorator you can name-drop; note maxsize and the cache_info() method.

Generators — frequently asked

What yield does; generator function vs normal function; lazy evaluation and why it saves memory (e.g. processing a huge file line by line).

Real Python — Intro to generators — opens with exactly the huge-file example; the mental model of "paused function" is the answer.

Generator expressions vs list comprehensions — (x*x for x in ...) vs [x*x for x in ...].

Real Python — same article — it measures both with sys.getsizeof; quote those numbers and you sound senior.

next(), StopIteration, and the iterator protocol (__iter__/__next__).

Python tutorial — Iterators — the official half-page that shows for-loops are just iter() + next() under the hood.

Write one live: a generator yielding Fibonacci numbers, or batching a list into chunks of n.

Python Tutor — paste your generator in and step through it visually; seeing the suspended state makes yield unforgettable.

Bonus link: contextlib.contextmanager — a decorator + generator combined. Mentioning this connects both flagged topics.

Python docs — contextlib.contextmanager — the example turns a yield into a with-block; a perfect "bring it together" flex.

JS parallel: generators exist in JS too (function*, yield) — know the JS equivalent at least conversationally.

javascript.info — Generators — same concept, JS syntax; ten minutes gets you to "yes, and in JS it's function*…".

Async Python — live coding

async def / await / asyncio.run — write a script that runs two coroutines concurrently with asyncio.gather.

Real Python — Async IO in Python — the standard walkthrough; type out its first three examples rather than reading passively.

How Python's async differs from JS: explicit event loop, cooperative scheduling, coroutines are built on generators.

Python docs — Coroutines and Tasks — the official reference; the coroutine→task distinction is what interviewers probe.

asyncio.gather vs create_task; handling exceptions in gathered tasks.

Python docs — asyncio.gather — note return_exceptions=True: it's the Python twin of Promise.allSettled.

The GIL in one minute: what it blocks (CPU-bound threads), what it doesn't (I/O-bound), threads vs multiprocessing vs asyncio.

Real Python — What is the GIL? — the article everyone cites; the CPU-vs-I/O benchmark table is your one-minute answer.

Usual Python questions

The mutable default argument trap (def f(x, acc=[])) — a favourite gotcha.

Hitchhiker's Guide — Common gotchas — this trap is literally the first item; the fix (acc=None) is two lines.

*args / **kwargs; keyword-only args.

Real Python — *args and **kwargs — packing vs unpacking; also needed to write generic decorators, so it compounds.

List/dict/set comprehensions fluently.

Real Python — List comprehensions — includes conditionals and nesting; practice rewriting three of your own loops.

Shallow vs deep copy (copy module); is vs ==.

Python docs — copy module — the shallow/deep distinction in one page; is = identity, == = equality.

Context managers: with open(...) — what __enter__/__exit__ do.

Real Python — The with statement — covers the protocol and writing your own; pairs with the contextmanager item above.

Common data structures: dict vs set lookup O(1), list vs tuple, when to use collections.defaultdict/Counter.

Python docs — collections — defaultdict and Counter with examples; Counter alone solves half of LeetCode-easy string problems.

3SQL — general + optimisation

0/25▶

General SQL plus SQL optimisation are both commonly asked, often as separate rounds. Below: a general fundamentals block — the screening-level questions that come before the optimisation ones.

★ General SQL fundamentals

Full fluency in SELECT / WHERE / ORDER BY / LIMIT — filtering with AND/OR/IN/BETWEEN/LIKE.

SQLBolt — interactive lessons 1–6; the single fastest general-SQL refresher, with exercises in the browser.

Primary key vs foreign key; constraints: NOT NULL, UNIQUE, CHECK, DEFAULT.

W3Schools — SQL constraints — quick reference with syntax for each; know that a PK = UNIQUE + NOT NULL.

GROUP BY with aggregates (COUNT/SUM/AVG/MIN/MAX) — and why you can't SELECT a non-grouped column.

SQLBolt — Queries with aggregates — lessons 10–11 with exercises; the non-grouped-column error is a favourite quick check.

NULL handling: IS NULL vs = NULL, COALESCE, how NULLs behave in aggregates and joins.

W3Schools — NULL values — the key trap: NULL = NULL is not true; COUNT(col) skips NULLs but COUNT(*) doesn't.

UNION vs UNION ALL (and INTERSECT/EXCEPT at a glance).

W3Schools — UNION — one page; the interview answer is "UNION dedupes (slower), UNION ALL doesn't".

Subqueries vs CTEs (WITH): correlated vs non-correlated subqueries, when a CTE reads better.

PostgreSQL docs — WITH queries — read the intro + first example; CTEs are how you keep live-coded SQL readable under pressure.

DISTINCT; DELETE vs TRUNCATE vs DROP; DDL vs DML vs DCL.

W3Schools — SQL tutorial index — use as a keyword-level lookup; these one-liner definition questions open many screenings.

Views: what they are, why use them; materialized views in one sentence.

PostgreSQL tutorial — Views — half a page; "a saved query you can SELECT from — materialized = results stored and refreshed".

String & date functions: CONCAT, SUBSTRING, DATE_TRUNC, EXTRACT, NOW() — the tools behind "revenue per month" questions.

Mode — SQL tutorial — the intermediate section drills string/date wrangling on real datasets; this also powers hourly/date-based aggregation questions.

Drill it: work through a structured practice set so syntax is automatic under pressure.

LeetCode — SQL 50 study plan — the best free drill set, sorted by pattern; 2–3 per day alongside your DSA problems.

Query classics — likely live

All JOIN types with a two-table example: INNER, LEFT, RIGHT, FULL, CROSS, self-join.

SQLBolt — Multi-table queries with JOINs — interactive; self-joins (employees + managers) are the variant that separates candidates.

WHERE vs HAVING; execution order of a SELECT (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT).

SQLBolt — Order of execution — one page that answers both; WHERE filters rows, HAVING filters groups.

Classic live query: second-highest salary (do it 3 ways: subquery, OFFSET, DENSE_RANK()).

LeetCode #176 — Second highest salary — solve it, then read the discussion for all three approaches; mention NULL-when-absent for bonus points.

Classic live query: find duplicate rows; delete duplicates keeping one.

LeetCode #182 — Duplicate emails — GROUP BY + HAVING COUNT > 1; then #196 for the delete variant.

Classic live query: top N per group (window functions: ROW_NUMBER() OVER (PARTITION BY ...)).

PostgreSQL tutorial — Window functions — the official intro; the PARTITION BY example is exactly the top-N-per-group pattern.

Aggregate + join combo: "count of orders per customer including customers with zero orders" (LEFT JOIN + COUNT).

W3Schools — LEFT JOIN — the trick: COUNT(orders.id), not COUNT(*), so zero-order customers show 0 instead of 1.

Optimisation — high priority

Indexes: how a B-tree index works, composite index column order, why an index on (a,b) helps WHERE a=… but not WHERE b=… alone.

Use The Index, Luke — free book by Markus Winand; chapter 1 (Anatomy of an Index) + the concatenated-index section answer this exactly.

EXPLAIN / EXPLAIN ANALYZE: read a plan, spot a sequential scan on a big table, fix it.

PostgreSQL docs — Using EXPLAIN — run it on your own local Postgres (e.g. via docker-compose); watching Seq Scan become Index Scan is the whole lesson.

When indexes don't get used: functions on the column, leading wildcards LIKE '%x', type mismatches, low selectivity.

Use The Index, Luke — The WHERE clause — each "index killer" gets its own short section; skim the headings and you have the list.

The N+1 query problem — what it is and how you'd fix it (joins, batching, dataloader pattern).

Stack Overflow — What is the N+1 problem? — the canonical Q&A; top answer gives you the definition, example, and fixes.

Pagination at scale: why OFFSET 100000 is slow; keyset/cursor pagination instead.

Use The Index, Luke — No OFFSET — the famous manifesto page; two diagrams explain keyset pagination better than any article.

SELECT * vs explicit columns; covering indexes / index-only scans.

Use The Index, Luke — index-only scan chapter — find it in the table of contents; "the index alone answers the query" is the phrase to use.

Normalization (1NF→3NF in plain words) vs deliberate denormalization.

Wikipedia — Database normalization — read only the plain-English summaries of 1NF–3NF; have a real denormalization example ready from your own work.

Transactions & ACID; isolation levels at a high level (dirty read, non-repeatable read, phantom).

PostgreSQL docs — Transaction isolation — the table mapping isolation levels to anomalies is the whole answer; screenshot it.

Prepared statements / parameterized queries — SQL injection prevention.

OWASP — SQL Injection — a solid reference to cite in any security-adjacent conversation; the fix is always "parameterize, never concatenate".

4AWS & infrastructure

0/16▶

Infrastructure questions come up often in full-stack rounds. Docker, EC2, Terraform, and CI/CD tooling (like GitHub Actions) are all fair game if they're on your resume.

AWS core

EC2 essentials: instance types, AMIs, security groups vs NACLs, key pairs. Be ready to describe how you deployed to EC2.

AWS docs — What is Amazon EC2 — the concepts page; security groups (stateful, instance-level) vs NACLs (stateless, subnet-level) is the classic follow-up.

S3: buckets, static hosting, presigned URLs, storage classes at a glance.

AWS docs — What is Amazon S3 — skim features; presigned URLs (temporary access without credentials) is the detail worth knowing cold.

RDS vs self-managed Postgres on EC2 — tradeoffs.

AWS — Amazon RDS — the talking points are on the product page: managed backups, patching, Multi-AZ failover vs cost and control.

Load balancers (ALB) + Auto Scaling Groups: how you'd scale a Node API horizontally.

AWS — Elastic Load Balancing — ALB routes by path/host at layer 7; pair with an ASG and health checks and you have the full scaling answer.

IAM in one minute: users, roles, policies; why EC2 instance roles beat hardcoded keys.

AWS docs — IAM introduction — least-privilege + "roles for machines, users for humans" is exactly the answer interviewers want.

Lambda vs EC2 vs containers — when serverless makes sense.

AWS — Lambda — the rule of thumb: spiky/event-driven → Lambda, long-running/steady → containers or EC2; mention cold starts as the tradeoff.

VPC basics: public vs private subnets, why the DB lives in a private subnet.

AWS docs — What is Amazon VPC — the diagram of public/private subnets + NAT gateway is the picture to redraw from memory.

Docker & deployment

Image vs container; what each Dockerfile instruction does; layer caching and ordering (COPY package.json before COPY .).

Docker docs — Get started — the official tour; the layer-caching ordering trick is the mark of someone who's actually shipped with Docker.

Multi-stage builds — smaller images.

Docker docs — Multi-stage builds — one page; "build stage with dev deps, slim runtime stage" is the sentence to say.

docker-compose for local dev: app + Postgres + Redis in one file.

Docker docs — Compose — write this exact three-service file alongside your SQL practice; that's studying two sections at once.

Terraform: what state is, plan vs apply, why IaC beats console clicking. One concrete example of what you provisioned.

HashiCorp — Terraform tutorials — do the AWS get-started track; "state maps config to real resources" is the key concept they'll probe.

GitHub Actions: walk through a CI/CD pipeline you wrote — trigger, test, build, deploy.

GitHub docs — Actions — review the workflow syntax (on/jobs/steps) so you can sketch a pipeline on a whiteboard.

Environment variables & secrets management (never in the repo — env files, GitHub secrets, SSM/Secrets Manager).

The Twelve-Factor App — Config — the one-page principle interviewers expect you to cite: config in the environment, never in code.

Caching & Redis

Why Redis for a job/message queue — in-memory speed, data structures (lists, sorted sets), TTL.

Redis docs — review the data types section; "sorted set scored by send-time" is a beautiful answer for a scheduled-message queue.

Cache strategies: cache-aside vs write-through; cache invalidation and TTL tradeoffs.

AWS — Caching overview — plain-English comparison of the strategies; cache-aside (lazy loading) is the default answer for read-heavy APIs.

Redis as a message queue vs a proper broker — what breaks at scale, and what you'd reach for next (SQS/RabbitMQ).

AWS — What is a message queue — durability, acknowledgements, dead-letter queues: the three things a real broker adds over a Redis list.

5System design & optimisation

0/16▶

At a "base level," system design rounds are usually testing whether you can structure your thinking out loud — not whether you can design Twitter at scale. A clear framework wins this round.

The 6-step framework (memorize it)

1. Clarify requirements (functional + non-functional: users, scale, latency). Always ask questions first.

System Design Primer — How to approach — the "How to approach a system design question" section is a near-verbatim script for this step.

2. Rough estimates: requests/sec, storage, read:write ratio.

System Design Primer — Back-of-the-envelope — powers-of-two and latency tables; memorize "1M requests/day ≈ 12/sec" as your anchor.

3. Define the API (a few REST endpoints).

restfulapi.net — same resource as Section 1; here just write 3–4 endpoints with verbs and status codes before drawing boxes.

4. Data model (tables, keys, indexes).

System Design Primer — Database section — RDBMS vs NoSQL tradeoffs; for base-level rounds, a clean relational schema is almost always right.

5. High-level diagram: client → LB → app servers → cache → DB → queue/workers.

Excalidraw — free whiteboard; draw this six-box diagram until you can produce it in under a minute while talking.

6. Scale & tradeoffs: caching, replication vs sharding, async processing, single points of failure.

System Design Primer — index of topics — read the short sections on caching, replication, sharding and queues; one paragraph each is enough depth here.

Likely prompts — practice out loud

URL shortener (the classic opener).

System Design Primer — Pastebin/Bit.ly solution — a full worked answer; read once, then redo it yourself with the 6 steps.

Rate limiter (token bucket vs sliding window).

Cloudflare — What is rate limiting — plain-English algorithms overview; "Redis counter + sliding window" makes a tidy base-level answer.

Notification / reminder system — design it "at scale": what triggers a send, how you schedule, how you fan out to many users.

ByteByteGo blog — search "notification system"; Alex Xu's walkthrough is the standard version to study.

Analytics ingestion pipeline — design an event-ingestion service end to end: ingestion API → queue/buffer → hourly aggregation → data store → dashboard. If you have a real project like this, use it as your worked example.

Excalidraw — draw the pipeline end to end and export the PNG; if they share a whiteboard, you'll redraw it in two minutes flat.

A campaign/messaging sender for a product you're familiar with (schedule → template → send at scale → track opens/clicks). Thinking about the target company's actual product beforehand looks great.

Tech Interview Handbook — System design — browse a few worked examples so your design uses the right vocabulary for whatever domain the company is in.

System optimisation (its own round)

"An API endpoint is slow — walk me through debugging it": measure first (logs, APM), then DB query? N+1? missing index? then caching, then payload size, then horizontal scaling.

Latency numbers every programmer should know — the famous gist; grounding your "measure first" answer in real numbers (disk vs RAM vs network) impresses.

Where to add caching layers: CDN → HTTP cache → Redis → query cache. And what each invalidates on.

Cloudflare — What is a CDN — covers the outermost layer; then narrate inward: browser cache → CDN → Redis → DB.

Sync vs async work: moving slow tasks (emails, reports) to a queue + workers.

AWS — What is a message queue — same page as Section 4, different angle: decoupling and smoothing spikes.

Frontend performance: code splitting, lazy loading, memoization, bundle size — cite any real numbers you remember from past performance work.

web.dev — Learn Performance — Google's free course; skim the module titles and attach one real example to each technique you mention.

Horizontal vs vertical scaling; stateless app servers; sticky sessions vs shared session store.

The Twelve-Factor App — Processes — "stateless processes, state in backing services" is the principle that makes horizontal scaling possible; cite it by name.

6Live coding — LeetCode easy

0/13▶

Live coding at the easy tier is common in full-stack rounds. The bar is clean code + thinking out loud, not tricks. Solve each in ≤15 min, narrating as you go. Pick ONE language for DSA (your strongest) and stick to it.

The essential ten

Two Sum (hashmap, O(n)).

LeetCode #1 — Two Sum — the hashmap "have I seen the complement?" pattern; it reappears in a dozen other problems.

Valid Parentheses (stack).

LeetCode #20 — Valid Parentheses — the canonical stack problem; edge cases: empty string, closing bracket first.

Valid Anagram / first non-repeating character (frequency map).

LeetCode #242 — Valid Anagram — frequency counting; then #387 (first unique char) is the same map, second pass.

Reverse a string / check palindrome (two pointers).

LeetCode #125 — Valid Palindrome — two pointers from both ends; the alphanumeric-filtering twist is what they check.

Merge two sorted arrays (or lists).

LeetCode #21 — Merge Two Sorted Lists — the two-pointer merge; the dummy-head trick keeps your code clean under pressure.

Best Time to Buy and Sell Stock (one pass, track min).

LeetCode #121 — Best Time to Buy and Sell Stock — track min-so-far and best-profit in one pass; a favourite screener.

Contains Duplicate / remove duplicates from sorted array.

LeetCode #217 — Contains Duplicate — Set size vs array length in one line; then #26 for the in-place two-pointer variant.

Maximum subarray (Kadane's — easy/medium border, worth knowing).

LeetCode #53 — Maximum Subarray — Kadane's in 5 lines: "extend or restart"; being able to explain WHY it works is the differentiator.

FizzBuzz + flatten a nested array (warm-up tier, still asked).

LeetCode #412 — Fizz Buzz — yes, really; for flatten, know both recursion and JS's built-in arr.flat(Infinity).

Reverse a linked list (iterative).

LeetCode #206 — Reverse Linked List — the prev/curr/next three-pointer dance; draw it once on paper and it sticks.

Interview mechanics

Narrate the pattern before coding: "This looks like a hashmap lookup problem, so O(n) time, O(n) space…"

Tech Interview Handbook — Coding cheatsheet — a literal checklist of what to say before, during and after coding; rehearse it once per problem.

Always state complexity at the end, and test with one normal case + one edge case (empty input, single element).

NeetCode — Roadmap — do the "Arrays & Hashing" node; each problem has a free video that models exactly this narrate-and-verify habit.

Practice typing in a bare editor with no autocomplete/AI — the environment will likely be a plain shared editor.

CoderPad — free sandbox — the exact style of editor many companies use for live rounds; do your last few problems in it.

7Your projects & experience

0/16▶

Your own projects and previous experience come up in almost every round. Every line on your resume is a potential question. Each item below has a draft answer — a 90-second script. Highlighted [placeholders] are the parts only you can fill in — rewrite them in your own words, out loud.

Role 1 (your most recent job)

Your core product area: what does the scale look like technically (users, requests, volume)? What breaks at that volume, and what did you build/fix?

Tech Interview Handbook — Behavioral guide — use its story-structuring template to turn a raw metric into a context → decision → result narrative with real numbers.

Draft answer

"At [company], I work on [product area], which handles roughly [scale] a month. I own [your actual slice: onboarding? a core flow? a dashboard?]."

What breaks at that volume — pick the ones that are true and give one example each: upstream/partner APIs failing or timing out mid-flow (so every step needs graceful degradation and retries), duplicate submissions (so writes must be idempotent), and many programs/tenants sharing one platform (so config, theming and API versions must isolate them).

Land it with a number — "For example, [one concrete thing you built or fixed], which [measurable result — e.g. cut failed requests by X%]."

A major migration or rewrite you were part of: what specifically improved (metrics: load time, error rate, conversion)? What was hard about migrating live systems?

Martin Fowler — Strangler Fig — if your migration ran old and new side by side, this is the named pattern for it; citing it elevates the story.

Draft answer

"We rebuilt [system] from v1 to v2. The driver was [the real reason: tech debt? performance? scaling to new use cases faster?]."

The hard part — "These were live systems, so we migrated incrementally — old and new ran side by side and users/programs moved over one at a time" (if that's how it went, name it: the strangler-fig pattern). The pain was keeping feature parity while the old system kept receiving fixes.

Your role + result — "I built [your part: core components? routing/theming architecture? migration of specific pieces?]. Result: [metric — load time down X%, launch time from X weeks to Y]."

Design system or shared component library: how you structured it, how you got teams to adopt it, versioning strategy.

Brad Frost — Atomic Design — the vocabulary (atoms → molecules → organisms) most interviewers know; map your components onto it.

Draft answer

"With multiple products/programs sharing UI, every one needed its own branding on the same flows — that's why we built a design system rather than copy-pasting UI."

Structure — "A token layer (colors, type, spacing per program) under a shared component library — roughly atoms → molecules → organisms — plus usage docs." Adjust to what you actually built.

Adoption & versioning — the follow-ups they'll ask. Be ready with: how you got teams to use it ([migrated one high-visibility screen first? made default templates use it?]) and how you shipped changes without breaking consumers ([semver? deprecation warnings? changelog?]).

Impact — "Spinning up UI for a new program went from [X] to [Y]."

Custom analytics + A/B framework: how it works end to end (event capture → storage → assignment → analysis). Expect follow-ups — if you have more than one analytics-adjacent project, keep the stories distinct.

Wikipedia — A/B testing — refresh the vocabulary (variant assignment, significance, sample size) so follow-up questions don't outrun you.

Draft answer

Pipeline in one breath — "A small SDK captures events — page views, clicks, funnel steps — and sends them to our collector API, which stores them in [your store]. Dashboards query aggregates on top."

A/B mechanics — the detail that impresses: "Variant assignment is deterministic — hash of user ID + experiment ID — so a user always sees the same variant without us storing assignments. We log an exposure event and compare conversion between variants."

Why custom? — they WILL ask why not an off-the-shelf tool: [cost? keeping user data in-house for compliance? flexibility?]. Then one experiment you ran and what it changed: [example + result].

Keep this story distinct from any other analytics project you mention.

Any API-driven frontend architecture: what "API-driven" means concretely in that project.

restfulapi.net — be ready to sketch the contract: which endpoints drove which UI states, and how errors/loading were handled.

Draft answer

"API-driven means the backend drives the UI: the frontend renders screens, fields and flows from API responses rather than hardcoding them — so [what it enabled: config changes without a frontend redeploy? faster launches?]."

Your part — "[the rendering layer? schema/response handling? validation and error states?]."

Tradeoff question to expect — "What's the downside?" Answer: flexibility costs you type safety and makes testing harder; you mitigate with [schema validation, contract tests, storybook states — whatever you did].

Any compliance/security constraints you worked under — a great bridge if the target company is security-focused.

OWASP — Top 10 — know the categories by name (injection, broken auth…); useful in casual conversation at a security-focused company.

Draft answer

"Working in [domain] meant security constraints shaped everything: we never touch raw sensitive data on the frontend — [tokenization / processor-hosted fields, if true] — no PII in logs or analytics, strict environment separation, and audit trails."

The bridge line (memorize this) — "That experience is actually part of why this role appeals to me: I've seen firsthand that security is as much about people and process as code."

If asked deeper: name OWASP Top 10 categories you actively handled (injection via parameterized queries, XSS via output encoding/CSP, broken auth via [your auth setup]).

Side projects

Any queue/scheduling side project deep-dive: why that queue technology, what scheduling handles, what happens if it crashes mid-send (idempotency, retries). How did you know it was reliable?

Stripe — Idempotency — the famous engineering post; "idempotency key per scheduled job" is the crash-mid-send answer.

Draft answer

Architecture in 30s — "A scheduled job runs [e.g. daily], computes the day's work, and pushes send-jobs into a queue. Workers pop jobs and process them with backoff for rate limits. It serves [scale]."

Why this tool — "Lightweight, already in our stack, and its data structures fit: [e.g. a list as the work queue, or a sorted set scored by send-time for scheduling], TTLs for cleanup."

Crash mid-send (they'll ask) — "Sends are idempotent: each job has a key. A worker checks-and-sets the key before processing, so a retry never double-sends." Say what you actually did; if it wasn't this, the honest version + "here's what I'd add" is just as strong.

At 10x scale — "I'd move to a real broker — SQS or RabbitMQ — for durability, acks and dead-letter queues, which a simpler queue doesn't give you."

Any in-progress project: the full architecture, key design tradeoffs, what you'd do differently. Since it's in progress, know exactly what works today vs what's planned — don't oversell.

Wikipedia — Data mart — if relevant, be able to define this crisply and contrast with a data warehouse.

Draft answer

One-breath pitch — "[Project] is a tool I'm building: [what it does end to end]."

Own a real tradeoff — pick one deliberate design choice and explain why: "I chose [e.g. hourly aggregation over real-time] because [it makes queries cheap and the system dramatically simpler]. It's a deliberate tradeoff, and I'd revisit it if a use case demanded otherwise."

Honesty structure — "Today, [what genuinely works] is running; [what's planned] is next. If I started over I'd [one real lesson]." Interviewers trust "in progress" projects described this precisely.

Any team project across multiple stacks: what you personally built vs what teammates did — be precise about ownership.

Tech Interview Handbook — Behavioral guide — the "I vs we" section; vague ownership claims are the fastest way to lose an experienced interviewer.

Draft answer

Lead with ownership, not the stack list: "It was a team project — I personally built [your exact pieces], while teammates owned [e.g. a different app/service]."

Then one integration sentence: "My part talked to theirs via [REST API / shared DB / contract], and the thing we had to align on was [auth? data shapes?]."

Rule: never say "we" about code you didn't write — a senior interviewer probes exactly there.

Any real-time feature you built: what "real-time" actually means (websockets? polling? state management?).

MDN — WebSockets API — decide which mechanism you actually used (websockets, SSE, polling) and be able to compare all three in a sentence each.

Draft answer

First, decide the truth: real-time via [websockets / server-sent events / polling] — then say it plainly and be able to compare: websockets = bidirectional persistent connection; SSE = one-way server push over HTTP; polling = client asks on an interval.

Then decode any vague resume phrasing ("optimized data flow") into one concrete sentence — [e.g. "restructured state management so screens stopped over-fetching" or "cached X, cutting requests by Y"].

Behavioral + "why this company"

Why this company: know the product, and connect it to your own domain exposure.

Tech Interview Handbook — Behavioral guide — 20 minutes on the company's product pages; naming something specific in your "why us" answer beats any generic enthusiasm.

Draft answer

Three beats, ~45 seconds total:

1 · Domain — "At [previous company], [relevant constraint] shaped everything I built, and it taught me [a lesson] — which connects directly to what this company works on. That's concrete to me, not abstract."

2 · Product — name something specific from their site: [a specific product or feature you found while browsing]. One named product beats ten adjectives.

3 · Fit — "The role is [stack], which is precisely how I've worked for [X] years — so I can contribute quickly while growing into anything new."

STAR story 1: a hard technical bug or production incident you owned.

The Muse — STAR method — the clearest STAR explainer; write the four beats for your incident story, then time it at 90 seconds.

Draft answer

Fill this skeleton with a real incident — [strongest candidates from your work: a payment/critical flow failing in production, a bad deploy, a data bug in a pipeline]:

S — one sentence of stakes: "[System] broke in production, affecting [who/how many]."
T — "I owned finding and fixing it [under what pressure]."
A — your debugging method is what they're grading: reproduced it, checked logs/monitoring, isolated the layer (frontend? API? DB?), found [root cause], shipped [fix].
R — resolution + prevention: "Restored in [time], then added [a test / an alert / a runbook] so it can't recur silently." The prevention step is what makes the story senior.

STAR story 2: a disagreement (tech choice or with a teammate) and how you resolved it.

Tech Interview Handbook — Behavioral guide — has sample conflict questions; the winning shape is "disagreed → gathered data → committed to the outcome".

Draft answer

Pick a real disagreement — [a tech choice: build vs buy? a migration approach? a design-system API debate?] — and shape it:

S/T — "A teammate and I disagreed on [what]; the decision mattered because [stakes]."
A — the winning shape: you argued with data, not volume — "I [built a quick prototype / benchmarked both / wrote up tradeoffs] and we reviewed it together."
R — either outcome is a good story: "The data supported my approach and we shipped it" OR "the team chose the other path — I committed fully, and [what you learned]." Disagree-and-commit told sincerely is a strength, not a loss.

STAR story 3: a deadline crunch or scope cut — how you prioritized.

The Muse — STAR method — same template; make the Result beat concrete (shipped X on time by cutting Y, followed up with Z).

Draft answer

Pick a crunch — [a launch date? a partner deadline?] — and shape it:

S/T — "We had [time] to ship [what], and the full scope wasn't going to fit."
A — the graded skills are prioritization and communication: "I split scope by user impact — [core flow] was non-negotiable, [nice-to-have] could follow — and flagged the cut early to [stakeholder] rather than missing silently."
R — "Shipped the core on time; delivered [the cut piece] in the following [week/sprint]." Cutting scope loudly and early is the senior move — say it in those words.

Why you're moving on from your current role — have a positive, forward-looking answer.

Tech Interview Handbook — Behavioral guide — frame it as running toward (scale, a domain, growth), never away from; one rehearsed sentence is enough.

Draft answer

One rehearsed, forward-looking sentence — for example:

"[Current company] gave me unusual end-to-end ownership — [1-2 concrete things] — and I've grown a lot there. I'm now looking for [bigger scale / a domain I care about / more growth], and this role is exactly that. I'm running toward something, not away from anything."

Rules: never criticize your current/past employer, keep it under 30 seconds, and don't volunteer more unless asked.

3 questions to ask THEM (team structure, tech stack for your team, what shipping looks like in the first 90 days).

Tech Interview Handbook — Questions to ask — a curated list by round type; pick three that you genuinely care about and memorize them.

Draft answer

Three ready to use — adapt to whoever is interviewing you:

1 — "How is the full-stack team structured — do engineers own features end to end, from frontend through infra?"
2 — "What does the day-to-day stack look like for this team, and which cloud services do you lean on?"
3 — "What would a strong first 90 days look like in this role?"

Bonus (shows domain interest): tailor a fourth question to something specific about the company's product or engineering culture.

Structured full-stack interview prep · red-dot sections are high priority — if you're short on time, do only those. All links open in a new tab.