Coding interviews: an explanation, not a solution
Whisperer can read the task off your screen and talk you through the approach. What it deliberately does not do is hand you the finished implementation while somebody is watching you think — because thinking out loud is the thing being assessed.
A dedicated coding role · a vision mode that reads the screen
- Explaining an approach you half-remember
- Naming the complexity you just derived by hand
- Reading a task written in your second language
- Rehearsing out loud with something that never gets bored
- Producing the solution while they watch you type
- Answering the follow-up about your own code
- Anything the stated rules of the round forbid
- Anything you could not reproduce on Monday
Mechanism
Reading the task, not the room
Coding rounds put the task on a shared screen, which is text an assistant cannot hear. A screenshot goes to a vision mode instead: it reads the statement, the examples and the constraints, and can work with several screenshots when the problem does not fit on one.
A separate coding role handles the answer, on a model chosen for code rather than for conversation.
- Capture The task from the screen A screenshot, or several, for a statement that scrolls. The constraints matter as much as the statement and are usually below the fold.
- Answer The coding role Its own model, chosen independently of the one answering in conversation, because the two jobs reward different things.
- Yours The narration Say what you are doing and why as you write. That is the recorded signal the round is actually graded on.
Honest position
We would rather you used it before the interview
Not out of squeamishness. A candidate who leans on an assistant through a live coding round gets a job they then have to do without it, and the gap shows up in week two — at which point it is a worse problem than a failed interview would have been.
Used as a rehearsal partner it is genuinely strong: infinite patience, no embarrassment, and it will let you explain the same approach four times until the explanation is clean.
Limits
Two practical ones
-
First
Monitoring software sees processes, not pixels
The overlay is excluded from screen capture, which says nothing about proctoring tools that inspect the process list. Where the rules of an assessment are stated, they apply regardless of what is technically invisible.
-
Second
One recording at a time, not an archive migration
A finished recording can be uploaded: the Meetings section takes one file up to 25 MB — mp3, m4a, wav, ogg, flac, aac, plus mp4 and webm, from which the audio track is used. What is missing is bulk upload of a whole archive; and it spends the same minutes a live call does.
Questions
What people ask first
Can it read the problem from a shared screen?
Yes, through a screenshot — the vision mode reads statements, examples, diagrams and code. For a long problem, take several and send them together.
Will it just write the solution?
It can produce code, and on a live assessment that is the use we advise against. The follow-up question about your own implementation is where it collapses, and it collapses loudly.
Is the coding model different from the chat one?
Yes, if you want it to be. Models are set per role, and the coding role is independent of the one used for conversation.
Can proctoring detect it?
It may. Proctoring usually watches the process list rather than the screen, and no window-level exclusion hides a running process.
What is the best way to use it for interviews?
Rehearsal. Explain your approach out loud against it until the explanation is tight, then go in without needing it.
Practise the explanation, not the answer
Take a problem you have already solved and explain it aloud four times. The fourth one is the one you want in the room.