CrackOps
Interview PrepTracksLinuxAWS LabSoonInterview RoomSoon
Sign inStart free
CrackOps

Interview prep for the people who keep production up.

[email protected]
ProductInterview PrepTracksDashboardInterview Room
RolesDevOpsSREPlatformCloud
CompanyAboutContactPrivacyTerms
© CrackOps
Tracks/SRE & Observability
Advanced 3 minScenario based

How would you run chaos experiments on a live streaming pipeline without viewers ever noticing?

Scenario

A live-sports streaming platform's pipeline runs from venue ingest through encoders, packagers and origin to a CDN, with playback APIs on Kubernetes backed by Redis and telemetry flowing through Kafka. Last season a single packager pod crash froze manifests for 40 seconds during a semi-final, and nobody had ever tested that failure. The tournament starts in six weeks.

The interviewer asks

“Leadership wants confidence in the streaming pipeline before the tournament, but says no viewer may notice an experiment. How would you design and run chaos experiments safely? Walk me through one experiment in detail.”

The 30-second answer

I treat chaos as hypothesis testing with a seatbelt. Each experiment states a viewer-facing steady state — stall ratio, manifest age, start time — and a falsifiable prediction, then climbs a ladder: staging with a looped real feed and synthetic viewers, then production on a test channel or cell that only synthetic viewers watch, using header-scoped faults so real requests are untouched, and only then small real-traffic experiments and game days. Abort conditions are written before the run and wired to automation that removes the fault in seconds. I never run on match days, during incidents, or with a low error budget, and every finding becomes a fix plus a regression experiment.

Sign in to finish this question

A free account unlocks the rest of it, and saves your progress across every track.

  • The voiced mock interview (3 min)
  • The full senior answer, step by step
  • Animated architecture diagrams
  • The whole conversation, 12 turns
  • Deep dive: how it works, mistakes, risks and trade-offs
  • 3 copy-ready command snippets
  • 5 follow-up questions they'll ask next
  • A self-check of 8 things interviewers listen for
Create a free accountSign in

More SRE & Observability interview questions

  • Order latency spikes every trading day at 09:15. How do you find the cause and prove it?
  • How would you monitor HPA scaling decisions in real time and catch metrics-server or adapter lag before it hurts?
  • Build a capacity plan for festival peaks you can predict and flash spikes you can't. Show me the math.
  • How would you roll out ownership, SLOs and error budgets across thousands of microservices?
All SRE & Observability questions

Linux commands for this track

  • sar Collect and replay system activity history
  • mpstat Per-CPU utilisation: find the hot core
  • pidstat Per-process CPU, memory, disk and context switches over time
  • sysctl Read and tune kernel parameters at runtime
  • ulimit Show and set per-process resource limits
  • numactl Control NUMA CPU and memory placement
  • strace Trace the system calls a process makes
  • ltrace Trace the library calls a program makes