Karat NextGen Interview: Review AI Changes in a Multi-File Project and Defend Your Decisions

A Karat NextGen interview asks you to work with AI while remaining responsible for the engineering decision. Practise locating the right code, explaining the contract, challenging a plausible suggestion, and showing that your repair behaves correctly.

This article is for an invitation that specifically names NextGen. It includes an original multi-file repository and a review ledger you can rehearse aloud. Start with PracHub’s Validate AI-Generated Code Safely if you want a focused prompt before attempting the project.

Evidence boundary: Current Karat documentation supports the NextGen environment and published skill descriptions. The repository, proposed patch, tests, and review dialogue below are original PracHub exercises. We did not establish the current interview flow through two independent, same-cycle NextGen candidate reports. Nothing here claims a leaked project, universal timer, scoring weight, or hiring cutoff.

Confirm that your invitation is for NextGen

Official fact, checked October 11, 2026: Karat’s NextGen page describes human-led, one-on-one interviews, a VS Code-based environment, project-based questions, and an integrated AI assistant. Its FAQ encourages use of that assistant and explicitly prohibits external AI tools. Apply that rule to a confirmed NextGen session; it does not establish AI permission in every interview carrying the Karat name.

The December 10, 2025 launch announcement describes multi-file projects and live discussion of reasoning, trade-offs, and judgment. A tutorial that prepares you only to paste a standalone algorithm into an empty editor misses that important distinction.

Read your personalized instructions for language, environment, tools, and expected preparation. Karat’s technical-interview measurement article says interviews depend on the company and role. Do not borrow another candidate’s question count or retake assumptions without checking that they apply to your invitation.

Tool details can change too. Karat’s April 2026 NextGen retrospective describes changes to its integrated model and editing workflow. Practise reading, reviewing, and verifying code across tools; the integrated interface can change. It is not a promise about the model your interview will provide.

Read the project before asking for a change

Download the original review-exercise ZIP. It contains starter, suggested, and solution directories, a readable patch, and a README. Use Python 3.12 or later with the standard library; no account credentials or package installation are needed.

Start in starter. Its conflict-preview feature is intentionally unimplemented, so the contract tests initially fail. Read the requirements and inspect the modules before opening the reference solution. The task is to return active booking IDs that overlap a requested interval in a particular room.

This is a read-only preview. It does not create reservations, prevent concurrent double booking, or demonstrate database transaction safety. Existing bookings have valid integer-minute intervals and unique IDs. Requests require start < end; invalid requests raise ValueError. Intervals are half-open: a booking ending at minute 20 does not conflict with a request beginning at 20.

Trace one call from ConflictService.conflict_ids into the repository and overlap predicate, then back to the returned IDs. Use that call path as your dependency map. Reading every unrelated utility first would not resolve the feature’s central uncertainty.

Before running an unfamiliar real repository, inspect its documented commands and dependencies. In this exercise, the README’s test command is sufficient. If a real interview environment cannot run a command, explain the blocker and use permitted tools to isolate it rather than silently treating an unexecuted test as passing.

Give the assistant a bounded task

Preparation inference: A useful request names the entry point, constraints, and required evidence. For private practice, an example is: “Inspect the conflict-preview call path. Explain the half-open interval contract and propose the smallest change. Preserve room filtering, active status, input data, and deterministic ordering. Add tests that distinguish touching intervals from containment. Do not introduce caching or new dependencies.”

That prompt is a practice technique, not a required Karat script. During a real NextGen interview, use only the supplied assistant and permitted interface. Ask the interviewer when a requirement is ambiguous instead of asking AI to invent a product decision.

Separate requests for explanation from requests to edit. An assistant can first identify the relevant modules and existing conventions. You can then review that account against the files, approve a bounded implementation direction, and inspect the diff. This preserves a visible chain from requirement to change.

A weak request such as “make it production-ready” leaves scope undefined. The assistant may add a cache, an abstraction, or a new dependency that creates more review work than the feature requires. Name the behavior you need and the changes you can justify under the actual task.

Challenge the plausible patch with a counterexample

The suggested directory contains an intentionally flawed AI-style proposal. It extracts an overlap helper, adds a room-keyed cache, and includes a passing smoke test. Its overlap predicate is:

def overlaps(start, end, other_start, other_end):
    return start <= other_start <= end

For a request [20,30), a booking [10,40) contains the whole request. The proposed predicate returns false because the booking starts before 20. Conversely, a booking [30,40) only touches the request’s excluded end, yet the predicate returns true. One short expression has both a false negative and a false positive.

Under this exercise’s valid, nonempty half-open contract, the correct helper is:

def overlaps(start, end, other_start, other_end):
    return start < other_end and other_start < end

Explain the two strict comparisons. Each interval must begin before the other ends. Replacing them with inclusive comparisons would change touching endpoints into conflicts. A test that uses only a booking strictly inside the request cannot distinguish these interpretations.

The proposed cache has a separate defect. It stores results by room while the answer also depends on the requested start and end. On one service instance, query room A for [10,20), then [30,40). With bookings named early and late in those respective windows, the second answer must be late, not the earlier cached result.

Adding the missing interval fields to the key would address this collision, but it would not establish freshness after booking changes. This small task has no measured performance problem or invalidation contract. The reference repair removes caching and keeps the read path simple.

Keep a review ledger that explains each decision

For each review decision, name the contract and the evidence. Do not reject every suggestion simply because AI produced it, and do not accept a change because its explanation sounds confident.

The invalid-request row describes the behavior that results from missing validation, not a claim that the assistant explicitly proposed that requirement. That distinction matters in an interview: describe what the code does before attributing an intention to its author.

A good spoken review is specific: “I will keep the helper extraction, replace the predicate because containment fails, remove the cache because the task has no freshness contract, and add the ID tie-breaker. I will preserve the repository’s room filter and the active-booking filter.” That gives the interviewer a reviewable plan rather than a blanket verdict.

Verify through the public service method

Run the same contract suite from each directory:

python3 -m unittest test_contract -v

Original execution evidence: With CPython 3.12.14, the reference solution passed all 12 test methods. The suggested patch passed its separate single happy-path smoke test but reported seven failures in the contract suite, including two invalid-request subcases. The starter raised the expected unimplemented-feature errors. These are local exercise observations, not provider benchmarks.

The suite covers an inside booking, a containing booking, overlap from either side, touching at either boundary, another room, cancelled bookings, equal-start ordering, repeated requests, invalid endpoints, and preservation of input data. Expected IDs are written independently rather than obtained by calling the implementation being tested.

Tests should go through ConflictService.conflict_ids as well as any focused helper checks. A correct overlap helper alone would not reveal a room-keyed stale result returned before the helper runs. Likewise, sorting a local result list is different from mutating the repository’s stored records; inspect which object the code actually owns.

After fixing a failure, rerun the relevant case and then the complete small suite. Record the final command, interpreter version, and result. If a test remains red, identify the failing behavior and explain whether it is an implementation defect, an incorrect test expectation, or an unresolved requirement.

The repair scans the room’s bookings and sorts the matching conflicts by (start,id). With n selected room records and k conflicts, the local work is O(n + k log k), with additional lists proportional to the selected and matching records. That is a reasoning bound for this implementation, not a measured production latency guarantee.

Defend the change and its remaining limits

Use a short closing explanation: “The feature previews conflicts for valid half-open requests. I traced the service through the room repository and overlap helper. The initial suggestion passed its happy path but failed containment, touching, repeated-window, ordering, and invalid-input checks. I kept the useful helper boundary, removed unneeded state, and verified the repair through the public service method.”

Then name the limit: “This does not make a booking atomic. Two callers can both preview no conflict before either writes. Enforcing reservations would require a separate storage and concurrency design.” This prevents a correct local feature from becoming an unsupported system-wide claim.

If the interviewer changes the requirement to closed intervals, request validation and overlap expectations must change together. If cancelled bookings must be included, amend the status filter and its tests. State the changed assumption, identify affected code, and rerun the cases that distinguish the new contract.

Karat publicly describes communication, AI proficiency, productivity, and product sense among NextGen skill areas. A practical way to make your work assessable is to connect each important change to a requirement, an observed result, and a remaining risk. Those labels do not reveal private scoring weights or guarantee an outcome.

Five PracHub questions for the review loop

These are related practice records, not a NextGen question list. Their individual contracts differ; in particular, the integer interval drill uses inclusive endpoints rather than this repository’s half-open convention.

After reviewing the exercise, attempt AI-Assisted Coding: Add a Read-Through Cache for a Product GET API in an Existing Repo. Compare the two contracts: the product API requires a cache; this conflict preview does not.

Sources and Further Reading

• Karat: NextGen environment, skills, and AI-use FAQ
• Karat: December 2025 NextGen launch announcement
• Karat: What technical interviews measure
• Karat: April 2026 lessons from AI-enabled interviews