CoderPad interview practice. Explain, code, test.

Before the timer

Learn the editor, then close the reference

CoderPad’s official candidate guide describes a browser-based interview environment where you write and run code. Its sandbox guide recommends trying execution, editor settings, and language information before the interview.

1. Open the official CoderPad sandbox or a local Python 3 editor. Choose Python and run a tiny assertion such as assert 2 + 2 == 4. Add print("passed") so successful execution is visible.
2. Check the pad’s language information for the actual runtime and available libraries. Adjust indentation and key bindings so basic editing feels familiar.
3. Keep an independent copy of your practice code. The official sandbox documentation says tabs and contents are removed after an hour of inactivity; do not treat it as permanent storage.
4. Set a separate timer. Read the problem and tests, then close this guide while you work. The exercises below need only Python’s standard library.

Official documentation checked October 11, 2026. We verified the published setup guidance, not a live employer pad or its configured features.

A repeatable routine

Show your thinking before you optimize

Restate the input, output, and one ambiguous edge case. Walk through a small example by hand. Describe a correct approach before typing, then implement the smallest complete version. Run the tests and explain why the algorithm works.

Think aloud at decision points: “I need the original order, so I will count first and scan again.” Continuous narration is unnecessary. If you get stuck, state the uncertainty and construct a smaller example.

These time limits are practice targets, not CoderPad requirements. Try one exercise per session. Across later sessions, progress from counting to intervals to graphs.

The practice set

Three exercises, with the solutions kept closed

Copy the assertions beneath your function. Python assertions produce no output when they pass, so add print("All checks passed") after them. The examples check important cases; explain why your solution handles other valid inputs too.

first_unique_ticket(["a", "b", "a", "c"]) == "b"

assert first_unique_ticket([]) is None
assert first_unique_ticket(["a"]) == "a"
assert first_unique_ticket(["a", "a"]) is None
assert first_unique_ticket(["a", "b", "a", "c"]) == "b"
assert first_unique_ticket(["a", "b", "b", "a"]) is None
assert first_unique_ticket(["A", "a"]) == "A"
assert first_unique_ticket(["é", "x", "é"]) == "x"
tickets = ["a", "b", "a"]
assert first_unique_ticket(tickets) == "b"
assert tickets == ["a", "b", "a"]

def first_unique_ticket(tickets):
    counts = {}
    for ticket in tickets:
        counts[ticket] = counts.get(ticket, 0) + 1

    for ticket in tickets:
        if counts[ticket] == 1:
            return ticket
    return None

merge_windows([(40, 60), (10, 20), (20, 45)]) == [(10, 60)]

assert merge_windows([]) == []
assert merge_windows([(10, 20)]) == [(10, 20)]
assert merge_windows([(20, 30), (10, 20)]) == [(10, 30)]
assert merge_windows([(10, 40), (20, 30)]) == [(10, 40)]
assert merge_windows([(10, 20), (10, 20)]) == [(10, 20)]
assert merge_windows([(0, 1), (1439, 1440)]) == [(0, 1), (1439, 1440)]
assert merge_windows([(40, 60), (10, 20), (20, 45)]) == [(10, 60)]
windows = [(30, 40), (10, 20)]
assert merge_windows(windows) == [(10, 20), (30, 40)]
assert windows == [(30, 40), (10, 20)]

def merge_windows(windows):
    merged = []
    for start, end in sorted(windows):
        if not merged or start > merged[-1][1]:
            merged.append((start, end))
        else:
            previous_start, previous_end = merged[-1]
            merged[-1] = (previous_start, max(previous_end, end))
    return merged

shortest_handoff({"help": ["billing", "ops"], "billing": ["risk"], "ops": ["risk"]}, "help", "risk") == ["help", "billing", "risk"]

graph = {
    "help": ["billing", "ops"],
    "billing": ["help", "risk"],
    "ops": ["risk"],
}
assert shortest_handoff(graph, "help", "risk") == ["help", "billing", "risk"]
assert shortest_handoff(graph, "risk", "help") is None
assert shortest_handoff({}, "solo", "solo") == ["solo"]
assert shortest_handoff({}, "a", "b") is None
assert shortest_handoff({"a": ["a", "b", "b"]}, "a", "b") == ["a", "b"]
assert shortest_handoff({"a": ["b"], "b": ["a"]}, "a", "c") is None
assert shortest_handoff({"a": ["b", "c"], "b": ["c"]}, "a", "c") == ["a", "c"]
assert graph == {"help": ["billing", "ops"], "billing": ["help", "risk"], "ops": ["risk"]}

from collections import deque


def shortest_handoff(graph, start, goal):
    queue = deque([start])
    previous = {start: None}

    while queue:
        team = queue.popleft()
        if team == goal:
            path = []
            while team is not None:
                path.append(team)
                team = previous[team]
            return path[::-1]

        for neighbor in graph.get(team, []):
            if neighbor not in previous:
                previous[neighbor] = team
                queue.append(neighbor)
    return None

After the timer

Save a diagnosis, not just a passing function

For each point below, mark independent, needed a hint, or not yet. Keep the evidence beside the mark. This is a practice checklist, not a prediction of a hiring decision.

• Contract. I clarified ordering, mutation, boundaries, and the empty-input result before coding.
• Correctness. I can explain an invariant or argument that covers all valid inputs, not only the example.
• Testing. I ran the given cases and added one that could break my first idea.
• Complexity. I defined the input-size variables and included sorting, copying, and stored state.
• Communication. I explained a decision and responded to the follow-up without reading the solution.

If the solution required a hint, close it and implement it again from a blank editor in a later session. Change one constraint and explain what breaks. Track time only alongside correctness and how much help you needed.

Round out your preparation with behavioral interview practice and the STAR story builder. For architecture questions, try the system-design hub. The AI mock practice guide shows how to use feedback after an unaided attempt.

Official references

These sources support the editor setup advice. The exercise wording, solutions, time budgets, and review checklist are original editorial material.

• CoderPad Interview preparation guide covers the pad and running code.
• CoderPad sandbox guide covers practice access, settings, language information, and session retention.

Common questions