Articles
CodeInterview Live Coding: Prepare the Editor and Explain Your Tests
Prepare CodeInterview live coding with candidate editor controls, a tested interval exercise, clear test explanations, recovery steps, and permission checks.
A CodeInterview live coding session gives the interviewer more to evaluate than a final function. Your edits, test choices, and explanation reveal whether you understand the contract and can diagnose a wrong result. Prepare the editor, then practise making that reasoning visible.
Agree on the problem's boundaries before coding, and make each run answer a specific question. This guide uses an original closed-interval exercise to connect input assumptions, implementation, terminal output, and follow-up reasoning.
Official documentation establishes the platform controls described below. We found insufficient independent same-cycle completed candidate reports to claim a standard employer question set, timer, or passing score. Our exercises and preparation recommendations are labeled accordingly.
Confirm what your CodeInterview invitation actually describes
The official candidate getting-started guide describes joining a supplied link, a shared pad with code on the left and terminal output on the right, and a task provided by the interviewer. The language selector, Run control, output clearing, and editor settings support the coding conversation.
CodeInterview also offers a separate coding-test product. Features advertised for an automated test do not establish the rules for your live session. Read the actual invitation for the role, format, time zone, language, communication channel, and allowed resources.
Our preparation recommendation is to clarify anything that changes how you will work. Is this a live discussion with the employer, an asynchronous assessment, or a frontend task with an additional preview? Are external documentation and packages permitted? A product capability does not answer those assessment-policy questions.
If you receive a preparation or demonstration link, use it within the employer's instructions. Do not open a real assessment early merely to experiment. Keep a record of the scheduled time and the support route so a setup issue does not become a guessing exercise.
Separate candidate controls from interviewer controls
The official interviewer guide describes creating interviews, using templates, inviting candidates, and ending sessions. Those actions belong to the interviewer workflow. They are not a list of controls you should expect in the candidate pad.
| Documented control or capability | Preparation implication |
|---|---|
| Candidate language selection and Run | Verify the selected language and the executable entry point before implementing the full solution |
| Candidate editor settings | Choose readable indentation and familiar keybindings where available; avoid changing settings while diagnosing a logic bug |
| Interviewer templates and session ending | Work from the supplied task; do not assume you can replace the template or reopen an ended session |
| Interviewer-side replay and review | Explain decisions during the session instead of planning to add an explanation afterward |
The official editor page describes recorded code playback and private notes for the interviewing team. The candidate guide says candidates cannot access replay after the interview. That distinction matters: do not promise yourself a post-session opportunity to rerun or annotate the submitted work.
Our inference is that explicit test explanations make recorded edits easier to interpret. This is a communication recommendation, not evidence about the employer's scoring weights. Your responsibility is to make the work understandable while the session is active.
Establish the execution contract before the algorithm
At the start, distinguish the requested function from the surrounding runner. A correct function that is never called produces no useful execution evidence. A print statement may demonstrate output locally while failing a task that expects a return value.
Our rehearsal checklist is deliberately small: identify the function signature, valid input shape, return type, mutation policy, and one expected result. Read the supplied code before replacing it. If the employer provides a harness, preserve its entry point and explain any modification.
Run the smallest meaningful example once execution is permitted. Confirm that the output corresponds to the current code and chosen input. Old output can remain visible after an edit; a previous success does not validate the revised function. Label your next run verbally: “I changed the overlap condition, and this run checks touching endpoints.”
Do not invent installed packages or runtime versions. Use the visible environment and permitted tools. When a library matters, state the dependency and confirm availability before making the solution depend on it. A standard-library implementation can be a useful baseline, but it is a design choice rather than a platform requirement.
Define closed intervals with two discriminating examples
The following exercise is original preparation, not a reported CodeInterview employer question. Accept a list of integer endpoint pairs, each with start <= end, and return a sorted list of disjoint closed intervals representing their union. The input may be unsorted and must remain unchanged.
Closed intervals include their endpoints. Therefore [1, 2] and [2, 3] overlap and merge to [1, 3]. In contrast, [1, 2] and [3, 4] remain separate under this contract: we do not merge integer-adjacent ranges merely because no integer lies between 2 and 3.
That second example prevents an accidental change to the problem. A scheduling task using half-open ranges or a requirement to coalesce adjacent integer runs could produce different answers. Clarify the representation rather than treating “intervals” as a complete specification.
The other discriminating example is containment: [1, 10] followed by [2, 3] must remain [1, 10]. Replacing the accumulated end with the new end would shrink the union. Before writing the loop, say what state you maintain: the last merged interval covers all overlapping intervals encountered in the sorted prefix.
Implement the merge and explain its invariant
This original Python function copies endpoint pairs, sorts them, and either opens a new interval or extends the last one. It rejects reversed endpoints under the declared interface.
def merge_closed(intervals):
pairs = []
for start, end in intervals:
if start > end:
raise ValueError("reversed interval")
pairs.append((start, end))
pairs.sort()
merged = []
for start, end in pairs:
if not merged or start > merged[-1][1]:
merged.append([start, end])
else:
merged[-1][1] = max(merged[-1][1], end)
return merged
Explain the branch in words. If the next start is strictly beyond the accumulated end, the ranges are disjoint. Otherwise they overlap, including equality at a shared endpoint. Taking the maximum end preserves a containing interval and extends a partially overlapping one.
Sorting means later starts cannot move backward. Consequently, an interval disjoint from the last merged interval cannot overlap an earlier completed interval. That is the reason checking only the last interval is sufficient; it is not just a familiar coding pattern.
For n intervals, sorting dominates the usual O(n log n) time bound. The copied pairs and result require O(n) additional space. If the interviewer permits input mutation or supplies already-sorted input, explain how that changes the implementation and cost. Do not claim the current code is constant-space.
The function assumes well-formed pairs of integer endpoints. Reversed endpoints are checked; arbitrary malformed objects are outside this exercise's input contract. If a follow-up requires public API validation, expand the contract and tests explicitly instead of implying comprehensive validation already exists.
Make terminal output demonstrate specific properties
This exact function and a matching harness were executed offline. We did not run a hiring session or test CodeInterview's execution service. The six cases below produce a short test log with a separate expected answer for each property.
cases = [
("empty", [], []),
("singleton", [(5, 5)], [[5, 5]]),
("touching", [(2, 3), (1, 2)], [[1, 3]]),
("gap", [(1, 2), (3, 4)], [[1, 2], [3, 4]]),
("nested", [(2, 3), (1, 10)], [[1, 10]]),
]
for name, data, expected in cases:
before = list(data)
actual = merge_closed(data)
assert actual == expected, (name, actual, expected)
assert data == before, (name, "input changed")
print(name, "PASS", actual)
try:
merge_closed([(4, 2)])
except ValueError:
print("reversed PASS")
else:
raise AssertionError("reversed endpoint was accepted")
All six cases passed, including rejection of reversed endpoints. We also checked permutation invariance on a three-interval fixture and idempotence after converting the result back to endpoint pairs. These additional checks support ordering independence and stable normalization; they do not prove every possible implementation property.
Explain what a failing assertion means before editing. If touching intervals remain separate, inspect the comparison at the boundary. If the nested case shrinks to [1, 3], inspect end preservation. If the return value is right but the caller's list changed, inspect sorting ownership.
A useful live test log states the input, expected result, actual result, and hypothesis. Reading “PASS” aloud without explaining the property tells the interviewer less. Likewise, several similar normal examples can all pass while leaving the important equality branch untested.
Handle execution and communication trouble separately
Our recovery recommendation separates three states: the code visible in the pad, the outcome of the most recent run, and whether the interviewer can hear your explanation. Evidence about one state does not establish the others.
If execution appears stalled, state which test you attempted and what output is currently visible. Do not treat a pending run as a pass. Follow the interviewer or available support route before refreshing, changing language, or launching competing runs. Preserve the current problem context and identify the last confirmed result.
If audio fails while the editor remains usable, use the agreed communication channel to describe the issue and the last confirmed step. If the pad disconnects, distinguish your last visible code from a confirmed saved state. Avoid assuming that rejoining extends the employer's time limit or grants access after the session ends.
These are proposed recovery behaviors, not a verified guarantee of persistence under every failure. A clear final handoff can say: “The touching and nested cases passed; the large-input run is still pending.” That is more accurate than claiming the solution passed all tests because the code looks finished.
Treat AI features as a capability, not permission
The official product tour describes AI Assist inside the collaborative room, with prompts and responses visible and saved. It also describes additional shell, browser, and database modes. Their availability in the product does not establish that your invitation enables or permits them.
Confirm the session rules before using assistance. If AI use is explicitly allowed, explain how you validate a suggested change against the contract. An assistant that changes > to >= in our merge branch breaks the touching-endpoint requirement, even if the generated code is tidy.
Our suggested AI-allowed rehearsal is to request a counterexample, then check it independently with the original harness. Keep ownership of the final behavior and explain any rejected suggestion. If assistance is not allowed, rehearse the same reasoning beforehand and use only permitted resources during the assessment.
Practise a complete edit, run and explanation cycle
| Question | What to explain during a run |
|---|---|
| Merge Overlapping Closed Intervals into a Sorted Disjoint List | Why touching closed endpoints merge and nested ranges cannot shrink |
| Check an Interval Against Existing Intervals for Conflicts | Which endpoint convention defines a conflict |
| Intersect Two Sorted Lists of Disjoint Intervals | How two sorted inputs affect progression and boundary equality |
| Convert Sampled Call Stacks into Timestamped Function Start and End Events | How the observed samples support start and end events |
| Implement a simple service with tests | Which assertions establish the service's required behavior |
Rehearse one complete cycle: clarify the contract, predict a boundary result, run the test, and explain the evidence. Then change one assumption and identify which code and assertions must change with it.
Sources and Further Reading
- CodeInterview Help: getting started for candidates
- CodeInterview Help: getting started for interviewers
- CodeInterview: code editor and recorded playback
- CodeInterview: product tour and AI Assist
- CodeInterview: separate coding-test product
References checked October 4, 2026. Original Python fixtures were executed offline. Employer rules, enabled modes and permitted assistance come from the actual invitation.