This guide's research places the Software Engineer role at Warner Bros. Discovery across backend services, video delivery and consumer-facing frontends for streaming products including Max and Discovery+, along with real-time sports data. The reported interview questions follow the same mix: data structures and algorithms, system and object-oriented design, database modelling, and behavioral questions about outages, disagreements and ambiguous requirements.
The design questions candidates report go below the architecture diagram. A rate limiter is asked for with class structures and component interactions, a multiplayer chess game with object-oriented patterns and game-state management, and a payment processing system as an exercise in OOP concepts. The database questions are just as concrete: a relational schema for video comments queried by user, SQL versus NoSQL for session data against billing data, and a Redis cache in front of a database during a live sports traffic spike. Prepare to write interfaces, tables and indexes, not only to draw boxes.
Candidates describe four stages over roughly 3-5 weeks: an automated online assessment, a recruiter screen, technical deep dives, and a final loop. The assessment is reported as a HireVue session with around 20 multiple-choice questions on data structures, OOP and operating-system fundamentals, plus 5 pre-recorded video behavioral questions. The final loop is reported to cover system design, coding, operational excellence (debugging, refactoring, testing, CI/CD) and behavioral questions. Confirm the current format with your recruiter, since it varies by team and level.
Automated Online Assessment
reportedCandidates report this stage as a HireVue session: around 20 multiple-choice questions covering data structures and algorithms, object-oriented programming and operating-system fundamentals, plus 5 pre-recorded video behavioral questions. Database schemas are also reported among the quiz topics. Nobody is there to clarify a question or react to an answer, so the multiple-choice section rewards recall you have refreshed recently, and the video section rewards an answer that is already structured before the recording starts. These recorded answers come before any live interview, so treat them as your first impression and prepare them as carefully as a live interview.
What to demonstrate
- Recall of CS fundamentals across data structures, complexity, OOP concepts, operating-system basics and schema design, without an interviewer to prompt you
- Whether a recorded behavioral answer has a clear situation, a decision you made and an outcome, delivered without rambling or restarting
- Whether you read each multiple-choice option carefully instead of choosing the first one that looks familiar
How to prepare
- Build a one-page review sheet for the quiz topics: complexity of common operations, stack/queue/heap/hash behaviour, the four OOP pillars with an example each, processes versus threads, deadlock conditions, paging, and normal forms with a small schema
- Record yourself answering the reported behavioral prompts (an outage you diagnosed, a shortcoming you are addressing, a design disagreement, ambiguous requirements) and watch the playback once for filler and missing outcomes
- Answer a timed set of mixed CS multiple-choice questions and write down why each wrong answer was wrong, not just the right letter
Recruiter Screen
reportedMuch of this call is the part candidates treat as small talk: start date, notice period, work authorisation, location and hybrid expectations, on-call, and compensation. Those are the constraints that end processes late, after several engineers have each spent time on you. Raising a hard constraint now costs you nothing, and a competing deadline mentioned early is something scheduling can sometimes work around. Use the call to confirm what the technical stages will cover, since the format varies by team and level.
What to demonstrate
- Whether your hard constraints (start date, notice period, authorisation, days on site, on-call) are compatible with the role before interviews are booked
- Whether you can give a compensation range with a basis behind it rather than deflecting until the offer stage
- Whether you can summarise your background in a way that maps onto the role's stack and the kind of systems you have built
How to prepare
- Write each constraint down in one line before the call and state them as facts rather than negotiating them live
- Prepare a short summary of your most relevant system: what it did, your part in it, and the stack, so the recruiter can place you
- Ask what the technical deep dives and final loop cover for this team, and whether design rounds expect class-level design, code, or architecture diagrams
Technical Deep Dives
reportedCandidates describe this stage only as a series of in-depth technical interviews across engineering topics, and no reported question is tied to it. Prepare two things in parallel: live problem solving across the reported coding categories, and a walk-through of one or two systems you built. Be ready to justify the architecture, database choice and testing approach of a past project, and to survive follow-up questions about every major choice. When solving live, read the input bounds first; they tell you which complexity class is admissible before you have thought about the algorithm.
What to demonstrate
- Whether you can justify a past architecture, database choice and testing approach with the constraint that drove it, rather than describing what the team happened to use
- Whether your approach to a coding problem is justified by the stated input size and properties (sorted, duplicates, bounded values) instead of by the first pattern you recognised
- Whether you reach a working solution first and then improve it, explaining the trade-off at each step
- Whether you can name the bottleneck in your own solution and what would remove it
How to prepare
- Pick one or two systems you built and write, for each: why that database, what you would change now, how it was tested, and the failure it handled worst. Rehearse answering 'why not the alternative?' for each
- Work the reported coding categories: stack problems (bracket matching, postfix evaluation), search in a rotated sorted array, bottom view of a binary tree, an efficient prime check, and an LRU cache with O(1) get and put
- Before writing code, write one line naming your target complexity and the input bound that justifies it, then compare it with what you submitted
Comprehensive Interview Loop
reportedCandidates report the final loop as a series of interviews covering system design, coding, operational excellence and behavioral questions. Two parts need specific preparation. Design: do not stop at cloud boxes. The reported design prompts ask for class structures, design patterns and component interactions (a rate limiter, a chess game, a modular payment system) alongside large-scale topics such as a URL shortener, a real-time chat application and an OTT recommendation engine. Operational excellence: this guide's research describes it as maintaining and improving code in a realistic setting, including debugging and refactoring a provided codebase, planning unit, integration and end-to-end tests, and understanding deployment pipelines and monitoring.
What to demonstrate
- Whether a design answer moves between levels: requirements and scale, then components, then the classes and interfaces inside the critical component
- Whether you can find a bug or bottleneck in unfamiliar code and refactor it without changing behaviour, with tests that prove it
- Whether caching, data-store and consistency choices come with a reason and a failure story, for example a cache during a sudden live-event spike
- Whether behavioral stories show a decision you owned, including what went wrong and what you changed afterwards
How to prepare
- For the rate limiter and the chess game, write the actual interfaces and classes (names, fields, key methods) and explain which pattern each uses and why, then connect them to the data flow
- Take a messy file from an old project, write characterisation tests first, then refactor it and explain each change aloud as you would to an interviewer
- For the URL shortener and chat application, prepare the read path, the write path, the storage choice and the cache invalidation story separately
- Prepare an outage story end to end: detection, diagnosis, the fix, communication, and the change that stopped it recurring
PracHub editorial advice for the preparation topics above.
Treating the pre-recorded video questions in the online assessment as a formality
Candidates report 5 recorded behavioral questions alongside the multiple-choice section; the reports do not say which prompts are used. Prepare them like live answers: as practice, build stories from the reported behavioral prompts (an outage, a shortcoming, a design disagreement, ambiguous requirements), outline situation, decision and outcome for each in a few lines, and record a practice answer so you hear the filler and the missing ending before it counts.
Walking into the assessment's multiple-choice section without refreshing OS, OOP and schema basics
The reported quiz covers data structures, OOP, operating-system fundamentals and database schemas, which working engineers rarely revisit. Spend a session on the facts that are easy to half-remember: complexity of heap and hash operations, processes versus threads, deadlock conditions, virtual memory, inheritance versus composition, and normalisation. Read every option before answering, since a near-miss distractor costs as much as not knowing the answer.
Answering an object-oriented design prompt with only cloud boxes and arrows
Reported prompts ask for a rate limiter with class structures and component interactions, a chess game with design patterns and game-state management, and a payment system built on OOP concepts. After agreeing scope, name the interfaces and classes for the core component, show one method signature that carries the key logic (for example tryAcquire on a limiter, or validateMove on a board), and say which pattern you used and what it lets you extend without editing existing code.
Describing a past project's stack without being able to say why each choice was made
For each project you plan to mention, prepare the reason behind the architecture and the database, the alternative you rejected and why, how the system was tested, and what you would change now. 'The team already used it' is acceptable only if you can say what it cost.
Chasing the optimal solution silently and ending with nothing that runs
Get a working brute-force solution first and optimise it iteratively while talking. State the naive approach and its complexity, code it if the optimal one is not yet clear, then improve it step by step. If a problem looks far harder than expected, ask clarifying questions and state partial ideas rather than going quiet.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Solve classical stack-based problems, such as matching nested brackets…
Solve classical stack-based problems, such as matching nested brackets or evaluating postfix expressions.
Approach
- Name the brute-force solution and its complexity before improving on it.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- Which test case would catch an off-by-one here?
- How does this change if the input no longer fits in memory?
Implement an LRU Cache using a doubly-linked list and a hashmap, expla…
Implement an LRU Cache using a doubly-linked list and a hashmap, explaining the time complexity of your get and put operations.
Approach
- Name the brute-force solution and its complexity before improving on it.
- State the target complexity and say which constraint rules the naive version out.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Choose ladder rungs against a measured bandwidth distribution
You have 60 candidate encoding rungs sorted ascending by bitrate, and an audience bandwidth histogram of 1,000 buckets measured from delivered throughput. A viewer plays the highest rung whose bitrate is at most 80% of their sustained throughput, and cannot play at all if no rung qualifies. Choose exactly 12 rungs, always including the lowest candidate, maximising total delivered bitrate across the audience. Return the chosen rungs and the objective value, state the complexity, and say why a log-spaced ladder is not automatically the answer.
Approach
- Precompute for each candidate i the bucket at which viewers can first afford it, threshold_i = bitrate_i / 0.8, by binary search over the bucket edges: O(n log m). Build a prefix sum over bucket counts so any viewer-count range is O(1).
- Formulate the contribution: with the selected set sorted, if rung i is selected and j is the next selected rung, every viewer whose threshold falls in [threshold_i, threshold_j) plays rung i, contributing count * bitrate_i. Call it value(i, j), computable in O(1) from the prefix sums.
- Run the DP over (last selected rung, rungs used): f[j][t] = max over i < j of f[i][t-1] + value(i, j), with the lowest rung forced selected and a sentinel j = n+1 closing the final interval. O(n^2 k) = 60^2 * 12, about 43,000 transitions. The point is that the ladder is measured, not that the algorithm is clever.
- Say when the structure buys more: if value satisfies the concave quadrangle inequality, the inner maximisation admits divide-and-conquer optimisation at O(n k log n). That condition depends on the histogram's shape and must be tested on the real distribution rather than assumed.
- Name what the objective leaves out, because the interview point is the modelling: storage and cache footprint scale with rung count, device decode limits make some rungs unusable by whole client classes, and delivered bitrate is a crude proxy for perceived quality. Log spacing is a prior about a smooth unimodal distribution, and measured throughput is usually bimodal, which is exactly where the prior loses.
Worked solution 40 min
- Write threshold_i and the prefix-sum lookup, and confirm the 80% headroom appears in exactly one place.
- Derive value(i, j) and check it by hand on a three-rung example against a two-bucket histogram.
- Write the DP recurrence with the forced lowest rung and the closing sentinel, and count the transitions at n = 60, k = 12.
- Compare the DP's chosen rungs against a log-spaced ladder on a deliberately bimodal histogram and quantify the difference.
- List the constraints the objective omits and say where each would enter the formulation.
Follow-up
- Add a per-device decode cap so one client class cannot use rungs above 1080p. Does the DP still decompose, and along which dimension?
- Throughput varies during playback and the player switches rungs. What does that do to the highest-affordable-rung model, and what would you measure instead?
- Storage and cache footprint become a hard budget rather than a fixed rung count. Which dimension of the DP state changes?
Stop two devices winning the last concurrent stream slot
playback_session(id UUID PK, account_id, status ENUM('starting','active','ended'), last_heartbeat_at, started_at) and account_plan(account_id PK, max_concurrent_streams INT). Session start currently runs SELECT count(*) FROM playback_session WHERE account_id = :a AND status = 'active', compares the result with the plan limit, then inserts. A household on a two-stream plan regularly ends up with three. Name the anomaly, say which PostgreSQL isolation levels do and do not prevent it, then give a schema and a statement that hold the limit, plus the lease TTL and heartbeat interval you would set and why.
Approach
- Name it precisely: write skew over a phantom. Both transactions evaluate the same predicate, both see one active session, and each inserts a row the other's read would have matched. Neither writes a row the other wrote, so there is no write-write conflict for the database to block on and no constraint to violate.
- Give the isolation answer without hand-waving. READ COMMITTED does not prevent it. REPEATABLE READ in PostgreSQL is snapshot isolation and does not prevent it either — snapshot isolation stops lost updates on the same row, not write skew across a predicate. SERIALIZABLE does, via SSI predicate locks: one transaction aborts with SQLSTATE 40001 and the caller retries. Price that: a retry loop sits directly in front of the first frame, and SSI's conflict tracking runs on a path taking 10^3 to 10^4 starts per second.
- Prefer materialising the conflict to raising the isolation level. Pre-create the plan's slots as rows:
account_stream_slot(account_id, slot_no, session_id NULL, expires_at NULL, PRIMARY KEY (account_id, slot_no)). A phantom problem becomes a row-lock problem, which every isolation level already handles correctly and cheaply. - Acquire in exactly one statement:
UPDATE account_stream_slot SET session_id = :sid, expires_at = now() + interval '90 seconds' WHERE (account_id, slot_no) = (SELECT account_id, slot_no FROM account_stream_slot WHERE account_id = :a AND (session_id IS NULL OR expires_at <= now()) ORDER BY slot_no LIMIT 1 FOR UPDATE SKIP LOCKED) RETURNING slot_no. Zero rows updated means the account is at its limit — a product outcome to return to the viewer, not an exception. SKIP LOCKED makes two simultaneous starts take different slots instead of one queueing behind the other. - Reclaim by predicate rather than by a sweeper.
expires_at <= now()inside the acquire means a crashed client's slot is reusable the instant it expires, with no background job anywhere in the correctness path. Renew withUPDATE ... WHERE account_id = :a AND slot_no = :n AND session_id = :sid: thesession_idequality is what stops a late heartbeat, from a client whose slot already expired and was reassigned, from stealing it back. - Defend the numbers in both directions. At a 10-second heartbeat and a 90-second TTL a client must miss eight consecutive heartbeats before eviction, and a crashed client strands a paid slot for up to 90 seconds. Do not compute the eviction rate as a per-heartbeat loss probability raised to the eighth power — losses are correlated, a mobile handover drops a burst — so size the TTL against the measured distribution of short outages, not against an independence assumption that does not hold.
Follow-up
- The lease store is Redis and the session table is PostgreSQL. What happens when the Redis acquire succeeds and the session insert then fails?
- A viewer moves from phone to television mid-title. Should the phone's slot be released explicitly, and what failure modes does that add?
- Two starts arrive for the same device and the same title four milliseconds apart. Should they consume one slot or two, and what key decides?
Put segment duration where alignment cannot drift
content_version(id, title_id, duration_ms, encoder_build_id, packaging_status) and rendition(id, content_version_id, stream_kind ENUM('video','audio','subtitle'), width, height, frame_rate_milli_fps, segment_duration_ms, gop_size_frames, status). Every video rendition of a content version must have identical segment boundaries, and each segment must begin at an IDR frame, so gop_size_frames has to divide the segment length in frames. Both facts currently live per rendition and nothing stops a re-encoded rung from disagreeing. Restructure so the database rejects drift, and say what breaks at a frame rate of 24000/1001 with a 2,000 ms segment.
Approach
- Identify the functional dependency. For video rows,
segment_duration_msis determined bycontent_version_id, not byrendition_id. A dependency stored at the wrong grain is exactly what lets two rows disagree, and the invariant is presently a sentence in a comment rather than anything the database can refuse. - Move the authoritative value to the parent as
content_version.segment_frames. Ask whether the child copy earns its keep: the manifest build already loads the content_version row to resolve the URL, so the join costs nothing and the denormalised copy buys no read. If it is kept anyway for write-path convenience, guard it with a composite foreign key —UNIQUE (id, segment_duration_ms)on the parent andFOREIGN KEY (content_version_id, segment_duration_ms) REFERENCES content_version(id, segment_duration_ms)on the child. Under the default MATCH SIMPLE semantics a NULL in either child column satisfies the constraint, which is the escape hatch that lets audio and subtitle rows carry no video segment length. - Fix the representation before writing any CHECK. 24000/1001 is 23.976023976… and is not representable in integer thousandths, so
frame_rate_milli_fps = 23976is already a different number from the real rate and every derived value drifts from it. Store the exact rational asframe_rate_num INTEGER, frame_rate_den INTEGER— 24000 and 1001 — and store the segment length in frames rather than milliseconds. - With frames and an exact rational, both invariants become integer CHECKs that cannot round:
CHECK (segment_frames % gop_size_frames = 0)for IDR alignment, and the millisecond duration becomes derived —segment_frames * 1000 * den / num— rather than a second stored copy to keep in sync. - Work the stated case: at 24000/1001, 2,000 ms is 48000/1001 frames, about 47.952, so no segment of that target length contains a whole number of frames and no integer GOP size divides it. 96 frames is exactly 4.004 s and admits any GOP size dividing 96. The encoder has to round a millisecond target to whole frames, and that rounding is where two rungs encoded at different times end up on different boundaries.
- Accept what the schema still cannot catch. Rate control can relocate an IDR without changing any stored column, so add a post-packaging QC step that compares segment counts and first-sample timestamps across the video renditions of a version and fails the publish on a mismatch, and pin
encoder_build_idper rendition so a rung re-encoded on a newer build is a visible difference rather than an inference.
Worked solution 30 min
- Work the frame arithmetic for 25, 30000/1001 and 24000/1001 at 2,000 ms and at 4,004 ms, marking which combinations yield a whole number of frames.
- Draft both schemas — milliseconds on the child with a composite FK, frames on the parent — and write the CHECK constraints each one admits.
- Insert two video renditions of one content version with different segment lengths and confirm the second is rejected.
- Insert an audio rendition with a null video segment length and confirm it is accepted.
- Write the post-packaging QC query that compares segment counts across the video renditions of one version and returns the offending rendition ids.
Follow-up
- One rung fails QC and is re-encoded alone. What do you verify before republishing the manifest, and what is the rollback if boundaries moved?
- Audio renditions legitimately use a different segment length from video. Which of your constraints still applies and which has to be weakened?
- How do you migrate the existing millisecond column to frames without a window in which neither constraint holds?
Design a global, real-time chat application, detailing how you would h…
Design a global, real-time chat application, detailing how you would handle concurrent connections, data storage, and message delivery.
Approach
- Choose a partition key and say what query it makes expensive.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
Follow-up
- How does this behave when that dependency is down for an hour?
- What breaks first when traffic grows ten times?
Design a high-throughput Rate Limiter including class structures, inte…
Design a high-throughput Rate Limiter including class structures, internal component interactions, and end-to-end data flow.
Approach
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
- Fix the scope first: who calls this, how often, and what they do when it fails.
Follow-up
- What would you drop to keep the system up under load?
- How does this behave when that dependency is down for an hour?
Design a multiplayer online chess game, focusing on object-oriented de…
Design a multiplayer online chess game, focusing on object-oriented design patterns, game state management, and API design.
Approach
- State the consistency you need, and where you are willing to be stale.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
Follow-up
- How does this behave when that dependency is down for an hour?
- What would you drop to keep the system up under load?
Explain the core concepts of object-oriented programming (OOPS) and ho…
Explain the core concepts of object-oriented programming (OOPS) and how you would apply them to design a modular payment processing system.
Approach
- Work from the requirement backwards to the design.
- Say what you would check first and why it is the highest-information step.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Give playback start a failure contract the player can act on
A television app calls POST /playback/sessions to start a title and today receives HTTP 403 with a free-text message for every refusal. The refusals are not alike: the account has no entitlement, no active availability_window covers this content_version in the caller's territory, the plan's concurrent-stream limit is already met, the device supports only software-level DRM for a version that requires hardware, and the backend is shedding load. Define the response body, the status code carrying each class, and the exact action the player takes for each.
Approach
- Partition by what the player does, not by where the refusal came from. Five behaviours fall out: terminal-and-explain (no rights in this territory), terminal-and-upsell (no entitlement), recoverable-by-user-action (out of streams, and the user can stop one), recoverable-by-a-different-request (the device cannot decrypt this packaging, but can play another), and retry-later (shed). If two classes produce the same player behaviour, you have over-split and the client cannot use the distinction anyway.
- Map classes onto codes the SDK's generic HTTP layer already handles: 401 for a missing or expired credential, which the player refreshes and retries once; 403 with distinct stable codes for entitlement versus territory; 409 for the concurrency limit, because the conflict is with existing state the user can change; 422 when the requested content_version cannot satisfy the capabilities the client declared; 503 with Retry-After for shed. Never merge 401 and 403 — they have opposite retry semantics, and merging them produces a client that either loops on an unfixable refusal or drops a fixable one.
- Shape the body as RFC 9457 problem details with a stable machine-readable code as the switch value, plus class-specific data. The concurrency refusal must carry the active sessions (device label, title, started_at); 'you are out of streams' with no list is an unactionable dead end whose only exit is a support ticket. 451 is worth raising for the territory case and worth rejecting: it is defined for legal demands to block a resource, not for a licence that has not been bought, and a stable code under 403 says the same thing without misusing a status.
- State what a refusal must not contain. The territory refusal should not enumerate the territories and dates where the title is available, and the entitlement refusal should not vary its prose by account state, or the endpoint becomes an oracle for someone probing it. Keep the discriminating detail in the code the client switches on, not in text the client renders verbatim.
- Define the default branch: an unrecognised code is terminal, shows a generic error, and does not retry. That single rule is what makes adding a sixth code next quarter a non-breaking change for every client already in the field.
Worked solution 20 min
- List the five refusal classes in a column and write beside each the exact UI the player shows and whether it retries, before assigning any status code.
- Assign a status and a stable code per class, then re-read the retry column: only the shed class may retry without user action.
- Write the concurrency refusal body in full, including the active-session list, and check a user could pick a stream to stop from it alone.
- Write the player's switch and confirm the default branch is terminal rather than a retry.
Follow-up
- The session starts, then the subscription lapses ten minutes in. Which code does the client see, from which endpoint, and at what moment?
- Two devices in one household hit the limit at the same instant. What does each receive, and does the answer depend on where the limit is enforced?
Origin egress quadruples while viewer demand stays flat
Overnight, origin egress for segments rose about fourfold while edge-delivered bytes, concurrent sessions and peak bitrate stayed flat. Segment hit ratio at the edge fell from 95% to 81%; manifest hit ratio is unchanged and every POP is affected equally. No playback alarm fired, so the first signal was a cost alert. The previous evening's release added a signed delivery token to segment URLs. Produce an ordered diagnostic checklist, name the change that explains the numbers, and show the arithmetic linking hit ratio to origin load.
Approach
- Establish that demand did not change before touching any cache config: compare edge bytes delivered, concurrent sessions and requests per second week over week. Origin volume is (1 - h) x edge volume, so h moving 0.95 to 0.81 takes the origin share from 0.05 to 0.19, a 3.8x rise. The observed numbers are already self-consistent, which rules out a traffic story.
- Slice hit ratio by path prefix, content type and POP. Segments down, manifests flat, all POPs equally affected points at a rule change applied to the segment path, not a regional failure, a purge storm or an eviction problem.
- Read the cache key the edge actually computes for a sampled segment request rather than the configuration you believe is deployed: which query arguments, headers and cookies are included. Diff it against the previous release.
- Count distinct cache keys per segment URL over one hour. A ratio near one key per viewer is proof the token is in the key; a ratio near one is proof it is not, and sends you to storage suppression instead.
- If the key is clean, check origin responses on segments for Set-Cookie and for a Vary on a per-request header, either of which stops a shared cache storing the object independently of the key.
- Fix by keeping the token in the URL for the edge to verify and excluding it from the key. Verification must be signature-only at the edge (HMAC or public-key over path plus expiry) so it needs no origin callback. State the trade-off out loud: one cached object now serves every holder of a valid token, so token lifetime and path scope become the only limits on URL sharing.
Follow-up
- How do you rotate the token signing key without breaking sessions already in flight?
- What token lifetime do you choose, given a segment stays cached for hours and a single playback can run three hours?
- Why would a staging test with twenty clients never surface this, and what test would?
For someone fluent in a dynamic language who has shipped real work but has never had to say what the runtime is doing underneath. The week is built on measuring and deliberately breaking things, because the questions that expose this background are the ones where the interviewer asks why a second time.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Online assessment: fundamentals quiz and recorded answers
- Build a one-page review sheet for the reported quiz topics: data-structure operation costs, OOP pillars with one example each, processes versus threads, deadlock conditions, paging, and normal forms
- Answer a mixed set of CS multiple-choice questions under a timer and write why each wrong option is wrong
- Record answers to two reported behavioral prompts (a production outage you diagnosed, and your biggest professional shortcoming) and review the playback for structure
Deliverable: A fundamentals review sheet plus two recorded behavioral answers you have watched back and tightened.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Coding: stacks, binary search and trees
- Solve bracket matching and postfix evaluation with a stack, and list the edge cases (empty input, unmatched closer, too few operands)
- Solve search in a rotated sorted array in O(log n) and test it on arrays rotated by 0, 1 and n-1 positions, with and without the target present
- Solve the bottom view of a binary tree with a level-order traversal keyed by horizontal distance, and write an efficient prime check, stating each complexity
- For every problem, write a small harness with the example cases plus an empty and a single-element case before submitting
Deliverable: Five working solutions, each with its complexity stated and a test harness covering edge cases.
Practice prompt ↗Practice prompt ↗03Coding: LRU cache and the ladder-selection drill
- Implement an LRU cache with a hashmap and a doubly-linked list, and explain why get and put are O(1)
- Write boundary tests: fill to capacity and assert nothing is evicted, insert one more and assert the least recently used key is gone, then read an old key first and check the victim changes
- Work the ladder-selection coding exercise (choose 12 encoding rungs against a bandwidth histogram) and check its DP against the listed checks
- Practise one sliding-window problem that counts overlapping pattern occurrences in linear time
Deliverable: A tested LRU cache and a completed ladder-selection exercise with its complexity justified.
Practice prompt ↗Practice prompt ↗04Object-oriented design: rate limiter, chess and payments
- Design a rate limiter at class level: a limiter interface, token-bucket and sliding-window implementations, a key resolver, and the data flow from request to decision; then say how it changes when it runs across many servers
- Design a multiplayer chess game: board, piece hierarchy, move validation, game state and the API for making a move, naming the patterns you use
- Explain the four OOP concepts through a modular payment processing system where a new payment method is added without editing existing classes
Deliverable: Three class sketches with interfaces and key method signatures, each with a one-line justification of the pattern used.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Data modelling, SQL and data-store trade-offs
- Design a relational schema for video comments queried by user: tables, keys, the index that serves the user query, and how pagination works
- Argue SQL versus NoSQL for session data against billing data, naming the consistency and durability each needs
- Explain how a Redis cache in front of the database behaves during a sudden live sports traffic spike: what is cached, how entries expire, and what happens when a popular key expires under load
- Work the concurrent-stream SQL drill, then the segment-alignment worked exercise, checking your segment-alignment schema against that exercise's listed checks
Deliverable: A comments schema with indexes, a written session-versus-billing store comparison, and both SQL drills completed.
Practice prompt ↗Practice prompt ↗06System design at scale and operational excellence
- Design a URL shortener: ID generation, storage choice, read-heavy caching and the write path
- Design a real-time chat application: connection handling, message storage, delivery guarantees and what happens when a node dies
- Sketch an OTT recommendation service with a low-latency serving path and an offline pipeline behind it
- Work the CDN origin-egress debugging drill as an ordered checklist, then the playback-start error-contract design exercise
Deliverable: Three design outlines with read and write paths separated, plus a debugging checklist and a completed error-contract table.
Practice prompt ↗Practice prompt ↗07Behavioral stories, recruiter prep and a mock loop
- Write stories for the reported prompts: a design disagreement settled with evidence, ambiguous requirements you structured, a stakeholder challenging an architectural decision, and end-of-sprint task requests you had to prioritise
- For one past project, write why you chose its database, what you rejected, how it was tested and what you would change now, then have someone question each choice
- Write your recruiter-screen constraints and compensation range in one line each
- Run a mock loop: one coding problem from day 2 or 3, one design prompt from day 4 or 6, and two behavioral answers, with a partner asking follow-ups
Deliverable: A set of written behavioral stories, a defended project walk-through, and notes from one full mock loop.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The reported behavioral prompts centre on outages, a personal shortcoming, design disagreements and ambiguous requirements. Separately, the online assessment is reported to include 5 pre-recorded behavioral questions. Prepare each story as a decision you made: the situation in two sentences, the options you had, what you chose and why, and what you measured or changed afterwards. A story where you carried out someone else's plan is weaker than a smaller one where the call was yours.
Describe a situation where you had to work with ambiguous requirements…
Describe a situation where you had to work with ambiguous requirements. How did you structure your approach to deliver a successful outcome?
Approach
- Close with what you would do differently, concretely.
- Pick a story where you made the decision, not one where you watched it.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
How do you handle disagreements with team members or managers regardin…
How do you handle disagreements with team members or managers regarding technical design decisions?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Estimate a catalogue re-packaging pass you have never run
A device class you still support accepts only one of the two common-encryption schemes, so part of the catalogue needs a second encrypted copy: roughly 200,000 content versions, each with 6-12 video renditions plus audio and subtitles. Nobody here has run a pass at this scale. You are asked for a date and a cost. Describe estimating work you had never done: how you decomposed it, what you measured before committing, the number you gave and the uncertainty attached to it, and how far off you turned out to be.
Approach
- The probe is whether you find the dominant unknown before producing a number. Here one fork is worth more than every other term: if the encoded elementary streams or the unencrypted packaged output were retained, this is a re-packaging pass - I/O-bound and cheap. If only encrypted output survived, it is a re-encode - CPU-bound at hours of machine time per hour of source. Settle it by querying what storage actually holds, not by asking what the pipeline is meant to retain.
- Decompose into units you can measure on a sample instead of terms you can argue about: assets in scope, renditions per asset, bytes per asset, machine-seconds per asset, publish and verification time per asset, and the steady-state storage and cache delta afterwards.
- Buy the information cheaply before committing. Run 50 assets end to end sampled across the size distribution rather than 50 short ones, recording wall clock, cost and failure rate. One day of calibration converts three of six terms from guesses into measurements, and that conversion is the whole technique.
- Give a range with its dominant term named and say what collapses it: six to ten weeks if this is a re-encode, about two if the elementary streams are retained, and you will know which within two days. A single date with no uncertainty is a worse answer than a range you can defend.
- Include the terms people forget because they land after the run: roughly double the storage for the affected catalogue, a second set of objects competing for the same cache footprint in every POP, and the manifest and key-mapping change that points each client at the right copy. The run finishing is not the project finishing.
- Say how far off you were, in which direction, and which term caused it. An estimate that missed on a term you never decomposed teaches more in the retelling than one that happened to land.
Follow-up
- Two days in, throughput is half your sample rate. What do you tell the person holding the date?
- Which titles go first, and on what basis?
- What happens to edge hit ratio for the affected catalogue once two encrypted copies are live?
- 01
Describe a time when you encountered a major technical challenge or outage. How did you diagnose the root cause and resolve it?
- 02
What is your biggest professional shortcoming, and what active steps have you taken to address and overcome it?
- 03
How do you handle disagreements with team members or managers regarding technical design decisions?
- 04
Describe a situation where you had to work with ambiguous requirements. How did you structure your approach to deliver a successful outcome?
- 05
Tell me about a time a stakeholder challenged one of your architectural decisions. How did you respond, and what was the outcome?
- 06
New task requests arrive at the end of a sprint. How do you decide what to take on, and how do you communicate it?
Is this an official Warner Bros. Discovery interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Warner Bros. Discovery. Rounds and questions reflect what candidates have reported, not a process Warner Bros. Discovery has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What is in the Warner Bros. Discovery online assessment?
Candidates report a HireVue session with around 20 multiple-choice questions covering data structures and algorithms, OOP and operating-system fundamentals, plus 5 pre-recorded video behavioral questions. Database schemas are also reported among the quiz topics. Refresh CS fundamentals beforehand and rehearse your behavioral stories on camera.
PracHub Software Engineer practice ↗What kind of coding questions should I expect?
Reported coding questions are classic data-structure problems: an LRU cache built from a hashmap and a doubly-linked list, search in a rotated sorted array, the bottom view of a binary tree, an efficient prime check, and stack problems such as bracket matching or postfix evaluation. Practise getting a working solution first, then improving it while explaining the complexity.
PracHub Software Engineer practice ↗Do the design questions expect architecture diagrams or class design?
Both. Reported prompts include large-scale systems (a URL shortener, a real-time chat application, an OTT recommendation engine) and prompts that ask for class structures and patterns (a rate limiter, a multiplayer chess game, a modular payment system). Do not stop at cloud boxes: be ready to name interfaces, classes and how components interact.
PracHub Software Engineer practice ↗What does operational excellence mean in the final loop?
This guide's research describes it as maintaining and improving code in a realistic setting: finding bugs or performance problems in a provided codebase and refactoring it, planning unit, integration and end-to-end tests, and understanding deployment pipelines and monitoring. Practise by refactoring an old file of your own behind characterisation tests and explaining each change aloud.
PracHub Software Engineer practice ↗How should I split my preparation time?
Cover all four reported stages rather than only coding. The 7-day plan in this guide runs in this order: CS fundamentals and recorded behavioral answers for the online assessment, the reported coding categories, object-oriented design with class-level detail, schema and data-store trade-offs, system design at scale and operational excellence, and finally behavioral stories with a defended walk-through of one past project.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
Candidates report roughly 3-5 weeks across four stages. Some report scheduling delays or gaps in communication. If you have not heard back within a week of an interview, send a short, polite follow-up to your recruiter.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.
Advice Media Software Engineer Interview Questions & Guide 2026
Design practice for Advice Media software engineer prep that pushes past topology: turn a loose requirement into a schema and an API contract, then work out the read and write paths it implies.
Zscaler Software Engineer Interview Guide
Concurrency exercises for Zscaler candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Verkada Software Engineer Interview Guide
Prepare for the software engineer interview at Verkada with original coding, system design and debugging exercises, each paired with a worked solution and the reasoning behind it.