Spotify Staff SDET Interview Preparation Guide

Direct answer

Make the mismatch visible the moment you see it, whether that is after the upstream team is already running behind or as soon as it surfaces during planning itself, and look first for a way to decouple your own delivery from their exact finish order, such as a stub, an adapter, or a feature flag, so you have room to negotiate re-sequencing or reduced scope instead of just waiting to see if the date slips.

Structured elaboration

Surface the mismatch immediately, not once it is a crisis

Whether you discover it because the other team is visibly behind, or because it becomes obvious during a shared planning session, name it out loud right away: here is what we committed to, here is what we now depend on, here is the gap.

Look for a decoupling option before assuming you have to slip

A mock interface, a stubbed API, or a feature flag lets your work continue against a placeholder while the real dependency finishes in parallel, with a defined swap-in point once it is ready.

Negotiate re-sequencing with a concrete ask, not just a complaint

Pointing out that another team is behind invites defensiveness. Proposing a specific way both teams can still hit their dates if two pieces are resequenced invites problem-solving instead.

Communicate consistently to everyone downstream of the decision

Use the same explanation each time: what changed, what the new plan is, and what happens if it changes again.

Set escalation triggers before you need them

Agree upfront on the specific checkpoint, a date or a milestone, at which, if the upstream work still is not ready, the issue escalates automatically to both leads, rather than waiting for the final deadline to find out.

Worked example

Base case: discovered after the upstream team is already behind. A team is building a feature on top of a platform capability, and the platform team is now behind schedule on it. Rather than waiting to see if the platform team catches up, the team builds a lightweight adapter against a mocked version of the interface, so its own work continues. They set an explicit go or no-go checkpoint a week before their real deadline: if the real dependency is not ready by then, they ship against the mock with a manual fallback, and swap in the real dependency once it lands.

Planning-time discovery variant. During a multi-team sprint-planning session, it becomes clear in the room that one team's planned start date for a shared integration depends on another team's work, which is not scheduled to finish until after the first team's own committed date, a mismatch nobody had caught before that meeting. The engineer facilitating the session, in this scenario a DevOps engineer coordinating the shared infrastructure both teams touch, flags the conflict on the spot and proposes re-sequencing right there: the first team starts against a stubbed interface while the second team's work continues in parallel, with the real dependency swapped in once ready. Right after the session, the facilitator sends a short written summary to both team leads and stakeholders using a repeatable communication template: what was found, what was agreed, and what happens if either date slips again. The summary also sets an explicit escalation trigger: if the second team's work is not ready by a named checkpoint date, it escalates automatically to both leads instead of surfacing again only at the final deadline.

Trade-offs and pitfalls

Building a decoupling layer, such as an adapter, a mock, or a flag, costs real engineering time that is wasted if the upstream team finishes on schedule after all. It is worth it when the downside of waiting and being wrong is worse than the cost of building it and not needing it, which is usually true for anything on a hard external deadline.

Escalating too early, before giving the upstream team a real chance to communicate a plan, burns trust and can look like an attempt to shift blame preemptively. Escalating too late removes any options besides slipping the date. Pre-agreed, specific escalation triggers tied to a date rather than a feeling are what keep this from being a judgment call made under pressure.

Direct answer
Represent the test matrix as rows of concrete input variants (very long strings, missing fields, extra unknown fields, deeply nested arrays, base64 attachments, malformed JSON, unicode surrogate pairs, injection payloads, permission-denied) crossed against columns of the request DIMENSIONS that can independently vary (which field the variant applies to, HTTP method, auth state, and expected status code), then select which cells to automate first based on risk and blast radius rather than trying to automate the full cross-product.

Structured elaboration: the matrix shape

Worked example: selecting combinations under limited resources
Crossing every variant against every field is exactly the combinatorial-explosion problem pairwise (all-pairs) testing exists to solve. Dimensions multiply rather than add: this matrix's own three independent dimensions (10 variants x 8 fields x 3 auth states) already reach the 240-cell full cross-product cited above, and a fourth independent dimension (say, 5 HTTP methods) would push that to 1,200 cells for the same 10 variants and 8 fields, not a modest increase. Pairwise testing is the standard answer: instead of requiring every value of every dimension to appear together with every value of every other dimension simultaneously, which is what full cross-product coverage guarantees, it only requires that every pair of values, drawn from any two dimensions, appears together in at least one test row. That is enough to catch the large majority of real defects, because combinatorial-testing research has repeatedly found that most software faults are triggered by an interaction between at most two parameters, not by needing every parameter to combine at once. Run for real against this matrix's own three dimensions (10 variants x 8 fields x 3 auth states, 134 required pairs), a standard greedy pairwise-covering algorithm needs only 80 test rows to cover every one of those 134 pairs (verified directly: all 134 covered by the 80 generated rows), a 3x reduction from the 240-cell full cross-product. The 80 is not arbitrary: the two largest dimensions here (10 variants x 8 fields) set a hard lower bound, since covering every variant against every field at least once already requires 10 x 8 = 80 rows on its own, and a well-constructed pairwise set gets the third dimension (3 auth states) covered essentially for free by choosing which auth state accompanies each of those 80 rows rather than adding new rows for it.

Rather than crossing every variant against every field, select automation targets by two criteria applied in order: (1) severity if the case is missed (a crash, a 500, a security bypass, or data corruption ranks above a merely unhelpful 400 message), and (2) how CHEAPLY the case is exercised once the request-building harness exists (once you can post arbitrary JSON to the endpoint, a very-long-string variant costs almost nothing extra to add, so it is nearly free even at low individual risk). This produces the "Yes" column above: malformed JSON, missing required fields, injection payloads, and permission checks are automated first because they combine high severity with low marginal cost; base64/attachment-specific and unicode-specific cases are deferred to a second wave because they are lower-frequency in practice and more expensive to construct realistic payloads for.

Folded-in cases: typed field and null/missing-field validation
For a concrete POST /users-shaped endpoint with an integer id field, add explicit rows for a STRING value where an integer is expected ("id": "abc"), a float where an integer is expected ("id": 1.5), and id entirely absent versus id: null (these are two different states a strict validator should distinguish: absent means "not provided," null means "explicitly provided as empty," and a schema can legitimately treat them differently, e.g. "absent uses a default, null is rejected").

Trade-offs & pitfalls
The biggest pitfall in building this kind of matrix is treating every cell as equally worth automating; a matrix with 10 variants x 8 fields x 3 auth states is 240 theoretical cells, and attempting to automate all of them produces a slow, brittle suite with diminishing returns. The severity-times-cost prioritization above is the practical answer, but it must be revisited whenever a production incident reveals that a previously deprioritized cell (e.g. a specific unicode edge case) was actually high-severity for this particular system, since the initial prioritization is a judgment call, not a fixed formula.

Direct answer

Start with the dynamic programming (DP) state dp[i] meaning "length of the longest strictly increasing subsequence ending at index i," giving an $O(n^2)$ solution by comparing every pair. The faster $O(n \log n)$ approach uses a patience-sorting idea: maintain an array tails where tails[k] is the smallest possible tail value of any increasing subsequence of length k+1 found so far, and use binary search to find where each new number belongs, updating in $O(\log n)$ per element instead of scanning all previous elements.

Structured elaboration

O(n^2) DP first. For each index i, look at every earlier index j and extend the best subsequence ending at j if nums[j] < nums[i]:

def lis_length_dp(nums):
    """
    O(n^2) DP: dp[i] = length of the longest strictly increasing subsequence
    ending at index i. dp[i] = 1 + max(dp[j] for j < i if nums[j] < nums[i]).
    Time O(n^2), Space O(n).
    """
    if not nums:
        return 0
    n = len(nums)
    dp = [1] * n
    for i in range(n):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)
    return max(dp)

O(n log n) patience-sorting improvement. The $O(n^2)$ version's inefficiency is that for every i it re-scans all earlier j's to find the best predecessor. Patience sorting avoids that by keeping only one number per achievable subsequence length: the smallest tail seen for that length, because a smaller tail is always at least as useful as a larger one for extending further (any number that could extend a subsequence ending in the larger tail could also extend one ending in the smaller tail). This means you never need to compare against every earlier element: binary search directly finds the correct length-slot to update.

from bisect import bisect_left

def lis_length_patience(nums):
    """
    O(n log n) patience-sorting approach: tails[k] = smallest possible tail
    value of an increasing subsequence of length k+1. Time O(n log n),
    Space O(n).
    """
    tails = []
    for x in nums:
        j = bisect_left(tails, x)
        if j == len(tails):
            tails.append(x)
        else:
            tails[j] = x
    return len(tails)

Note that tails itself is not a valid increasing subsequence from the input at every step; it only tracks the best-possible tail value per length. Reconstructing an actual longest increasing subsequence (not just its length) requires additionally storing, for each element, the index that was its predecessor when it was inserted, then walking those predecessor links backward from the last-updated slot.

Worked example

nums = [10, 9, 2, 5, 3, 7, 101, 18]
print(lis_length_dp(nums))
print(lis_length_patience(nums))

Output:

4
4

Both approaches agree on length 4 (one such subsequence is 2, 5, 7, 101, or equivalently 2, 5, 7, 18, or 2, 3, 7, 101; multiple length-4 increasing subsequences exist, but the length is uniquely 4). Tracing the patience-sorting tails array as it processes nums: it ends up holding one representative tail value per achievable length, and its final size (4) directly gives the answer without ever comparing the current element against every earlier one.

Trade-offs & pitfalls

Key points

• The $O(n^2)$ DP directly generalizes to variants that need more information per state (for example, "longest increasing subsequence with at most one allowed decrease"), since dp[i] can be extended with extra dimensions; the patience-sorting approach is faster but harder to adapt to such variants because it discards information about which specific elements formed each subsequence.
• A common mistake is treating the tails array itself as an answer subsequence; it only encodes lengths and best-possible tail values, not an actual subsequence from the input, unless predecessor pointers are tracked alongside it.
• For strictly increasing vs. non-decreasing subsequences, the only change needed in the patience-sorting version is which binary search variant you use (bisect_left for strictly increasing, bisect_right for non-decreasing), since that changes whether equal values are allowed to extend a run.

Complexity

• $O(n^2)$ DP: time $O(n^2)$, space $O(n)$.
• Patience-sorting: time $O(n \log n)$ (n binary searches, each $O(\log n)$), space $O(n)$ for the tails array.

Edge cases

• Empty array: both approaches return 0.
• All elements equal: with strictly-increasing semantics, the longest increasing subsequence has length 1 (no two equal elements extend each other).
• Already sorted (fully increasing) input: dp grows to length n, and tails grows to length n as well, both correctly reporting the whole array as the answer.
• Descending input: both approaches correctly report length 1, since no element can extend any other.

Direct answer

Postman/Newman, REST-Assured, and a lightweight HTTP client each fit a different point on the trade-off between accessibility and code-native integration: Postman is the easiest to start in and the most approachable for non-programmers, REST-Assured gives the strongest fit for a Java-heavy team that wants tests as real code, and a lightweight client is the leanest option when you don't want a testing-specific dependency at all.

Structured elaboration

Maintainability. REST-Assured tests live as real code in the same repository and language as the service under test, so they get code review, IDE refactoring support, and version control diffing the same way any other code does. Postman collections are JSON files that CAN be version-controlled, but editing them productively usually happens through Postman's own UI, which makes diffs noisier and large-scale refactoring (renaming a variable used across fifty requests, say) more manual. A lightweight client's tests are whatever plain code you write, maintainability is entirely a function of how disciplined the team is about structuring that code, since the tool itself gives you no scaffolding either way.

Parametrization. All three support it, but differently. Postman uses environment and collection variables, straightforward for simple substitution, awkward for anything more programmatic (looping over a generated dataset, for instance). REST-Assured and a lightweight client both get this for free from the host language's normal data structures and control flow.

Debugging. Postman's UI shows you the request and response interactively as you build a test, which is genuinely fast for exploring an unfamiliar API. REST-Assured and lightweight-client tests debug the way any code does: breakpoints, stack traces, print statements, less immediately visual, but more powerful once you're deep into a complex assertion chain.

Team collaboration and onboarding. Postman is approachable for team members who aren't strong programmers, a manual QA engineer can build and run a Postman collection without writing code. REST-Assured and lightweight-client suites require everyone touching them to be comfortable in that language, a real constraint on a mixed-skill team, but not a real constraint if the team is uniformly engineers.

Integration with CI and language-native test runners. REST-Assured and a lightweight client integrate natively with whatever your codebase already uses for CI reporting (JUnit, pytest, whatever the ecosystem's runner is), so failures show up in the same place as every other test result. Postman needs Newman as a bridge to run in CI at all, which works well but is an extra moving part compared to a suite that's just... normal code in the normal test runner.

Trade-offs and pitfalls

Constraint-driven choice. For a mixed-language team where not everyone shares a common backend language, Postman's language-agnostic UI is often the pragmatic choice, everyone can contribute regardless of what they code in day to day, even if it costs some of the maintainability and CI-native integration REST-Assured would offer a single-language team. A common workflow that gets the best of both: start exploring an unfamiliar API in Postman (fast, interactive, low ceremony), and once the important test cases are understood, port the ones that need to be a durable, CI-enforced part of the suite into REST-Assured or a lightweight client, keeping Postman for ad hoc exploratory work rather than as the system of record for regression coverage.

Definition (SDET perspective)
Idempotency for test execution means running the same test — once or many times, sequentially or in parallel — yields the same system state and outcome as a single run. Tests are safe to retry and can be executed concurrently without flakiness or side effects from previous runs.

Examples of idempotency violations

• Tests that create resources with non-unique names (e.g., create-user “test”) causing collisions or failures on retries.
• Shared global state mutated by tests (singletons, in-memory caches) producing order-dependent failures.
• Partial cleanup: a teardown that sometimes fails leaves orphaned DB rows causing later runs to fail.

Patterns to make tests idempotent

• Unique run IDs: generate a UUID/timestamp prefix for every resource (user-<runId>) so retries create isolated resources.
• Atomic setup/teardown: perform setup and teardown in one transactional step or guarded operations; ensure teardown is best-effort and idempotent (delete-if-exists).
• Transactional fixtures: wrap test actions in DB transactions and rollback after test, or use DB savepoints to revert state. For external systems, use sandboxed accounts or ephemeral environments.
• Defensive assertions and cleanup: verify preconditions (resource absent/present) before acting; use exponential-backoff retries for eventual consistency.
• Parallel-safe isolation: use namespacing (queues, buckets, topics per run) and avoid shared mutable singletons.

Why this matters
Idempotent tests enable safe CI retries, reliable parallelization, faster feedback, and lower flakiness — essential for scalable test automation.

Approach summary (SDET perspective)
Introduce performance tests as first-class jobs in the automation ecosystem but keep them logically separated from fast functional runs. Use the functional framework for test definitions where helpful, but run load/latency workloads on dedicated runners and infra to avoid noisy neighbors.

Architectural choices

• Separate runners (recommended): functional runner for unit/integration tests; dedicated performance runner(s) (k6/Gatling/JMeter) on isolated nodes or k8s pods. Pros: stable baselines, controllable resource allocation, easier scaling. Cons: additional infra.
• Same runner (only for lightweight latency/smoke): reuse framework harness to validate endpoints quickly; not suitable for high-concurrency load.

Resource isolation

• Run performance jobs on dedicated VMs/k8s namespaces with CPU/memory limits; use separate networks or subnets to emulate real topology.
• Use traffic shaping (tc/chaos/latency proxies) to measure client-side latency.
• Tag and pin runners to avoid co-located CI workloads; use spot instances for non-critical runs.

Data collection & aggregation

• Emit metrics from clients and target services to Prometheus via Pushgateway or exporters.
• Capture request/response times, error rates, throughput, system metrics (CPU, memory, GC, thread pools), and network stats.
• Store raw traces/logs in a time-series DB (Prometheus) and long-term storage (Elasticsearch/S3). Visualize in Grafana; keep run metadata in a test results DB for correlation.

Thresholding & failure semantics

• Define tiers: smoke latency gates (fast-fail), load thresholds (soft gates), and SLA breaches (hard fail).
• Use statistical thresholds (p95/p99) and error-rate limits. Example: fail build if p95 latency > 500 ms AND error rate > 1% for 2 consecutive runs.
• Implement anomaly detection and rollback rules for canaries; allow “warning” status that notifies but doesn’t block for flaky conditions.

CI gating strategies

• PR pipeline: unit + functional + lightweight performance smoke (single-user latency).
• Merge/master: nightly full load/stress runs; results posted to dashboards and issues created on regressions.
• Release/canary: run targeted performance suites against canary environment with strict pass/fail; gate production promotion on critical SLA metrics.
• Use progressive gating: require trending stability over N runs before blocking.

Cost & infra considerations

• Use auto-scaling k8s clusters and spot instances for large scale; schedule heavy runs off-hours.
• Right-size scenarios: synthetic population vs full-traffic replay; sample lower concurrency for CI and reserve full scale for nightly/regression windows.
• Reuse containers/images to reduce startup cost; archive artifacts to S3 to avoid repeated data transfer.

Example stack

• Test harness: pytest / Java test runner for definitions
• Load: k6 (scripts in repo) or Gatling
• Metrics: Prometheus + Grafana, ELK for logs
• Orchestration: GitHub Actions/Jenkins triggers, k8s for runners

Why this works: separates concerns, ensures repeatable baselines, provides fast feedback in PRs while enabling realistic, scalable stress testing with robust observability and controlled cost.

Direct answer: Derive default timeouts from MEASURED latency distributions (not guesses), set CI timeouts more generously than local ones to account for genuinely slower, shared, contended CI infrastructure, and treat both too-short AND too-long timeouts as detectable, distinct flakiness signatures worth specifically looking for, since they produce different, identifiable symptoms.

Structured elaboration

Deriving sensible defaults, a measurement-based process: for a given wait/timeout point, collect the ACTUAL observed duration distribution across many real runs (per the "temporarily widen and log" diagnostic technique) rather than picking a round number by intuition; set the timeout at a percentile comfortably above the observed distribution's tail (for example, the 99th or 99.9th percentile plus a safety margin), which is generous enough to rarely trigger on legitimate, if occasionally slow, behavior, while still being BOUNDED (not infinite), so a genuinely stuck operation still fails in a reasonable time rather than hanging the whole suite.

CI vs local timeout differences: CI runners are typically slower and noisier (shared resources, contention from parallel jobs) than a developer's local machine, so a timeout calibrated against LOCAL latency data will be systematically too tight for CI, producing exactly the "passes locally, flakes in CI" pattern covered throughout this topic; derive CI and local defaults SEPARATELY from their own respective measured distributions, or, more simply, apply an explicit CI-specific multiplier to the locally-derived value if separate CI-specific measurement isn't yet available, rather than assuming one timeout value is appropriate for both environments.

Detecting outlier flakiness from too-short timeouts: a systematic pattern of failures clustering right around a specific SPECIFIC timeout VALUE (many failures logging an elapsed time just barely over the configured timeout) is a strong signature that the timeout itself is miscalibrated too tight, distinguishable from a genuine application bug (which wouldn't show this specific "just over the threshold" clustering pattern).

Detecting outlier flakiness from too-long timeouts: too-long timeouts don't typically cause outright test FAILURES (the opposite problem), but they cause a DIFFERENT flakiness-adjacent cost, a genuinely stuck or hung operation now takes the full, excessive timeout duration to fail, inflating overall suite runtime and developer wait time; detect via monitoring the DISTRIBUTION of actual observed durations at a wait point, if the vast majority of runs complete in a small fraction of the configured timeout (a large gap between typical duration and the configured ceiling), that timeout is likely calibrated far too generously and is silently costing wall-clock time on the rare occasions something IS genuinely stuck.

Adaptive timeout strategies: rather than a single static value, an adaptive timeout that adjusts based on RECENT observed latency (a rolling percentile of the last N runs' actual durations, recalibrated periodically) automatically tracks legitimate drift in normal latency (a genuinely slower-but-still-healthy period) without requiring manual recalibration, while still catching a GENUINELY anomalous run relative to recent, adaptive context rather than a fixed historical baseline that might have gone stale.

Worked example: measuring the actual duration distribution for a specific wait point across 500 real CI runs shows a median of 400ms, a 99th percentile of 1.8 seconds, and a max of 2.3 seconds; the previously-configured timeout of 2 seconds sits right in the middle of that tail, explaining a specific, previously-mysterious ~1% flake rate at that wait point as exactly the too-short-timeout pattern described above (failures clustering just over 2 seconds). Recalibrating to 3.5 seconds (comfortably past the observed max with margin) based on this MEASURED distribution, rather than an arbitrary round-number guess, eliminates the specific flake pattern while still failing within a reasonable, bounded time if something is genuinely stuck.

Trade-offs & pitfalls: recalibrating a timeout based on a HISTORICAL distribution risks becoming stale if the underlying system's real latency characteristics later shift (a genuine performance regression, or conversely a genuine improvement); the adaptive-timeout approach addresses this directly, but a STATIC, once-calibrated timeout (even if well-derived initially, as in the worked example) should still be periodically re-validated against fresh data rather than assumed correct indefinitely, the same staleness discipline that appears throughout this topic for baselines, allowlists, and fixtures alike.

Direct answer

An ephemeral test environment is a full or partial deployment of your system, spun up on demand for a single test run (or a single pull request) and torn down automatically afterward, rather than a long-lived shared environment that every test run competes for. The core benefit is isolation: each run gets a clean, known starting state with no leftover data or state from a previous run.

Structured elaboration

Typical provisioning patterns, roughly in order of weight:

• Per-run containers: spin up the service (and any dependencies like a database) as containers for the duration of one test run, torn down immediately after. Fast and cheap for a single service.
• Lightweight VMs: used when a container can't adequately isolate what's being tested (kernel-level behavior, certain security boundaries).
• Ephemeral namespaces: in a Kubernetes cluster, provision a dedicated namespace per pull request or per run, isolating network and resources from other concurrent runs while sharing the underlying cluster infrastructure.

Two concrete examples: a per-PR database clone (a fresh copy of a schema, seeded with known test data, destroyed when the PR's environment tears down) and an ephemeral Kafka instance spun up just to run a set of streaming integration tests against, rather than sharing a single long-lived test Kafka cluster across every concurrent test run.

Common pitfalls to plan for: resource leaks (an environment that fails to tear down cleanly on a crashed test run, silently accumulating cost over time) and slow provisioning (if spinning up an environment takes several minutes, that latency directly taxes every test run and can dominate total test time more than the tests themselves).

Worked example

For an integration-test suite exercising a checkout service and its database, a per-PR pipeline provisions a fresh namespace, deploys the service plus a freshly seeded Postgres instance into it, runs the integration suite against that isolated environment, and tears the whole namespace down on completion regardless of pass or fail (guarded by a TTL, a time-to-live expiry, as a backstop in case the teardown step itself never runs due to a crash).

Trade-offs & pitfalls

The most operationally painful failure mode is a teardown step that doesn't run reliably (because the pipeline crashed, or a webhook fired but was missed), which silently accumulates orphaned environments and cost over time; a TTL-based backstop that force-deletes anything older than a threshold, independent of whether the "clean" teardown path ran, is what actually prevents that from becoming a real problem.

Definition & how it works
Ephemeral test environments are short-lived, fully provisioned app environments spawned on demand (often per-PR). Container-based provisioning uses Docker images + orchestration (Kubernetes, Helm, kustomize) to build those environments quickly from the same artifacts CI uses.

Benefits (especially for an SDET)

• Strong isolation: each PR gets a clean environment, eliminating flakiness from shared state.
• Reproducibility: same container images + config produce consistent test runs.
• Fast parallel testing: run e2e and integration tests concurrently for multiple PRs.
• Traceability: logs and environment metadata tied to PR for debugging.
• Automation-friendly: integrate with CI (GitHub Actions/GitLab) to tear down automatically.

Limitations

• Resource cost: many concurrent environments increase infra and networking costs.
• Provisioning time: can add latency to feedback loop if images/configs are large.
• Complexity: needs orchestration, secret management, and cleanup logic.
• Data setup: realistic test data seeding or external dependency virtualization adds effort.

Per-PR ephemeral vs long-lived staging

• Per-PR: best for isolation, faster debugging, and preventing merge regressions; higher cost and infra complexity.
• Shared staging: cheaper, mirrors production integration across many changes; risks flakiness, merge-order problems, and harder-to-reproduce failures.

As an SDET I'd push for per-PR for critical services and automated e2e, but keep a stable long-lived staging for release validation and performance tests to balance cost and coverage.

Choosing between a small hotfix and reverting to the previous stable release comes down to which action more reliably and quickly restores correctness with the least additional risk.

Decision criteria

Prefer a hotfix when the root cause is well-understood, the fix is small and isolated (touches little beyond the specific broken behavior), and reverting would also roll back unrelated, wanted changes that shipped in the same release. Prefer a revert when the cause isn't yet fully understood (a revert restores a known-good state without needing to be right about the cause), the "small" fix would actually need to touch several places, or there's any doubt the hotfix itself is fully safe under production conditions.

Two concrete examples

• Hotfix preferable: a null-check is missing on one specific field that a new client type started sending; the fix is one line, well-understood, and reverting would also undo unrelated bug fixes shipped in the same release.
• Revert safer: a new feature interacts with three other systems in ways not yet fully mapped, and a stakeholder needs the feature live today despite the fix genuinely needing more than a day; here, reverting removes both the feature and the risk cleanly, buying time to fix it properly without the pressure of an active production issue.

Risk assessment and customer impact

Weigh: confidence in root cause (low confidence favors revert), blast radius of the broken behavior (wide impact favors whichever restores service fastest), and what else would be lost by reverting (favors hotfix if the release bundled other now-live fixes worth keeping).

Trade-offs and pitfalls

A partial hotfix (fixes some cases but not all) is worse than either a clean revert or a complete fix, since it can create a false sense the issue is resolved while a subset of users remain affected; if a hotfix can't be verified to be complete, defaulting to revert is usually the safer choice.