In this article
Choose interview tests by the requirement each can challenge. This original Python job-selector exercise separates due-time boundaries from job states, then checks the collection behavior that isolated examples miss. Use an assistant only when the assessment explicitly permits it.
Turn the scheduling requirement into separate questions
Suppose a practice repository contains a helper that returns IDs of jobs eligible to run. A job is eligible when its state is queued and its run_at value is at or before now. Preserve the input order and leave the caller's records unchanged. The function selects work; it does not run jobs or claim them for a worker.
For this illustrative exercise, records already have unique string IDs, one of three states, and nonnegative integer timestamps measured in the same unit as now. The other states are sent and cancelled. Validation happens before this helper. These assumptions keep the test-selection discussion focused; inspect the actual caller before relying on similar assumptions in an interview.
Write two questions before reading generated tests: does this job satisfy the time rule, and does its state permit execution? A long list of examples may answer only the first. Choosing a test means choosing which uncertainty you want its result to resolve.
Start with the exact due time and an excluded state
An overdue queued job is a useful baseline, but many incorrect implementations pass it. At now equal to 100, a queued job scheduled for 100 distinguishes an inclusive deadline from a strict one. A sent job scheduled for 99 distinguishes queued-only selection from a rule that merely excludes cancelled jobs. These two cases target different decisions.
The deliberately flawed function below makes both mistakes. Its assertion fails because the exactly due job disappears. Python defines distinct operators for strict and inclusive comparisons; the exercise requirement supplies the reason to choose the inclusive operator. Python language reference: comparisons
If time allows only a small initial set, run the exact-boundary case and the overdue sent case separately. Report each observed mismatch. Do not let the first failing assertion conceal the second question, and do not spend the entire test window generating more overdue queued examples that the same flawed condition already accepts.
def ready_ids_proposed(jobs, now):
return [job["id"] for job in jobs
if job["state"] != "cancelled" and job["run_at"] < now]
assert ready_ids_proposed([
{"id": "due", "state": "queued", "run_at": 100}
], 100) == ["due"]
Cover time and state without multiplying every example
For queued jobs, choose times immediately before, exactly at, and immediately after now. For excluded states, hold time overdue while changing state to sent and cancelled. This separates the causes of eligibility. Add a zero-time example because a truthiness shortcut could silently discard a valid timestamp. Each expected result follows from the written contract.
You do not need every combination to investigate these particular faults. Testing a future cancelled job gives two independent reasons to exclude it, so that case can pass even when one condition is wrong. An overdue cancelled job makes the state condition carry the decision. Deliberately controlling the other input makes a failing result easier to interpret.
State the selection rationale aloud: the first three cases exercise the deadline, the next two exercise exclusion, and zero protects a valid boundary value. This is an explanation of your evidence, not a prediction of how an employer scores testing. Adapt it when the supplied repository introduces another meaningful state or time representation.
Keep selection separate from ordering and execution
The repair below directly expresses the two eligibility conditions. It neither sorts the collection nor changes a job to running. A generated patch that adds either behavior would require new agreement about the helper's responsibility. Preserve the current input-order contract even if sorting by due time looks useful.
Pass now as an argument instead of reading the clock inside the loop. The example can then use fixed integer values and finish immediately. There is no need to wait for a real deadline or guess how long a machine takes to execute. This design makes the disputed branch observable without changing the scheduling rule.
Before accepting the repair, walk through the equality case and the sent case independently. The inclusive comparison admits a due queued job, while the state comparison still rejects an overdue sent job. Python comparison semantics support that trace; they do not establish the scheduler's application requirements. Python language reference: comparisons
def ready_ids(jobs, now):
return [job["id"] for job in jobs
if job["state"] == "queued" and job["run_at"] <= now]
Check mixed records, order, and unchanged input
Single-record cases cannot show whether a helper stops after its first match, sorts successful results, or modifies records. The mixed fixture below deliberately places a later eligible timestamp before an earlier one. Its literal expected IDs protect input order. Repeating the call and comparing the original records checks observable state as well as the first answer.
Paste the repaired selector above this suite and run the file with Python. There are three test methods, including seven named eligibility subcases. unittest supports subtests for identifying individual cases within a method and equality assertions for comparing returned collections. Python unittest: assertions and subtests Keep the literal answers visible when an assistant helps format the table.
An empty collection deserves a separate assertion because an implementation that unconditionally reads the first record can pass every populated example. More tests become useful when they challenge another plausible behavior; their value does not follow from their count. Avoid computing expected IDs by repeating the implementation's filter in the test.
import unittest
def job(identifier, state, run_at):
return {"id": identifier, "state": state, "run_at": run_at}
class SelectionTests(unittest.TestCase):
def test_partitions(self):
cases = [
("overdue", "queued", 99, 100, ["x"]),
("due", "queued", 100, 100, ["x"]),
("future", "queued", 101, 100, []),
("sent", "sent", 99, 100, []),
("cancelled", "cancelled", 99, 100, []),
("zero overdue", "queued", 0, 100, ["x"]),
("zero due", "queued", 0, 0, ["x"]),
]
for name, state, at, now, expected in cases:
with self.subTest(case=name):
self.assertEqual(ready_ids([job("x", state, at)], now), expected)
def test_collection(self):
jobs = [job("later", "queued", 99), job("done", "sent", 1),
job("earlier", "queued", 50), job("future", "queued", 101)]
before = [dict(record) for record in jobs]
self.assertEqual(ready_ids(jobs, 100), ["later", "earlier"])
self.assertEqual(ready_ids(jobs, 100), ["later", "earlier"])
self.assertEqual(jobs, before)
def test_empty(self):
self.assertEqual(ready_ids([], 100), [])
if __name__ == "__main__":
unittest.main()
Use two temporary mutations to audit your choices
Temporarily change only the repaired deadline comparison to strict less-than. The exact-deadline and zero-due cases should fail. Restore it, then change the state condition to exclude only cancelled jobs. The sent case and the mixed collection should fail. Running these mutations separately reveals which requirement each part of the suite protects.
Both mutations were exercised during preparation of this guide, and the published repair passes the suite. That result supports these concrete expectations. It does not prove coverage of all possible defects. For example, these records cannot establish correct timestamp parsing, database ordering, or safe selection by two workers at once.
When time runs short, explain the remaining uncertainty in operational terms: this helper identifies eligible IDs from a snapshot; a worker still needs a separate mechanism to claim work without duplicate execution. Keep that limitation visible instead of attaching an unsupported concurrency guarantee to a passing unit test.
Common questions about choosing interview tests
Should I ask AI to generate the entire suite? Ask for candidate cases after you have written the contract and selected independent expected answers. Review which distinct fault each case could detect. The assistant can help express a table, but an attractive table with duplicated assumptions is weak evidence.
Should I test invalid records first? Prioritize them when validation belongs to this function or the supplied caller fails to validate. Here it is an explicit precondition. In a real repository, verify that boundary before spending your limited time on cases the function is never meant to accept.
Does a passing suite mean I can stop thinking? It means those assertions passed on that implementation. Explain the decision each protected and name the untested boundaries. A short, justified selection gives an interviewer more useful evidence than a large suite whose expected answers you cannot explain.
Sources & editorial notes
This article was authored with AI using primary-source research and an automated technical review. It has not been reviewed by a human. Code examples are illustrative; run and verify them in your own environment.
- Python language reference: comparisons
Defines the strict and inclusive comparison operators used to reason about the due-time boundary. Retrieved October 27, 2026; evergreen documentation, not an announcement.
- Python unittest: assertions and subtests
Documents named subtests and equality assertions used in the runnable verification suite. Retrieved October 27, 2026; evergreen documentation, not an announcement.
Put the reading into practice
Work through an existing repository, review AI suggestions, and test the decisions behind your changes.
Explore practice problems