Senior Software Development Engineer In Test (SDET) - FAANG-Standard Interview Preparation Guide

Direct Answer

I've had both versions: a mentoring relationship that ended because the mentee outgrew what I had to offer, which is a good outcome, and one that ended because it wasn't working, which is harder. In both cases I named it directly and early rather than letting it fade out, since an unspoken ending leaves the mentee guessing whether they did something wrong.

Framework

The two endings need different conversations. Outgrowing is success, and the conversation should sound like it: naming specifically what they no longer need from me, and pointing to what comes next, a different mentor with expertise I don't have, more autonomy, a formal program, makes it feel like a milestone rather than a rejection. Not working needs concrete, specific evidence rather than a general impression, and it needs to separate the relationship not working from the person not being good enough; often it's a mismatch, the wrong mentor for this specific gap, not a verdict on the mentee.

Either way, I handle the conversation the same way: say it directly rather than letting the relationship quietly taper, since ambiguity is worse than a clear ending for both people. Come with something concrete, what changed for outgrowing, specific examples for not-working, not vague dissatisfaction. And offer what comes next rather than just closing the door: a different mentor, a different structure, or nothing at all if the mentee is genuinely ready to fly solo.

Worked Example

A mentoring relationship stopped working when the mentee's growth area shifted to something outside my depth, they needed architecture-level judgment I didn't have. Rather than continuing to coach at a level I couldn't actually add value to, I said so directly: named what they now needed that I couldn't give them, and introduced them to someone better suited to that specific gap. The conversation was short and low-drama because it was framed around their need, not around either of our performance.

Trade-offs and Pitfalls

• Letting a relationship fade without naming it leaves the mentee wondering if they did something wrong; silence reads as a verdict even when it isn't.
• Framing "not working" around the mentee's shortcomings when it's actually a mismatch damages their confidence for no reason.
• Ending a mentoring relationship isn't a performance action; it doesn't need documentation or HR involvement unless the underlying issue is an actual performance problem. Conflating the two turns an ordinary mentoring transition into a formal process it doesn't need to be.
• A senior answer separates "the relationship ended" from "the mentee failed"; a junior answer often can't articulate the difference.

Clarify goal (1 line)
Ensure each parallel test run is hermetic and reproducible across distributed nodes despite differing clocks, images, kernels.

High-level strategy

• Make runtime immutable and observable, verify provenance before test execution, and enforce via automated policy checks in CI/CD.

Image pinning & provenance

• Pin images by digest (sha256) not tags; store in private registry and require signed manifests (Notary/TUF/COSIGN).
• Record build provenance (SLSA attestation) and SBOM per image so test harness can assert exact binary/source versions.

Environment attestation

• Use TPM-backed node attestation (SPIFFE/SPIRE) and IMA/IMA-evm for runtime integrity; verify kernel modules and critical syscalls before scheduling tests.
• Capture node metadata (kernel version, seccomp, cgroup settings) and compare to test requirements.

Clock synchronization

• Prefer monotonic clocks in tests; where wall time matters, enforce NTP/chrony with max drift SLAs or use PTP for low-latency clusters.
• As fallback, run tests inside controlled time namespaces (fake-hwclock or libfaketime) seeded from central authority to ensure identical timestamps.

Immutable infrastructure

• Use ephemeral worker instances (immutable images) provisioned from a golden artifact; avoid running tests on long-lived mutable hosts.
• Container runtimes should use read-only rootfs, drop privileges, and mount deterministic volumes.

Enforcement & automated compliance

• Implement policy-as-code (OPA/Rego) and gate test execution in CI: verify image digest + signature, attestation tokens, node metadata, and clock sync metrics before parallel dispatch.
• Continuous monitoring: run periodic compliance jobs that auto-remediate (re-register node, reprovision image) and block flaky nodes from test pools.
• Log and store full run metadata (provenance, node attestation, clock offsets) for reproducibility and post-mortem.

Example flow

1. CI builds image -> signs -> emits SLSA attestation/SBOM.
2. Scheduler validates signatures + node attestation + clock SLA via OPA.
3. Tests run in ephemeral, read-only containers with monotonic timers; results stored with provenance.

This combination ensures deterministic test inputs, trusted execution environment, and automated enforcement to achieve hermetic parallel runs.

Direct answer

Keep a stalled dependency peer-to-peer as long as direct conversation is still making progress. Escalate when you hit a concrete trigger: a scope change that neither side can unilaterally absorb, genuinely conflicting priorities that only someone with visibility into both roadmaps can arbitrate, or a hard deadline-driven blocker where peer-to-peer conversation has already stalled.

Framework

Default: work it peer-to-peer. Most stalls are under-communication or unclear ownership, and a direct conversation or a short written proposal usually unsticks them without anyone else getting involved.

Concrete triggers to escalate.

• Scope change: the fix now requires work neither team budgeted for, and only a manager can reprioritize that.
• Conflicting priorities: both sides are acting rationally from their own team's goals, and the trade-off needs someone with visibility into both roadmaps to arbitrate.
• Hard blocker with a deadline: a fixed external date is genuinely at risk, and peer-to-peer conversation has already stalled past a reasonable window, for example no movement after two direct attempts over several days.
• Repeated pattern: the same kind of stall keeps recurring with the same team, which means the real issue is the working relationship or process, not this one dependency.

What to bring when you escalate. A short brief: what's blocked, what you've already tried peer-to-peer, the realistic options and their trade-offs, and the specific decision you need.

Worked example (applying the criteria)

Situation: your team's deliverable needs a schema change from another team that they've deprioritized for two weeks despite two direct requests.
Applying the criteria: this isn't just a communication gap, direct conversation was already tried twice with no movement. It's a conflicting-priorities case, the other team's roadmap has no room for this without reprioritizing something else, combined with a hard blocker, a fixed external deadline in three weeks that this schema change sits on the critical path for (meaning if this dependency slips, the final deadline slips by the same amount, unlike a dependency with buffer to absorb delay).
Action: escalated to the shared manager with a one-page brief covering what's blocked, the two peer-to-peer attempts and their outcome, and two options: the other team reprioritizes one sprint of work, or your team ships a temporary workaround with known limitations, along with the deadline risk if neither happens within the week.
Result: the shared manager reprioritized one sprint item, unblocking the schema change with two weeks to spare before the deadline. Both teams also agreed to flag scope-affecting asks earlier next time, so the same dependency doesn't reach this point again.

Trade-offs and pitfalls

• Escalating too early over normal friction burns trust and reads as an inability to work horizontally.
• Escalating too late, repeatedly trying peer-to-peer past the point it's actually working, puts the deadline at real risk and looks like poor judgment in hindsight.
• A vague escalation with no options and no specific ask wastes the leader's time compared with a brief that names the decision needed.

Direct answer

A centralized mock-management platform needs a data model for versioned mock definitions scoped by environment and team, APIs for both configuring mocks and having tests inject them at request time, CI integration so mocks are provisioned automatically per test run, and enough scale headroom (caching, per-service isolation) to remain usable when a single test run spans dozens of microservices in parallel.

Structured elaboration

• Data model: a mock definition is versioned (so a breaking change to one team's expectations doesn't silently break another team's tests still pinned to an older version), scoped to an environment (dev/CI/staging shouldn't share live configuration), and owned by a team, with an audit trail recording who changed what and when.
• APIs: a configuration API for defining/updating mock behavior (what a given service's mock should return for a given request), and a runtime injection API that a test run calls at start-up to activate the specific set of mock versions it needs, so tests declare their dependencies on specific mock configurations explicitly rather than relying on ambient global state.
• CI integration: the pipeline resolves and provisions the correct mock versions automatically as part of test setup, and can gate a merge on "does this change break any consumer's pinned contract" checks against the platform's own audit trail.
• Collaborative editing: multiple engineers on a team (or across teams) need to propose and review changes to a shared mock definition without clobbering each other, a workflow closer to reviewing a pull request than editing a live config, changes land as a new version through the same versioned data model rather than an in-place mutation, so a bad edit is a revert, not data loss.
• Authentication: the platform itself is a shared service other teams depend on, so it needs its own access control, service-to-service authentication (a token or service identity) so a CI job can pull the mock versions it is entitled to, and write-side authorization so only the owning team can publish a new version of their own service's mock, with every read and write attributable in the audit trail.
• Migration strategy: existing consumers and providers migrate incrementally rather than in one cutover, teams can adopt the centralized platform for one service pair at a time while others continue using local, hand-written mocks, with the platform's own versioning making a gradual migration safe.
• At-scale, parallel-CI requirement: when a single test run spans dozens of microservices running in parallel, the platform needs response caching (so repeatedly-requested canned responses don't recompute or refetch every time), per-service or per-test-run isolation (so parallel runs configuring different mock versions don't collide), and realistic support for STATEFUL interactions (a mock that needs to remember it already received one call before behaving differently on a second), not just static canned responses.

Worked example

Team A depends on Team B's payment-service mock returning a specific response shape; Team B needs to evolve that shape for a new feature. With versioning, Team B ships mock-definition v2 alongside the still-available v1; Team A's CI continues resolving v1 until they explicitly migrate their tests to request v2, at which point Team B can deprecate v1 with confidence nothing still depends on it, verified by the platform's own audit trail of which version each consumer's CI runs are actually requesting.

Trade-offs and pitfalls

A platform ambitious enough to serve every team's mocks centrally becomes a single point of failure and a shared-infrastructure maintenance burden in its own right; the migration strategy (letting teams adopt incrementally rather than requiring a hard cutover) is what keeps this realistic to actually roll out. At the 50-microservice parallel-CI scale specifically, underestimating the need for response caching and per-run isolation is the most common design gap, without it, contention on the shared mock-management service itself becomes the new bottleneck the platform was supposed to remove.

Direct answer

I would write a short memo that agrees with the goal behind the ask (confidence that we are not shipping bugs) while explaining why 100% coverage does not reliably deliver that goal, propose a small set of alternative metrics and enforcement policies that correlate with it more directly, and lay out a negotiation path built on a short pilot with real data rather than a flat "no." The memo contests the metric, not the goal, which is what keeps leadership on the same side.

Structured elaboration

Why coverage alone is the wrong KPI (key performance indicator): coverage measures whether a line of code executed during a test, not whether the test actually verified correct behavior. A test with no real assertions can hit 100% of a file's lines and catch nothing. Pushing toward the last 10 to 20% of coverage, usually defensive error handling for scenarios that almost never occur, tends to cost far more engineering effort than the risk it removes. And once 100% becomes the target itself, it invites writing shallow tests purely to hit the number, a version of the well-known problem that a measure stops being a good measure the moment it becomes the target (often called Goodhart's law).

Alternative metrics I would propose, from lightest to heaviest to implement:

• Defect escape rate: the share of bugs found in production versus caught before release. This is a more direct proxy for "no bugs" than coverage ever was.
• Change failure rate: the share of releases that need a hotfix or rollback.
• Churn-weighted coverage: instead of a flat target everywhere, require higher coverage on files that change frequently, since a file edited constantly carries more real risk per line than one untouched for years.
• Historical-failures-weighted coverage: set stricter coverage bars specifically on the parts of the codebase with an actual track record of defects, rather than treating every file as equally risky.
• A defect-risk prediction model, using signals like change size, file history, and past defect density to flag high-risk changes for extra review, is a credible longer-term option for a mature organization, but I would flag it as a future-state investment, not something to promise as a month-one deliverable.

Enforcement policies: gate coverage on new and changed code specifically (a change must not lower coverage on the files it touches) rather than requiring the entire legacy codebase to hit a uniform number, since retrofitting old, stable, low-risk code is usually the most expensive and least valuable part of a 100% mandate. Pair that with periodic, targeted verification (spot-checking that tests on the highest-risk files actually catch a deliberately introduced defect, not just execute the line) on a sample of high-risk files rather than everywhere, since that kind of check is too expensive to run universally.

Negotiation plan: first, acknowledge the goal explicitly in the memo, leadership wants assurance there are not bugs, and that is a goal engineering shares. Second, pull two quarters of this codebase's own coverage and defect data and show the actual correlation (or lack of one) between high coverage and escaped defects, so the case is made with this organization's own evidence, not an abstract argument. Third, propose piloting the alternative metric set on one product line for a defined period, with an explicit "what would tell us this worked" criterion agreed in advance. Fourth, frame the ask in terms leadership already cares about: redirecting effort from the last, most expensive slice of coverage toward the metrics that more directly reduce escaped defects is a better use of the same engineering budget, not a request to lower the bar.

Worked example

Suppose a two-quarter pull of this codebase's own data shows that files already above 90% coverage still accounted for roughly 40% of the quarter's escaped, customer-visible defects. That single data point does more to move a skeptical executive than any general argument about coverage's limitations, because it shows the specific mandate is not achieving its own stated purpose in this specific codebase. The memo would present that number alongside the proposed pilot, not as proof the alternative metrics work yet, but as the reason the current single KPI deserves a second look.

Trade-offs and pitfalls

• Pushing back on the 100% ask without offering a credible substitute reads as engineering resisting quality itself, which damages trust with leadership; the memo has to lead with an alternative, not a refusal.
• The alternative metrics, especially churn-weighted and historical-failures-weighted coverage, depend on the organization's incident and change-tracking data being reasonably clean; if that data is itself unreliable, the alternatives inherit that unreliability and the memo should say so upfront rather than overselling them.
• Leading with technical nuance before restating the shared goal loses the room fast; the memo's structure (goal, then evidence, then proposal) is deliberate, not just a formatting choice.
• A single-product-line pilot risks leadership generalizing a good or bad result too broadly in either direction; being explicit about what the pilot can and cannot tell you protects against both overreacting to a lucky result and dismissing a real one.

Recommendation (short): Prefer inlining tiny, obvious values for clarity; use factories when constructing objects with many defaults or when you need permutations; use fixture files for large, externalized datasets or when multiple tests share complex static data.

Rationale (SDET view):

• Inline: fastest to read and maintain for 1–3 primitive inputs; keeps intent visible in test.
• Factory: keeps tests DRY, supports builders for variations, easy to generate valid/invalid cases programmatically.
• Fixture file: good for large JSON/XML payloads, contract tests, or when non-trivial real-world data must be versioned.

Examples:

Inline (simple logic):

def test_discount_applies_for_vip():
    price = 100
    is_vip = True
    assert calculate_price(price, is_vip) == 90

Factory (many fields / permutations):

user = UserFactory(role='admin', signup_days_ago=40)
assert feature_flag_enabled(user) is True

Fixture file (large payload):

// tests/fixtures/realistic_order.json
{ "order": { "lines": [...], "shipping": {...}, "promotions": [...] } }

Use in test to validate import/parsing logic.

Decision: choose the simplest approach that keeps tests readable, fast, and maintainable.

Direct answer
Layer the strategy the same way as any resilience test suite: unit tests on the cache-interaction logic itself (serialization, key construction, TTL handling), integration tests against a real (disposable) cache instance proving the application actually behaves correctly with it, fault-injection scenarios specifically simulating a cache node failure or partition, and load tests validating behavior stays correct (not just fast) as concurrent sessions scale up; run all of it against a test environment that mirrors production's topology (multiple cache nodes, realistic eviction policy) while using synthetic session data, never real user sessions.

Structured elaboration

1. Unit level. Test the application's own cache-interaction code (how a session key is constructed, how a value is serialized/deserialized, how a TTL is set) with a fake or in-memory cache double, catching straightforward logic bugs cheaply.
2. Integration level. Run the same logic against a real, disposable instance of the actual caching technology (a local Redis container, for example), proving the application's real client configuration (connection pooling, timeouts, serialization format) actually works against the real thing, not just an idealized fake.
3. Fault injection. Simulate a cache node failing (killing one node in a multi-node cluster) and a network partition isolating the application from the cache, and assert the SPECIFIC documented behavior: does the application fail the request cleanly (if sessions are considered critical-path and un-cacheable-elsewhere), or does it fall back to a degraded mode (re-authenticate, treat the session as expired), whichever the design actually intends; the cache's own failover mechanics are a different system's concern from this test, which verifies only that the APPLICATION behaves correctly when the cache it depends on degrades.
4. Load testing, focused on correctness under scale, not just speed. Generate many concurrent synthetic sessions and assert session data remains correctly isolated per session (no cross-session data leakage under concurrent load) and that eviction under memory pressure behaves as configured (least-recently-used sessions are evicted, not an arbitrary or unintended set), rather than only measuring requests-per-second.
5. Test environment and data differences from production. Use a smaller but topologically-representative cluster (same node count and eviction policy shape as production, scaled down in capacity) so tests exercise real distributed-cache behavior (replication, failover) without needing production-scale hardware, and use entirely synthetic session data (fabricated user IDs and session payloads) so no real user data ever needs to exist in a test environment, while still exercising the SAME data shapes and sizes production sessions actually have.

Trade-offs and pitfalls

• A smaller test cluster can behave differently from production under specific failure modes that only manifest at larger scale (a particular rebalancing behavior that only appears with many more nodes); treat a smaller topology as good-enough for most fault-injection scenarios, but validate the riskiest assumptions periodically against a production-scale staging environment too.
• Testing only for speed (load testing that measures throughput and latency but never checks correctness under that same load) can miss a real bug where the caching layer starts silently serving stale or cross-contaminated session data specifically under contention, which a pure performance benchmark would never surface.
• Synthetic session data needs to be representative in shape and size (payload size, field structure) of real sessions, not just structurally valid; a synthetic session payload that's much smaller than real ones can hide a serialization or eviction-policy bug that only appears at realistic data sizes.

Approach summary
I’d build an adaptive, safety-first test strategy that favors fast feedback: enforce a clear test pyramid, deliver incrementally behind feature flags, apply risk-based acceptance criteria that evolve with pivots, and implement automated guardrails that block dangerous releases but don’t stop iteration.

Test pyramid

• Unit tests (fast, dev-run) ~70%: enforce API contracts and edge cases; maintain mutation tests for critical logic.
• Integration tests ~20%: exercises service boundaries, DB contracts, third‑party stubs.
• End-to-end / UI tests ~10%: smoke flows and high-value user journeys only; run in parallel and gated.

Incremental delivery + feature flags

• Break feature into vertical slices; ship smallest slice behind a flag.
• Use toggle types: dark-launch, gradual ramp, kill-switch.
• CI/CD gates deploy to canary first (1% prod) then ramp via flag.

Risk-based acceptance criteria

• For each slice define Acceptance Risk Profile (data loss, security, performance, business impact).
• Map to minimal required tests: e.g., payment slice => unit + integration + automated performance baseline + security scan; low-risk UI tweak => unit + smoke.
• Maintain a living checklist per risk class that PM/devs/sdet sign off.

Guardrails (automated & observable)

• Pre-merge: static analysis, contract tests, unit coverage thresholds for critical modules.
• Pre-deploy: pipeline policy that requires passing canary checks and SLO regression tests.
• Post-deploy: automated monitoring alarms, anomaly detection, and automatic flag rollback on error-rate or latency thresholds.
• Add chaos tests in staging for resilience.

Operational details

• Feed results into a single dashboard (build, canary metrics, flag state, test coverage).
• Short feedback loops: failing canary auto-notify Slack, auto-create bug with repro steps.
• Keep test infra scalable (containerized parallel runners) and prioritize flaky-test reduction.

Result: Enables rapid pivots—small risky surface per release, measurable safety nets, and quick rollback—balancing speed and quality.

Direct answer
Different companies name the same underlying idea, owning an outcome end to end and beyond your formally assigned scope, under different labels. Recognizing which of a specific company's named principles maps to that idea, and then having a real, specific story ready, is the actual skill being tested.

Structured elaboration

1. Read the company's actual published list and identify the principle whose description centers on end-to-end accountability and going beyond formal scope, rather than assuming it is whichever principle happens to sound closest to the word "ownership."
2. Select a real story where you did something that was, strictly, not your job, or continued past the point where you could have handed it off to someone else.
3. Structure it briefly: what you noticed, why you didn't wait for someone else to take it on, what you actually did through to completion, and the outcome.
4. Include one honest lesson, ideally something you would do differently next time; a story with no self-critique at all tends to read as less genuine.

Worked example
A project's launch depended on a piece of infrastructure owned by a team that had deprioritized it. Rather than escalating and waiting, or quietly working around the gap, the candidate built the missing piece directly, with the owning team's agreement, on a tight timeline, then handed it back afterward with documentation so that team could maintain it going forward, and followed up a month later to confirm it had actually been adopted rather than quietly abandoned. The lesson: doing the initial work wasn't the hard part; making sure ownership genuinely transferred back afterward, rather than quietly staying with the person who had stepped in, was the part that mattered most and the part that was easiest to skip.

Trade-offs and pitfalls
A story where you took something over and never handed it back can read as scope-grabbing rather than ownership; the follow-through and handoff matter as much as the initial action. Mapping too literally from a principle's name, rather than its actual published description, risks picking the wrong principle for a company whose specific wording differs from what the word alone suggests. A story with no genuine lesson or self-critique often reads as rehearsed rather than reflective.

Direct answer

CPython's Global Interpreter Lock (GIL) allows only one thread to execute Python bytecode at a time, even on a multi-core machine. For CPU-bound work, this means adding more Python threads does not add parallelism: threading only helps when threads spend time waiting (I/O), because the GIL is released during blocking I/O calls.

Structured elaboration

The GIL is a single mutex around the CPython interpreter's internal state. A thread must hold it to execute Python bytecode, and releases it periodically (roughly every fixed number of bytecode instructions, governed by sys.setswitchinterval()) or when it calls into a blocking operation implemented in C that explicitly releases the GIL (file I/O, network I/O, time.sleep, and many C-extension functions such as most of NumPy's array operations).

This gives a clear decision rule for CPU-bound versus I/O-bound work:

• I/O-bound (waiting on the network, disk, or another process): threading works well. While one thread is blocked waiting for a socket, the GIL is free for another thread to make progress. asyncio is the more scalable choice at very high concurrency (thousands of pending operations), since it avoids per-thread OS overhead entirely, at the cost of requiring the whole call chain to be written in an async style.
• CPU-bound (pure Python computation: parsing, hashing, tight loops): threading provides no speedup, because only one thread can hold the GIL and execute Python bytecode at a time; all the CPU-bound threads simply take turns, no faster in aggregate than one thread doing the same total work. multiprocessing sidesteps this by running separate OS processes, each with its own interpreter and its own GIL, genuinely using multiple cores at the cost of process-startup overhead and the need to serialize data across the process boundary. A native extension (C, Rust via a Python binding, or NumPy/Cython code that explicitly releases the GIL while it runs) can also achieve true parallelism from Python threads, because the GIL is released for the duration of the extension call.

Applied to maximizing a CPU-bound test suite's throughput specifically: if the suite's bottleneck is genuinely CPU-bound test logic (heavy parsing, hashing, or computation inside the tests themselves, as opposed to waiting on a database or a network fixture), spreading it across threading.Thread workers will not help; the correct lever is either multiprocessing (or a process-based test runner such as pytest-xdist's process workers) to actually use multiple cores, or restructuring the hot path to spend its time inside a GIL-releasing C extension. Conversely, if the suite's bottleneck is I/O-bound (network calls to a test environment, disk-heavy fixture setup), adding more threads is the right lever, and asyncio is worth it once the number of concurrent waits gets large enough that per-thread overhead itself becomes the bottleneck.

Worked example

Verified: a direct timing comparison of the same CPU-bound work run sequentially, across threading.Thread workers, and across multiprocessing.Process workers.

import threading
import multiprocessing
import time


def cpu_bound_work(n):
    """Pure-Python busy loop: no I/O, no GIL-releasing C call inside the hot path."""
    total = 0
    for i in range(n):
        total += i * i
    return total


N = 8_000_000
WORKERS = 4


def run_sequential():
    start = time.perf_counter()
    for _ in range(WORKERS):
        cpu_bound_work(N)
    return time.perf_counter() - start


def run_threaded():
    start = time.perf_counter()
    threads = [threading.Thread(target=cpu_bound_work, args=(N,)) for _ in range(WORKERS)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    return time.perf_counter() - start


def run_multiprocess():
    start = time.perf_counter()
    procs = [multiprocessing.Process(target=cpu_bound_work, args=(N,)) for _ in range(WORKERS)]
    for p in procs:
        p.start()
    for p in procs:
        p.join()
    return time.perf_counter() - start


if __name__ == "__main__":
    seq = run_sequential()
    threaded = run_threaded()
    mp = run_multiprocess()
    print(f"sequential (1 worker at a time), {WORKERS}x N={N}: {seq:.2f}s")
    print(f"threading.Thread x{WORKERS} (GIL-bound):        {threaded:.2f}s")
    print(f"multiprocessing.Process x{WORKERS} (real cores): {mp:.2f}s")
    print(f"threaded/sequential ratio: {threaded/seq:.2f} (near 1.0 = no speedup from threads)")
    print(f"sequential/multiprocess speedup: {seq/mp:.2f}x")

Output (one run, on a multi-core development machine; exact seconds vary by hardware and load, which is why the ratio, not the raw seconds, is the point):

sequential (1 worker at a time), 4x N=8000000: 0.81s
threading.Thread x4 (GIL-bound):        0.77s
multiprocessing.Process x4 (real cores): 0.36s
threaded/sequential ratio: 0.96 (near 1.0 = no speedup from threads)
sequential/multiprocess speedup: 2.22x

The threaded run is no faster than the sequential run (ratio close to 1.0, and on some runs threading is even slightly slower due to GIL handoff overhead), confirming that spreading CPU-bound Python bytecode across threads buys nothing. The multiprocess run is genuinely faster (about 2x on this run, on a machine with several cores available), because each process gets its own interpreter and its own GIL and can actually use separate cores. Repeating this run shows the same qualitative pattern (threaded ratio consistently near 1.0, multiprocess consistently faster), even though the exact seconds and speedup factor vary run to run with machine load, which is precisely why the answer's decision rule rests on CPython's documented GIL semantics rather than on any single run's exact timing.

Trade-offs and pitfalls

• A very common wrong answer is "just use more threads" for a CPU-bound test suite. It is easy to write, and the code will run without error, but it will not use additional cores.
• multiprocessing is not free. Each worker is a full separate Python process; test fixtures, database connections, and large in-memory objects generally cannot simply be shared across the process boundary and must be re-created per worker or passed through serialization, which is itself a real cost worth measuring before committing to a large worker count.
• Not all C extensions release the GIL. Some third-party C extensions hold the GIL for their entire duration; assuming a library call is "free parallelism" without checking its documentation is a common mistake.