TL;DR: Start with a written hypothesis, not a failure. Inject the smallest thing whose behaviour you claim to know, in one non-critical service, during business hours, with an abort condition defined before you start. If you cannot state what you expect to happen, you are not running an experiment, you are running an outage.
How to approach it
Lead with the hypothesis and the abort condition, because that is what separates chaos engineering from breaking things. Then give a staged progression with a gate between stages. Naming a tool is worth almost nothing here.
A strong answer
The unit of work is an experiment, and it has four parts: a steady state you can measure, a hypothesis about what happens when you inject a fault, the smallest injection that tests it, and an abort condition. "We believe that killing one of six checkout pods will not move p99 latency by more than ten percent, and we will stop if the error rate exceeds one percent." That sentence is the discipline. Without the hypothesis you learn nothing when it survives, and without the abort condition you have no plan for the case you were testing for.
Stage one is a single pod termination in a non-critical service, in business hours, with the owning team watching. Business hours is deliberate and it is the part people get wrong: the point is to have your experts awake, not to be brave. What you are actually testing at this stage is rarely the application. It is whether your observability can see the failure at all, and the usual first finding is that it cannot.
Stage two, once that is boring, is resource and dependency faults: CPU pressure, a latency injection of a few hundred milliseconds on a downstream call, a dependency returning errors. Latency is the highest-value fault in this whole discipline, because timeouts and retry budgets are almost always wrong and nothing else reveals it. This stage is where you discover the retry storm: if A and B each make three total attempts, the downstream can receive nine calls. Three retries plus the initial attempt at each layer permits sixteen calls.
Stage three is infrastructure: node loss, zone loss, breaking a network path between two services. Only after stage two is unremarkable, because a zone failure exercises everything at once and you want the simple faults already ruled out.
Stage four is continuous and unannounced, in production, on a schedule. Almost nobody should start here, and it is the version people quote when they have not done the first three.
The controls that make it defensible: bounded blast radius, always one service and one fault; an automatic abort wired to the SLO burn rate rather than a human watching a dashboard; a documented rollback; and the owning team present. And the finding goes in a ticket with an owner. An experiment that reveals a weakness nobody fixes has converted engineering time into an anecdote.
What interviewers probe next
"What would you inject first at this company?" Start with the bounded single-pod hypothesis described above once staging checks pass. Dependency latency comes next, scoped to a small caller cohort; a shared dependency can have a much larger blast radius.
"How do you get permission?" Start in staging to build the process, then bring a specific business case: name a past incident the experiment would have caught. Asking to break production abstractly gets refused, correctly.
"What if the experiment causes a real incident?" Then it is a real incident: abort, declare, run the normal process, and write it up. The programme survives that if the abort worked and dies if it did not, which is why the abort condition is the part to get right.
Common mistakes
Naming tools instead of a method. The tool is the least interesting decision here.
Starting in production because Netflix does. Netflix arrived there after years of the earlier stages and an architecture built for it.
Omitting the abort condition, which is the single most common gap and the one that turns the answer from senior to enthusiastic.
Treating the goal as finding failures. The goal is validating beliefs, and an experiment that confirms the system behaves as designed is a success rather than a wasted afternoon.
References