Interview guides · A tech startup

A tech startup Software Engineer Interview Guide

A tech startup Software Engineer interview guide: recruiter screen, technical deep dives, leadership round, reported questions and a 7-day plan.

The 60-second brief

Candidates describe A tech startup as a startup building developer tools around MCP (Model Context Protocol) ecosystems, packaged as a developer-first platform. The Software Engineer opening is described as a founding position: you would work alongside the founders and take developer tools from idea to shipped product. Candidates describe the responsibilities as writing and testing code, shaping requirements and timelines with the team, taking part in code reviews, joining product discovery, and bringing feedback from the developer community back into the product. The requirements candidates describe name React, TypeScript, a Node.js-style backend and SQL or NoSQL databases.

This guide is for candidates applying to the Software Engineer role at A tech startup, which candidates describe as an entry-level founding position that still expects evidence of real project work, internships or open-source contributions. It covers the three reported rounds (Recruiter Screen, Technical Deep Dives, Leadership Discussion), the reported fundamentals, system design and behavioral questions, and a seven-day plan. Technical questions are linked to a stack of JavaScript, TypeScript, React, Node.js and databases.

Candidates report three rounds over roughly 3-5 weeks: a Recruiter Screen, Technical Deep Dives that may include a take-home assignment or live coding, and a Leadership Discussion with senior leadership.

Focus areas

Data Structures and Algorithms (DSA)
JavaScript
System Design

Overview

The role is described as building developer tooling from the ground up alongside the founders. That shapes what you should rehearse: instead of a single algorithm puzzle, expect questions that span the whole path of a feature, from a React interface, through a Node.js service, to a database and the production monitoring around it. The reported topic mix is Data Structures and Algorithms, JavaScript, TypeScript, System Design and algorithmic problem solving, so be ready to write working code in JavaScript or TypeScript and also to reason about architecture out loud.

The reported questions fall into three groups. The fundamentals group asks about HTTP protocol differences, handling and debugging runtime errors, React and modern JavaScript or TypeScript patterns, backend latency work and a recent complex bug. The design group asks for a scalable URL shortener or real-time chat application, GPU isolation or data integrity in a distributed system, SQL against NoSQL for a high-traffic service, monitoring, tracing and high availability, and a conceptual blockchain design. The behavioral group covers a difficult teammate, competing priorities, five-year goals, learning a technology under a deadline and team contribution. Several of the fundamentals questions are really stories about your own past work, so prepare real projects with real numbers from your own history.

Candidates also report that the technical stage can include a take-home assignment or live coding, described as practical, production-style work rather than whiteboard puzzles. Prepare by building a small TypeScript service with tests and a clear README, and by practising talking while you code. Reports also say that getting stuck is acceptable as long as your reasoning stays visible, so rehearse narrating a plan, a hypothesis and a next step aloud. Reported tips for the founding-team framing say your stories should show ownership of a feature from design to deployment, with your own contribution and a measurable outcome stated plainly.

The A tech startup interview process

The three stages below are what candidates describe, in the order they report them. The technical stage is the one with an optional take-home or live coding component.

Recruiter Screen

Candidates describe the Recruiter Screen as a first conversation to check fit and talk through the role. Treat it as the place to explain why a founding developer-tools role at an MCP-focused startup suits you, and to confirm what the rest of the loop looks like, including whether a take-home or live coding is coming. Nothing technical is reported for this stage, but a clear two-minute account of your background makes every later round easier.

What to demonstrate

Fit for the role, which candidates report as the purpose of this screen
Discussion of the role itself, as candidates report for this stage

How to prepare

Write a two-minute career summary that ends on a project where you owned a feature from design to deployment.
Read the public Model Context Protocol overview so you can say, in two sentences, what MCP is and why developer tools for it interest you.
Be ready to connect your background to the React, TypeScript and Node.js requirements candidates describe, in case the conversation turns to your stack.
Prepare a short list of questions about the technical stage: whether it is a take-home or live coding, and which language it uses.

Technical Deep Dives

The technical stage is reported to be a set of detailed technical conversations, with a take-home or live coding possible, and candidates describe the emphasis as practical, production-style scenarios. The reported topics across the loop are Data Structures and Algorithms, JavaScript, TypeScript, System Design and algorithmic problem solving. Approach it in three layers: write clean, tested JavaScript or TypeScript for a small problem; explain the reasoning behind your stack and design choices; and walk through a design problem such as a URL shortener, real-time chat or a high-availability setup, naming the trade-offs as you go.

What to demonstrate

Working, readable code if the stage includes live coding or a take-home
Reasoning behind technology and architecture choices, not only the choices themselves
System design trade-offs such as consistency against availability, caching and storage engine choice
Debugging and performance experience on real backend work

How to prepare

Build a small Node.js and TypeScript HTTP service with a database, tests and a README, to rehearse the take-home format.
Practise array, hash-map, string and graph problems in TypeScript, saying the complexity aloud after each solution.
Prepare a spoken summary of how HTTP/1.1, HTTP/2 and HTTP/3 differ, and a latency-optimisation story with before and after numbers.
Rehearse the URL shortener, real-time chat, SQL against NoSQL and monitoring and tracing questions with a time limit, naming the read path, write path and failure modes each time.

Leadership Discussion

Candidates report that the last conversation is with senior leaders and centres on whether you fit the team. Reported tips say founding-team candidates should show that they are self-starters who can own a feature from design to deployment, and candidates are encouraged to ask about technical challenges, the roadmap and team culture. Prepare behavioral stories with a clear personal contribution, and a few real questions for the people you meet.

What to demonstrate

Overall fit and alignment, as reported for the leadership stage
Ownership: what you personally decided and delivered
Communication of technical decisions to people who are not specialists

How to prepare

Write out stories for a difficult teammate, competing priorities and learning a technology under a deadline, each with your own actions and a result.
Prepare a five-year answer that connects growth in developer tools and ownership to this specific role.
Write three questions about technical challenges, roadmap and team working style that you actually want answered.
Practise explaining one of your design decisions to a non-technical listener in a few sentences.

Where candidates lose points

Answering the complex-bug and runtime-error questions with a general list of debugging habits and no actual case.

Prepare one bug you personally diagnosed: the symptom, the evidence you collected, the wrong hypothesis you ruled out, the root cause, the fix and the regression test you added. Practise telling it in a few minutes.

Describing React and TypeScript experience as a list of libraries, without explaining any decision you made.

For each project, be ready to explain a choice (state placement, a typed API client, a discriminated union for request states) and the reason behind it. Practise saying why you chose it and what you would change.

Starting a URL shortener, chat or blockchain design by drawing boxes before scope and numbers are set.

Spend the opening minutes on requirements: read and write volume, latency target, what happens on failure and what consistency is needed. Then walk the write path and the read path separately, and name the first thing that breaks when traffic grows tenfold.

Treating SQL against NoSQL as a slogan, such as relational databases not scaling or NoSQL being faster.

Decide from access patterns: the queries, the relationships and the consistency you need. Be able to say when a relational schema with indexes and a cache is enough, and when a key-value or document store fits a lookup-heavy workload.

Telling team stories entirely in terms of what the group did, so your own contribution and the measurable outcome are unclear.

Use I for your decisions and actions, say the team only for outcomes that were shared, and attach a concrete result such as an error rate, a latency number or a shipped feature. Keep a short written version of each story.

Questions & practice

Explain the difference between different HTTP protocols and their methodologies.

Medium · Technical Fundamentals & Coding

Approach

Walk the versions in order and say what each fixed: HTTP/1.0 opened a new TCP connection per request; HTTP/1.1 made connections persistent by default, required the Host header and added chunked transfer encoding, but responses on one connection still come back in order, so one slow response blocks the rest.
HTTP/2 keeps the same methods and status codes but uses binary framing to multiplex many streams over one TCP connection, with HPACK header compression. A single lost TCP packet still stalls every stream on that connection (TCP-level head-of-line blocking).
HTTP/3 runs over QUIC on UDP: loss recovery is per stream, TLS 1.3 is built into the handshake (1-RTT, optional 0-RTT resumption with replay risk), and connection IDs let a session survive a client changing networks. Note that UDP can be blocked on some networks, so clients fall back to HTTP/2.
If 'methodologies' means request methods, separate safe from idempotent: GET, HEAD and OPTIONS are safe; PUT and DELETE are idempotent but not safe; POST is neither, and PATCH is not guaranteed idempotent. That is why retries on POST need an idempotency key.
Close with a practical choice and tie it to MCP, the protocol this company's tools target: its remote transport (Streamable HTTP) sends client messages as HTTP POST requests and can stream server messages over SSE. That suits stateless servers behind a load balancer because any instance can handle any POST, but a long-lived SSE stream or a stateful session still needs session affinity or a shared session store.

Follow-up

For an MCP-style remote server, how would you push server-to-client updates to a browser: Server-Sent Events, WebSockets or long polling, and what does each cost behind a load balancer?
Why can domain sharding and asset concatenation, common HTTP/1.1 tricks, hurt performance under HTTP/2?
What does TLS add to each request, and how do session resumption and keep-alive reduce that cost?

What optimizations have you performed on backend servers to improve latency?

Medium · Technical Fundamentals & Coding

Approach

Open with measurement, not the fix: which endpoint, its p50/p95/p99 before the change, and how you found where time went (a profiler, tracing spans or EXPLAIN ANALYZE). Tail percentiles matter because averages hide the slow requests users notice.
Name the concrete change and why it worked: removing an N+1 query by batching or joining, adding a composite index that matches the WHERE and ORDER BY, adding connection pooling so requests stop paying connection setup, or running independent downstream calls concurrently (Promise.all in Node) instead of sequentially.
If you cached, explain the pattern and its cost: cache-aside in Redis with a TTL, how invalidation happens on writes, and how you avoid a stampede on expiry (request coalescing or jittered TTLs).
For Node services, show you know the event loop: CPU-heavy work such as large JSON parsing, hashing or image processing blocks every request, so move it to worker_threads or a queue and watch event-loop lag as a metric.
Finish with the after numbers, what you checked did not regress (error rate, memory, staleness), and the trade-off you accepted, such as eventually consistent reads from a cache or replica.

Follow-up

How did you confirm the latency gain came from your change and not from lower traffic or a deploy elsewhere?
Your cache hit rate is high but p99 is still bad. Where do you look next?
When would you move work to an asynchronous queue instead of making the synchronous path faster?

Can you walk us through a complex bug you resolved recently?

Medium · Technical Fundamentals & Coding

Approach

Pick a bug with real difficulty, such as a race condition, a memory leak, an intermittent production-only failure or a timezone or encoding error, and state the symptom and its impact in a sentence or two before the investigation.
Walk the debugging sequence: reproduce it (or capture enough logs and traces when you cannot), narrow the search space with git bisect, feature flags or by removing components, form one hypothesis at a time and test it with added instrumentation.
Include the hypothesis that turned out wrong and the evidence that ruled it out; that shows method rather than luck.
State the root cause precisely (for example, two async handlers reading and writing the same record without a version check, or listeners added on every request and never removed) and separate the fix from the workaround.
End with prevention: the regression test that fails without the fix, the alert or log line that would have caught it sooner, and any lint rule or code-review check you added.

Follow-up

If you could not reproduce the bug locally, what would you add in production to catch it the next time?
How did you make sure the fix did not hide a second bug with the same symptom?
What would you change in the codebase or process so this class of bug cannot ship again?

What are the trade-offs between SQL and NoSQL databases for a high-traffic service?

Medium · System Design & Architecture

Approach

Start from access patterns and invariants, not brand names: which queries run on the hot path, whether they are key lookups or ad hoc filters and joins, and which rules must never break (balances, uniqueness, foreign keys).
Relational (PostgreSQL, MySQL): ACID transactions, joins, secondary indexes and a schema that rejects bad data. Reads scale with replicas and caching; writes scale with partitioning or sharding, which is more operational work (or tools such as Citus or Vitess). JSONB columns cover some flexible-schema needs.
NoSQL is several families: key-value and wide-column stores (DynamoDB, Cassandra) partition by key and scale writes horizontally, but you model tables around known queries and denormalise; document stores (MongoDB) suit nested records read together; graph stores suit relationship traversal.
Name the costs: a poor partition key creates hot partitions; cross-partition queries and joins are expensive or unsupported; consistency is often tunable (Cassandra quorum reads and writes with R + W > N, DynamoDB eventually consistent reads by default with a strongly consistent option), and multi-item transactions are more limited than in a relational database.
Give a verdict for a concrete case: keep orders and payments relational, and put high-volume append-heavy data such as events, sessions or chat messages keyed by user or conversation in a wide-column or key-value store, with a cache in front of either.

Follow-up

Your Postgres primary is write-bound. What do you try before moving to a NoSQL store?
How would you choose a partition key for chat messages, and what query does that choice make expensive?
How do you run a migration between the two without downtime?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

How would you design a scalable URL shortener or a real-time chat application?

Medium · System Design & Architecture

Approach

Say which one you are designing, then fix scope and rough numbers: for a URL shortener, writes per day, the read-to-write ratio (heavily read-skewed), retention and whether custom aliases or click analytics are needed; for chat, concurrent connections, group size, message history and delivery guarantees.
URL shortener write path: generate a short code by base62-encoding a unique counter (7 characters give 62^7, about 3.5 trillion codes) with ID ranges handed out to each app server so there is no single hot counter, or hash the long URL and resolve collisions with a conditional insert. Store code to URL in a key-value store or a table keyed by code.
URL shortener read path: look up the code, serve from a cache for hot links, and choose the redirect status deliberately: 301 lets browsers cache it and cuts load but hides repeat clicks, 302 keeps every click visible for analytics. Send click events to a queue rather than writing them synchronously.
Chat: clients hold WebSocket connections to stateless gateway servers; a registry (for example Redis) maps user to gateway, and a pub/sub layer routes messages between gateways. Persist messages partitioned by conversation ID with a per-conversation sequence number for ordering.
Chat delivery: treat it as at-least-once with a client-generated message ID so retries are deduplicated, sync missed messages on reconnect from the last sequence number seen, and send push notifications to offline users; presence comes from heartbeats with a timeout.

Follow-up

For the shortener, how do you stop abuse such as spam links and enumeration of sequential codes?
For chat, how do you keep message order in a group conversation when senders are connected to different gateways?
What breaks first at ten times the traffic, and what do you change?

Describe how you would implement isolation on a GPU or manage data integrity in a distributed system.

Medium · System Design & Architecture

Approach

Clarify which half you are answering, since the two are different problems; then give the menu of options with the isolation each provides.
GPU isolation, strongest to weakest: a whole GPU per tenant (passthrough to a VM, or the Kubernetes device plugin assigning a full device to a container); NVIDIA MIG on supported GPUs such as A100 and H100, which splits one card into hardware partitions (up to seven) with dedicated memory and compute; MPS, which runs processes concurrently with weaker fault isolation; plain time-slicing, which shares the card with no memory isolation between processes.
For GPU multi-tenancy, add what sits around the hardware: per-tenant quotas and scheduling, clearing memory between jobs, and monitoring per-partition utilisation with tools such as nvidia-smi or DCGM, plus the trade-off that stronger isolation wastes capacity when jobs are small.
Data integrity across services: keep each invariant inside one database transaction where possible; when a workflow spans services, use a saga with compensating actions, and a transactional outbox so the state change and the event are committed together. Two-phase commit gives atomicity but blocks if the coordinator fails.
Make every consumer idempotent (idempotency keys or a processed-message table) because brokers deliver at least once, use optimistic concurrency with a version column to stop lost updates, and run reconciliation jobs that compare systems and flag drift.

Follow-up

A saga step fails after money has moved. Walk through the compensation and what the user sees in the meantime.
Why can a process sharing a GPU under time-slicing affect another tenant, and how would you detect it?
How would you detect that two services have silently diverged on the same record?

How do you approach monitoring, tracing, and high availability in a production environment?

Medium · System Design & Architecture

Approach

Define health from the user's side first: SLIs such as request success rate and p99 latency, an SLO for each (99.9% monthly availability allows about 43 minutes of downtime in a 30-day month), and alerts on error-budget burn rate rather than on every CPU spike.
Metrics: RED (rate, errors, duration) per service and endpoint, USE (utilisation, saturation, errors) per resource, plus runtime-specific signals such as event-loop lag for Node. Use histograms so percentiles can be computed, and watch label cardinality.
Tracing: instrument with OpenTelemetry, propagate context across services with the W3C traceparent header (including through queues), and choose sampling: head-based is cheap, tail-based keeps the slow and failed traces you actually need. Put the trace ID in structured logs so you can jump from an alert to a trace to the log lines.
High availability: run stateless instances across availability zones behind a load balancer with health checks, replicate the database with tested failover, and remove single points of failure such as one cron host or one Redis.
Contain failures: timeouts on every network call, retries with exponential backoff and jitter only for idempotent operations, circuit breakers and graceful degradation (serve cached or partial results), plus rollbacks and runbooks you have rehearsed.

Follow-up

An alert fires for p99 latency but error rates are normal. Walk through how you find the cause.
Why can retries make an outage worse, and how do you stop a retry storm?
How would you test that database failover actually works before a real incident?

Can you explain how you would design a blockchain system conceptually?

Medium · System Design & Architecture

Approach

Start with the data structure: each block holds a header with the previous block's hash, a Merkle root of its transactions, a timestamp and (in proof of work) a nonce. Changing any past transaction changes that block's hash and breaks every later link, which makes tampering evident.
Explain why the Merkle tree matters: a light client can verify a transaction is in a block with a proof of O(log n) hashes instead of downloading every transaction.
Consensus decides who appends the next block: proof of work (the chain with the most cumulative work wins, finality is probabilistic, so wait for confirmations), proof of stake (validators lock stake and can be slashed for misbehaviour) or a BFT protocol for permissioned networks, which tolerates f faulty nodes out of 3f + 1 and gives fast finality.
Cover the rest of the system: a peer-to-peer gossip network, a mempool of pending transactions, digital signatures to prove ownership, a state model (UTXO or account balances with nonces) and the double-spend check before inclusion.
State the trade-offs and when not to build one: throughput and latency are far below a central database, and if a single trusted operator exists, an append-only log with signed entries or a ledger database gives auditability without consensus.

Follow-up

Two miners find a block at the same time. What happens to the chain and to the transactions in the losing block?
How does an account-based chain stop the same signed transaction from being replayed?
Why does a BFT protocol need 3f + 1 nodes to tolerate f faulty ones?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan moves from the loop and role, through the JavaScript, TypeScript and React fundamentals, live coding with a small MCP server, backend and database questions, system design and finally behavioral stories. Each day ends with a written or recorded output you can review, and the last day is a full mock.

Day 1 — Map the loop and the role

Write the three reported rounds (Recruiter Screen, Technical Deep Dives, Leadership Discussion) on one page, and next to each, the reported question types you are least ready for.
Read the public Model Context Protocol overview and write a two-sentence explanation of what MCP is.
Write and say aloud a two-minute career summary ending on a project where you owned a feature from design to deployment.

Deliverable: A one-page loop map, a two-sentence MCP summary and a rehearsed two-minute career summary.

Day 2 — Runtime errors and the React and TypeScript story

List the React, JavaScript and TypeScript patterns you have used (state placement, effects, discriminated unions, generics) with one decision and its reason for each.
Record a spoken answer to the React and TypeScript experience question, then rewrite it to name specific decisions.

Deliverable: A written debugging checklist, a pattern list with reasons, and one recorded React and TypeScript answer.

Day 3 — Live coding, the take-home format and a small MCP server

Solve four or five array, hash-map, string and graph problems in TypeScript, saying the time and space complexity aloud after each one.
Build a small Node.js and TypeScript HTTP endpoint backed by a database, with tests and a short README, to practise production-style code.
Build a tiny MCP server with the official TypeScript SDK that exposes one tool and one resource over stdio, and run it from an MCP client.
Be able to explain the host, client and server roles, the JSON-RPC 2.0 messages between them, and how the stdio transport differs from Streamable HTTP.

Deliverable: Four or five solved problems with complexity notes, a small tested TypeScript service with README, and a working MCP server with a short written explanation of its roles, messages and transports.

Day 4 — HTTP, backend latency and databases

Write a comparison of HTTP/1.1, HTTP/2 and HTTP/3 covering connection reuse, multiplexing and head-of-line blocking, plus a short list of when each matters.
Prepare a backend latency story with before and after numbers, covering caching, indexing and asynchronous processing.

Deliverable: A written HTTP comparison, a latency story with numbers, and a SQL against NoSQL decision table.

Day 5 — System design practice

Design a URL shortener and a real-time chat application, each with separate read and write paths, a storage choice, a scaling plan and failure modes.
Outline an answer on monitoring, tracing and high availability: metrics, logs, traces, alerts and a redundancy plan.
Prepare a short conceptual answer for GPU isolation and data integrity in a distributed system, and for a blockchain design, listing core components and trade-offs.

Deliverable: Three design write-ups (URL shortener, real-time chat, monitoring and availability) and a short outline each for the GPU or integrity question and the blockchain question.

Day 6 — Behavioral stories

Write STAR outlines for the difficult-teammate, competing-priorities and learn-fast-under-deadline questions, each with your own actions and a result.
Write your complex-bug story and your team-contribution examples as concrete behaviours, not adjectives.
Say each story aloud, then cut anything that does not show your decision or its outcome.

Deliverable: Five story outlines (teammate, priorities, fast learning, complex bug, team contribution) with results.

Day 7 — Leadership mock and your questions

Write a five-year answer tied to this founding role and say it aloud.
Write three questions about technical challenges, roadmap and working style that you want answered.
Run a full mock: one coding problem, one design question and two behavioral questions, spoken aloud with your reasoning visible.

Deliverable: A rehearsed five-year answer, three written questions for the leadership round, and a recorded mock to review.

Behavioural preparation

Candidates report the Leadership Discussion as the stage for overall fit and alignment with senior leadership, and the reported behavioral questions focus on working with difficult people, handling priorities, learning quickly and growing in the role. For a founding position, every story should show something you owned and decided, and what resulted.

Can you walk us through a complex bug you resolved recently?

How do you handle and debug common runtime errors?

Medium · Technical Fundamentals & Coding

Approach

Open with a repeatable sequence, then back it with a real example: reproduce the error, read the exact message and stack trace, check what changed recently (deploys, dependencies, config), narrow the failing path with logs or a debugger, form one hypothesis at a time, fix it, and add a regression test.
Name the error classes you meet in a TypeScript and Node.js stack: TypeError from undefined values, unhandled promise rejections, missing await, async race conditions, JSON parse failures and bad API responses. Say how strict TypeScript settings, runtime validation at API boundaries and source maps shorten diagnosis.
For production errors, describe the tooling: structured logs carrying a request id, an error tracker with grouped stack traces, metrics for error rate, and git bisect when you know a build used to work. For a React front end, mention error boundaries and the browser console and network tab.
Separate handling from debugging: catch errors where you can recover or add context, and let unexpected ones surface rather than swallowing them. Since Node 15 an unhandled rejection crashes the process by default. A process-level handler should log the error with context and then exit, so a supervisor such as systemd or Kubernetes restarts a clean process, instead of swallowing the error and running on in an unknown state. For request-level errors, return a clear error response rather than a stack dump.
Finish with one concrete case of yours, such as an intermittent failure or one that only reproduced in production, and say how you confirmed the fix worked.

Follow-up

How would you debug an error that only happens in production and that you cannot reproduce locally?
When should an error be caught and handled, and when should the process be allowed to fail?
How do you stop the same class of runtime error from coming back?

Describe your experience with React and modern JavaScript/TypeScript patterns.

Medium · Technical Fundamentals & Coding

Approach

Choose one or two real projects and describe what you owned, instead of listing libraries. Say what the app did, how many components or screens were involved, and which decisions were yours.
On React, cover state placement (local state, lifting state, context, and a server-state cache for fetched data), keys on lists, effect dependency arrays and when to derive values during render instead of using an effect. Say you add memoisation after measuring with the React profiler, not by default.
On TypeScript, give specifics: strict mode, narrowing, discriminated unions for loading, error and success states, generics for reusable hooks or API clients, avoiding any, and sharing types between a React client and a Node.js backend.
On modern JavaScript, show you understand the runtime: async and await, Promise.all against sequential awaits, closures, the event loop, immutability in state updates, and ES modules. Be honest about the parts you know less well and say how you would close the gap.
Close with a pattern you would change in hindsight, to show you evaluate your own code.

Follow-up

When is useEffect the wrong tool, and what would you use instead?
How would you type a function whose return type depends on its argument?
How do you find and fix a component that re-renders too often?