Meta QA Engineer Interview Preparation Guide (Mid-Level)

Situation & goal
I would design a performance test plan to validate the public REST API can sustain 10,000 RPS at peak while meeting SLA latency and error targets, and to produce reliable, reproducible results developers can act on.

Workload modeling & test cases

• Capture real traffic: sample access logs for endpoints, methods, auth patterns, payload sizes, and session behavior.
• Define workload mix: e.g., 60% GET /items, 20% POST /orders, 15% PATCH /orders/{id}, 5% auth/health — reflect production proportions.
• Request distribution: use Poisson (approx. exponential inter-arrival) for arrival variability; include steady-state 10k RPS, ramp-up (10 min), spikes (2x for 5 min), and soak (1–2 hours).
• Think time and concurrency: model client think times, keep-alive vs new connections, and distribution of request sizes.

Acceptance criteria

• Latency: p50 < 50 ms, p95 < 150 ms, p99 < 300 ms under 10k RPS.
• Error rate: total 4xx+5xx < 0.1%; no repeated 5xx spikes.
• Throughput: sustained 10k RPS for 10 minutes without SLA violations.
• Resource limits: CPU < 85%, memory < 80%, acceptable GC/latency patterns.

Tooling & environment

• Tools: k6 or Gatling for load generation (scripts as code), Grafana+Prometheus for metrics, ELK for logs, Jaeger for traces.
• Environment: dedicated, isolated test cluster mirroring prod (same instance types, autoscaling rules, DB replicas). Use separate load generators in different availability zones to avoid network bottlenecks.

Test data & setup

• Synthetic but realistic data: seeded DB snapshots, unique IDs per virtual user, data cleanup or namespace isolation.
• Authentication: use service tokens or simulated OAuth flows; cache tokens to avoid auth becoming bottleneck unless testing auth specifically.

Reliability & reproducibility

• Infrastructure-as-code to provision environment and load generators (Terraform/Ansible).
• Version-control test scripts and parameters; parameterize seed, RPS, durations.
• Run multiple iterations (≥3) and compare p95/p99 variance; collect system metrics, JVM GC, DB latencies, network stats.
• Correlate failures with traces/logs; establish baselines and document run configs.

Post-test analysis

• Break down by endpoint, backend calls, DB queries; identify hotspots and propose mitigations (caching, query tuning, autoscale rules).
• Deliver a run report: charts, acceptance pass/fail, root-cause candidates, recommended next steps.

Direct answer

A regression is a defect where something that used to work stops working because of a later change. Measure it as a rate against the amount of change (regressions per 100 merged changes, per release), attribute each one to the change and to the safety net that missed it, and set policies on the system (tests, review of the seam, risk-based test selection). Never rank people by regressions; that trains people to hide or re-label them.

Terms. A contract test checks that two components still agree on the data or calls they exchange. The seam is the boundary where two components meet, where changes in one most often break the other. Risk-based test selection means running first the tests most likely to catch a problem given what changed. Blameless means reviewing what in the system let a problem through rather than who caused it.

1. Define and measure

• Numerator: defects confirmed as regressions, meaning a reproducible earlier-working behaviour. A rule such as "worked in the previous release and a test or user can show it" keeps the label consistent.
• Denominator: merged changes (pull requests) or deployments in the same window. Raw counts rise just because you shipped more.
• Timeframe: pick and state it. A rolling 4 to 8 week window smooths noise for frequent releases. Per-release works for release trains. Count regressions found up to a fixed age after release (say 30 days), and restate the number later because it matures as late regressions surface.
• Slice it by component, so the number points to somewhere to act.

2. Attribute to the causing change

Heuristics, from strongest to weakest:

1. Bisect: if the bug reproduces, git bisect finds the first commit where it appears: you mark one old commit as good and one recent commit as bad, git checks out the middle, you test it and answer good or bad, and this halves the range each time, so about 8 steps cover 200 commits (2^8 = 256).
2. SZZ-style blame: take the lines the fix commit changed, use git blame to find which earlier commit last touched them, and treat that as the likely introducer (this is the SZZ algorithm, named after its authors in the research literature; it is a heuristic and wrong on refactors and whitespace). Traced example: the fix commit F changes lines 40 to 52 of pricing.py. git blame on those lines, run on the commit just before F, shows they were last changed by commit C (a change that rounded prices), so C is the suspected introducer. If C was only a reformatting commit, step back to the commit that changed the lines before C.
3. Release or deploy diff and feature-flag flips: narrows to a window.
4. Bug-to-commit links kept by convention (ticket id in the commit message).
5. Otherwise record "unknown". An honest unknown beats a guessed name.

3. Policies that reduce regressions without blame

• Every regression fix ships with a test that fails without the fix.
• Review each regression as a blameless review (about what allowed it through, not who wrote it) with three questions: what change, which check should have caught it, what would have made that check exist?
• Add contract tests where the most-regressing components meet (the seam described above).
• Report by component and team, never by author; there is no leaderboard.
• Do not set a target on the raw count. A count target rewards relabelling regressions as "new bugs".

Worked example (illustrative)

One month: 200 merged changes, 12 regressions, so 12 / 200 = 6% overall. By component:

Billing has a rate about three times Search's. Blame-tracing the 8 shows 5 trace to one shared pricing helper with no unit tests. The policy that follows is aimed at that seam (contract tests plus a required reviewer from the owning team), not at whoever committed last. Re-measure over the next window using the same definition.

Pitfalls

• Changing the definition mid-way and comparing before with after.
• Trusting blame output blindly: a reformatting commit "causes" everything.
• Counting only bugs users report, missing regressions caught internally, so the rate looks better when testing gets worse.
• Using the metric to judge individuals, which ends honest tagging.

Direct answer. An adapter/plugin architecture that lets a framework add new browsers, mobile devices, test runners, or reporting sinks with minimal core changes needs three things: a stable adapter CONTRACT (an interface the core depends on and every extension implements), a PLUGIN LIFECYCLE (how an extension is loaded, initialized, and torn down), and FAILURE ISOLATION (one broken plugin cannot crash the core runner).

Structured elaboration.

• Adapter API contract: a minimal interface (e.g. start_session(capabilities), quit()) that the core framework depends on exclusively - the core never imports a concrete adapter class, only the interface, so adding a new environment means writing a new implementation, not modifying the core.
• Plugin lifecycle: register (the adapter announces itself, typically via a name-keyed registry or a language-native plugin-discovery mechanism like Python entry points or a Java ServiceLoader), initialize (any setup the adapter needs before first use), execute (the actual start_session/interaction calls during a test run), and teardown (guaranteed cleanup even if the test using it failed).
• Versioning strategy: the adapter contract itself is versioned (semantic versioning), so a plugin built against contract v1 fails an explicit compatibility check rather than silently misbehaving against a v2 core.
• Compatibility testing: a small conformance test suite that EVERY adapter must pass (start a session, confirm a known element is findable, quit cleanly) before it's trusted in the main framework - this catches an adapter that technically implements the interface but violates its behavioral contract.
• Isolating plugin failures: every call into a plugin goes through a try/except (or equivalent) boundary in the core, so an exception inside one plugin's hook becomes a LOGGED, sandboxed failure rather than an unhandled exception that kills the entire test run.

Worked example. Walk one concrete request through the architecture: a test asks for the "safari-cloud" environment. The core calls registry.resolve("safari-cloud"), knowing nothing about what that name means. The registry finds no adapter registered under that name. Policy branches here: if a fallback is configured (say, any unrecognized cloud-browser name falls back to a known-good desktop adapter), the registry returns that fallback adapter instead, and the run continues with a logged "used fallback" event; if no fallback is configured, the registry raises a clear, named error ("no adapter registered for 'safari-cloud'") that fails the run loudly and immediately, rather than propagating a confusing downstream AttributeError from calling methods on None. Both branches are DELIBERATE, reviewed policy decisions, not accidents of missing error handling.

Trade-offs and pitfalls. A fallback that's too permissive (falling back for EVERY unknown request) can silently run tests against the wrong environment for weeks before anyone notices results don't mean what they think - the fallback should be an explicit, narrow policy decision (e.g. "any browser variant falls back to desktop-chrome"), never a blanket catch-all that masks genuine misconfiguration.

Recommended format

• Use component-scoped, human-readable kebab + BEM-like pattern:
  • component-name__element--action[--state]
• Examples:

<!-- element -->
<div data-test-id="login-form__email-input"></div>

<!-- action (click/submit) -->
<button data-test-id="login-form__submit--click"></button>

<!-- state -->
<span data-test-id="banner__close--hidden"></span>

Component-level scoping

• Prefix with the owning component to avoid collisions (login-form, user-card).
• Use double underscore for element, double dash for action/state to make intent explicit.

Actions vs elements

• Elements: end with element type (input, label, icon).
• Actions: append action verb (--click, --submit, --open). Keep actions sparse; prefer targeting element and perform action in test code unless the UI exposes an action-only node.

Avoid implementation-detail locators

• Never reference CSS classes, internal structure, or JS hook names.
• Prefer stable semantic names (e.g., submit, cancel, profile-name) over presentation (red-button).
• If element is purely presentational and unstable, add a stable wrapper with test id in markup.

Enforcement in PRs

• Add a linter rule (custom ESLint/TSRule) to validate data-test-id pattern.
• CI check that runs a small script to detect violations and duplicates.
• PR template checklist: "data-test-id added / follows convention".
• Code review guidance and small training doc with examples.
• Add unit/visual tests to catch accidental renames and maintain a registry file for critical global ids.

I would pair these with team training, a short README, and periodic audits to keep the convention consistent.

Direct answer

Write the test to CONSUME an existing LoginPage object: the page object owns the locators and the one login(username, password) action, and the test itself only calls that action and asserts on the outcome, with setup/teardown and parametrized credential sets handled at the test level, not inside the page object.

Structured elaboration

A Page Object is a thin wrapper around ONE page's elements and the actions a user can take on it. The dividing line that matters here: the page object exposes a business-meaningful method (login), never raw selectors leaking into the test, and it does not assert anything itself, since assertions belong to the test, not the page. Parameterizing the credential sets is a separate, orthogonal concern from the page object's design: @pytest.mark.parametrize supplies each credential pair to the same test body, and the page object does not need to know or care how many times it gets called.

For setup/teardown, a real test would create a fresh WebDriver session per test (function-scoped fixture, driver.quit() in teardown) so credential sets do not share browser/session state across parametrized runs, which matters because a leftover cookie or "remember me" state from one credential pair could otherwise mask a login bug on the next.

Worked example

import pytest
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    USERNAME = (By.ID, "username")
    PASSWORD = (By.ID, "password")
    SUBMIT = (By.ID, "login-btn")

    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)

    def login(self, username, password):
        self.wait.until(EC.presence_of_element_located(self.USERNAME)).send_keys(username)
        self.driver.find_element(*self.PASSWORD).send_keys(password)
        self.driver.find_element(*self.SUBMIT).click()

@pytest.fixture
def driver():
    from selenium import webdriver
    d = webdriver.Chrome()          # a real suite: one fresh session per test
    yield d
    d.quit()

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow(driver, username, password):
    driver.get("https://example.com/login")
    page = LoginPage(driver)
    page.login(username, password)

No browser binary is available in this environment, so the page object's CONTROL FLOW (not real browser rendering) was verified separately against a mocked driver, asserting the exact sequence of locator calls LoginPage.login makes for each parametrized credential pair:

from unittest.mock import MagicMock

@pytest.fixture
def driver():
    d = MagicMock()
    d.find_element.return_value = MagicMock()
    return d

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow_mocked(driver, username, password):
    page = LoginPage(driver)
    page.login(username, password)
    assert driver.find_element.call_args_list == [
        ((By.ID, "username"),),
        ((By.ID, "password"),),
        ((By.ID, "login-btn"),),
    ]

$ pytest test_login_pom_mock.py -v
test_login_flow_mocked[user1-pass1] PASSED
test_login_flow_mocked[user2-pass2] PASSED
test_login_flow_mocked[invalid-wrongpass] PASSED
3 passed in 0.16s

This confirms, against the real installed Selenium 4 API (By, WebDriverWait, expected_conditions, not hand-typed from memory), that the page object calls find_element(By.ID, "username") (via the WebDriverWait-guarded lookup), find_element(By.ID, "password"), and find_element(By.ID, "login-btn") for every credential pair, in that order, regardless of which pair is under test. (The webdriver.Chrome()-based driver fixture above is what a real suite would run against a live browser; this mocked version is only for verifying the page object's logic here.)

Trade-offs and pitfalls

The most common mistake is putting the assertion inside the page object (e.g. a login_succeeded() method that itself asserts), which makes the page object opinionated about what "success" means for every caller; a page object should expose state (is the dashboard visible?) and let the TEST decide what that state should be for a given credential pair. A second pitfall is sharing one browser session across all three parametrized credential sets to save setup time: that shortcut trades correctness for speed, since a stale session can hide or fake a login result. Finally, WebDriverWait with a hardcoded 10-second timeout is a reasonable default but should be a configurable constant, not repeated as a magic number across every page object in a real suite.

Direct answer

When legal or compliance flags a possible regulatory problem on something about to ship, that flag is new information, not an attack on the project. The first move is to separate the specific risk from the whole feature: find out exactly what triggers the concern, then look for a way to ship everything outside that blast radius (the specific data, users, or markets the flagged concern actually touches) while the risky piece gets handled properly. Treating the flag as either a full block to fight or a formality to route around are both weak answers; the senior move is to make the freeze as small as the actual risk.

Structured elaboration

1. Turn the flag into a scoped, written finding

Ask for the specific clause or regulation, the specific data flow or behavior it applies to, and which markets or user segments are affected. A flag that sounds like 'this violates a regulation' often narrows down to 'this one data field, in these two markets.' Until that scoping happens, nobody can reason about mitigation, they can only argue about the abstract freeze.

2. Sort what's actually blocked from what's just slow

Once scoped, most flags fall into three buckets: genuinely unsafe to ship anywhere (rare, but real, treat it as a hard stop); unsafe in specific markets or for specific data (the common case, often scoped out with a flag or market-level rule); or unsafe as currently designed but fixable with a smaller change than a full freeze (needs a scoped rework, not a blanket delay).

3. Bring a mitigation, not just a constraint

Offer a concrete option: disable the flagged behavior for the affected markets, gate it behind a feature flag (a toggle that turns a piece of functionality on or off without a new deployment), or ship a version that omits the specific data flow while the rest proceeds. This turns the conversation from 'can we go or not' into 'does this mitigation satisfy the concern,' which moves much faster.

4. Get joint, written sign-off before proceeding

Both the business owner and compliance need to agree in writing on what shipped, what did not, the remaining risk, and who owns closing it. This protects everyone if the interpretation is questioned later and prevents the same argument from recurring next release.

5. If a real freeze can't be avoided, negotiate the timeline explicitly

Sometimes there is no safe scoped path and the freeze has to hold for the affected piece. Here the negotiation shifts to: what's the minimum change needed to clear the concern, who is assigned to it, and can the review be fast-tracked with a dedicated reviewer instead of sitting in a general queue. A freeze with a committed, shrinking timeline is a very different conversation from an open-ended one.

Worked example

A team is about to ship a feature that logs a new field for product analytics, and legal flags that collecting that field may violate a data-protection rule in one region. Scoping the flag shows the issue is narrow: one field, one region. Instead of freezing the whole release, the team ships everywhere else immediately, and for the flagged region ships the same feature with that one field's collection disabled behind a config switch. Legal signs off on the scoped version in writing. The team opens a follow-up item, with an owner and a target date, to redesign how that field is collected (for example, aggregating it instead of storing it per user), so the region isn't stuck without the feature indefinitely.

Trade-offs and pitfalls

• Treating every compliance flag as either a full block or a nuisance to route around is the most common mistake here; both extremes erode trust with the compliance function over time.
• Scoped mitigations (flags, market gating, field exclusions) are good short-term tools but can quietly become permanent if nobody owns the follow-up fix. The sign-off should name an owner and a date, not just describe a workaround.
• Escalating past compliance to force a ship date, without addressing the underlying concern, tends to resurface later as a bigger problem: a real violation or a regulator inquiry. Speed gained by skipping the process rarely survives contact with the risk it was protecting against.
• The strongest signal of seniority isn't how fast the team got to yes, it's whether the final decision is something both sides would still defend the same way months later.

Direct answer

Lead with acknowledgment of why the request matters to them, then give the real reason it's being deprioritized rather than a vague "capacity," and close with something concrete, not just "we'll revisit it," so the message lands as a decision with a next step instead of a dismissal.

Structured elaboration

• Acknowledge specifically. Show you understood the need, not just that you heard a request.
• Give the actual reason. A real tradeoff (what it's being deprioritized in favor of) is more respectful and more credible than a generic "we don't have capacity."
• Don't oversell "later." If you're not confident it's coming back, don't imply it will just to soften the moment, that costs more trust later than the original no.
• Give something concrete now. A specific next step (when it will be reconsidered, what would change its priority) turns a closed door into an open one.

Worked example

A stakeholder had asked for a feature that clearly mattered to their team, and after quarterly planning I had to tell them it wasn't making the cut. I opened by naming the specific customer problem their request solved, so they knew I understood it, not just logged it. I explained directly that we were prioritizing two initiatives tied to a larger revenue and retention risk this quarter, and that was the actual tradeoff, not a vague resourcing excuse. Rather than leaving it there, I said I'd keep it visible on the backlog with a proposed priority score and bring it into the next planning review, and offered a short session to capture details now so it wouldn't need to be re-explained from scratch later.

Trade-offs and pitfalls

Being specific about the tradeoff only works if it's true, inventing a more flattering reason than the real one tends to surface later and costs more trust than the original deprioritization. Offering a "next planning review" is only a real commitment if you follow through and actually raise it, an empty promise to revisit is worse than an honest no. And if the requester keeps pushing past a clear, well-reasoned no, that's a signal to bring in whoever owns the tradeoff decision, your manager or a product lead, rather than re-litigating it yourself repeatedly.

Direct answer

I shipped a change to a signup flow that looked correct in every test environment but broke for users on a specific combination of browser and network condition we hadn't covered, and it was a customer, not our monitoring, who found it first, mid-demo, which made the failure both technical and painfully visible. Working out why it failed meant separating the actual technical root cause from the process gap that let it ship at all, and the fix that stuck was the one that closed the process gap, not just the code.

What happened and how I investigated

The change passed our automated tests and looked fine in manual quality testing, but broke for a subset of users because of an interaction between a caching layer and a redirect that only showed up under a specific, uncommon network condition. It surfaced when a prospective customer hit it during a live demo, which told me something important on its own: our alerting wasn't watching for this failure mode at all, so if the customer hadn't hit it live, it could have persisted undetected. Rather than just fixing the immediate bug, I traced two separate things: the technical root cause, the caching and redirect interaction, and the process gap, which was that our test matrix didn't cover that network condition and our monitoring had no signal that would have caught it in production either.

What I said and to whom, while it was still broken

As soon as I confirmed the cause, I told my manager and the account team handling that customer directly, with the specific technical explanation and an honest estimate of the fix timeline, rather than a vague "we're looking into it." That let the account team manage the customer conversation with real information instead of a placeholder.

What changed as a result

The immediate fix addressed the caching and redirect bug. The change that outlived the incident was adding the specific network condition to our test matrix and adding a monitoring alert for that class of redirect failure, so the next similar bug would be caught by our own systems instead of by a customer mid-demo. I also flagged that our sign-off process treated "tests pass" as equivalent to "ready to ship" with no explicit check for untested conditions, which is a narrower and more honest description of what our tests actually covered.

Trade-offs and pitfalls

The pitfall is stopping at the technical fix and treating the incident as resolved, when the more durable failure was the process gap that let something with an untested condition ship in the first place. A failure caught by monitoring and one caught by a customer can share the identical root cause, but they are different signals about how much your detection is actually covering.

Direct answer
A thorough manual test case for POST /orders needs a unique test ID and description, explicit preconditions (a valid auth token, the product actually in stock), numbered test steps carrying the exact sample request, an expected result that specifies both the HTTP status code and the response body's schema (not just "it works"), a teardown step so the test doesn't leave the system in a state that corrupts the next run, and a set of documented test-data variants covering both the success path and the specific failure modes named in the question: invalid product and insufficient stock.

Structured elaboration and worked example

Trade-offs and pitfalls
The most common wrong turn is writing "expected result: order created successfully" without pinning down the status code and response schema, which makes the test case unautomatable and ambiguous to a second reviewer: does "successfully" mean 200 or 201? does the response need to include the computed total_price, or just echo the request? A second pitfall is skipping teardown for a resource-creating endpoint like this one, on the assumption that a fresh test database will be reset before the next run; that assumption breaks the moment the test suite runs against a shared or long-lived environment (a staging environment, a nightly regression run against a persistent test account), where leftover orders from a failed or skipped teardown accumulate and can silently affect later tests that assume a clean order history for that account.

Direct answer

Validating an application's error handling as an SRE means testing not just that errors are caught, but that the system's response to each class of error (a bad request, a downstream timeout, a hard dependency outage) is the correct, safe behavior at every layer, unit tests for the error-handling logic itself, integration and contract tests for how the application reacts to a real dependency's actual failure modes, and chaos tests for how the whole system behaves under a genuinely injected failure.

Structured elaboration

• Unit tests: verify the error-handling logic in isolation, does a specific invalid input produce the correct, specific error response rather than an unhandled exception or a misleading generic error.
• Integration tests: verify the application's behavior against a real (or realistically simulated) dependency returning actual error conditions, a timeout, a connection refusal, a malformed response, confirming the application handles each distinctly rather than treating all failures identically.
• Contract tests for third-party APIs: verify the application correctly interprets the third-party API's documented error format and status codes, catching a mismatch (the application expecting one error shape while the actual API returns a different one) before it manifests as a real incident.
• Chaos tests: inject an actual failure (kill a dependency, introduce network latency or a partition) into a running system and confirm the observed behavior matches what unit and integration tests predicted in isolation, since a chaos test validates the INTEGRATION of all the individual error-handling pieces under a real, systemic failure condition, which isolated tests cannot fully guarantee on their own.

Worked example

For an application that calls a third-party payment API: a unit test confirms that a locally-raised validation error (an invalid amount) returns a specific, correct 400-style response to the caller. An integration test against a sandboxed version of the payment API confirms that when the sandbox returns a simulated timeout, the application retries according to its documented policy and eventually returns a specific, correct error to the user rather than hanging indefinitely. A contract test confirms the application correctly parses the payment API's actual documented error response shape, catching a case where the application's error-handling code assumed a slightly different field name than the API actually returns. A chaos test, run periodically in a controlled environment, actually blocks network access to the payment API for a defined window and confirms the application surfaces the same correct, user-facing error and does not, for instance, silently hang or return an incorrect success response, validating end to end that the pieces tested individually above actually work together under a real failure.

Automating this in a CI/CD pipeline: unit and integration tests run on every commit, since they are fast; contract tests run on every commit against a maintained mock reflecting the third-party API's documented contract, with a separate, less frequent (nightly or weekly) run against the real sandboxed API to catch contract drift; chaos tests run on a scheduled cadence (for example weekly) in a dedicated environment rather than per-commit, since they are more expensive and disruptive to run constantly, with results reported to the team and any regression treated as a release-blocking finding.

Trade-offs and pitfalls

The most common gap is testing error handling only at the unit level and assuming that guarantees correct behavior under a real, systemic failure, when the actual integration between error-handling logic, retry policy, and dependency behavior can behave differently than any individual piece suggests in isolation. The second pitfall is letting the contract-test mock drift from the real third-party API's actual current behavior without a periodic real-sandbox check, which silently invalidates the confidence the contract tests were supposed to provide.