Interview guides · Disney Entertainment and ESPN Product & Technology

Disney Entertainment and ESPN Product & Technology Software Engineer Interview Guide

Disney Entertainment and ESPN Product & Technology Software Engineer interview guide: reported rounds, system design and behavioral questions, 7-day plan.

The 60-second brief

Disney Entertainment and ESPN Product & Technology is the engineering organisation behind digital products for entertainment and sports fans. Candidates describe the work as spanning streaming infrastructure, advertising platforms and internal engineering tooling. The topic tags attached to this loop point the same way: general software engineering, observability, ad platform engineering on an audience team, build and tooling infrastructure, and AI systems. A Software Engineer here is described as taking features from design and prototyping through production deployment and maintenance, working with product managers, designers and other engineering teams, and reviewing code, improving CI/CD, strengthening observability and paying down technical debt along the way.

This guide is for engineers preparing for a Software Engineer loop at Disney Entertainment and ESPN Product & Technology. It covers the three reported rounds (Technical Screen, System Design Session, Behavioral Interviews), the fifteen reported questions on databases, debugging, architecture, streaming-scale design and behavioral stories, and a plan that practises them in order. It does not cover compensation or team-specific stacks, which vary by posting.

Candidates report three rounds over roughly 3-5 weeks: a Technical Screen, a System Design Session and Behavioral Interviews with peers and leadership. The exact round count is said to vary with team and seniority.

Focus areas

Software Engineering (General)
Observability (General)
Ad Platform Engineering (Audience Team)

Overview

The reported questions fall into three groups. The first is production engineering: tuning a database under heavy traffic, finding a memory leak in a running service, weighing a monolith against microservices for a streaming product, keeping a service available through failures, and handling asynchronous work in your own stack. The second is design at event scale: tracking real-time engagement during a live sports event, delivering content globally with low latency, building an ad-insertion platform with a tight response budget, and designing for observability from the start. The third is behavioral: a refactor for ten times the traffic, a technical disagreement, debt versus shipping, mentoring, a process bottleneck and ambiguity.

The workloads in these questions share a shape. Live events produce sudden, synchronized spikes. Ad decisions sit on the playback path, so a slow decision is felt by the viewer. Telemetry arrives in volume and has to be counted without being lost or double-counted. Prepare each design answer around those pressures: say what happens to the read path and the write path during a spike, what degrades gracefully when a dependency is slow, and which numbers you would watch to know it is healthy.

Candidates also report that the role lists Java, Python, Go or JavaScript/TypeScript, distributed systems and cloud platforms as must-haves, with streaming media, ad-tech and large-scale data pipelines as nice-to-haves, and that CI/CD, containers and cloud-native tooling are part of the technical evaluation. Pick one language and be ready to write correct, tested code in it, and keep two or three real projects at a level of detail where you can explain a decision, its alternative and its measured result.

Reports describe the whole loop as conversational: clarify the requirement, state assumptions, discuss trade-offs and validate the approach before building it. That is advice you can act on directly. Practise opening each answer with scope questions, naming the trade-off you are accepting, and closing with how you would verify that the design works.

The Disney Entertainment and ESPN Product & Technology interview process

The three stages below are what candidates describe; the exact number and order of interviews can vary by team and seniority.

Technical Screen

Candidates describe the first stage as an initial evaluation of technical skill through coding challenges or assessments. The reports do not give a platform, duration or problem list, so prepare for both a timed assessment and a live coding conversation. Choose the language you write most fluently (the role lists Java, Python, Go and JavaScript/TypeScript), practise writing complete, runnable solutions with your own tests, and say your assumptions out loud before you start. The reported technical and domain questions on database performance, production memory leaks and asynchronous processing are the material to rehearse for the conversational side of a technical stage.

What to demonstrate

Working, readable code in a mainstream language, since a coding challenge can only be judged on code that runs
Coding standards and tests: the reported evaluation areas ask whether code is clean, maintainable and well tested
Systematic debugging of a failing or slow program
Fundamentals behind the code, such as how a database executes a query or how your runtime handles concurrent work

How to prepare

Solve two or three problems in your main language end to end, including edge-case tests
Rehearse a spoken answer on database performance: measure with EXPLAIN, fix indexes and query shape, then consider pooling, caching and read replicas
Write out your debugging sequence for a leaking production service: confirm growth, capture heap snapshots over time, diff them, find the retaining reference, and ship a fix with a regression check
Prepare a concrete description of how asynchronous work is handled in your current stack: queues or event loop, timeouts, retries, idempotency and backpressure

System Design Session

Candidates describe a deep-dive session on architectural choices and design capability. The reported design questions cover a live-sports engagement tracker, a global content delivery system, a low-latency ad-insertion platform and observability designed from scratch, and the technical-domain questions add monolith versus microservices and high availability. One report advises against rushing: clarify requirements and explain why before drawing boxes. Treat the hour as a structured conversation. Pin down users, traffic shape and latency budget, sketch the data path, then go deep on the one or two components where the hard trade-off lives.

What to demonstrate

Trade-off analysis: pros and cons of different technologies and patterns, which the reported evaluation areas list first
Performance work: locating and resolving bottlenecks in a distributed system
Resiliency: keeping services running through high-traffic events
Clarifying requirements before committing to an architecture

How to prepare

Design the live-event engagement tracker on paper: client beacons, ingestion, a partitioned stream, windowed aggregation, a store for dashboards, and what happens to counts during a spike
Design global content delivery with edge caching, origin shielding, cache keys, invalidation and failover between regions, and be ready to quantify latency gains
Design an ad-insertion path with a strict decision budget: pre-computed eligibility, fast lookups, a timeout with a fallback response, and impression logging off the hot path
Prepare a balanced monolith-versus-microservices answer for a streaming product, and a list of the signals, metrics, logs and traces you would build in from the first release

Behavioral Interviews

Candidates describe interviews with peers and leadership that focus on past experiences and cultural fit. Reports also mention going deep into any project on your resume: the technical challenges, your decisions and their impact. The reported prompts cover a refactor for ten times the traffic, a technical disagreement, technical debt against shipping speed, mentoring, a process bottleneck and ambiguous requirements. Build a bank of four or five real stories, each with your own decision, a measured result and something you would change, and map each story to several prompts.

What to demonstrate

Past experience told through specific decisions and outcomes, as the stage is described
Communication and collaboration with product managers, designers and other engineers
Handling technical disagreement while keeping the working relationship intact
Depth of understanding of the projects on your resume

How to prepare

Write each story in Situation, Task, Action, Result form, with numbers for the before and after state
Pick one story where you changed a system under load, one disagreement, one trade-off between debt and delivery, and one mentoring or process-improvement example
Re-read your resume and write the hardest technical decision and the rejected alternative for every project listed
Practise the opening two sentences of each story aloud so the context stays short and the reasoning gets the time

Where candidates lose points

Drawing the architecture for the live-event or ad-insertion design before pinning down traffic, latency budget and failure behaviour

Spend the opening on scope: who calls the system, peak load at a game start or a stream launch, the response budget for an ad decision, and what the viewer sees if a dependency is slow. State assumptions out loud, then design.

Answering the database performance question with a flat list of techniques (add an index, add a cache, shard) and no order of operations

Lead with measurement: slow-query data, EXPLAIN output, lock waits and connection counts. Then fix query shape and indexes, add pooling, then caching and replicas, and say what each costs in staleness or complexity.

Treating a production memory leak as a restart-and-hope problem, or guessing at causes without heap evidence

Describe the sequence: confirm steady growth in a metric, take heap snapshots at two points, diff them to find the retaining reference, fix it, then add an alert and a regression test.

Presenting microservices or monoliths as the default answer for a streaming product instead of weighing them

Give both sides: deployment independence, scaling hot paths separately and team ownership against network failure modes, operational overhead and data consistency. Say which you would choose for a given team size and why.

Telling behavioral stories in the team's voice, with no personal decision and no measured result, for example a traffic refactor with no before-and-after figures

Write each story in STAR form with your own decision highlighted, a baseline and result number, and one thing you would change. Practise each one aloud so the reasoning, not the backstory, takes most of the time.

Questions & practice

Explain how you handle asynchronous processing in your current technology stack.

Medium · Technical & Domain Expertise

Approach

Separate the two meanings: in-process concurrency and out-of-process background work. Be precise about the runtime you use: Python asyncio is a single-threaded event loop, so a blocking call stalls it (offload with asyncio.to_thread); Node offloads file and crypto work to the libuv pool; Java needs an explicit executor for CompletableFuture; Go uses goroutines and channels.
For background work, the producer enqueues a job (SQS, RabbitMQ, Kafka, Celery) and workers consume it. Delivery is usually at-least-once, so handlers must be idempotent (dedupe key, upsert), acknowledge only after the work commits, and send poison messages to a dead-letter queue after a set number of attempts.
Address ordering and backpressure: Kafka orders only within a partition, so key by entity id; cap concurrency with a semaphore or prefetch count, and use bounded queues so producers slow down instead of exhausting memory.
Solve the dual-write problem between the database and the queue with a transactional outbox (event row written in the same transaction, relayed afterwards) or change data capture.
Make it observable: queue depth and age of the oldest message, retry and dead-letter counts, and a correlation id carried in message headers.

Follow-up

A worker crashes halfway through a job. What happens to the message, and why is reprocessing safe?
How do you time out or cancel an async task in your stack?
Someone asks for exactly-once processing. What can you actually guarantee, and how?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
Where does the fingerprint get computed relative to request decompression and the body-size limit?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

How do you optimize database performance for high-traffic applications?

Medium · Technical & Domain Expertise

Approach

Measure before tuning: rank queries by total time (pg_stat_statements or the slow-query log), then read EXPLAIN ANALYZE for sequential scans on large tables, row estimates far from actual counts, and nested loops over big inputs.
Index for the query shape: composite index with equality columns first, then the range or ORDER BY column; a covering index (INCLUDE) allows index-only scans. Every extra index costs write throughput and storage, so drop unused ones.
Protect the database from connection storms with a pooler such as PgBouncer in transaction mode and a bounded pool per service; Postgres runs one process per connection, so thousands of direct connections hurt.
Scale reads with replicas (route read-your-writes to the primary because replicas lag) and a cache-aside layer in Redis with TTLs, invalidation on write and jittered expiry or request coalescing to avoid a stampede.
Scale writes by batching, spreading hot rows (sharded counters), and partitioning large tables by time for pruning and cheap retention drops; shard by key only once a single primary is out of write headroom.

Follow-up

A query got slow as data grew but the code did not change. What do you check first (stale statistics, bloat, a plan flip)?
How would you handle a single hot row, such as a counter that every viewer of one popular event updates?
When would you denormalise a table, and what does it cost you on writes?

What are the trade-offs between monolithic and microservices architectures in a streaming context?

Medium · Technical & Domain Expertise

Approach

Name the axes before choosing: independent deploys and scaling, fault isolation and team ownership on one side; network hops, distributed data, and operational load (service discovery, tracing, per-service pipelines) on the other.
Use a streaming example: playback start (manifest, entitlement, license) has a different load and availability profile from catalog browse or recommendations. Separating them lets the playback path scale and deploy on its own and lets browse features degrade without blocking playback.
Count the costs: each synchronous hop adds latency and a failure point, and availability multiplies in series (three dependencies at 99.9% each give about 99.7%). One database per service means cross-service queries need events or read models with eventual consistency.
Recommend a middle path: a modular monolith with enforced boundaries, extracting services where scaling needs or release cadence really differ, using the strangler-fig pattern. Warn against a distributed monolith (shared database, lockstep deploys).

Follow-up

How would you extract the first service from a monolith without downtime or a big-bang cutover?
How do you keep one user request that crosses five services debuggable?
If the user-profile service is down, should playback still start? How would you design for that?

How do you ensure high availability and fault tolerance in your service design?

Medium · Technical & Domain Expertise

Approach

Start from a target: an SLO and its error budget per user journey, then list single points of failure across compute, data, network and third-party dependencies.
Remove them with redundancy: stateless instances in several availability zones behind health-checked load balancers, enough spare capacity that losing a zone does not overload the rest, and replicated data (synchronous within a region for no-loss failover, asynchronous across regions with a non-zero RPO).
Contain dependency failures: a timeout on every call, retries with exponential backoff and jitter only for idempotent operations (use idempotency keys), circuit breakers, bulkheads with separate pools, and fallbacks such as serving stale cached data.
Handle overload explicitly: rate limiting and load shedding by priority, queues to absorb bursts, and pre-scaling before known peaks because autoscaling reacts with a lag.
Prove it works: failover drills and fault injection, canary deploys with automated rollback, and alerts on the SLIs the SLO is defined on.

Follow-up

Retries made an outage worse. Why does that happen across several layers, and how do retry budgets fix it?
Active-active or active-passive across regions: what does each cost in consistency and money?
How do you stop two nodes from both acting as leader after a failover (quorum, fencing tokens)?

Design a system to track real-time user engagement for a live sports event.

Medium · System Design & Architecture

Approach

Clarify scope: which signals (concurrent viewers, reactions, poll votes), how fresh the numbers must be, exact or approximate counts, the expected peak and the spikes at key moments, and who reads the result (in-app counters, internal dashboards).
Ingest: clients batch events to stateless collectors behind a load balancer, which write to a durable log (Kafka or Kinesis). Partitioning by event id alone makes one live event a hot partition, so salt the key into sub-partitions and merge downstream.
Aggregate in a stream processor (Flink, Kafka Streams) with short tumbling windows on event time and watermarks for late data; pre-aggregate per partition, then merge. Count concurrent viewers from heartbeats that expire, and unique viewers with HyperLogLog (Redis HLL has about 0.81% standard error).
Serve from a separate read path: aggregates in Redis or a time-series store, pushed over WebSocket or SSE, or polled through a CDN with a very short TTL so millions of readers do not hit the store.
Keep a cold path: raw events land in object storage or a warehouse for exact post-event numbers, deduplicated by event id because delivery is at-least-once.

Follow-up

Kickoff sends traffic up many times over within seconds. What protects the collectors and the log?
How do you count concurrent viewers when clients drop without sending a stop event?
An event arrives after its window has closed. Do you drop it, update the window, or reconcile later?

How would you architect a global content delivery system to minimize latency?

Medium · System Design & Architecture

Approach

Clarify what is delivered: video segments and static assets (highly cacheable) versus personalised API responses, live versus on-demand, and the latency metric that matters (time to first byte, startup time, rebuffering).
Use tiered caching: edge PoPs near users, a mid-tier or origin shield that collapses misses so the origin sees roughly one request per object per shield, and an origin on replicated object storage.
Route users to the nearest healthy PoP with anycast or latency-based GeoDNS, with health-check failover; terminate TLS at the edge and use HTTP/2 or HTTP/3 to cut handshake round trips; consider multi-CDN steering from real-user measurements.
Design the cache keys and TTLs: normalise keys (drop irrelevant query parameters), version immutable objects in the URL instead of purging, give live manifests short TTLs and segments long ones, validate signed URLs or tokens at the edge, and coalesce concurrent misses.
Track cache hit ratio, origin egress, time to first byte and rebuffer rate per region to find where latency comes from.

Follow-up

A popular title launches and every edge misses at once. What does the origin see, and what protects it?
Content must be pulled quickly when rights expire. How do you invalidate it everywhere?
When would a second CDN be worth its cost and complexity?

Explain the design considerations for an ad-insertion platform that requires low-latency response times.

Medium · System Design & Architecture

Approach

Clarify the model: server-side insertion (ads stitched into the stream manifest at each break) or client-side, live or on-demand, and the latency budget for one ad decision. In live streams, cue markers such as SCTE-35 signal the break, and VAST/VMAP describe the ad response.
Lay out the path: break signal, then an ad decision service applies targeting (segment, geo, device), frequency caps, pacing and budgets, returns creatives, and a stitcher rewrites each session's manifest to point at the ad segments.
Keep the decision fast and safe: hard timeout with a fallback (house ad or slate) so playback never waits, campaign and audience-segment data held in memory and refreshed asynchronously, and creatives transcoded ahead of time to match the stream's renditions.
Handle the live burst: every viewer reaches the break at the same moment, so fetch decisions ahead of the break with jitter, keep the decision service stateless and horizontally scaled, and use approximate or locally batched counters for caps and budgets with a bounded overspend.
Track impressions with beacons written asynchronously to an event log, dedupe them, and reconcile billing from the log, not the hot path.

Follow-up

Budgets are counted in several regions. How much overspend is acceptable, and how do you bound it?
A creative was not transcoded for one rendition. How do you stop it from breaking playback?
p99 decision latency starts breaching its budget. What do you look at, and what degrades first?

How do you approach designing for observability and monitoring from the ground up?

Medium · System Design & Architecture

Approach

Start from user journeys: define SLIs (availability, p99 latency, correctness) and SLOs, and page on error-budget burn rate over several windows, not on CPU, so every page matches user pain.
Instrument all three signals: RED metrics per service (rate, errors, duration) and USE for resources, structured logs carrying trace and request ids, and distributed traces with context propagated (W3C traceparent through OpenTelemetry) across HTTP calls and message queues.
Control cardinality and cost: never use user ids as metric labels, put high-cardinality detail in logs and traces, and sample traces (tail-based sampling can keep every error and slow request).
Make it the default: a shared service template with instrumentation built in, dashboards and runbooks shipped with each service, deploy markers on graphs, and synthetic checks for critical paths.
Keep alerts honest: every alert has a runbook and an action, and alerts that fire without action get tuned or deleted after review.

Follow-up

p99 latency alerts but the average looks fine. How do you find the slow requests?
Observability spend grows faster than traffic. What do you cut first?
How do you follow one request through an async queue and a worker?

Describe your process for debugging a memory leak in a production environment.

Medium · Technical & Domain Expertise

Approach

Confirm it is a leak and not a bigger steady state: memory retained after garbage collection keeps climbing under stable traffic. Correlate the start with deploys, traffic mix or one endpoint, and compare heap usage with process RSS to split heap from native memory.
Mitigate first: roll back if a deploy lines up, or recycle instances on a schedule, while keeping one affected instance out of the load balancer for evidence.
Take two heap snapshots some time apart and diff them: jcmd GC.heap_dump plus Eclipse MAT dominator tree on the JVM, tracemalloc snapshot comparison in Python, heap snapshots in Node, pprof inuse_space in Go. Look for the type whose retained size grows.
Check the usual causes: unbounded maps or caches keyed by user or request id, listeners never unregistered, ThreadLocals on pooled threads, unclosed streams or connections, goroutines blocked forever.
Fix with a bounded structure (LRU with size limit and TTL), reproduce under a load test to show the slope is flat, and add a post-GC heap metric with an alert so a regression is caught early.

Follow-up

The heap is flat but RSS keeps growing. Where do you look next (native allocations, allocator fragmentation, JVM native memory tracking)?
A JVM heap dump pauses the process. How do you capture one without hurting live traffic?
What would you add to code review or CI so this class of leak does not come back?

Suggested practice checklist

Each day targets one part of the reported loop: coding warm-up for the Technical Screen, databases and debugging, architecture trade-offs, the three streaming designs, behavioral stories, and a final mock run of all three stages.

Day 1 — Coding warm-up in your main language

Pick one language from the reported list (Java, Python, Go or JavaScript/TypeScript) and commit to it for the loop
Write a one-page map of the three reported rounds and mark the one you are least ready for

Deliverable: Two passing solutions with tests in your chosen language, plus a one-page round map with the weakest stage marked.

Day 2 — Database performance under heavy traffic

Outline a spoken answer to the database performance question in measurement-first order: slow-query data, EXPLAIN, indexes, query shape, pooling, caching, replicas
Work the practice problems on detecting a concurrent edit and on stopping joins from fanning out a page
Write a short list of the trade-offs of each fix, such as cache staleness and replica lag

Deliverable: A one-page database tuning checklist with the trade-off of each step, and two solved SQL practice problems.

Day 3 — Production debugging and asynchronous processing

Write your step-by-step plan for finding a memory leak in your runtime, naming the actual tools you would use for heap snapshots and diffs
Write a short account of how your current stack handles asynchronous work: queues or event loop, retries, timeouts, idempotency, backpressure
Record yourself answering both questions aloud and cut anything that does not change a decision

Deliverable: A debugging runbook for a leaking service, a written asynchronous-processing answer, and one recorded spoken take of each.

Day 4 — Architecture trade-offs, availability and observability

Write a balanced comparison of monolith and microservices for a streaming product, ending with a recommendation for a stated team size
List the availability mechanisms you would use: redundancy, health checks, timeouts, retries with backoff, circuit breakers, graceful degradation and multi-region failover
Sketch an observability design from scratch: metrics, structured logs, traces, service-level indicators and alerts tied to user-visible symptoms

Deliverable: A comparison table with a recommendation, an availability checklist, and a one-page observability design.

Day 5 — Three streaming-scale designs

Design the real-time engagement tracker for a live sports event, covering ingestion, partitioned streaming, windowed aggregation, storage and spike behaviour
Design a global content delivery system covering edge caching, cache keys, origin protection and invalidation
Design a low-latency ad-insertion platform with a decision budget, a timeout fallback and impression logging off the hot path

Deliverable: Three one-page designs, each with stated assumptions, a data-flow sketch, the hardest trade-off and the first thing that breaks at ten times the load.

Day 6 — Behavioral story bank

Write four or five STAR stories from your own work, each with a baseline, your decision and a measured result
Map each story to the six reported prompts: the traffic refactor, the disagreement, debt versus shipping, mentoring, the process bottleneck and ambiguity
Re-read your resume and write the hardest decision and the rejected alternative for every project listed

Deliverable: A story bank in which every reported prompt has a chosen story, plus a decision-and-alternative note for each resume project.

Day 7 — Full mock loop

Do a timed coding problem in your chosen language, narrating your assumptions
Do one design from day 5 aloud, starting with clarifying questions and finishing with how you would verify the design
Tell two stories aloud and record them, then list the three weakest answers across the whole run

Deliverable: A recorded mock covering code, design and behavioral answers, with a ranked list of gaps and one fix for each.

Stories for the peer and leadership interviews

Candidates report that the Behavioral Interviews are held with peers and leadership and centre on past experiences and cultural fit, including detailed questions about projects on your resume. The reported prompts test how you scale a system, settle technical disagreements, trade debt against delivery, mentor, remove process friction and work with unclear requirements. Prepare stories where your own decision is easy to find and the result is measured.

Describe a time you had to refactor a system to handle a 10x increase in traffic.

Medium · System Design & Architecture

Approach

Pick a refactor you actually led. Open with the trigger and a baseline: peak requests per second, p99 latency, error rate and which resource saturated first. A traffic number you cannot source weakens the whole story.
Show the diagnosis before the fix: a trace, profile or load test that located the first bottleneck, for example database connections, a hot partition or a long synchronous call chain, instead of a generic list of scaling tricks.
Name the options you rejected and the trade-off you accepted: vertical scaling, caching with staleness, read replicas, moving writes behind a queue, sharding. Say what each would have cost in complexity and operations.
Describe the rollout: load test beyond the target, canary or feature flag, a rollback path and the dashboards you watched. Close with measured before and after results and the next ceiling you knew about.
The sinking mistake is a team-effort story with no personal decisions, or a rewrite narrative with no evidence the old design was the limit.

Follow-up

How did you build the load test, and how closely did it match real traffic?
What failed first when you pushed past the target, and how did you find out?
What would break at 100x, and what would you change then?