Python Coding Interview Questions for Testers (2026)

TL;DR

Prepare for Python tester coding interviews by solving collection, string, parsing, API, retry, fixture, mocking, and debugging problems with runnable tests. Clarify the input contract, cover boundaries, state complexity, and explain how the solution behaves in a real automation suite.

Key Takeaways

• Interviewers evaluate contracts, edge cases, tests, readability, and debugging in addition to correct output.
• Know lists, tuples, sets, dictionaries, comprehensions, iterators, exceptions, context managers, and type hints.
• Use the data structure that matches membership, order, counting, grouping, or queue behavior.
• Write boundary tests before optimization and state time and space complexity.
• Keep retries bounded and limited to safe transient operations.
• Use pytest fixtures and parametrization for explicit setup and broad input coverage.
• Practice explaining production test utility, not only algorithm syntax.

The most useful Python coding interview questions testers face are grounded in automation work: transform data, find duplicates, validate responses, handle failures, design fixtures, and make code testable. A strong answer is correct, readable, covered by edge cases, and honest about complexity and assumptions.

This guide gives runnable Python and pytest examples plus the explanation an interviewer expects. Type each solution yourself, alter the inputs, and practice talking through decisions before looking at the model answer.

TL;DR

In a timed round, solve the simplest correct version first. Test it, explain complexity, then improve it only if the constraints require improvement.

1. What Python coding interview questions testers evaluate

A tester coding round is not always an algorithm contest. It may combine a small data problem, a test-automation task, a bug review, and follow-up design questions. Interviewers look for structured thinking and code that another engineer could maintain.

Start every exercise with a contract. Ask what input types are allowed, whether order matters, how duplicates should behave, whether invalid input should raise or be skipped, how large the input can be, and whether mutation is allowed. If the interviewer cannot answer, state a reasonable assumption and proceed. This prevents a correct algorithm from solving the wrong problem.

Use a simple loop before a compressed one-liner when it communicates intent better. Python fluency is not measured by minimizing line count. Name variables from the domain, keep side effects visible, and avoid mutable default arguments. Add type hints when they clarify the boundary, but do not spend the entire round constructing elaborate types.

After coding, test categories deliberately:

• Empty and minimal inputs.
• Typical inputs.
• Duplicates and ordering.
• Boundary values.
• Invalid inputs defined by the contract.
• A case that would break a naive approach.

State complexity in terms of input size. Mention expected versus worst-case behavior when hash tables are involved only if it matters to the discussion.

The JavaScript coding questions for testers offer parallel exercises in another common SDET language. Compare language mechanics, but keep the same quality bar for contracts and tests.

2. Python language foundations for QA and SDET roles

Know the behavior of core collections. Lists are ordered and mutable. Tuples are ordered and immutable, though contained objects can still be mutable. Sets store unique hashable elements and support efficient expected membership checks. Dictionaries map unique hashable keys to values and preserve insertion order as a language guarantee in modern Python.

Understand equality versus identity. == asks whether values are equal according to their type. is asks whether two references identify the same object. Use is None, but do not use is for string or integer value comparison.

Review truthiness, slicing, unpacking, comprehensions, generator expressions, enumerate, zip, sorted, and key functions. Know that a generator is lazy and usually consumed once. Be able to explain shallow and deep copies, especially when test data contains nested dictionaries or lists.

Functions are objects. Learn positional and keyword arguments, default values, *args, **kwargs, closures, and decorators at a practical level. Never use a mutable list or dictionary as a default when each call should get fresh state:

def add_tag(tag: str, tags: list[str] | None = None) -> list[str]:
    result = [] if tags is None else list(tags)
    result.append(tag)
    return result


assert add_tag("smoke") == ["smoke"]
assert add_tag("regression") == ["regression"]

Review exceptions, with statements, iterables, iterators, modules, package imports, virtual environments, and dependency locking. For automation, also know JSON handling, file paths through pathlib, regular expressions, dates and time zones, and HTTP client conventions used by your team.

Explain these concepts through test consequences. A shared mutable default can leak state between tests. A consumed generator can make a second assertion unexpectedly empty. A shallow copy can allow one test case to mutate another's nested data.

3. Coding exercise: remove duplicates while preserving order

A classic question asks you to remove duplicates. The important detail is whether original order must remain. Converting directly to a set removes duplicates but does not express an ordered-result contract.

A readable O(n) expected-time solution uses a set for membership and a list for output:

from collections.abc import Iterable
from typing import TypeVar

T = TypeVar("T")


def unique_in_order(values: Iterable[T]) -> list[T]:
    seen: set[T] = set()
    result: list[T] = []

    for value in values:
        if value not in seen:
            seen.add(value)
            result.append(value)

    return result


def test_unique_in_order() -> None:
    assert unique_in_order([]) == []
    assert unique_in_order(["a"]) == ["a"]
    assert unique_in_order(["a", "b", "a", "c"]) == ["a", "b", "c"]
    assert unique_in_order([1, 1, 2, 1]) == [1, 2]


if __name__ == "__main__":
    test_unique_in_order()
    print("all tests passed")

This assumes values are hashable. If nested dictionaries are allowed, the set approach raises TypeError. State that constraint. You could use equality-based scanning for unhashable items, but the time cost becomes O(n squared), or derive a stable key if the domain provides one.

An interviewer may ask for duplicate values instead of unique values. Clarify whether each duplicate should appear once or once per repeated occurrence. For test result IDs, you might return an ordered list of IDs observed more than once. A Counter is useful, but a one-pass count plus an ordered pass may communicate the rule best.

Do not optimize away the tests. Empty input, one item, repeated first and last values, mixed ordering, and unhashable input are the questions hiding inside the algorithm.

4. Coding exercise: group failed tests by error type

Automation systems often transform result records. Suppose each result has a test name, status, and optional error type. Return failed test names grouped by error type, preserving input order within each group.

from collections import defaultdict
from typing import TypedDict


class TestResult(TypedDict, total=False):
    name: str
    status: str
    error_type: str


def group_failures(results: list[TestResult]) -> dict[str, list[str]]:
    grouped: defaultdict[str, list[str]] = defaultdict(list)

    for result in results:
        if result.get("status") != "failed":
            continue

        name = result.get("name")
        if not name:
            raise ValueError("failed result must include a name")

        error_type = result.get("error_type", "UnknownError")
        grouped[error_type].append(name)

    return dict(grouped)


sample: list[TestResult] = [
    {"name": "login", "status": "failed", "error_type": "Timeout"},
    {"name": "search", "status": "passed"},
    {"name": "checkout", "status": "failed", "error_type": "Assertion"},
    {"name": "logout", "status": "failed", "error_type": "Timeout"},
]

assert group_failures(sample) == {
    "Timeout": ["login", "logout"],
    "Assertion": ["checkout"],
}

The algorithm is O(n) time and O(f) additional space for failed records. The contract chooses a default category when error type is missing and raises when a failed record lacks a usable name. An alternative could skip malformed input or return validation errors, but that must be deliberate.

Follow-up questions may include sorting groups, returning counts, processing a stream, or handling millions of records. Sorting adds cost. Streaming can yield aggregates only after enough input has arrived, and exact grouping still requires storage proportional to the distinct content retained.

This exercise tests dictionaries, default values, types, validation, and domain judgment in one compact problem.

5. Coding exercise: validate an API response contract

A QA coding task may provide parsed JSON and ask for validation. Separate parsing, schema-like validation, and business rules. Do not assume every key exists or every value has the correct type.

The function below validates a simple paginated response using only the standard library:

from typing import Any


def validate_page(payload: Any) -> list[str]:
    errors: list[str] = []

    if not isinstance(payload, dict):
        return ["response must be an object"]

    items = payload.get("items")
    if not isinstance(items, list):
        errors.append("items must be a list")
        items = []

    next_cursor = payload.get("next_cursor")
    if next_cursor is not None and not isinstance(next_cursor, str):
        errors.append("next_cursor must be a string or null")

    seen_ids: set[str] = set()
    for index, item in enumerate(items):
        if not isinstance(item, dict):
            errors.append(f"items[{index}] must be an object")
            continue

        item_id = item.get("id")
        if not isinstance(item_id, str) or not item_id:
            errors.append(f"items[{index}].id must be a nonempty string")
        elif item_id in seen_ids:
            errors.append(f"duplicate id: {item_id}")
        else:
            seen_ids.add(item_id)

    return errors


assert validate_page({"items": [], "next_cursor": None}) == []
assert validate_page({"items": [{"id": "1"}, {"id": "1"}]}) == [
    "duplicate id: 1"
]
assert validate_page([]) == ["response must be an object"]

Returning all detected errors can be more diagnostic than raising at the first one. A boundary validator might instead raise a custom exception to stop unsafe processing. Discuss which consumer needs the result.

In a real project, a JSON Schema or typed model can validate structure, but business invariants such as uniqueness, allowed state transitions, or cross-field rules still need explicit logic. Never invent a success contract based only on HTTP 200. Validate the status, headers where relevant, body shape, semantic content, and resulting state.

For wider service-testing preparation, review API test engineer interview questions.

6. Design exceptions, cleanup, timeouts, and retries safely

Exception handling should preserve failures and recover only when the code has a defined response. Catch a specific exception near the boundary that can handle it. A broad except Exception: pass converts evidence into a false pass or a confusing later error.

Use try/finally or a context manager for cleanup that must run even when assertions fail. Be careful not to replace the original failure with a cleanup error. In production frameworks, attach cleanup failure information while preserving the primary test result according to runner behavior.

Retries belong around transient, safe operations. Define which exceptions are retryable, maximum attempts, delay policy, total deadline, and observability. Never retry an unsafe write unless the operation has idempotency protection or the contract explicitly permits it.

This runnable example retries a callable for selected exceptions:

import time
from collections.abc import Callable
from typing import TypeVar

T = TypeVar("T")


def retry(
    operation: Callable[[], T],
    *,
    attempts: int,
    delay_seconds: float,
    retry_on: tuple[type[Exception], ...],
) -> T:
    if attempts < 1:
        raise ValueError("attempts must be at least 1")

    for attempt in range(1, attempts + 1):
        try:
            return operation()
        except retry_on:
            if attempt == attempts:
                raise
            time.sleep(delay_seconds)

    raise RuntimeError("unreachable")


calls = 0


def eventually_succeeds() -> str:
    global calls
    calls += 1
    if calls < 3:
        raise TimeoutError("temporary")
    return "ok"


assert retry(
    eventually_succeeds,
    attempts=3,
    delay_seconds=0,
    retry_on=(TimeoutError,),
) == "ok"

For application code, inject a sleep function or clock to make retry tests fast and deterministic. Add exponential backoff and jitter only when requirements justify them. Automation retries should not create synchronized load or disguise a repeatable defect.

7. Use pytest parametrization, fixtures, and monkeypatch

pytest is common in Python test stacks. Know plain assertions, test discovery, fixtures, scopes, parametrization, markers, temporary paths, monkeypatching, and failure output. Follow the versions and plugins pinned by the target repository rather than assuming every environment has the same extensions.

Parametrization is appropriate when the behavior is the same and only data changes:

import pytest


def normalize_status(value: str) -> str:
    normalized = value.strip().lower()
    if normalized not in {"passed", "failed", "skipped"}:
        raise ValueError(f"unsupported status: {value}")
    return normalized


@pytest.mark.parametrize(
    ("raw", "expected"),
    [
        ("PASSED", "passed"),
        (" failed ", "failed"),
        ("Skipped", "skipped"),
    ],
)
def test_normalize_status(raw: str, expected: str) -> None:
    assert normalize_status(raw) == expected


def test_normalize_status_rejects_unknown() -> None:
    with pytest.raises(ValueError, match="unsupported status"):
        normalize_status("blocked")

Run it with pytest -q after installing pytest in a virtual environment.

Fixtures should provide a coherent dependency or resource and guarantee teardown. Scope them narrowly by default. A session-scoped mutable object can leak state across tests. Yield fixtures make setup and teardown visible, but cleanup must tolerate partial setup and already-removed resources.

Use monkeypatch to replace environment variables, attributes, or mappings within a test's lifetime. Patch where the code under test looks up the dependency, not where it was originally defined. Prefer dependency injection for complex collaborators because it reduces patching ambiguity.

Do not turn every literal into a fixture. Test-local data is often easier to read. Use parametrization for meaningful equivalence classes, not hundreds of opaque cases that produce unreviewable failure IDs.

8. Mock external boundaries without testing the mock

Mocking isolates a boundary so a test can control outcomes, but it narrows proof. A mocked HTTP response proves your client logic handles that response. It does not prove DNS, TLS, authentication, routing, schema compatibility, or the real service.

Design code so pure logic is separate from I/O. For example, a function can accept a fetch callable and validate the returned payload. The test supplies a deterministic callable without patching global modules:

from collections.abc import Callable
from typing import Any


def active_user_ids(
    fetch_users: Callable[[], list[dict[str, Any]]],
) -> list[str]:
    users = fetch_users()
    return [
        user["id"]
        for user in users
        if user.get("active") is True and isinstance(user.get("id"), str)
    ]


def fake_fetch_users() -> list[dict[str, Any]]:
    return [
        {"id": "u1", "active": True},
        {"id": "u2", "active": False},
        {"id": 3, "active": True},
    ]


assert active_user_ids(fake_fetch_users) == ["u1"]

For unittest.mock, know Mock, patch, return values, side effects, call assertions, and autospec. Use interaction assertions only when the interaction is part of the contract. Overly specific call-order checks couple tests to implementation and make refactoring expensive.

Create contract tests against a controlled real dependency or provider sandbox where appropriate. Keep a small end-to-end flow for the highest-value integration. The test pyramid is a distribution of evidence, not a ban on mocks or UI tests.

In an interview, state both sides: mocks make rare errors and deterministic branches easy to test, while real integration coverage is still required for boundary confidence.

9. Practice debugging and automation design questions

Code review exercises may contain shared mutable state, missing waits, swallowed exceptions, hard-coded data, duplicate setup, or assertions that prove too little. Read from the failure outward. Identify the first incorrect state, not only the final exception.

For a Selenium Python question, understand explicit waits, locator contracts, browser isolation, and stale elements. Avoid fixed sleeps. The Selenium CSS selector examples in Python show direct supported locator syntax. If JavaScript execution appears in a debugging question, explain its test boundary using Selenium execute_async_script in Python.

For API automation, separate the transport client, domain operations, data builders, and assertions enough to keep tests readable. Validate timeouts explicitly. Do not let a library default create an unbounded or surprisingly long wait. Redact tokens and personal data from logs.

For file processing, use pathlib.Path, explicit encoding, and temporary directories. For dates, use timezone-aware values when comparing events across systems. For concurrency, know that threads, processes, and async tasks have different isolation and scheduling properties. Do not add concurrency until shared state is safe.

A strong debugging answer follows a sequence:

1. Reproduce with the same code, data, configuration, and environment.
2. Preserve the original traceback and artifacts.
3. Classify product, test, data, environment, or infrastructure ownership.
4. Form one hypothesis from evidence.
5. Run a test that distinguishes it from alternatives.
6. Fix the root condition and add a regression check.
7. Run independently, repeatedly, and with normal concurrency.

This method is more credible than calling any intermittent failure "flaky."

10. Python coding interview questions testers: a four-week plan

During week one, refresh Python foundations. Implement collection transformations, counting, grouping, sorting, parsing, and error handling. Write tests for every exercise. Explain mutability, hashing, identity, generators, context managers, and common complexity.

During week two, focus on tester problems. Validate JSON-like data, compare record sets, detect duplicates, parse logs, generate boundary values, and reconcile expected versus actual results. Use type hints and small pure functions. Practice one SQL problem daily if the role includes data validation.

During week three, work with pytest and automation design. Build fixtures with safe cleanup, parameterize equivalence classes, patch one external boundary, and test a retry helper. Create one API test project or browser test using the team's likely tools. Run linting and type checking if configured.

During week four, simulate interviews. Solve one problem in 30 minutes, including clarification, code, tests, complexity, and follow-up discussion. Review a deliberately flawed test. Present a small framework design and a debugging case. Record yourself and remove long, unstructured narration.

Use a daily scorecard:

Do not learn new syntax on the final day. Rehearse familiar patterns, confirm the coding environment, and sleep. In the interview, ask focused questions, solve the base case, and adapt when constraints change.

Interview Questions and Answers

Q: What is the difference between a list and a tuple?

Both are ordered sequences. A list is mutable, while a tuple is immutable as a container and can be hashable when all its elements are hashable. I use tuples for fixed records or keys when immutability is part of the contract, not as a performance superstition.

Q: What is the difference between == and is?

== compares values using equality behavior. is compares object identity. I use is None for the singleton and == for ordinary value comparisons.

Q: Why are mutable default arguments dangerous?

The default object is created when the function is defined and reused across calls. Mutations can therefore leak state between calls or tests. I use None as the default and create a fresh object inside.

Q: When would you use a set in test code?

A set is useful for uniqueness, membership, and set comparisons when ordering and duplicates are not part of the contract. I would not use it when I need original order or duplicate counts without adding another structure.

Q: What is a generator?

A generator produces values lazily through iteration instead of building the entire result immediately. It can reduce memory use for streams, but it is usually consumed once and may defer exceptions until iteration.

Q: How do pytest fixtures work?

Fixtures declare reusable dependencies by name. pytest resolves their dependency graph, runs setup according to scope, injects the value, and performs teardown for yield fixtures. I keep mutable fixtures narrow and cleanup reliable.

Q: When should tests be parametrized?

Parametrize when several inputs exercise the same behavior and assertion structure. Give cases meaningful IDs when needed. Separate cases when their setup, expected behavior, or failure meaning differs significantly.

Q: How do you test an exception with pytest?

Use pytest.raises as a context manager, optionally matching a stable part of the message or inspecting the exception. The test should also prove the operation reached the intended invalid condition.

Q: What should a retry implementation include?

A retry needs a narrow exception policy, maximum attempts or deadline, delay strategy, and observability. It should wrap only safe operations or idempotent writes. Tests should cover immediate success, eventual success, final failure, and nonretryable errors.

Q: What is mocking, and what does it not prove?

Mocking replaces a collaborator with controlled behavior so a unit can be tested deterministically. It does not prove the real integration, protocol, configuration, or schema. I combine it with contract and end-to-end coverage according to risk.

Q: How would you compare two API result sets?

First clarify whether order and duplicates matter and which key identifies a record. I may use lists for ordered equality, Counters for multiset equality, or dictionaries keyed by stable ID for field comparison. I report missing, unexpected, and changed records separately.

Q: How do you debug an intermittent automation failure?

I reproduce the exact context, preserve the original traceback and artifacts, classify the layer, and identify the first divergence. I form one hypothesis and run a discriminating experiment. I do not start with an unexplained retry or sleep.

Q: What is time complexity of dictionary lookup?

It is expected O(1) for normal hash-table use, with memory cost for the table. I avoid claiming an unconditional guarantee because collisions and adversarial conditions can affect worst-case behavior.

Q: How do you keep Python test code maintainable?

I keep business intent visible, isolate I/O, use typed boundaries where useful, create deterministic data, and avoid hidden globals. Fixtures have coherent responsibilities, assertions are diagnostic, and dependencies are pinned and reviewed.

Common Mistakes

• Coding before clarifying order, duplicates, invalid input, and mutation.
• Choosing a one-liner that obscures the contract.
• Using is for value equality.
• Using mutable default arguments.
• Catching Exception and continuing without a defined recovery.
• Retrying assertions, unsafe writes, or deterministic bugs.
• Testing only a happy path or printing output without assertions.
• Using a set when order or duplicate count matters.
• Overusing mocks and claiming integration confidence.
• Building session-scoped mutable fixtures that leak state.
• Patching the wrong import location.
• Omitting timeouts around external I/O.
• Claiming O(1) behavior without stating hash-table assumptions.
• Ignoring cleanup failures, sensitive logs, or parallel execution.

Conclusion

The best way to prepare for Python coding interview questions testers encounter is to practice complete engineering answers: clarify the contract, choose a fitting data structure, write readable code, test boundaries, and explain complexity and automation relevance. Syntax is only one part of the score.

Start with the duplicate-removal and API-validation exercises in this guide. Reimplement them without looking, change one requirement, and explain how the tests and complexity change. That practice builds the adaptability a QA or SDET coding round actually measures.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• SDET 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