Sample report
Coding interview debrief
A fictional example of your post-interview report. How reports work.
Overview
Overall
Lean hire · Strong band
Medium bar
Strong problem solver for mid level. Testing discipline is the gap.
Reached the optimal sort-and-sweep approach for Merge Intervals with one minor nudge and stated complexity correctly without being asked. On Top K Frequent Elements you chose a size-k heap and explained the tradeoff against bucket sort, but time ran out before ties were handled, and the final code failed 2 of 14 tests. Most bugs were found by the test runner or the interviewer rather than by tracing.
- Problems
- 1 solved · 1 partial
- Tests
- 30 / 32 passed
- Hints
- 1 minor
- Duration
- 45:00 of 45:00
Dimension scores
Problem understanding & clarification
3/4At barAsked the questions that mattered on both problems before designing, though the empty-input case slipped through on Merge Intervals.
“Should intervals that only touch, like one to three and three to five, be merged into one?”
“If two numbers have the same frequency, does the order between them matter?”
How to improve. Add empty and single-element inputs to your clarification checklist. You asked about boundaries, not about size.
Approach & algorithm design
3/4At barReached sort-and-sweep independently and explained why sorting by start makes one pass sufficient. For Top K you chose a heap over the linear bucket-sort approach.
“Once they're sorted by start, any overlap has to be with the last interval I merged, so one pass is enough.”
“Bucket sort gets this to linear time, but the heap keeps memory at k, which matters if the input is huge.”
How to improve. When the constraints don't say otherwise, commit to the asymptotically optimal approach and raise the memory tradeoff as a follow-up.
Complexity analysis
4/4Above barCorrect, justified time and space for both solutions, offered without prompting.
“Sorting dominates, so n log n time, and the output can hold all n intervals, so linear space.”
“Counting is linear and each heap push is log k, so n log k overall.”
How to improve. Keep doing this. Next, mention how sorting in place versus sorting a copy changes the space bound.
Implementation quality
3/4At barReadable, idiomatic Python on both problems. The first Merge Intervals draft indexed into a possibly empty list.
merged = [intervals[0]]
counts = Counter(nums)
How to improve. Before running, reread your first and last few lines with an empty input in mind.
Testing & debugging
2/4Below barRelied on the test runner to find bugs. Neither the empty-input failure nor the tie-ordering failures were caught by tracing.
“Good. Now look at line 3. What does it do with an empty list?”
“Let me just run it and see what breaks.”
How to improve. Before each run, name two inputs you expect to break your code and trace one by hand.
Communication
3/4At barKept the interviewer oriented and checked in at decision points, with one long silent stretch while implementing Top K.
“I'm going to write the sweep first and come back to the sort key, does that sound okay?”
How to improve. During long implementation stretches, say what the next few lines will do before typing them.
Problem breakdown
Tests
18 / 18
Complexity
O(n log n) time
Stated correctly
Optimal
Yes
Hints
1 minor
First pass at 19:52
Approach
Sort by start, then sweep once, extending the last merged interval whenever the next one overlaps it.
Sorting dominates; the output can hold all n intervals.
Key moments
- 1:12+Clarified whether touching intervals merge
- 6:05+Stated the invariant behind the sweep
- 18:31−Empty input surfaced by the interviewer
- 19:52First fully passing run
- 21:40+Complexity stated without prompting
Nitsort() mutates the caller's list. Use sorted() or call out the side effect.
- Updating the last merged interval in place keeps the loop to a single comparison.
Tests
12 / 14
Complexity
O(n log k) time
Stated correctly
Optimal
No
Hints
None
Never fully passing
Approach
Counted frequencies, then kept a size-k min-heap of (count, value) pairs and returned it sorted by count.
Correct for the heap approach. Bucket sort reaches O(n).
Key moments
- 25:30+Asked how ties should be ordered
- 27:48+Compared the heap with bucket sort
- 31:00−Two-minute silent stretch
- 41:20−Ran the suite instead of tracing the tie case
- 45:00Time ran out with 12 of 14 passing
Failing tests
- Ties keep first-seen order
- Negative values with equal counts
MajorHeap entries fall back to comparing values on equal counts, so ties come out in numeric order instead of first-seen order.
Minorsorted(..., reverse=True) reorders ties again. Sort by count only, or carry the first-seen index.
- Counter with a bounded heap is idiomatic and easy to follow.
Strengths and next steps
Strengths
Clarifies before coding
You asked the boundary question on both problems before designing, and it shaped the comparison you wrote.
Explains why, not just what
You stated the invariant behind the sweep and justified both complexity bounds without being asked.
Weighs alternatives
Comparing the heap with bucket sort showed you know when memory can matter more than asymptotics.
Improvements
Test before you run
Both bugs in this session were found by the runner or the interviewer, not by you.
Drill. For your next five problems, write two inputs you expect to break your code before the first run, and trace one by hand.
Default to the optimal approach
On Top K you chose O(n log k) when O(n) was available and the constraints did not favor memory.
Drill. Re-solve Top K Frequent Elements with bucket sort, keeping ties in first-seen order.
Narrate long stretches
There was a two-minute silent stretch while you implemented Top K.
Drill. In your next mock, say what the next three lines will do before typing them.
Get a report on your own interview.