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

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
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.

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

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.

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. 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.

Root-cause analysis (first 2 weeks)

• Gather data: collect CI run logs, failure flakes, timestamps, affected tests, branches, env metadata.
• Triage sample failures: reproduce locally/CI with debug flags, capture screenshots, network traces, DB state.
• Categorize causes: timing/race conditions, environment instability (containers, DB), test-data coupling, order-dependency, external service flakiness, assertions that are too strict.
• Run targeted reruns (n=10) per failing test to measure flakiness distribution.

Prioritize fixes

• Severity × frequency matrix: prioritize tests that fail most often and block merges or rollbacks.
• Quick wins first: flaky tests due to timeouts, waits, or test-data setup. Medium: infra fixes. Long: design changes (decoupling, better harness).

Short-term mitigations (0–4 weeks)

• Reduce noise: quarantining/marking high-flake tests as flaky (with tracking) so they don’t gate merges.
• Increase CI retries with jitter for non-blocking suites and add verbose logging on retry.
• Stabilize environment: pin base images, increase resource limits, use stable test DB snapshots.
• Improve timeouts: replace fixed sleeps with explicit waits/health checks.

Long-term improvements (1–6 months)

• Invest in deterministic test design: idempotent test data builders, explicit cleanup, avoid shared state.
• Add contract/mocked external services for integration points; use service virtualization.
• Introduce test isolation: run tests in parallel-safe sandboxes, container-per-test where feasible.
• Strengthen CI observability: structured logs, flaky-test dashboard, historical trends.
• Enforce test-quality gates: flakiness budget, review checklist for new tests.

Metrics to track (weekly, 6-month targets)

• Flaky-failure rate (%) per run — target: from 20% → <2% in 6 months.
• Number of rollbacks per month — target: reduce by 90%.
• Mean time to detect flaky test (hours).
• Number of quarantined tests and their resolution rate.
• Test suite runtime and CI success rate.
• Percentage of tests with deterministic setup/teardown.

Regularly review metrics with dev teams, iterate priorities, and convert quarantined tests into permanent fixes.

Direct answer

For a payment-processing integration test, I'd choose a database snapshot restored into an isolated per-run instance over purely seeded/generated data, because payment logic tends to depend on real-world edge cases (specific currency rounding behavior, historical transaction states, unusual customer records) that a hand-written seed script is unlikely to reproduce faithfully, and I'd use real containerized dependency services rather than mocks for anything actually processing money, reserving mocks only for a genuinely external third-party payment gateway.

Structured elaboration

Reasoning through the trade-offs for this specific case:

• Database snapshots vs seeded data: payment logic is exactly the kind of domain where subtle edge cases (a transaction that was partially refunded, a currency with unusual rounding rules, a customer record with an unusual history) matter, and those are hard to anticipate and hand-write into a seed script. A masked snapshot of real (anonymized) transaction history captures edge cases a seed script would have to be told to include explicitly.
• Containerized dependency services vs mocks: for the parts of the system actually doing the financial computation (ledger updates, balance calculations), real containerized services exercise the real logic and real database constraints; mocking those would hide exactly the class of bug (an off-by-one in balance math, a constraint violation) this test exists to catch. A genuinely external dependency, like the actual card-network gateway, is the right place to mock or use a sandbox, since you don't control it and don't want its availability to determine your test's pass/fail.
• Network isolation and secrets handling: given the sensitivity of payment data, the isolated environment needs network policies preventing any accidental call to a real external payment processor, and any test credentials must be clearly scoped to the sandbox/test environment, never real provider credentials.
• Repeatability: a snapshot-based approach needs a defined refresh cadence (the snapshot goes stale as the schema evolves) and a masking/anonymization step applied consistently, so repeatability doesn't silently degrade as production data shape changes.

Worked example

The test environment restores an anonymized snapshot of transaction data into a freshly provisioned, isolated Postgres instance per test run; the actual ledger and balance-calculation services run as real containers against that data; calls to the card network are routed to the provider's official sandbox endpoint rather than a hand-rolled mock, since a real (if externally-hosted) sandbox is more likely to catch a genuine integration mismatch than an internally maintained mock that can drift from the real API's behavior.

Trade-offs & pitfalls

The failure mode to watch for is the anonymization step being incomplete or inconsistently applied as the schema evolves, which is both a compliance risk and a correctness risk (masked-but-not-quite-right data can silently change the very edge cases the snapshot was meant to preserve); a validated, versioned masking pipeline, not an ad hoc script, is what keeps this approach trustworthy over time.