Working Under Observation

The skill underneath every format in this roadmap

Strip away the specifics of bug-squash, integration, machine coding, and AI-allowed pairing, and one behavior is graded in every single one: can you work productively while someone watches, and can they follow what you're doing without having to stop you and ask? This is not a soft skill bolted onto the "real" technical evaluation — in a live round, it is part of the technical evaluation, because an interviewer who can't follow your reasoning has no way to distinguish a strong candidate who's quiet from a weak one who's lost. Silence is unscoreable, and unscoreable reads as risk.

Clarify before you commit to an approach

Every format in this roadmap hands you a prompt with deliberate ambiguity — not because the interviewer is being cagey, but because judging how you handle ambiguity is the point. Real tickets, real bug reports, and real API integration tasks are always underspecified; asking good questions is the job, not a warm-up before the job. Concretely:

• Restate the goal in your own words before writing code. "So the fix should make X true without changing Y's existing behavior — is that right?" surfaces misunderstandings for pennies, versus discovering them 40 minutes in for the full cost.
• Ask about scope explicitly. "Should I handle the case where the input is empty, or is that out of scope for this pass?" — a specific, bounded question, not "any other requirements?" which invites nothing useful back.
• State your assumptions out loud even when you don't ask. If you decide unilaterally that a field is always present, say so: "I'm assuming this field is always populated based on the schema — flag me if that's wrong." This converts a silent, undiscoverable risk into a two-second checkpoint.

Narrate continuously, not just at the end

The single most common failure mode reported across bug-squash, pairing, and integration rounds isn't wrong code — it's long, unexplained silence while the interviewer has no idea whether you're deep in productive thought or completely lost. A useful habit: say what you're about to do before you do it, not after.

• "I'm going to add a print statement here to check what this variable actually holds at runtime" — before you add it, not after you've already stared at output for thirty seconds.
• "I think the bug is upstream of this function, based on the log line — let me check the caller" — states a hypothesis, not just an action.
• "This isn't working the way I expected — let me reconsider" is a perfectly good thing to say out loud. Narrating a wrong turn and correcting it looks far better than the interviewer discovering the wrong turn on their own, three minutes later, with no idea why you're still down that path.

Manage the clock like a resource, not a threat

Every format here is time-boxed, and the clock rewards a specific discipline: get something end-to-end working before polishing anything. A rate limiter that handles the happy path in 40 minutes, with 20 minutes left to discuss edge cases and add one, beats a beautifully abstracted rate limiter that's still not running when time is called. This is the same "MVP first" discipline the Machine-Coding Execution Speed topic covers in depth — it applies just as much to a bug-squash or integration round as to a machine-coding one.

A practical checkpoint habit: at roughly the halfway mark, say out loud where you are relative to the goal. "I'm about halfway through the time and I have the core flow working but haven't handled the error case yet — I'll prioritize that next." This does two things: it gives the interviewer a chance to redirect you if you're solving the wrong problem, and it demonstrates the self-awareness that a silent candidate can't.

Recovering when you're stuck, out loud

Getting stuck is expected and not, by itself, a bad signal — how you handle it is. The recovery pattern that reads well in every format:

1. Say exactly where you're stuck, specifically: "I expected this call to return a list, but it's returning None and I don't see why yet" — not a vague "I'm not sure this is working."
2. Rephrase the immediate sub-goal, smaller than the original ask: "Let me just confirm what this function actually returns before I assume anything else."
3. Ask one focused question if you're still stuck after a genuine attempt — not a request for the answer, but for the one piece of information that would unblock you: "Is this API supposed to be idempotent, or could a retry double-charge here?"

What reads badly, across every format researched for this roadmap: going silent for an extended stretch, defensively insisting a wrong approach is fine when an interviewer gently pushes back, and — especially in AI-allowed rounds — pasting a large assistant-generated block and visibly not knowing what it does. All three are variations on the same underlying failure: making yourself unreadable to the person whose job is to read you.