SDET Coding Interview Questions for Testers (2026)

TL;DR

SDET coding interviews reward correct, readable problem solving plus a tester's verification discipline. Master core data structures, parsing, state, SQL, and async behavior, then practice clarifying assumptions, coding a simple solution, testing edge cases, and explaining tradeoffs aloud.

Key Takeaways

• Treat every coding prompt as a contract clarification, implementation, verification, and communication exercise.
• Prioritize strings, arrays, maps, sets, stacks, queues, intervals, parsing, trees, and practical asynchronous behavior.
• Choose data structures from required operations and constraints, then state time and space complexity precisely.
• Write normal, boundary, adversarial, and regression checks before calling a solution complete.
• Connect algorithms to logs, payloads, retries, event streams, test data, selectors, and framework utilities.
• Prefer pure functions and explicit dependencies because deterministic code is easier to test and explain.
• Practice in the language allowed for the target role and compile or run every solution under interview-like limits.

SDET coding interview questions testers receive are designed to reveal two related skills: can you write maintainable software, and can you prove that it behaves correctly? A strong solution clarifies the contract, chooses a suitable data structure, handles invalid and boundary input, runs verification cases, states complexity, and connects the technique to real automation work.

This guide is language-aware but not language-exclusive. Runnable examples use the Python standard library so you can practice without a framework setup. If the job requires Java, JavaScript, TypeScript, C#, or another language, implement the same patterns there and learn its collection, error, concurrency, and testing idioms. Do not switch languages merely because one example looks shorter.

TL;DR

Use the loop clarify -> example -> algorithm -> code -> verify -> complexity -> follow-up. Repeat it until it feels natural under a timer.

1. What SDET coding interview questions testers actually measure

Most SDET coding rounds are not competitive-programming contests. Interviewers often want to know whether you can build framework utilities, reason about service data, debug automation, and collaborate through code. A problem about character counts may reveal how you handle input contracts, naming, data structures, tests, and complexity.

Start by restating the prompt. Ask whether comparison is case-sensitive, whether order matters, what happens with None or null, whether duplicates are meaningful, how large input can be, and whether mutation is allowed. Ask only questions that affect the design. If the interviewer leaves a choice open, state your assumption and proceed.

Use a small example before coding. For "find duplicate IDs," write a normal list, no-duplicate list, empty list, and repeated duplicate. This exposes whether output should preserve first-seen order and whether each duplicate appears once or multiple times. It also gives you immediate verification input.

Prefer the simplest approach that meets constraints. A clear O(n) map solution is usually better than a compact expression you cannot explain. Brute force can be a reasonable starting point when you state its cost and then improve it. Do not optimize without knowing the scale or required operations.

Finally, narrate without reading every keystroke. Explain decisions, call out a discovered error, fix it, and run tests. Interviewers do not require flawless first-pass typing. They do require evidence that you can reason and recover.

2. Build a focused preparation map

Organize practice by patterns, not by memorized company questions. The same map or queue idea appears in logs, API payloads, browser events, and algorithm prompts. A focused sequence creates transfer.

Spend more time on implementation and explanation than passive reading. For each pattern, solve one easy and two medium exercises, then adapt one to a testing use case. Revisit the same problem after several days without looking at the prior answer.

If your target stack is Java, use the Java coding interview questions for testers guide for collections, streams, exceptions, and concurrency idioms. For JavaScript or TypeScript roles, review async and await in tests and practice promise error handling rather than only array puzzles.

3. Strings, arrays, and two-pointer reasoning

String questions often hide contract decisions. Is a string a sequence of bytes, code points, or user-perceived characters? Should punctuation, case, and whitespace matter? A tester should surface these assumptions. In many interviews, the expected scope is simple ASCII or language-native iteration, but say so.

Practice reversal, palindrome checks, first unique character, frequency counts, longest common prefix, substring windows, tokenization, and normalization. For arrays, practice compaction, pair sums, sliding windows, rotation, missing values, and comparison. Two pointers are useful when the input is sorted or when scanning from both ends avoids extra storage. Do not use the pattern if it makes the code less clear.

A practical exercise is to normalize an error message into a stable signature. Dynamic request IDs and extra whitespace can make equivalent failures look different. The contract matters because excessive normalization can collapse distinct defects.

import re


def error_signature(message: str) -> str:
    if not isinstance(message, str):
        raise TypeError("message must be a string")
    without_ids = re.sub(r"request_id=[A-Za-z0-9-]+", "request_id=<id>", message)
    return " ".join(without_ids.lower().split())


def test_error_signature() -> None:
    first = "Timeout  request_id=abc-123  while reading"
    second = "TIMEOUT request_id=xyz-999 while reading"
    assert error_signature(first) == error_signature(second)
    assert error_signature(" permission denied ") == "permission denied"


if __name__ == "__main__":
    test_error_signature()
    print("signature checks passed")

This runs in O(n) time relative to message length and returns a new string. Follow-ups include Unicode case normalization, multiple identifier formats, redaction, and preserving meaningful numbers such as status codes. Explain that regex patterns should come from known log contracts, not a broad guess that hides defects.

4. Maps, sets, counting, and reconciliation

Maps answer "how many" or "which value belongs to this key." Sets answer "have I seen this" or "what is the unique membership." Practice frequency maps, duplicate detection, grouping, intersections, anagrams, first unique items, and joining records by ID.

Choose the variant deliberately. A regular dictionary preserves insertion order in current Python, but an interview in another language may require a linked map. A set loses duplicates and often order. A multiset or counter retains counts. If the output must explain every occurrence, converting to a set too early destroys evidence.

Reconciliation is an SDET-rich application. Suppose an API returns order IDs and the database contains persisted records. Compute missing in database, unexpected in database, and duplicates within each source. Do not compare only counts because equal totals can hide different members.

from collections import Counter


def reconcile(expected: list[str], actual: list[str]) -> dict[str, list[str]]:
    expected_counts = Counter(expected)
    actual_counts = Counter(actual)
    return {
        "missing": sorted((expected_counts - actual_counts).elements()),
        "unexpected": sorted((actual_counts - expected_counts).elements()),
        "duplicate_expected": sorted(
            key for key, count in expected_counts.items() if count > 1
        ),
        "duplicate_actual": sorted(
            key for key, count in actual_counts.items() if count > 1
        ),
    }


def test_reconcile() -> None:
    result = reconcile(["a", "b", "b", "c"], ["a", "b", "d", "d"])
    assert result == {
        "missing": ["b", "c"],
        "unexpected": ["d", "d"],
        "duplicate_expected": ["b"],
        "duplicate_actual": ["d"],
    }


if __name__ == "__main__":
    test_reconcile()
    print("reconciliation checks passed")

The expected time is O(n + m + k log k) here because results are sorted, and space is O(n + m) in the worst case. Ask whether deterministic output order is required. If not, sorting can be removed.

5. Stacks, queues, intervals, trees, and graphs

A stack matches nested structure and last-in-first-out work. Practice balanced brackets, expression validation, path normalization, and undo-like state. Improve a boolean bracket checker by returning the invalid position and expected token. Test empty input, wrong closer, missing closer, unrelated characters, and deep nesting.

A queue supports first-in-first-out processing and breadth-first search. Practice level-order tree traversal, shortest unweighted path, and bounded job queues. In test infrastructure, queue questions lead naturally to fairness, capacity, cancellation, poison jobs, and retry policy. State whether enqueue and dequeue need thread safety.

Intervals appear in test scheduling, availability, traces, and outage reports. Clarify whether intervals are closed, open, or half-open. For half-open intervals [start, end), [1, 3) and [3, 5) do not overlap, although a business rule may still choose to merge adjacent windows. Sort by start, then extend the last merged interval when overlap is detected.

Trees model DOM or comment structure. Graphs model service dependencies, workflow states, and test prerequisites. Practice depth-first and breadth-first traversal, cycle detection, reachable nodes, and topological ordering. Always track visited nodes in a graph that can cycle. Recursive solutions can overflow on deep input, so discuss an iterative option when scale matters.

For an automation scenario, imagine selecting all services affected by a dependency failure. Graph traversal finds reachability, but the result alone does not prove impact. Edge type, fallback, cache, and runtime state matter. This is an excellent moment to distinguish the algorithm's contract from a production conclusion.

6. Parsing structured input and designing test data

Parsing questions are common because SDETs consume JSON, CSV, XML, logs, environment variables, and command output. A reliable parser validates types, required fields, optional defaults, unknown values, encoding, size, and error context. It does not silently convert every malformed record into an empty object.

Use a two-step design: parse syntax, then validate domain semantics. Valid JSON can still contain a negative quantity, unknown status, duplicate identifier, or timestamp in the wrong relationship. Keep these failures distinguishable so diagnostics are useful.

Practice transforming a list of API records into a map by ID. Ask what should happen with duplicate IDs. Last-write-wins is easy but can hide corruption. Rejecting duplicates or collecting all versions may be better. Test missing ID, null, wrong type, unknown field, empty collection, maximum size, and a record at the boundary.

Test data builders should make valid defaults easy and differences visible. Prefer valid_order(quantity=...) over fixtures with twenty positional fields. Builders must not hide required business decisions or share mutable objects between tests. Seed random generators and print the seed on failure.

Property-based testing can generate broader input, but it does not replace a precise oracle. Define properties such as normalization idempotence, sort-order preservation, decode-encode round trip under the contract, or result membership. Preserve the minimized failing example. In an interview, explain the property even if the environment does not include a property-testing package.

7. Async code, retries, timeouts, and concurrency

Modern automation spends much of its time waiting for browsers, services, queues, or files. Async coding questions test whether you understand completion and failure, not just syntax. Prepare sequential versus concurrent execution, bounded concurrency, exception propagation, cancellation, timeouts, and cleanup.

A retry function needs a contract. Which errors are transient? Is the operation idempotent? How many attempts, what delay policy, what total deadline, and what evidence is retained? Never retry assertion failures or all exceptions by default. A timeout should bound the operation and cancel or isolate late work where supported.

Python's asyncio.TaskGroup provides structured concurrency in supported modern Python versions. If one child fails, remaining tasks are canceled and failures are raised as an exception group. The following example is runnable as python async_checks.py.

import asyncio


async def fetch_value(value: int, delay: float) -> int:
    await asyncio.sleep(delay)
    return value


async def collect() -> list[int]:
    tasks: list[asyncio.Task[int]] = []
    async with asyncio.TaskGroup() as group:
        tasks.append(group.create_task(fetch_value(2, 0.02)))
        tasks.append(group.create_task(fetch_value(1, 0.01)))
    return [task.result() for task in tasks]


async def main() -> None:
    result = await asyncio.wait_for(collect(), timeout=1.0)
    assert result == [2, 1]
    print("async checks passed")


if __name__ == "__main__":
    asyncio.run(main())

Notice that result order follows task-list order, not completion order. An interview follow-up may ask for completion order, a concurrency limit, or partial results. State the desired semantics before changing code. Shared mutable state still requires synchronization even in cooperative concurrency.

8. SQL and API data questions

SDETs often need SQL for setup, validation, diagnosis, and reconciliation. Prepare filtering, joins, grouping, HAVING, subqueries or common table expressions, window functions, ordering, and transaction basics. Understand how NULL affects comparison and aggregation. Avoid changing shared data casually during an interview exercise.

A common question asks for duplicate event identifiers:

SELECT event_id, COUNT(*) AS occurrence_count
FROM delivery_events
GROUP BY event_id
HAVING COUNT(*) > 1
ORDER BY event_id;

This is valid on widely used relational databases and SQLite when the table exists. It identifies duplicate keys but does not prove duplicate business effects. Join or reconcile against the consumer's state to answer that question. Add a time range for a large production-like table, use approved read access, and inspect the query plan when performance matters.

Another pattern is "latest row per entity." A window function such as ROW_NUMBER() OVER (PARTITION BY entity_id ORDER BY event_time DESC, sequence DESC) can rank candidates, but tie-breaking must be deterministic. Ask whether event time or ingestion time defines latest.

For APIs, practice parsing status, headers, and JSON, then validating business state. Cover non-success responses, invalid JSON, absent fields, unknown enums, pagination, rate limiting, and timeouts. The API pagination testing guide connects common coding patterns to real boundary cases.

Keep SQL assertions readable. Fetch the smallest safe dataset, map rows to named fields, and report useful diffs. A test that dumps ten thousand rows without identifying the mismatch is hard to debug.

9. Write code that is easy to test and review

Interview code should expose its dependencies. A function that reads the current time, environment, network, and global cache internally is difficult to verify. Pass a clock, client, or data source when the problem benefits from control. Do not overbuild dependency injection for a ten-line algorithm, but name the production concern.

Prefer pure transformations for parsing, filtering, comparison, and expected-result calculation. Keep I/O at the boundary. This enables small deterministic tests and makes concurrency safer. Validate input at the appropriate layer and raise specific errors with context.

When asked to review code, examine correctness before style. Look for missing cases, mutation, resource leaks, race conditions, unchecked return values, swallowed exceptions, unstable ordering, insecure secrets, and misleading logs. Then discuss naming, decomposition, complexity, and maintainability.

Test code deserves production standards because it affects release decisions. Avoid page objects that become giant service locators, utility classes full of unrelated static methods, and helpers that catch every exception. Make failures actionable: expected state, actual state, relevant ID, elapsed time, and safe artifacts.

Explain tradeoffs without performing a full rewrite. "For this interview-sized input, a dictionary is clear and O(n). If input exceeds memory, I would stream and use an external store or sort, but that complexity is not justified by the stated constraint." This demonstrates scalability judgment without abandoning the problem.

10. SDET coding interview questions testers should practice in 30 days

Days 1 through 5: refresh language syntax, collections, functions, exceptions, and the test runner. Solve strings and arrays. For every solution, write at least four checks and state complexity. Compile or execute every file.

Days 6 through 10: practice maps, sets, counting, two pointers, and sliding windows. Turn two problems into log or API examples. Re-solve one earlier problem from memory. Review the core Java interview questions for Selenium testers if Java is required.

Days 11 through 15: practice stacks, queues, intervals, trees, and graph traversal. Add invalid-input behavior. Explain recursion limits and iterative alternatives. Do one forty-five-minute mock round in a plain editor.

Days 16 through 20: practice parsing, SQL, HTTP response handling, and data reconciliation. Create small fixtures with duplicates, missing fields, unknown values, and pagination boundaries. State the source of truth for each comparison.

Days 21 through 25: practice async completion, timeouts, bounded retries, cancellation, and shared-state hazards. Use a fake clock or dependency in one exercise. Review failures and remove arbitrary sleeps.

Days 26 through 30: alternate full mock interviews and review. Rotate coding, debugging, code review, and framework utility exercises. Record yourself, shorten vague explanations, and maintain an error notebook. On the final day, review patterns and language APIs, not dozens of new puzzles.

Interview Questions and Answers

Q: How do you find duplicates while preserving first duplicate order?

Use a seen set and a second set for values already emitted. Scan once, and append a value the first time it is encountered in seen but not in emitted. This is expected O(n) time and O(k) space.

Q: When would you use a map instead of a set?

Use a set for membership or uniqueness. Use a map when each key needs a count, associated record, position, or other value. State whether duplicate input should overwrite, accumulate, or fail.

Q: How do you test a palindrome function?

Clarify normalization first. Then cover empty, one character, odd and even length, non-palindrome, case, spaces or punctuation if included, and Unicode scope. Verify that input is not mutated unless allowed.

Q: What makes a retry helper safe?

It retries only classified transient failures on an idempotent or reconciled operation. It has bounded attempts and deadline, preserves the initial error, supports cancellation, and exposes metrics. Randomized delay may reduce synchronized retries in distributed use.

Q: How would you merge intervals?

Clarify boundary semantics, sort by start, and scan while comparing each interval with the last merged interval. Extend on overlap, otherwise append. Sorting makes time O(n log n), with O(n) output space.

Q: How do you compare API and database records?

Normalize only contractually equivalent fields, index both sources by stable key, detect duplicates, then report missing, unexpected, and field-level differences. Account for documented consistency delay and use the correct source of truth.

Q: What cases belong in a parser test?

Cover valid minimal and full input, empty input, missing required field, wrong type, unknown value, malformed syntax, duplicate key policy, encoding, and size boundary. Keep syntax and domain-validation failures distinguishable.

Q: How do you test async code deterministically?

Inject dependencies, clocks, and synchronization points. Await explicit completion rather than sleeping, bound waits, control response order, and assert cancellation and cleanup. Use stable seeds for randomized schedules.

Q: What is the difference between O(n) and O(n log n) in practice?

O notation describes growth, not exact runtime. A sort-based O(n log n) solution may be simpler or use less auxiliary structure than expected O(n) hashing. Choose based on constraints, order needs, memory, and input behavior.

Q: How do you handle NULL in SQL assertions?

Use IS NULL or IS NOT NULL, not equality with NULL. Understand how aggregates treat nulls and define whether missing, unknown, and empty are equivalent. Test those states explicitly.

Q: What do you do if your code fails an example during the interview?

Trace the smallest failing case, state the likely invariant violation, fix it, and rerun all cases. Explain the mistake briefly without becoming defensive. Recovery is useful evidence of debugging skill.

Q: How much should an SDET study algorithms?

Study enough to select and implement core data structures and common patterns confidently. Add parsing, SQL, async behavior, testing, and framework design because those often match the job more directly. Let the requisition determine extra depth.

The interviewQnA field below adds concise prompts for continued practice.

Common Mistakes

• Starting to code before clarifying output and invalid-input behavior.
• Memorizing solutions without understanding the data structure or invariant.
• Writing only the happy path and claiming tester strength verbally.
• Giving complexity for the main loop while ignoring sorting or nested work.
• Using a set when counts or duplicate evidence matter.
• Catching every exception and returning a value that hides failure.
• Retrying non-idempotent actions without reconciliation.
• Using sleeps to coordinate asynchronous code.
• Overengineering a small problem before producing a correct baseline.
• Failing to run or manually trace the final solution.

Conclusion

The best way to prepare for SDET coding interview questions testers face is deliberate, executable practice. Clarify each contract, choose a data structure from the needed operations, implement readable code, verify edge cases, state complexity, and connect the solution to a quality-engineering problem.

Use the 30-day plan, keep an error notebook, and work in the language required by the role. A candidate who can prove a simple solution and explain its limits will usually create more confidence than one who memorizes many clever answers.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Python Coding Interview Questions for Testers (2026)
• Java Coding Interview Questions for Testers (2026)
• JavaScript Coding Interview Questions for Testers (2026)
• SQL Coding Interview Questions for Testers (2026)
• SQL Interview Questions for QA and Testers (2026)
• Agile Scrum Interview Questions for Testers