SDET Coding Interview Questions FAANG Style (2026)

TL;DR

FAANG-style SDET interviews combine data structures, production-quality coding, test automation, APIs, SQL, concurrency, debugging, and test-system design. Strong candidates write correct code while explaining testability, failure modes, complexity, and operational trade-offs.

Key Takeaways

• Expect algorithms plus testing judgment, not LeetCode performance alone.
• State assumptions, derive edge cases, and explain complexity before polishing code.
• Use deterministic waits, isolated data, observable failures, and stable contracts in automation answers.
• Connect every implementation choice to reliability, diagnosability, or execution cost.
• Practice coding aloud under a timer and verify solutions with boundary-focused examples.
• Treat debugging and test-system design as engineering problems with measurable trade-offs.

SDET coding interview questions FAANG style assess more than whether you can finish an algorithm. Interviewers want evidence that you can write maintainable code, expose risk, diagnose failures, and design reliable test systems at scale.

Use this guide as a spoken practice set. For each question, clarify the contract, name edge cases, outline the approach, implement it, and test it aloud. If you need a broader preparation sequence first, follow the SDET roadmap, then use the /practice workspace for timed repetition.

TL;DR

These questions resemble the breadth of a software development engineer in test interview. They do not predict any specific employer's private question bank.

1. SDET Coding Interview Questions FAANG Style: Arrays and Strings

Q: How would you find the first non-repeating character in a string?

Count Unicode code points in insertion order, then return the first with a count of one. In Java, a LinkedHashMap<Integer, Integer> preserves encounter order and avoids breaking supplementary characters into separate char values. The algorithm uses O(n) time and O(k) space, where k is the number of distinct code points; test empty input, repeated emoji, and a unique character at the final position.

Q: Given test execution durations, how do you find the two tests whose total is closest to a target shard time?

Sort pairs of duration and original test ID, then move two pointers inward based on whether the current sum is below or above the target. Preserve IDs because sorting raw durations loses the identity needed by the scheduler. This costs O(n log n), handles duplicate durations, and should define a deterministic tie rule such as lexicographically smaller IDs.

Q: How do you remove duplicate test IDs while preserving order?

Insert each ID into a LinkedHashSet, which combines uniqueness with encounter order, then copy the set to a list. Decide whether IDs are case-sensitive and whether null is legal before coding because those choices change expected output. The operation is O(n) expected time and is clearer than repeatedly calling List.contains, which degrades to O(n squared).

Q: How would you validate balanced brackets in a generated JSON-like expression?

Push opening delimiters onto a stack and require every closing delimiter to match the top. Reject a close when the stack is empty and reject the full expression if openings remain after the scan. This is O(n) time and O(n) worst-case space; if quoted strings are allowed, add parser state so brackets inside escaped string content are ignored.

Q: How do you find the longest run of identical test statuses?

Scan once while tracking the current status, current length, best start, and best length. Update the best only when the current run becomes longer, which naturally keeps the earliest run on ties. A good test set includes no statuses, one status, all identical values, alternating values, and two equal maximum runs.

Q: How would you compare two version strings such as 4.10.0 and 4.9?

Split on dots, parse each numeric component, and compare corresponding components while treating missing trailing components as zero. Do not compare the original strings lexicographically because 10 sorts before 9 as text. Validate malformed input explicitly, and use arbitrary-size integers if the contract does not cap component length.

2. Hash Maps, Stacks, Queues, and Trees

Q: When would you use a hash map instead of a sorted map in test infrastructure?

Choose a hash map for expected O(1) key lookup when iteration order and range queries do not matter, such as resolving fixture IDs. Choose a tree-based sorted map when you need ordered traversal, floor or ceiling lookup, or deterministic range selection. Mention that collision behavior, memory overhead, and thread safety are separate concerns from asymptotic lookup.

Q: Design an LRU cache for authentication tokens.

Combine a hash map with a doubly linked list so lookup, promotion, insertion, and eviction are O(1). Store the most recently used node at the head and evict the tail when capacity is exceeded, but never serve a token past its expiry merely because it is recent. Production code also needs synchronization or a concurrent cache library, metrics for misses, and a capacity-zero test.

Q: How would you model a queue of test jobs with priorities?

Use a priority queue ordered first by severity or business priority and then by an increasing sequence number for FIFO behavior within a priority. A comparator must be consistent and avoid subtracting integers because subtraction can overflow. Test equal priorities, empty polling, requeued jobs, and starvation policy for continuously arriving high-priority work.

Q: How do you detect a cycle in a dependency graph of tests?

Run depth-first search with three states: unvisited, visiting, and complete. Reaching a visiting node identifies a back edge and therefore a cycle; retain parent links if the caller needs the actual cycle path. The cost is O(V + E), and disconnected components require starting DFS from every unvisited vertex.

Q: How would you serialize a binary tree for a reproducible fixture?

Use preorder traversal with an explicit null marker, or level-order traversal if human readability is more important. Values need escaping or length-prefixing so separators inside data cannot corrupt decoding. Verify round-trip equality on empty, skewed, duplicate-valued, and sparse trees rather than comparing only a happy-path string.

Q: Find the lowest common ancestor of two nodes in a binary search tree.

Starting at the root, move left when both target values are smaller and right when both are larger; otherwise the current node is the split point. This takes O(h) time and O(1) iterative space, where h is tree height. Clarify whether both values are guaranteed to exist, because otherwise membership checks are required before returning an ancestor.

3. Sorting, Searching, and Complexity

Q: Search a sorted array containing duplicate response times for the first target occurrence.

Use binary search but record a match and continue into the left half instead of returning immediately. The result remains O(log n), unlike scanning backward after an arbitrary match, which can become O(n). Test a missing target, all-equal input, the first index, and the last distinct value.

Q: How would you merge overlapping maintenance windows?

Sort intervals by start time, then append a new interval only when it begins after the current merged end; otherwise extend that end. Define whether touching windows such as [1,2] and [2,3] overlap, since open and closed interval semantics differ. Sorting dominates at O(n log n), and the output requires O(n) space in the worst case.

Q: How do you select the kth slowest test without sorting every duration?

Maintain a min-heap of size k while scanning durations, removing the smallest whenever the heap grows beyond k. The heap root is then the kth largest duration, with O(n log k) time and O(k) space. Reject invalid k values, and retain test IDs alongside durations if duplicates must be distinguishable.

Q: Explain when O(n squared) code is acceptable in an SDET solution.

It can be reasonable for a bounded input, a clearer oracle, or a small offline dataset where implementation risk matters more than runtime. State the actual bound and estimate operations instead of defending complexity abstractly. For example, pairwise comparison of 30 screenshots is 435 comparisons, while the same approach over a million events is inappropriate.

Q: How would you sort semantic test priorities such as P0, P1, P2, and unknown?

Map recognized labels to explicit ranks and assign unknown values a documented fallback rank. A lookup table is safer than relying on lexical order or fragile substring parsing. Make the sort stable so two P1 tests keep their original scheduling order, and test lowercase or whitespace according to the normalization contract.

Q: What is the difference between stable and unstable sorting for test results?

A stable sort preserves the relative order of records that compare equal, which matters when an earlier ordering already encoded timestamp or suite order. An unstable sort may arbitrarily rearrange equal-status results and make reports look inconsistent. If reproducibility matters, use a stable implementation or add a unique tie-breaker rather than assuming library behavior.

4. Test Automation Coding Interview Questions

Q: Write a reliable Playwright assertion for a save operation.

Wait on an observable product outcome, not a fixed delay: trigger Save and assert the success message or persisted value with Playwright's auto-retrying locator assertion. If the response contract is important, begin page.waitForResponse before the click and await both operations. Keep selectors user-facing where possible, and inspect the response only when it adds evidence beyond the UI state.

import { test, expect } from '@playwright/test';

test('saves profile', async ({ page }) => {
  await page.goto('/profile');
  await page.getByLabel('Display name').fill('Ada Tester');
  const saved = page.waitForResponse(r =>
    r.url().endsWith('/api/profile') && r.request().method() === 'PUT'
  );
  await page.getByRole('button', { name: 'Save' }).click();
  expect((await saved).ok()).toBeTruthy();
  await expect(page.getByText('Profile saved')).toBeVisible();
});

Q: How do you eliminate a flaky wait from a Selenium test?

Replace Thread.sleep with a wait tied to the exact state required by the next action, such as visibility, clickability, URL change, or a domain-specific condition. Keep implicit waits low or disabled when explicit waits are used so timeout behavior stays understandable. Capture the DOM, screenshot, browser logs, and elapsed condition on timeout to distinguish a slow product from a wrong locator.

Q: What belongs in a page object?

Put locators and cohesive user interactions behind intent-revealing methods such as checkoutWith, while assertions about the test's business outcome usually remain in the test or a dedicated assertion layer. Avoid a giant page object that exposes every element and duplicates application structure. Return meaningful domain data when an interaction produces it, and do not hide unconditional sleeps or broad exception handling inside helpers.

Q: How would you test file download behavior?

Start listening for the download event before clicking, save the artifact to an isolated temporary path, and validate both suggested filename and content. For a CSV, parse rows and assert required headers and representative values instead of checking only file existence. Clean up through the runner's temporary directory lifecycle and include empty, unauthorized, and large-export cases.

Q: How should test data be generated for parallel browser tests?

Create unique data per worker or test using a run ID plus worker ID, and provision it through an API or fixture rather than a slow UI flow. Track created resources so teardown is idempotent even after partial failure. Random data without a logged seed harms reproduction, while shared named accounts create races and order dependence.

Q: How do you test a date picker without making the test fail tomorrow?

Inject or control the clock when the application supports it, then choose a date relative to that fixed instant. Assert the submitted ISO value and the visible localized label separately because display and transport have different risks. Cover month boundaries, leap day, disabled dates, timezone transitions, and keyboard operation rather than hard-coding a date that eventually becomes invalid.

For deeper framework practice, compare the Playwright TypeScript framework tutorial with the Selenium Java framework tutorial.

5. API and Contract Coding Questions

Q: How would you test an idempotent payment endpoint?

Send the same valid request twice with one idempotency key and verify that the second response refers to the original operation without duplicating the charge. Repeat with concurrent identical requests because sequential behavior alone misses races. Also test key reuse with a different payload, expiry behavior according to the contract, and persistence across a service restart; the API idempotency testing guide expands this matrix.

Q: Write a small validator for an HTTP success response.

Validate the intended status set, media type, required schema fields, and business invariants rather than treating any 2xx as equivalent. A 204 response must not be parsed as JSON, and a 202 may require polling rather than asserting completed work. Error messages should include method, sanitized URL, correlation ID, status, and a bounded body excerpt for diagnosis.

Q: How do you test cursor pagination?

Traverse pages until the next cursor is absent while recording item IDs and every cursor seen. Assert no duplicate items, no repeated cursor, page-size limits, stable ordering, and termination. Add mutations between page requests to verify the documented consistency model, because offset-style assumptions may not hold for cursor pagination.

Q: What negative tests belong around bearer-token authentication?

Cover missing, malformed, expired, revoked, wrong-audience, wrong-issuer, and insufficient-scope tokens. Verify status codes and authorization headers without logging token contents, and confirm a valid token for one tenant cannot access another tenant's object. Distinguish authentication failure from resource hiding rules, since some systems deliberately return 404 instead of 403.

Q: How would you validate backward compatibility of an API?

Compare the new schema to the published contract and flag removed fields, newly required inputs, narrowed enums, or changed types. Run consumer contract tests against the candidate build and replay representative sanitized requests where policy permits. Additive fields are usually compatible for tolerant clients, but generated clients or strict deserializers make that an assumption worth testing.

Q: How do you test retry behavior without waiting through real delays?

Inject a fake clock or configurable backoff and use a stub server that fails a known number of calls before succeeding. Assert attempt count, delay sequence, jitter bounds, retryable status classification, and final error propagation. Ensure unsafe operations are retried only when idempotency protection exists, and verify cancellation stops pending retries.

6. SQL and Data Validation

Q: Find duplicate active users by normalized email.

Normalize according to the application's documented rule, then group active rows and retain groups with more than one member. Do not silently assume every provider treats dots or plus suffixes identically. The following PostgreSQL query handles case and surrounding whitespace only, which keeps the rule explicit.

SELECT lower(trim(email)) AS normalized_email, count(*) AS duplicate_count
FROM users
WHERE status = 'active'
GROUP BY lower(trim(email))
HAVING count(*) > 1
ORDER BY duplicate_count DESC, normalized_email;

Q: How would you verify an ETL row-count reconciliation?

Compare counts at each filter and transformation boundary, not only source total against target total. Separate inserted, updated, rejected, deduplicated, and intentionally filtered records so the conservation equation is auditable. Then sample keys across each category and validate aggregates because equal row counts can still hide incorrect contents.

Q: Explain the risk of using NOT IN with nullable data.

If the subquery returns null, SQL's three-valued logic can make every comparison unknown and unexpectedly return no rows. Prefer NOT EXISTS with a correlated predicate when expressing anti-joins. Demonstrate the behavior with a null-containing fixture and confirm the query plan on production-scale shapes.

Q: How do you find the latest test result for each test case?

Use row_number() over partitions by test-case ID ordered by execution time descending, with a unique result ID as a deterministic tie-breaker. Filter the ranked rows to one in an outer query. An index beginning with test-case ID and execution time can help, but verify it using the database's plan output rather than asserting it blindly.

Q: What transaction-isolation test would you write for seat reservation?

Run two transactions that attempt to reserve the last seat and coordinate them at the read-write boundary. Assert exactly one commit succeeds or exactly one reservation exists, depending on the documented locking strategy. Repeat enough times to expose timing-sensitive faults, record transaction IDs, and clean the fixture between runs.

Q: How would you test a database migration safely?

Apply it to a production-shaped copy, verify schema and data invariants, then run both the old and new application versions if a rolling deployment is expected. Measure locks and duration on representative volume, and test restart after interruption when the migration tool supports it. A rollback plan may be a forward repair for destructive changes, so define recovery rather than promising an impossible reversal.

Build more query fluency with SQL coding interview questions for testers.

7. Concurrency and Asynchronous Systems

Q: What is a race condition in a test runner?

A race occurs when correctness depends on nondeterministic ordering of concurrent operations, such as workers updating one shared report file. Reproduce it by controlling barriers around the vulnerable operations instead of hoping repeated runs collide. Fix ownership or synchronization in the production path, then keep a deterministic regression test that proves both interleavings are safe.

Q: How would you make a shared counter thread-safe in Java?

Use AtomicLong for independent increments and reads, or a lock when the counter participates in a larger invariant with other state. volatile only provides visibility and ordering guarantees; it does not make read-modify-write increment atomic. Test with synchronized worker start, await completion, and assert the exact total rather than sleeping for threads to finish.

Q: How do you test an asynchronous job API?

Assert that submission returns the documented accepted status and job identifier, then poll a status endpoint with a bounded deadline and backoff. Validate allowed state transitions, terminal success output, terminal error detail, cancellation, and an unknown job ID. Separate service timeout from test-runner timeout so a failure explains which budget expired.

Q: How would you verify at-least-once message processing?

Publish messages with stable IDs, deliberately trigger redelivery, and assert the consumer's externally visible effect is idempotent. Inspect acknowledgments, retry count, dead-letter routing, and ordering only to the degree guaranteed by the broker contract. A processed-message table is useful evidence, but the decisive assertion belongs on the business state.

Q: Why can parallel tests pass individually but fail as a suite?

They may share accounts, ports, files, rate limits, mutable feature flags, or cleanup routines that delete another test's data. Correlate failures with worker IDs and resource names, then rerun with controlled sharding to locate the collision. The durable fix assigns resource ownership and unique namespaces; serial execution only masks the coupling.

8. Debugging and Failure Analysis

Q: A UI test times out only in CI. What do you inspect first?

Compare artifacts from CI and local runs: trace, screenshot, DOM, console, network, runner load, viewport, locale, timezone, and environment configuration. Identify the last confirmed event and the first missing event to narrow the fault boundary. Reproduce with the CI container and settings before increasing a timeout, because more waiting does not correct a blocked request or hidden element.

Q: An API test intermittently receives 409. How do you investigate?

Capture the sanitized request identity, idempotency key, resource version, correlation ID, and competing operations around the same record. Determine whether 409 is an expected optimistic-lock or uniqueness response, then inspect whether test data is shared or cleanup overlaps execution. A retry is valid only if the contract identifies the conflict as transient and the operation remains safe.

Q: How do you distinguish a product defect from a test defect?

Reduce the failure to independent evidence such as an HTTP call, database invariant, or manual interaction using the same inputs. Compare behavior with the approved requirement and verify the test's preconditions, oracle, selectors, and environment. Classification follows evidence: a wrong expectation is a test defect, while reproducible contract violation outside the harness is a product defect.

Q: A test passes when debugging but fails at full speed. What does that suggest?

The debugger changes timing, which points toward missing synchronization, an application race, premature cleanup, or an unawaited asynchronous operation. Instrument state transitions and replace timing guesses with explicit completion signals. Avoid retaining the slower execution as a fix because it preserves the underlying nondeterminism.

Q: How would you debug a memory increase during a long test run?

First distinguish bounded caching from an unbounded leak by charting heap after repeated garbage-collection cycles. Compare heap dumps or allocation profiles at controlled checkpoints and group retained objects by reference path. Check whether pages, drivers, listeners, screenshots, response bodies, or report nodes survive teardown, then verify the fix with the same workload and memory ceiling.

The flaky test debugging guide provides a reusable evidence checklist.

9. Test-System Design and Quality Strategy

Q: Design a test execution service for thousands of tests.

Separate scheduling, worker leasing, execution, artifact storage, and result aggregation so each component can scale independently. Give every attempt an immutable ID, use renewable leases to recover abandoned work, and make result writes idempotent. Discuss prioritization, environment capacity, quarantine, cancellation, security boundaries, and metrics such as queue delay, runtime percentiles, infrastructure errors, and rerun yield.

Q: How would you reduce a two-hour regression suite?

Measure duration, critical-path dependencies, failure yield, and resource saturation before choosing a remedy. Parallelize isolated tests, move setup to APIs, remove redundant coverage, split slow system scenarios into lower-level checks, and use risk-based selection for pull requests while retaining scheduled broad coverage. Guard against speed gains that increase flakiness or create blind spots by tracking escaped defects and selected-test recall.

Q: What should a flaky-test quarantine system do?

It should identify candidates from repeated evidence, preserve visibility, assign ownership, set an expiry, and prevent known noise from blocking unrelated changes under an explicit policy. Quarantine cannot mean deletion from reports or permanent reruns until green. Track recurrence, age, affected branches, failure signatures, and whether the test still detects real product defects.

Q: How would you choose between UI, API, and unit coverage?

Place most deterministic logic checks near the code, exercise service contracts and integrations at the API layer, and reserve UI tests for critical journeys and browser-specific behavior. The choice depends on the failure being detected, not a fixed pyramid quota. Optimize for useful feedback per maintenance cost while ensuring cross-layer risks such as wiring, accessibility, and deployment remain covered.

Q: Design observability for a test platform.

Emit structured events with run, shard, worker, test, attempt, environment, commit, and correlation identifiers. Combine metrics for throughput and latency with logs for detail and traces across scheduler, worker, application, and dependency calls. Protect secrets and personal data, define retention tiers for large artifacts, and make dashboards answer whether a failure came from product, test, or infrastructure.

10. How Interviewers Grade SDET Coding Interview Questions FAANG Style Answers

Interviewers usually grade the path as well as the final code. They listen for requirement clarification, a workable baseline, correct invariants, suitable data structures, complexity analysis, meaningful tests, and calm response to hints. In an SDET loop, they also look for maintainability and whether your solution produces diagnostic evidence when it fails.

Q: What should you say before writing code?

Restate the contract, ask about input bounds and invalid values, and work one example that exposes ambiguity. Then propose a straightforward approach and name its complexity before optimizing. This gives the interviewer a chance to correct assumptions without wasting implementation time.

Q: How should you respond when the interviewer points out a bug?

Acknowledge the counterexample, trace it through your invariant, and identify the smallest correction. Re-run earlier examples plus a new regression case so the patch does not merely move the defect. Treat the hint as collaboration; recovery quality is itself an engineering signal.

Q: How many test cases should you discuss for an algorithm?

Choose cases by category rather than chasing a number: empty or minimum input, ordinary input, duplicates, boundaries, invalid input, and a worst-shape case for complexity. Add a domain-specific failure such as Unicode, overflow, or concurrency when relevant. Explain why each case can reveal a distinct defect.

Q: Should you optimize immediately?

Begin with the simplest correct approach when it helps expose the invariant, but state if it cannot meet the given bound. Improve it deliberately by identifying the repeated work or expensive operation and replacing it with a suitable structure. Preserve a small reference implementation as an oracle during discussion when that makes verification easier.

Q: What if you do not remember a library method?

State the operation you need and use a small helper with clear semantics rather than inventing an API. Interviewers generally care more about sound reasoning than exact memorization, unless the role explicitly tests framework fluency. Keep the helper's behavior testable and return to the main problem promptly.

Common Mistakes

• Coding before defining whether input can be null, empty, duplicated, malformed, or extremely large.
• Giving complexity for only one operation while ignoring sorting, copying, recursion depth, or output space.
• Writing automation that waits for time instead of waiting for observable state.
• Treating retries as a universal cure without checking idempotency or preserving the first failure.
• Building page objects that hide assertions, sleeps, and broad exception suppression.
• Using random test data without recording a seed or owning cleanup.
• Claiming full coverage from line percentage while ignoring behavior, risk, and production topology.
• Debugging from intuition alone when traces, logs, request IDs, and minimal reproduction can isolate the boundary.
• Naming a tool without explaining why its guarantees match the system constraint.
• Finishing code without walking through a counterexample and a boundary case.

Before an interview, upload your resume to the QAJobFit resume workspace and make sure the engineering examples you discuss match claims in your experience section.

Conclusion

SDET coding interview questions FAANG style reward a blend of software construction and quality engineering. Practice algorithms, but also practice explaining synchronization, isolation, contracts, observability, and risk because those details separate a test engineer who writes scripts from an SDET who builds dependable systems.

Pick five questions from different sections, solve them aloud in 45 minutes, and review the recording for unclear assumptions and untested branches. Repeat with a new set until your explanation remains structured under pressure.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• SDET Coding Interview Questions for Testers (2026)
• Top 30 SDET Interview Questions and Answers (2026)
• Cloudflare QA and SDET Interview Questions (2026)
• Coinbase QA and SDET Interview Questions (2026)
• Databricks QA and SDET Interview Questions (2026)
• Datadog QA and SDET Interview Questions (2026)