Model the asset lifecycle explicitly. Upload acceptance, asset creation, processing, ready playback and failure are different states. Give the upload, asset, playback identity and webhook event separate names.
Mux’s video documentation describes APIs for on-demand and live video. Its webhook guide says events are asynchronous and duplicates can occur, so consumers should treat delivery idempotently. Those are product facts; the prompts below are PracHub exercises.
Acknowledge durable work quickly. A webhook handler should verify the signature, store the event identity and enqueue downstream work before the request deadline. Slow processing belongs behind a durable queue with bounded retries.
Measure quality at the right grain. Viewer startup failures, playback sessions and assets are different denominators. Aggregate each fact table before joining and state which sessions are eligible for a metric.
Explore your preparation priorities
Choose a focus to see how to prepare.
Define what saved means
Contract: identify the durable state and the evidence that confirms it.
YOUR PREPARATION- Name the logical operation and the state visible before confirmation.
- List the invariants a retry must preserve.
PracHub practice map for an asset state or webhook delivery. Select a checkpoint to connect the system contract, concurrency boundary and failure response to a practice prompt.
Define video identities
editorialSeparate upload, asset, playback and webhook event IDs. Keep environment scope in every lookup.
What to demonstrate
- API modeling
- Tenant boundaries
How to prepare
- Merge playback intervals.
- Create colliding IDs in two environments.
Make webhooks replay-safe
editorialVerify signatures, deduplicate complete event identities and acknowledge only after durable acceptance.
What to demonstrate
- Security
- Idempotency
- Queues
How to prepare
- Deliver ready twice.
- Lose the handler response after commit.
Explain the quality readout
editorialDefine eligible playback sessions, error numerator and time window before optimizing a dashboard query.
What to demonstrate
- Measurement
- SQL correctness
How to prepare
- Run the quality fixture.
- Add sessions without errors and repeated dimensions.
PracHub editorial advice for the preparation topics above.
Follow the state, not just the happy path
Choose a scenario to trace what changes.
The expected version still matches the stored state.
- 01Edit version 3Edit version 3.
- 02Compare versionCompare version.
- 03Save version 4Save version 4.
Commit one new version and return durable confirmation.
Use the three save outcomes to reason about an asset state or webhook delivery: a confirmed write, a version conflict and a lost response.
Using one ID for upload, asset and playback
Name each lifecycle identity and keep environment scope in every key.
Acknowledging a webhook before durable acceptance
Verify and store the event identity before returning success; move slow work behind a queue.
Counting error events as failed playbacks
Deduplicate to the metric’s session grain and state the denominator.
Letting one endpoint monopolize retries
Use per-destination limits, backoff and a terminal review state.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Merge playback intervals
Given unsorted [start, end) integer intervals for one playback session, merge overlapping or touching intervals. Reject negative or reversed intervals.
Approach
- Sort by start then end.
- Append a new interval only when its start is greater than the current end; otherwise extend the end.
Worked solution 35 min
- Validate each half-open interval.
- Sort a copy by start and end.
- Merge when the next start is less than or equal to the current end; touching intervals form one continuous playback span.
def merge_intervals(intervals):
clean = []
for start, end in intervals:
if not isinstance(start, int) or not isinstance(end, int) or start < 0 or end < start:
raise ValueError("invalid interval")
clean.append((start, end))
out = []
for start, end in sorted(clean):
if not out or start > out[-1][1]:
out.append([start, end])
else:
out[-1][1] = max(out[-1][1], end)
return [tuple(item) for item in out]
Scroll sideways to view long lines.
Follow-up
- How would you retain a reason label without erasing distinct overlapping causes?
Apply webhook events once per environment
Given environment, event ID, type and object identity records, preserve first-seen order. Ignore exact replays and reject reuse of an event ID with different content.
Approach
- Key by environment and event ID and retain a fingerprint of accepted content.
- Validate the type and referenced object before projecting a state change.
Follow-up
- How long can you safely retain event identities?
Count recent stream failures
Implement add(timestamp) and count(now) for failures in (now - 10, now]. Timestamps are nondecreasing, equal timestamps are distinct events and the clock may advance without a new event.
Which events still count?
The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.
See the event values
- At 0s: +1 — expired
- At 5s: +1 — in window
- At 10s: +1 — in window
- At 14s: +1 — not arrived
- At 19s: +1 — not arrived
Synthetic stream failures at 0, 5, 10, 14 and 19 seconds. Drag the clock: the interval is (now - 10, now], so the lower boundary is excluded.
Approach
- Use a deque and remove values at or before now - 10.
- Reject a backward clock. Each event enters and leaves once.
Follow-up
- How would you split the count by environment and stream?
Find the latest asset status
Given asset_events(environment, asset_id, event_id, occurred_at, status), return the latest state per asset in environment e. Break timestamp ties by event ID.
Approach
- Filter environment before ranking and partition by environment and asset.
- Select row one before filtering ready or errored states.
Worked solution 35 min
- Filter to one environment.
- Partition by environment and asset; order by event time and event ID descending.
- Keep row one before filtering by status.
CREATE TABLE asset_events (environment TEXT, asset_id TEXT, event_id INTEGER, occurred_at INTEGER, status TEXT);
INSERT INTO asset_events VALUES
('e','a1',1,10,'processing'),('e','a1',2,20,'ready'),
('e','a2',3,20,'errored'),('other','a1',99,99,'errored');
WITH ranked AS (
SELECT *,ROW_NUMBER() OVER (
PARTITION BY environment,asset_id ORDER BY occurred_at DESC,event_id DESC
) rn FROM asset_events WHERE environment='e'
)
SELECT asset_id,status FROM ranked WHERE rn=1 ORDER BY asset_id;
Scroll sideways to view long lines.
Follow-up
- How should late arrival differ from event occurrence time?
Calculate playback failure rate without join inflation
Return failed_playbacks / eligible_playbacks per asset. Playback sessions and error events are separate one-to-many tables; retain assets with zero errors.
Approach
- Aggregate eligible sessions and failed session identities separately before joining.
- Join on environment and asset, and guard a zero denominator.
Follow-up
- How would repeated error events within one failed session affect the metric?
Design an asynchronous asset-processing pipeline
Accept an upload, create an asset and run retryable processing stages. Workers can crash, a new attempt can replace an expired one and clients need an honest status.
Approach
- Freeze input identity and processing version before queueing.
- Use attempt IDs and ownership tokens. Commit stage results idempotently and publish state transitions through an outbox.
Worked solution 35 min
- Accept the upload and create stable upload/asset identities.
- Freeze input and processing version; create an attempt with a current ownership token.
- Write stage artifacts to attempt-specific paths and commit each state transition idempotently.
- Select a result only through an atomic token/version check; notify through a transactional outbox.
Follow-up
- How would you reprocess an asset under a new transformation version?
Design a reliable webhook delivery service
Deliver events to customer endpoints. Destinations can be slow, return errors or accept a request while the acknowledgement is lost. Keep environments isolated.
Approach
- Persist the logical event and one delivery row per endpoint before dispatch.
- Use stable event IDs, signed requests, bounded concurrency and retry attempts with backoff. Expose a terminal review state.
Follow-up
- How do you prevent one failing endpoint from consuming every worker?
Stop duplicate ready events from starting work twice
A duplicated asset-ready event starts two downstream exports. Reproduce the race and specify the durable boundary.
Approach
- Deliver the same event concurrently to two handlers and pause both after their lookup.
- Insert or claim the complete event identity atomically, then make downstream job creation part of the same transaction or outbox.
Worked solution 35 min
- Send the same event concurrently to two handlers.
- Pause both after a non-atomic existence check to reproduce duplicate job creation.
- Claim the environment/event identity through a unique insert in the transaction that creates the outbox job.
- Return success for a repeated identical event and conflict for reused identity with different content.
Follow-up
- What changes when two distinct events legitimately refer to the same asset?
A seven-session PracHub practice plan with one reviewable artifact per session. Adjust the pace to your experience and interview date.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map video identities
- Draw upload, asset, playback and event IDs.
- Add environment scope.
Deliverable: A lifecycle map
02Merge playback spans
- Run the interval solution.
- Test touching, nested and invalid intervals.
Deliverable: A tested utility
Practice prompt ↗03Query current state
- Run latest-asset SQL.
- Add late events and another environment.
Deliverable: A latest-state fixture
Practice prompt ↗04Receive webhooks safely
- Verify, store and acknowledge one event.
- Deliver it twice concurrently.
Deliverable: An idempotent handler contract
Practice prompt ↗05Design asset processing
- Trace a worker crash and replacement.
- Name the version and ownership guard.
Deliverable: A recovery-aware pipeline
Practice prompt ↗06Measure playback quality
- Define the eligible-session denominator.
- Prevent join inflation.
Deliverable: A metric definition
Practice prompt ↗07Rehearse product judgment
- Explain one API tradeoff.
- Tell one evidence-bounded incident story.
Deliverable: Two concise stories
Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Use real examples. Name your responsibility, the evidence available at the time and what changed after the decision.
Explain a quality improvement with the right denominator
Describe a real reliability or performance result and how you defined eligible users or requests.
Approach
- State the affected workflow, your responsibility and the measurement definition.
- Explain the decision, verification and limitation without overstating the result.
Follow-up
- What evidence would make you revise the conclusion?
Resolve an API contract disagreement
Describe a disagreement about compatibility, error behavior or rollout of a developer-facing API.
Approach
- State the affected workflow, your responsibility and the measurement definition.
- Explain the decision, verification and limitation without overstating the result.
Follow-up
- What evidence would make you revise the conclusion?
Communicate during a streaming incident
Tell a story where incomplete data made the customer impact uncertain.
Approach
- State the affected workflow, your responsibility and the measurement definition.
- Explain the decision, verification and limitation without overstating the result.
Follow-up
- What evidence would make you revise the conclusion?
- 01
Bring one result you improved and one decision you changed after seeing evidence.
Are these verified Mux interview questions?
No. They are PracHub editorial exercises informed by official Mux product and webhook documentation.
Mux — Video documentation ↗Mux — Listen for webhooks ↗Why does the guide emphasize duplicate webhooks?
Mux documentation explicitly tells consumers to handle duplicate delivery. The exact implementation exercises are PracHub teaching material.
Mux — Listen for webhooks ↗Is this Mux’s interview schedule?
No. It is a suggested seven-session practice sequence.
Sources & methodology 6 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01Mux — Video documentation ↗
Official product context for video assets, live streams and playback.
official · Accessed 2026-09-20 - 02Mux — Fundamentals ↗
Official identifiers, API and webhook context.
official · Accessed 2026-09-20 - 03Mux — Listen for webhooks ↗
Official delivery behavior, duplicate-delivery warning and testing guidance.
official · Accessed 2026-09-20 - 04Mux — Data overview ↗
Official playback quality and engagement analytics context.
official · Accessed 2026-09-20 - 05PostgreSQL — Window functions ↗
Technical reference for SQL reasoning. Runnable fixtures below use SQLite.
official · Accessed 2026-09-20 - 06PracHub — Software Engineer practice ↗
Cross-company practice; not evidence of company interview questions.
platform · Accessed 2026-09-20
Explore related engineering environments and compare the preparation focus.
SolarWinds Software Engineer Interview Questions & Guide 2026
Prepare for observability engineering by reasoning about telemetry identity, bounded ingestion, tenant scope and evidence-driven incident response.
Sezzle Software Engineer Interview Questions & Guide 2026
Prepare for payment engineering by making money arithmetic, operation identity, state transitions and reconciliation explicit.
Snowflake Software Engineer Interview Guide 2026
Snowflake provides a cloud SQL data platform for storage, analytics and data processing.
Qorvo Software Engineer Interview Questions & Guide 2026
Prepare for hardware-adjacent software by making units, deterministic inputs, simulation provenance and stale-worker protection explicit.