What is a technical phone screen, and what decision does it gate?
answer
- A filter, not the full evaluation
- Remote call, roughly 45 to 60 minutes
- One or two problems in a shared editor
- Screener recommends advance, reject, or borderline
basics
~20 sA technical phone screen is a 45-to-60-minute remote call where a candidate solves one or two small coding problems in a shared editor with an engineer listening. It gates the onsite: the screener recommends advance or reject.
solid answer
~40 sA technical phone screen is a remote call, commonly 45 to 60 minutes, in which an engineer gives you one or two small coding problems inside a shared browser editor while you talk through what you are doing. It is a filter rather than a full evaluation: its job is to decide whether the company should spend a panel day of several people's time on you. The screener normally leaves the call with a short written recommendation — advance, reject, or borderline — attached to the session link and whatever code you left in it. Because the sample is small and the clock is short, the recommendation usually turns on whether you produced something working and stayed legible while doing it, not on whether you found the most elegant possible solution.
go deeper
Know the shape before you join: a remote call under an hour, one or two coding problems, a shared browser editor, and an engineer listening. Show up early enough to test audio and open the session link.
Be able to explain why this stage is deliberately cheap and noisy, and what that implies: it filters rather than ranks, so a finished modest solution beats an unfinished ambitious one.
Show that you manage the stage rather than endure it — confirm the format at the start, keep the session in a state you would be happy to have archived, and adapt when the screener has two problems instead of one.
You will likely be running these as well as sitting them. Own the tradeoff that a 45-minute sample is cheap and noisy, and that the recommendation you write is read by people who were not on the call.
## What the stage is A technical phone screen is the first stage of most engineering loops where an engineer, rather than a recruiter, evaluates you. Despite the name, almost nobody screens by voice alone any more: you join a call and simultaneously open a **shared-editor session link** — a browser page that you and the screener both type into, with the screener watching your keystrokes live. The call typically runs 45 to 60 minutes, and one or two small coding problems fill most of it. It sits after any recruiter conversation and any automated assessment, and before the panel day. Its purpose is economic. A panel day consumes four or five engineers for an hour each plus a debrief; a screen consumes one engineer for under an hour. Companies accept that a short screen is a noisy signal precisely because it is cheap, and they tune it to be a **filter**, not a ranking. ## What actually happens on the call A common shape, using an illustrative invite of 52 minutes at a developer-tools vendor hiring a mid-level full-stack engineer: | Segment | Roughly | | --- | --- | | Joining, audio check, opening the session link, brief intros | 6 minutes | | First problem: reading it, agreeing on the approach, writing, checking | 23 minutes | | Second problem, if the screener has one | 19 minutes | | Your own questions and logistics | 4 minutes | Some screeners bring one problem and go deeper on it; some bring two deliberately, so that a candidate who stalls on the first still generates signal on the second. You usually cannot tell which you have unless you ask, and asking near the start is normal and welcome. The editor itself comes in two flavours, and the difference matters more than most first-timers expect. Some session links **execute** code and print output or run a small set of tests; others are plain collaborative text with syntax colouring and no run button at all. What counts as evidence of correctness changes completely between the two. ## What the screener is evaluating Interviewers on this stage are usually working engineers who volunteered or were rostered, not specialists in assessment. They are answering one question for the debrief: *would a panel day on this person be a reasonable use of five engineers' time?* In practice they watch for four things: 1. **Did something work?** A finished, checked solution to a modest problem is the single strongest signal available in this format. 2. **Was the process legible?** The screener has to write a paragraph justifying a recommendation. A candidate whose reasoning was audible is easy to write up; a silent candidate produces a thin, hedged note that reads as weak even when the code was fine. 3. **Was the clock respected?** Running out of time with nothing runnable is the most common way a competent candidate fails this stage. 4. **Were basics present?** Reading the problem, handling an empty or single-element input, noticing an obvious mistake without being told. ## What is recorded and what happens next After the call the screener writes a short recommendation, typically within a day, and the shared-editor session link is usually archived with it — the code you left behind is read again by whoever reviews the decision. That is why the *final state* of the session matters more than the best state it passed through: nobody replays your keystrokes. Outcomes are commonly advance, reject, or borderline; a borderline result often triggers a second screen rather than a rejection. The recruiter, not the screener, communicates the result, and a wait of a few business days is normal at most companies. A screener will almost never tell you the outcome on the call, and pressing for it reads poorly. ## Common misreadings - **Treating it as a chat.** It is a coding evaluation with a recruiter-sized invite on the calendar. - **Assuming the listener cannot read code.** The person on the other end usually writes code for a living and is watching your editor in real time. - **Optimising for elegance.** The stage rewards a working answer that was reached visibly. Spending the whole clock reaching for the optimal solution and leaving nothing that runs is a rejection even when the abandoned approach was correct in principle. - **Skipping setup.** Six minutes lost to a microphone or a session link that will not load is six minutes off the problem, and it is your problem, not the screener's. ## How to prepare for the format itself Practice typing code into a plain browser editor without autocomplete, out loud, against a timer. The subject matter belongs to your algorithm practice; what this stage adds is the constraint of doing it in an unfamiliar editor, on a call, with a stranger, in under an hour.
- Who is usually on the other end of a technical phone screen?Almost always a working engineer, often from the team or a nearby one, sometimes drawn from a rostered pool of volunteer screeners. It is rarely the hiring manager and essentially never the recruiter. Assume the person watching your shared-editor session link writes code daily and will read what you leave in it afterwards.
- What evidence from the call does the screener keep afterwards?Typically two things: the archived shared-editor session link with whatever state the code was in when the call ended, and a short written recommendation. Nobody replays your keystrokes, so the final contents of the session are the artefact. Leaving a half-deleted rewrite behind is materially worse than leaving a simpler solution that ran.
- How soon do candidates usually hear back after a technical phone screen?A few business days is common, though it varies widely by company and by how many candidates are in flight. The recruiter delivers the outcome, not the screener, so asking the screener on the call for a verdict is misplaced. If a stated timeline passes, a single polite check-in with the recruiter is normal.
saying these in an interview costs you the question
- Treating the screen as a casual chat and preparing nothing
- Assuming the screener cannot read code in real time
- Believing only the final answer is evaluated, not the process
- Chasing an optimal solution and leaving nothing runnable behind
- Pressing the screener for a verdict at the end of the call