The Coding Interview Starts After the Solution Passes

After a coding solution passes, ask the candidate to make one defined change, test both the new behavior and the existing contract, and explain the handoff. Good coding interview follow-up questions reveal how someone works with an existing implementation. Choose the change from the job’s responsibilities and review everyone against the same evidence.

The Hacker News discussion of Competitive Programmer’s Handbook puts algorithm practice back in view. Antti Laaksonen’s book is a July 3, 2018 draft. Its introduction describes competitive programming as algorithm design and implementation, with solutions tested for correctness. It also explains that contest programs are short and need no subsequent maintenance.

That last distinction gives you a useful interview question. If you are hiring someone to maintain a product, what happens when a correct solution must change? Keep algorithm reasoning where the role needs it. Then collect evidence about the work that begins when another engineer has to depend on the code.

What does a passing solution tell you?

A passing solution demonstrates that an implementation satisfies the cases you tested. It can also give you material for discussing correctness and complexity. Those are real observations, but they leave some maintenance questions unanswered.

You have not yet seen how the candidate reads a contract they did not invent. You may not know whether they can distinguish a new requirement from an accidental behavior change. A finished solution also tells you little about the note they would leave for the next engineer.

The handbook gives you a clear description of its own setting. A contest task rewards a correct implementation under its constraints. Your hiring task should reflect the responsibilities you need someone to perform. Neither description requires dismissing the other.

For an engineer working on a booking service, preserving the meaning of an existing API might deserve its own assessment criterion. For a role focused on algorithm development, deriving and analyzing an algorithm might remain central. State those targets before choosing the exercise.

This article uses a fictional booking example. It proposes a practical interview packet, not a validated hiring instrument. There is no evidence here that this particular exercise predicts productivity, removes bias, or produces better hires.

For the broader discussion of assessment formats, see our guide to coding interviews after AI. Here, the useful unit is smaller: an existing function, one requested change, a test, and a handoff.

Choose the maintenance work the role requires

Start with a responsibility the new engineer will have on entry. Translate it into a small observable task, then remove unrelated setup work from the exercise.

The US Office of Personnel Management’s job analysis guidance connects job tasks with the competencies needed to perform them. Applying that principle to software, you might choose preserving an API contract, extending a data model, or documenting a patch’s consequences. These software examples are our application of the guidance.

For this packet, the target is changing behavior while preserving a documented contract. You want to see whether the candidate can identify the affected records, implement the change, and protect the old behavior with tests. You also want a readable account of what changed.

That target does not require the candidate to configure your production stack or discover an undocumented business rule. Supply a working test command, a small repository, and the relevant rules. If installation fails, resolve that before you assess the patch.

OPM’s work samples guidance describes tasks resembling work performed on the job. It also cautions against assessing competencies you intend to teach after selection. If the role includes learning your framework after joining, do not quietly make framework familiarity the deciding criterion.

Keep the scope visible to the candidate. State which files matter, what they should submit, and how you will review it. Tell them whether documentation, search, and AI assistance are permitted. Our work-sample design guide covers those wider format decisions.

Give every candidate the same passing implementation

Supply the implementation and its tests to everyone. The maintenance task should begin from a common baseline, so its evidence does not depend on first solving an algorithm puzzle.

Here is the fictional packet. A booking service stores time intervals using integer values. The function returns whether all bookings can coexist in one room. The baseline below runs with Python’s standard library; the language is an example, not an assessment requirement.

Existing contract

Put these rules in the README alongside the function:

• Each record has start and end values, with start < end.
• Intervals are half-open: a booking ending at 20 can share the room with one starting at 20.
• Records can arrive in any order.
• The function returns a boolean and leaves the input list in its original order.
• Invalid intervals are outside this exercise. You may assume the supplied precondition holds.

These rules matter because they settle the questions the candidate would otherwise have to guess. In particular, adjacent bookings are allowed, and sorting must not mutate the caller’s list.

Supplied solution and baseline tests

# bookings.py

def can_share_room(bookings):
    ordered = sorted(bookings, key=lambda booking: booking["start"])
    return all(
        previous["end"] <= current["start"]
        for previous, current in zip(ordered, ordered[1:])
    )

# test_bookings.py
import unittest

from bookings import can_share_room


class BookingTests(unittest.TestCase):
    def test_empty_and_single_booking(self):
        self.assertTrue(can_share_room([]))
        self.assertTrue(can_share_room([{"start": 10, "end": 20}]))

    def test_adjacent_bookings_can_share(self):
        self.assertTrue(can_share_room([
            {"start": 10, "end": 20},
            {"start": 20, "end": 30},
        ]))

    def test_overlapping_bookings_cannot_share(self):
        self.assertFalse(can_share_room([
            {"start": 10, "end": 20},
            {"start": 15, "end": 25},
        ]))

    def test_unsorted_input_keeps_its_order(self):
        bookings = [
            {"start": 20, "end": 30},
            {"start": 10, "end": 20},
        ]
        original = [booking.copy() for booking in bookings]
        self.assertTrue(can_share_room(bookings))
        self.assertEqual(original, bookings)


if __name__ == "__main__":
    unittest.main()

The README gives one command: python -m unittest. Run it yourself before handing over the repository. The candidate should find a passing baseline, with no dependency download or hidden credentials.

Ask them to explain why checking neighboring intervals is enough after sorting. If any intervals overlap, at least one neighboring pair in the sorted sequence must overlap. You can also discuss the sorting cost and the extra list allocation if those concepts matter to the role.

Record that algorithm discussion separately from the maintenance observations. A candidate might explain the algorithm clearly and still miss compatibility. Another might preserve the contract carefully but need support explaining complexity. Keeping the criteria separate makes the review more specific.

Ask for one change and the tests that protect it

Give a precise request: cancelled bookings should stop occupying the room, while older records retain their meaning. Ask for a focused patch and tests that distinguish the changed behavior from behavior that must stay intact.

Use this request verbatim in the fictional README:

Records may now contain a boolean cancelled field. A record with cancelled: True does not occupy the room. A missing field or cancelled: False means the booking still occupies it. Preserve the existing interval rules and input order. Assume supplied cancellation values are booleans. Add tests and a short handoff note.

This limits the task to one behavior change. The candidate does not have to invent cancellation permissions, date parsing, storage, or a new response format. If they notice those questions, the handoff is a reasonable place to mention them.

A focused implementation

One acceptable patch filters before sorting:

def can_share_room(bookings):
    active = [
        booking for booking in bookings
        if not booking.get("cancelled", False)
    ]
    ordered = sorted(active, key=lambda booking: booking["start"])
    return all(
        previous["end"] <= current["start"]
        for previous, current in zip(ordered, ordered[1:])
    )

The missing-field default preserves older records. Filtering leaves the caller’s list alone. The overlap check can keep its original meaning because it now receives only records that occupy the room.

This is an example answer for preparing the exercise. Keep it out of the candidate packet. Accept other implementations that meet the contract; naming and layout preferences should not silently become new requirements.

Tests that establish the change

Add these methods to the supplied test class:

    def test_cancelled_overlap_does_not_block_room(self):
        self.assertTrue(can_share_room([
            {"start": 10, "end": 20},
            {"start": 15, "end": 25, "cancelled": True},
        ]))

    def test_explicit_false_still_blocks_room(self):
        self.assertFalse(can_share_room([
            {"start": 10, "end": 20},
            {"start": 15, "end": 25, "cancelled": False},
        ]))

    def test_all_cancelled_bookings_leave_room_available(self):
        self.assertTrue(can_share_room([
            {"start": 10, "end": 20, "cancelled": True},
            {"start": 15, "end": 25, "cancelled": True},
        ]))

The first new test fails against the supplied implementation. That is useful evidence: the test exercises the requested change. The second protects explicit active records, while the original overlap test protects records with no cancellation field.

The original adjacency and ordering tests still matter. They cover parts of the contract the request did not change. Ask the candidate to show which assertions establish the new rule and which preserve the old ones.

You can discuss whether to add a test that confirms cancelled records also remain in the caller’s list. That would make the input-preservation rule explicit for the new data shape. Treat a missing test as a concrete coverage observation, then inspect whether the implementation actually violates the rule.

Do not reward test volume on its own. Several tests repeating the same scenario can obscure a missing boundary. Review the relationship between each assertion and the stated contract.

Review the handoff with shared questions

Ask every candidate to explain the change using the same core questions. Reviewers should record code and test evidence before discussing the overall decision.

OPM’s structured interview guidance describes predetermined questions in a common order and shared rating standards. We recommend applying those principles to the code discussion. This exercise is not OPM-certified, and its predictive validity is unestablished.

A handoff someone could use

An example note might read:

Cancelled bookings are excluded before sorting. Missing cancellation fields default to active, so older records keep their behavior. Existing adjacency and input-order tests still pass. The new cancelled-overlap test fails on the original function. Inputs are assumed to contain boolean cancellation values; validation of imported data remains outside this patch.

That note tells the next engineer what changed, what stayed stable, and where the assumption ends. It does not need a long essay or a retelling of every edit.

Ask the same three core questions:

1. Which existing behavior did you protect, and where is the evidence?
2. Which test would fail without your change?
3. What should the next engineer know before changing this function again?

A reviewer can ask clarifying questions about the submitted work. Record those prompts too, especially when they supplied information that another candidate received in the initial instructions. Improve the packet when repeated questions expose an ambiguity.

A common review sheet

Use a sheet with evidence anchors agreed before interviews begin:

Adapt these proposed anchors to the responsibilities you identified, and decide how they affect the hiring decision before you see submissions. They are not research-backed score thresholds.

Pilot the packet with colleagues who understand the role. Ask where they needed clarification and whether the requested work represents an entry requirement. OPM notes that work samples take effort to develop and administer; budget for that preparation and review.

For a senior role whose central task is evaluating a design proposal, use a different exercise. Our senior engineer design review guide covers that responsibility. This small patch cannot stand in for every kind of engineering judgment.

Organize the assignment in Kit

Prepare the exercise and review criteria yourself, then use Kit to organize the assignment in the hiring pipeline. GitHub holds the implementation, tests, and code review; human reviewers interpret the evidence.

Kit’s code assignments use private repositories created from an employer’s template repository. Candidates connect GitHub for the assignment workflow. After submission, reviewers with connected GitHub accounts can receive repository invitations and inspect the code and history there.

Put the README, baseline tests, and deliverables in your template. If you want a pull request, request it in those instructions. Kit does not automatically create one or grade the implementation. Define the review criteria your team will use alongside the assignment.

Set a calendar submission deadline that fits the process and explain any expected effort separately. A deadline is not a timer measuring active coding hours. Do not interpret expiry as proof that the repository is frozen. Our code-assignment setup guide covers the wider workflow, including deadlines and review.

A correct solution is a useful starting point. For a maintenance role, follow it with one clear change, tests that protect the contract, and a handoff another engineer could use. Start by piloting this packet against an actual responsibility on your team, then revise the instructions before giving it to candidates.