Interviews
What interviewers score while you share your screen
The code is only one part of a live round. The interviewer is also recording how you frame, choose, verify and recover while the screen is shared.
4 min read
You finish the function. The tests pass. The interviewer writes no hire.
That result feels irrational if you believed the round was a private coding task with somebody watching. It was not. It was an evidence collection exercise, and the interviewer could only score what became visible while you worked.
A correct solution can still leave the packet empty. The code proves that one path worked. It does not automatically prove that you understood the prompt, chose deliberately, noticed risk, tested the important boundary or could recover when the first approach failed.
Those are separate signals. In a live round, silence hides nearly all of them.
The interviewer needs sentences they can write down
After the call, the interviewer does not submit your repository. They submit notes.
Those notes need observable evidence: clarified ambiguous requirements, identified a failure mode before implementation, compared two approaches, changed direction after a test disproved an assumption, explained the cost of the final choice.
Now compare that with the notes produced by a silent candidate: completed most of the task, needed one hint, code passed the examples.
The second note may describe a capable engineer. It does not contain enough evidence to argue for a senior hire when another candidate made the reasoning visible.
Your job is not to narrate every keystroke. Your job is to expose the decisions that change the evaluation.
The first score happens before you type
A prompt arrives with missing information because real work arrives with missing information.
The weak response converts the words directly into code. The stronger response names the ambiguity that changes the design. Are duplicate inputs valid? Can the collection be empty? Does order matter? Is this expected to fit in memory? What should happen when the dependency fails?
Do not ask a ceremonial list of questions. Ask the one whose answer changes what you build. Then state the working assumption if the interviewer leaves the choice with you.
That gives the interviewer two pieces of evidence before the editor opens: you can find the real boundary, and you can keep moving when nobody specifies it for you.
Explain choices at the moment they become expensive
Candidates often explain too much when nothing has been decided, then go quiet when the important choice appears.
I am creating a variable is noise. I am keeping the lookup table outside the loop because rebuilding it would turn the repeated search into quadratic work is evidence.
The useful narration has a simple shape: choice, reason, cost.
I will start with the synchronous version because it makes the state transition testable. If the operation becomes remote, I would move the boundary behind an async interface. The cost is one abstraction we do not need yet.
That sentence is short. It tells the interviewer that the simple version was selected rather than accidental, and that you can see the next constraint without solving a problem the prompt did not ask for.
Verification is part of the solution
Running the supplied example is not a verification strategy. It is confirmation that the happy path still resembles the prompt.
Before you run anything, name the cases that could disprove your approach. Empty input. Duplicate values. Cancellation. A late response. A stale cache. A view that disappears before work completes. The relevant boundary depends on the task, but the interviewer is looking for whether you can find it.
Then test the smallest case that separates correct reasoning from a lucky output. Say what you expect before running it. If it fails, the result becomes useful evidence because the interviewer can see you update the model rather than patch blindly.
A test that changes your mind is worth more than five examples that congratulate the code.
A stall is not the failure
Everybody stalls. The scored event is what happens next.
The damaging version is silent repetition: edit, run, stare, undo, try the same shape again. The interviewer sees activity and cannot see a method.
Use a recovery line instead: I am repeating the same assumption, so I am going to stop coding and reduce this to the smallest failing case. Or: this approach makes ownership unclear, so I am stepping back to name which object must outlive the operation.
The line does not pretend the mistake did not happen. It turns the recovery into evidence of debugging discipline.
If you need a hint, integrate it explicitly. Do not say yes and continue as if it was your idea. State what the hint changes and which part of the previous model was wrong. Interviewers distinguish between receiving information and using it.
What to rehearse
Recording yourself solving a problem is more useful than completing another silent problem set.
Score the recording on five transitions: how you framed the prompt, the first meaningful choice, the first verification, the first wrong assumption and the recovery. If one of those moments contains no spoken evidence, the interviewer cannot reliably credit it.
Remove narration that merely reports syntax. Add one sentence where a decision becomes expensive. Keep the final summary to three things: what works, what you verified and what you would change with more time.
Correct code remains required. It is the entry fee. The round is decided by whether the interviewer can see the engineer responsible for producing it.
Where this fits
This essay belongs to the Pass interviews path: Swift, SwiftUI, concurrency, architecture, mobile system design, live coding and behavioral answer systems.
