Mock interview breakdown: she solved it and still got "no hire". Here is the scorecard.

Kunal and I have been doing free mock interviews on weekends this month. One of them taught me more than the others, so with the candidate's permission (and details changed) here is the full breakdown. She solved the problem. Her code was correct. In a real loop she would have got a "lean no hire". Let us see why.

The question type

A merge intervals variant. Medium difficulty. Nothing exotic.

Minute by minute

• 0-3: started coding immediately. Did not ask whether intervals arrive sorted, or whether [1, 3] and [3, 5] should merge (touching intervals).
• 3-18: sort + merge. Clean, correct code.
• 18-25: Kunal asked a follow-up: what if intervals arrive one at a time as a stream? She defended the original solution instead of listening to the question.
• 25-35: Kunal tried an input with touching intervals. Bug. She fixed it silently without saying what was wrong.
• 35-45: no complexity analysis until we asked for it.

The scorecard

Most companies score something like four dimensions on a 1 to 4 scale:

• Problem solving: 3
• Coding: 3
• Communication: 1
• Testing and verification: 1

Overall: lean no hire. Not because she cannot code. Because the debrief question at most companies is some version of "would I want to debug production with this person at 2 am?" and the panel did not get to see how she thinks.

The code, with the assumption made visible

int[][] merge(int[][] iv) {
    Arrays.sort(iv, (a, b) -> Integer.compare(a[0], b[0]));
    List<int[]> out = new ArrayList<>();
    for (int[] cur : iv) {
        // "<" means touching intervals like [1,3] and [3,5] MERGE.
        // If the interviewer says touching should stay separate, use "<=".
        if (out.isEmpty() || out.get(out.size() - 1)[1] < cur[0]) {
            out.add(cur);
        } else {
            int[] last = out.get(out.size() - 1);
            last[1] = Math.max(last[1], cur[1]);
        }
    }
    return out.toArray(new int[0][]);
}

One character decides the touching case. That is why you ask.

What she changed

1. Say assumptions out loud before coding. "I'm assuming touching intervals merge, is that right?"
2. Dry run your own small example before saying "done". Include an edge case: empty input, a single interval, touching, fully nested.
3. When the interviewer asks a follow-up, stop and take it. A follow-up is a hint, not an attack.
4. When you find a bug, narrate it. "My condition is wrong for touching intervals, fixing it." That is a plus, not a minus.
5. State time and space complexity before anyone asks.

The redo

We did a second mock a week later with a different problem. Her solution was a little slower. She stated every assumption, tested three edge cases without being asked, and took the follow-up calmly. Strong hire from both of us.

Nothing about her DSA changed in one week. Only how much of her thinking we could see.

Time: O(n log n) for the sort. Space: O(n) for the output.