Chaos Engineering & Resilience Testing: SDET Interview Questions 2026

It is 11:42pm. You have spent the last three evenings revising your test automation framework answers, memorising the differences between stubs and mocks, and practising your CI/CD pipeline explanation until you can recite it in your sleep. You feel ready — or ready enough — for the lead SDET role at a fintech company that handles millions of transactions per day. Then, as you scroll through the interview confirmation email one final time, you spot it: "The technical interview will include a 30-minute session on resilience testing and chaos engineering principles." Your stomach tightens. You open Google. You type "chaos engineering interview questions SDET." You find an article about Netflix's Chaos Monkey from 2017, a GitHub repository with a Kubernetes pod killer script, and a Medium post titled "What Is Chaos Engineering?" that reads like a conference talk abstract. Nothing that tells you what an interviewer will ask. Nothing that tells you how to describe failure injection testing without sounding like you have just read the Wikipedia page. Nothing that gives you the language to say "I have tested systems under controlled failure — here is how I did it, what I learned, and why it matters" — which is exactly what a lead SDET interviewer expects to hear. Chaos engineering is the fastest-growing senior SDET interview topic that almost nobody prepares for — because most SDETs think it is a DevOps discipline, not a testing discipline. They are wrong. And the candidates who can explain steady-state hypothesis design, describe how to automate a circuit-breaker resilience test, and articulate the difference between fault injection and chaos engineering walk into the interview visibly ahead of every other applicant.

Mitchell Agoma has spent 20 years in test engineering — across government departments, the defence sector, financial services, and national retailers — and at every organisation that operated at scale, the question was not whether systems would fail but how gracefully they would fail and how quickly they would recover. At a financial services organisation, Mitchell's team was responsible for testing a payment-processing system that handled £2.3 million in transactions per hour. The architecture had circuit breakers, retry policies, fallback mechanisms, and rate limiters — and every single one of them was untested. The team ran 1,200 integration tests every night. Not one of them injected a network delay. Not one of them killed a database connection pool. Not one of them verified that when the downstream fraud-checking service timed out, the payment was queued for retry rather than silently dropped. When the fraud-checking service went down during a Black Friday peak — a scenario that the architecture was designed to handle — the system did not handle it. It cascaded. The payment service timed out. The circuit breaker did not open because it had never been tested under load. The retry policy flooded the already-overloaded fraud service. The queue backed up. The outage cost an estimated £180,000 in lost transactions over 47 minutes — all because the resilience mechanisms worked on the whiteboard but not in production. The lesson Mitchell's team took from that day: resilience mechanisms that have never been tested are not resilience mechanisms — they are assumptions. And assumptions fail in production, spectacularly, at the worst possible moment.

At a national retailer (Asda), the e-commerce platform used bulkhead patterns to isolate the checkout service from the recommendation engine — so a surge in browsing traffic would not take down the ability to buy. The architecture diagram was beautiful. The implementation was untested. When a marketing campaign drove 10x normal traffic to the product recommendation service, the bulkhead did not hold — because the connection pool configuration had been copied from a staging environment with 1/50th the capacity. Mitchell's team built a chaos experiment that simulated the exact traffic pattern: ramp recommendation requests to 10x, verify the checkout service remained responsive, and assert that the bulkhead's thread pool rejected excess requests rather than exhausting shared resources. The experiment failed on the first run. It took three iterations — adjusting thread pool sizes, connection timeouts, and queue depths — before the bulkhead held. The experiment was then automated into the deployment pipeline. Every release since has verified bulkhead resilience before reaching production. The thread that connects Mitchell's experience across government, defence, financial services, and retail: resilience testing is not a nice-to-have for systems that handle money, personal data, or critical infrastructure. It is the testing discipline that answers the question your users will ask during an outage — "why didn't you test for this?" — before they have to ask it.

The SDET Interview Coach iOS app — with 800+ questions across 32 topics, Claude-graded mock interviews from Junior to Lead, and dedicated modules on resilience testing, chaos engineering, and non-functional testing strategies — gives you the structured practice to describe failure injection, circuit breaker testing, and Game Day scenarios with the specificity of someone who has done it, for £4.99 per month. Do not let a 30-minute resilience testing session be the reason you hear "we have decided to move forward with another candidate."

What Interviewers Are Actually Testing When They Ask About Chaos Engineering — It Is Never "Do You Know What Chaos Monkey Is?"

When an interviewer asks "have you done chaos engineering?", they are not checking whether you can name Netflix's tools. A candidate who has read the SRE book can list Chaos Monkey, Chaos Kong, Gremlin, and Litmus — that is a vocabulary test, and vocabulary tests do not get lead SDET offers. What the interviewer is actually testing is whether you understand that chaos engineering is a structured experimental discipline — not random destruction. The core of chaos engineering is the scientific method applied to distributed systems: you form a hypothesis about how the system will behave under a specific failure condition (the steady-state hypothesis), you inject that failure in a controlled experiment, you measure the system's behaviour against your hypothesis, and you either confirm the system is resilient or discover a weakness to fix. The measure of a senior SDET in this domain is not whether they have run chaos-monkey on a staging cluster. It is whether they can design a chaos experiment, define a meaningful steady-state hypothesis, automate the experiment into a pipeline, and articulate why testing resilience is fundamentally different from testing functionality. That is what the interviewer wants to hear — not "I know what Chaos Monkey is" but "I understand that resilience is a system property that must be tested, not assumed, and here is how I design experiments to test it."

The one-sentence answer that anchors every strong chaos engineering interview response: "Resilience is a system property that must be tested, not assumed — and the measure of a senior SDET is not whether they can run a chaos tool, but whether they can design controlled experiments, automate resilience verification into CI/CD, and prove that the system degrades gracefully under failure rather than collapsing catastrophically."

The 7 Most Common Chaos Engineering and Resilience Testing Interview Questions — With Model Answers That Demonstrate Production Experience

Here are the questions that Mitchell has both asked in interviews and been asked — each with the model answer that distinguishes a candidate who has tested resilience from a candidate who has only read about Netflix's Chaos Monkey.

Q1: "What is chaos engineering — and how is it different from failure testing or negative testing?"

What the interviewer is testing: This is the foundational question. Can you define chaos engineering precisely and distinguish it from related disciplines? A candidate who says "it is breaking things on purpose" fails. A candidate who describes the scientific method and the distinction between known-unknowns and unknown-unknowns succeeds. Model answer: "Chaos engineering is the discipline of experimenting on a distributed system to build confidence in its ability to withstand turbulent conditions in production. It is distinct from failure testing and negative testing in three ways. First, scope: failure testing asks 'if I inject this specific failure, does the system handle it correctly?' — it tests known failure modes against known handling logic. Chaos engineering asks 'what happens when I introduce turbulence into the system?' — it explores unknown failure modes and emergent behaviour. Failure testing verifies the system handles failures it was designed for. Chaos engineering discovers failures the system was not designed for. Second, method: failure testing is assertion-based: inject failure, assert the error handler runs. Chaos engineering is hypothesis-driven: define a steady-state, inject turbulence, measure deviation from steady-state. Third, environment: failure testing can run in any environment because it tests code paths. Chaos engineering must run in an environment that approximates production because it tests system behaviour under realistic load, network topology, and resource constraints. The relationship is complementary: failure testing catches bugs in resilience code; chaos engineering catches gaps in resilience architecture. For example, a failure test verifies that the circuit breaker opens after 5 consecutive timeouts. A chaos experiment verifies that when the circuit breaker opens, the remaining services can handle the redirected traffic without themselves becoming overloaded — an emergent behaviour that no unit test or integration test can predict." For related guidance on systematic testing approaches, see our test case design techniques guide.

Q2: "How do you define a steady-state hypothesis — and what makes a good one?"

What the interviewer is testing: The steady-state hypothesis is the intellectual core of chaos engineering. The interviewer wants to know whether you can define a hypothesis that is specific, measurable, and falsifiable — or whether you will propose something vague like 'the system should still work.' Model answer: "A steady-state hypothesis is a statement of normal system behaviour — the baseline against which the chaos experiment's results are compared. A good hypothesis has four properties. Property 1 — Specific: it identifies the system, the metric, the threshold, and the duration. Bad: 'the system should handle failures.' Good: 'when 50% of inventory-service instances are terminated, the product-detail page continues to return HTTP 200 with inventory data for 99% of requests within 2 seconds, measured over a 5-minute window.' Property 2 — Measurable: the metric must be observable from outside the system — ideally from the same monitoring dashboards used in production (Prometheus, Datadog, Grafana). If you cannot measure it, you cannot verify it. Property 3 — Falsifiable: the hypothesis must be capable of being proven wrong. 'The system will not crash' is not falsifiable because the system could slow to a crawl without crashing. '99% of requests complete within 2 seconds' is falsifiable — if only 94% complete within 2 seconds, the hypothesis is disproved. Property 4 — Business-relevant: the metric should reflect the user experience or business outcome, not just technical health. 'CPU utilisation stays below 80%' is less meaningful than 'checkout completion rate stays above 99%.' The steady-state hypothesis is what transforms chaos engineering from 'let us break things and see what happens' into a rigorous experimental discipline. It is also what allows you to automate the experiment: if you can measure the steady-state programmatically (via an API query to your monitoring system), you can assert on it in an automated test. See our monitoring and observability guide for the instrumentation needed to make steady-state measurements reliable."

Q3: "Walk me through how you would test a circuit breaker — step by step."

What the interviewer is testing: Circuit breakers are the most commonly implemented resilience pattern — and the most commonly untested. The interviewer wants to see whether you can design a test that covers all three circuit states (closed, open, half-open) and the transitions between them. Model answer: "I test a circuit breaker through its full lifecycle across three states and five scenarios. Scenario 1 — Normal operation (closed state): the downstream service is healthy. Send N requests, verify all pass through the circuit breaker to the downstream, verify the success counter increments, and verify the circuit remains closed. Scenario 2 — Failure threshold exceeded (closed → open): configure the downstream to fail (HTTP 500) for M consecutive requests, where M equals the circuit breaker's failure threshold. Send M failing requests, then send one more request — and verify this request is rejected immediately by the circuit breaker without calling the downstream. The key assertion: the request fails fast (typically in under 5ms) rather than timing out after the downstream's configured timeout (typically 5-30 seconds). This fast-fail behaviour is the circuit breaker's primary value — it prevents resource exhaustion from waiting for a known-broken downstream. Scenario 3 — Recovery timeout (open → half-open): after the circuit opens, wait for the configured recovery timeout (e.g., 30 seconds). Then fix the downstream service (restore healthy responses). Send a probe request — this is the first request in the half-open state. Verify that (a) the request passes through to the downstream (the circuit allowed it), (b) the downstream returns a success response, and (c) the circuit transitions to closed. Scenario 4 — Half-open failure (half-open → open): similar to Scenario 3, but the downstream still fails. Verify that the single probe request fails and the circuit immediately returns to the open state — it does not require the full failure threshold again. Scenario 5 — Fallback verification: while the circuit is open, verify that the fallback behaviour works correctly. If the fallback is a cached response, verify the cache is returned. If the fallback is a degraded experience, verify the degradation is applied. If the fallback is an error message, verify the error is meaningful to the caller. The test should be automated — I use Toxiproxy (an open-source TCP proxy that simulates network conditions) to programmatically control the downstream's behaviour, or Spring Cloud Contract / WireMock to stub HTTP responses at the application layer. The test code looks something like:

@Test
void shouldOpenCircuitBreakerAfterFailureThresholdExceeded() {
    // Arrange: make downstream fail consistently
    toxiproxy.toxics()
        .latency("downstream-latency", ToxicDirection.DOWNSTREAM, 5000);

    // Act: send requests until threshold exceeded
    for (int i = 0; i < circuitBreakerThreshold; i++) {
        assertThrows(ServiceUnavailableException.class,
            () -> paymentClient.authorise(testPayment()));
    }

    // Assert: circuit is now open — requests fail fast
    long start = System.currentTimeMillis();
    assertThrows(CircuitBreakerOpenException.class,
        () -> paymentClient.authorise(testPayment()));
    long duration = System.currentTimeMillis() - start;
    assertThat(duration).isLessThan(50); // fast-fail, not timeout
}

The tooling is detailed in our Docker test automation guide — Toxiproxy and similar tools run in Docker containers, making them ideal for CI/CD pipeline integration.

Q4: "What is the difference between fault injection and chaos engineering — and when would you use each?"

What the interviewer is testing: This question separates practitioners from theorists. Fault injection and chaos engineering are often used interchangeably, but they serve different purposes. Model answer: "Fault injection is a technique — the deliberate introduction of faults into a system to test its error-handling behaviour. Chaos engineering is a discipline — the systematic experimentation on a system to discover its resilience weaknesses. Fault injection asks a specific question: 'does the system correctly handle a network timeout on this specific call?' Chaos engineering asks an open-ended question: 'what weaknesses exist in this system's resilience?' The practical difference is in scope and intent. Fault injection is targeted and verification-oriented: I inject a specific fault (a 5-second TCP connection delay) into a specific component (the payment service's connection to the fraud service) and verify a specific behaviour (the payment service times out after 3 seconds and queues the payment for retry). This is a functional test of resilience code — I know exactly what I am testing and what the expected outcome is. Chaos engineering is exploratory and discovery-oriented: I introduce turbulence into the system (terminate 30% of instances, add latency to inter-service calls, saturate a database connection pool) and observe what happens — without a complete expectation of the outcome. The goal is not to verify that the system handles a known failure; it is to discover unknown failure modes. In practice, I use both — fault injection for automated resilience verification in CI/CD (every deployment must pass the fault-injection test suite), and chaos engineering for periodic exploration in staging or production (discover weaknesses that the fault-injection tests do not cover). Fault injection is the safety net. Chaos engineering is the exploration that expands the safety net. At a financial services organisation, Mitchell's team ran fault injection tests on every deployment (testing known failure modes) and weekly chaos experiments in a staging environment (exploring unknown failure modes). The fault injection tests caught regressions. The chaos experiments caught the weaknesses the team had not thought to test for — including a database failover that succeeded but caused a 47-second read-replica lag that broke a reporting service. No fault injection test had been written for read-replica lag because nobody had considered it a risk. The chaos experiment discovered it in 20 minutes." For the broader context of non-functional verification, see our non-functional testing guide.

Q5: "How do you decide what chaos experiments to run — and what do you prioritise?"

What the interviewer is testing: This is the strategy question. You cannot run chaos experiments against every component and every failure mode — the combinatorial space is infinite. The interviewer wants to see that you can prioritise based on risk. Model answer: "I prioritise chaos experiments using a risk-based framework with three dimensions. Dimension 1 — Impact radius: if this component fails, how many downstream services and user journeys are affected? A payment-authorisation service that is called by every checkout transaction has a larger impact radius than a product-recommendation service that is called only on the homepage. I prioritise high-impact-radius components first. Dimension 2 — Failure history: has this component or this failure mode caused an incident in the past? I review the incident post-mortems from the last 12 months and design chaos experiments for every failure mode that caused a production incident. If a database connection-pool exhaustion caused an outage in March, there must be a chaos experiment that reproduces connection-pool exhaustion and verifies the fix. Dimension 3 — Architectural dependency graph: I map the service dependency graph and identify the critical paths — the minimum set of services that must be operational for the core business function to work. For an e-commerce platform, the critical path is: browser → CDN → web application → checkout service → payment service → payment gateway. Every service on this path gets a chaos experiment before any service off the path. The prioritisation output: I produce a chaos experiment backlog — a prioritised list of experiments, each with a hypothesis, a blast radius, an owner, and a target date. The top of the backlog is reserved for components that score high on all three dimensions: high impact radius, history of incidents, and on the critical path. The bottom of the backlog is for low-impact, no-incident-history, off-critical-path components — these get experiments when time permits but do not block releases. The framework prevents the most common chaos engineering mistake: starting with interesting but low-risk experiments (like killing a non-critical background worker) while the critical-path services remain untested under failure." For more on risk-based testing strategy, see our test strategy planning guide.

Q6: "What tools do you use for chaos engineering and resilience testing — and how do you choose between them?"

What the interviewer is testing: Can you name specific tools, explain their trade-offs, and demonstrate that you choose tools based on requirements rather than brand recognition? Model answer: "I categorise chaos engineering tools into three tiers based on maturity and blast-radius control. Tier 1 — Application-level proxies (lowest blast radius, safest for automation): Toxiproxy, WireMock, MockServer. These sit between the application and its dependencies, intercepting network calls and injecting failures at the protocol level — latency, connection resets, bandwidth throttling, HTTP error responses. Toxiproxy is my default choice for automated resilience tests in CI/CD because it is deterministic, programmable via a REST API, and runs in Docker. A test script can add a toxic (latency, timeout, bandwidth limit) before the test and remove it after — the blast radius is limited to the single service under test. Tier 2 — Infrastructure-level agents (medium blast radius, for staging environments): Gremlin, Chaos Mesh (Kubernetes), LitmusChaos. These operate at the infrastructure level — terminating pods, saturating CPU, filling disk, dropping network packets. Gremlin provides fine-grained blast-radius control (target specific containers, hosts, or percentages of traffic) and an abort mechanism (halt all experiments with a single command). I use these in staging environments where the blast radius is contained and the experiments test infrastructure resilience (does the pod autoscaler respond to a terminated instance within 30 seconds?) rather than just application resilience. Tier 3 — Production-safe experimentation platforms: AWS Fault Injection Simulator, Azure Chaos Studio, Gremlin with production safeguards. These are designed for running chaos experiments in production with strict safety controls — automatic experiment duration limits, automatic rollback on alert triggers, and audit trails. I use these only after Tier 1 and Tier 2 experiments have passed, and only for experiments that cannot be realistically simulated in staging (like testing the behaviour of a managed service — RDS failover, ElastiCache node replacement — which behaves differently in AWS's production environment than in a local simulation). The decision framework: start with Tier 1 (Toxiproxy) for CI/CD automation — every resilience pattern gets a Tier 1 test before merge. Progress to Tier 2 (Chaos Mesh/Gremlin) for staging-environment Game Days. Reserve Tier 3 (AWS FIS) for production experiments that are approved, time-limited, and monitored. No team should jump straight to Tier 3 without mastering Tier 1 and Tier 2 — the risk of an uncontrolled production experiment causing an outage is too high." For setting up the infrastructure to support these tools, see our Kubernetes test infrastructure guide.

Q7: "How do you measure the success of a chaos engineering programme — and how do you report it to stakeholders who think you are just breaking things?"

What the interviewer is testing: This is the leadership question. Chaos engineering can look like expensive vandalism to stakeholders who do not understand it. The interviewer wants to see that you can justify the investment in business terms. Model answer: "I measure chaos engineering success in four metrics that map directly to business value. Metric 1 — Weaknesses discovered and fixed: the number of resilience weaknesses identified by chaos experiments that were fixed before causing production incidents. Each weakness fixed is a potential incident prevented. Over a 6-month period at a financial services organisation, Mitchell's team ran 18 chaos experiments, discovered 7 weaknesses, fixed all 7, and prevented an estimated 3 major incidents — each of which would have caused 30-90 minutes of degraded service. Metric 2 — Mean time to recovery (MTTR) improvement: measured during Game Days, not during real incidents. Before the chaos engineering programme, the team's Game Day MTTR was 47 minutes. After 6 months of quarterly Game Days with targeted improvements to monitoring, runbooks, and automation, the MTTR dropped to 11 minutes. This is a 77% improvement in the team's ability to recover from failure — and it was measured without waiting for a real incident. Metric 3 — Resilience coverage: the percentage of critical-path services that have automated resilience tests. Starting from 0% (no resilience tests, only functional tests), the goal is to reach 100% coverage of critical-path services within 12 months. Each service added to the resilience test suite reduces the risk of an unhandled failure. Metric 4 — Deployment confidence: the number of deployments blocked by failing resilience tests — evidence that the tests are working as a safety net. Each blocked deployment is a potential production incident prevented. I report these metrics quarterly to stakeholders using language they understand: 'In Q1, our chaos engineering programme discovered 3 resilience weaknesses, all fixed before reaching production. We estimate these would have caused approximately 2 hours of degraded service, affecting an estimated 15,000 customers. The programme cost £12,000 in engineering time. The estimated cost of those 2 hours of degraded service — in lost transactions, support tickets, and engineering time for incident response — was approximately £65,000. Return on investment: 5.4x.' Numbers speak louder than principles. When stakeholders see the ROI, 'breaking things on purpose' becomes 'investing in reliability.' For the foundational metrics framework, see our QA metrics and KPIs guide."

Common Mistakes in Chaos Engineering — and How to Avoid Them in an Interview

The five most damaging mistakes Mitchell has observed across organisations — each one a trap that interviewers specifically listen for.

How to Practise Chaos Engineering Before Your Interview — A 2-Day Preparation Plan

Chaos engineering cannot be learned from reading alone. You must inject failures into a real system, observe the behaviour, and articulate what you learned. Here is a two-day plan:

Chaos Engineering Is Not Optional for SDETs Targeting Senior Roles in 2026

Resilience testing and chaos engineering were once the exclusive domain of site reliability engineers at Netflix and Amazon. That era is over. In 2026, any system that handles money, personal data, or critical business operations — which is to say, nearly every system that hires SDETs — is expected to degrade gracefully under failure, recover quickly, and demonstrate that its resilience mechanisms have been tested, not assumed. The patterns described in this guide — steady-state hypothesis design, circuit breaker lifecycle testing, fault injection versus chaos engineering, Game Day facilitation, and resilience coverage metrics — are the patterns that Mitchell's teams have applied in production across government departments, the defence sector, financial services, and national retailers like Asda, Co-op, and BT. They are not academic exercises. They are the difference between a system that absorbs failure and a system that amplifies it. In 2026, chaos engineering and resilience testing are what performance testing was in 2018 and what API testing was in 2015 — a skill that separates the SDETs who are choosing between offers from the SDETs who are waiting for rejection emails. Prepare now, practise deliberately, and walk into your interview with the specific, production-informed answers that make panels say "this candidate has operated systems under failure — not just read about it." Because by 2028, resilience testing will not be a specialisation. It will be part of the baseline SDET job description — and the candidates who prepared early will be the ones leading the interviews, not sitting in them.

For structured, AI-graded interview preparation across chaos engineering, resilience testing, and the full range of SDET topics, the SDET Interview Coach iOS app offers 800+ questions across 32 topics with Claude-powered mock interviews from Junior to Lead. The resilience testing module includes scenario-based questions on circuit breakers, bulkheads, retry policies, and steady-state hypothesis design — with AI-graded feedback on your technical accuracy and communication. Available on the iOS App Store for £4.99 per month.

If you are building your foundational system testing knowledge, start with our SDET system design interview guide — understanding system architecture is the prerequisite for testing system resilience. If you want to understand how resilience patterns integrate with deployment pipelines, see our continuous testing and DevOps guide. And if you are preparing for the non-functional testing dimensions that chaos engineering complements, see our non-functional testing interview guide.