The technical phone screen: what the first thirty minutes decide
The technical phone screen is the cheapest round the company runs, and it exists to answer one question: is it worth spending four engineers' afternoons on this person? Nothing about it rewards depth for its own sake. Almost everything about it rewards being clear.
First, find out which kind of screen it is
“Phone screen” covers at least three different formats, and the companies that publish their process describe them quite differently. As checked on 14 Oct 2026:
- Meta describes its initial tech screen as a 45-minute conversation with an engineer. Its own prep article splits it into about 5 minutes of introductions, 35 minutes of coding — two problems on computer-science fundamentals — and 5 minutes for your questions. Remote screens use a collaborative editor, and Meta tells candidates to expect no syntax highlighting or auto-completion.
- Google says that before in-depth interviews you will typically have one or two shorter phone or video conversations with your recruiter, which “usually assess key skills” for the role. It puts the whole hiring process at roughly 6–8 weeks.
- Amazon’s SDE II prep page lists no phone screen at all: an online assessment (90 minutes for two coding questions, then 20 minutes of system-design scenarios and a short work-style survey), followed by a loop of four 55-minute interviews.
So the first preparation step is a question to the recruiter: how long is it, who runs it, is it mostly coding or mostly my experience, and what editor will we use? Recruiters answer this routinely, and the answer decides how you spend the next week.
When the screen is about your experience
Smaller companies often run a shorter, conversation-heavy screen. A typical half hour looks something like this:
- Five minutes — introductions and the role. Short.
- Ten to fifteen minutes — your own experience, probed. Usually one project from your CV, taken apart.
- Ten minutes — one small technical question. Sometimes code in a shared document, sometimes a design sketch, sometimes fundamentals.
- Five minutes — your questions, which are also part of the assessment.
The part that actually eliminates people
In that format it is rarely the coding question. It is the project conversation, and specifically one failure: being unable to say what you personally did.
Have a three-sentence version of one project ready. What it was, what was hard about it, what you did about the hard part. First person singular throughout. Then be ready for the three questions that always follow:
- “Why did you do it that way?” — they want a trade-off, not a justification. Name what you gave up.
- “What would you change now?” — “nothing” is the worst available answer. Have one honest regret with a reason.
- “What broke?” — a real incident, what it looked like in production, and how you found it.
An engineer can usually tell within a couple of minutes whether you built the thing or sat near it. That is most of what this section measures.
The coding question you cannot run
Phone-screen code is often written somewhere without a compiler you can lean on — a shared document, a bare collaborative editor, sometimes literally dictation. Meta’s own advice is to practise in a simple text editor for exactly this reason. That changes the tactics.
- Restate the problem in one sentence before writing anything, so you do not solve the wrong one.
- Ask about input size. It tells you which complexity is expected, and asking is itself a signal.
- Talk while you type. On a call, silence is indistinguishable from being lost.
- Walk one example through the finished code, out loud. If nothing runs, that trace is the only proof the thing works — and it catches the off-by-one you were about to ship.
For the habit of talking through code, see how to explain code in a live coding interview.
Two problems in thirty-five minutes
If the screen follows the coding-heavy shape Meta describes, the arithmetic is unforgiving: roughly seventeen minutes per problem, including clarifying, writing and tracing. Candidates who treat the first problem as the whole interview often never reach the second.
Three habits keep you on schedule. Get a correct, plain solution down before polishing it — a working O(n log n) answer beats an unfinished O(n) one. State the time and space complexity as soon as the code is done rather than waiting to be asked. And when the first problem is finished, say so and move on; do not spend five spare minutes renaming variables while the clock runs on the problem you have not seen yet.
What interviewers are told to look for
Published guidance from large employers is consistent on this. Meta tells candidates to ask clarifying questions and to think out loud, because interviewers watch how you solve the problem, not just whether you reach the answer. Google’s interview tips say that rephrasing a question or asking for clarity is fine, as is asking for a few moments to collect your thoughts, and that the interviewer is looking at the thought process rather than only the answer. Google also says it uses the same rubrics for every candidate for a role.
Read together, that means a quiet, correct solution scores worse than you expect, and a narrated, slightly slower one scores better. The rubric can only record what the interviewer heard.
Nerves are part of what is being measured
It is not your imagination that you perform worse with someone watching. In a 2020 study by researchers at NC State and Microsoft, 48 computer-science students solved a technical problem either on a whiteboard in front of an interviewer or alone in a private room; the authors report that performance was reduced by more than half simply by being watched.
The practical lesson is to rehearse the condition, not just the content. Solve a few problems out loud with a friend watching, or record yourself with a timer running. The first sessions feel awkward; by the fifth, talking while thinking stops costing you attention. If you interview in English as a second language, rehearse the phrases as well: see technical interview in English as a non-native speaker.
The logistics people underestimate
Take the call somewhere quiet with a headset, not on speaker in a kitchen. Keep the job description open, plus your own CV — you will be asked about a line from it and “let me remember” costs you more than it should.
If there is a shared document or editor link, open it before the call rather than during it. Three minutes of “can you see my cursor” comes out of your coding time, not theirs.
Check the rules, too. Google’s interview-tips page states that Google Search and AI tools are not permitted during its interviews. Other employers set their own policies, so if you are unsure what is allowed in a given round, ask the recruiter beforehand.
Your questions are scored too
“What does the on-call rotation look like?”, “what is in flight for this team this quarter?”, “what does the code review process look like day to day?” Those read as someone who has done the job. “What is the culture like?” reads as someone filling a slot.
And ask what the next round contains. It is a perfectly normal question, and the answer tells you exactly what to prepare for.
After the call
Write down the questions you were asked and the places you hesitated while they are fresh; that list is a better study plan for the next round than any generic topic list. Then do not read too much into a quiet inbox. Amazon says it shares an interview outcome within five business days of the loop, while Google warns that it may be several weeks before a recruiter can share a decision. A few days of silence after a screen is normal.
Taking the screen at your desk? You can keep the answers on a second screen, see your AI interview assistant, on your phone. If the screen turns into a shared coding pad, read what to expect in a CoderPad interview. If an outside Interview Engineer runs it for the employer, read what to expect in a Karat interview.
Sources
- Meta Careers — Preparing for your software engineering interview at Meta (format and timing of the tech screen, editor, tips; checked 14 Oct 2026)
- Meta Careers — Preparing for your technical screen (45-minute conversation with an engineer; checked 14 Oct 2026)
- Google Careers — How we hire (recruiter conversations, 6–8 weeks, same rubrics; checked 14 Oct 2026)
- Google Careers — Interview tips (clarifying questions, thought process, no AI during interviews; checked 14 Oct 2026)
- Amazon Jobs — SDE II interview prep (online assessment, four 55-minute interviews, outcome timing; checked 14 Oct 2026)
- Behroozi et al., “Does stress impact technical interview performance?”, ESEC/FSE 2020 (checked 14 Oct 2026)
FAQ
How long is a technical phone screen?
Commonly thirty to forty-five minutes. Meta, for example, describes a 45-minute screen with an engineer: about 5 minutes of introductions, 35 of coding and 5 for your questions. Formats vary, so ask the recruiter for the exact one.
Will there be coding on a phone screen?
Often. Meta’s screen is mostly coding — two problems in about 35 minutes, in a collaborative editor without auto-completion. Smaller companies may ask one short question in a shared document. Where code is not executed, tracing an example out loud is what demonstrates correctness.
Is the phone screen with a recruiter or an engineer?
A technical phone screen is normally with an engineer — Meta says so explicitly — and sometimes with a hiring manager. Recruiter calls are usually separate, though Google notes that its shorter recruiter conversations can also assess key skills for the role.
What is the most common reason people fail it?
Not being able to explain their own project in plain language — what they personally did, what the trade-off was, and what they would change now.
Can I use AI tools during a phone screen?
It depends on the employer’s rules. Google’s interview-tips page states that Google Search and AI are not permitted during its interviews. If you are unsure what is allowed in your round, ask the recruiter beforehand.