What happens in a 30-minute technical phone screen?

Roughly three minutes of introductions, three to five minutes on one project from your resume, eighteen to twenty minutes on a single medium coding problem in a shared editor, and three minutes at the end for your questions. The interviewer usually has a hard stop and another call after yours, so plan for the round to end at minute twenty-eight rather than thirty.

How long should my introduction be in a phone screen?

Ninety seconds to two minutes, and never more than three. Every minute you spend on your background is a minute taken off the coding block, which is the part you are actually graded on. End the intro on the project you most want to be asked about, so the interviewer's follow-up lands on ground you have prepared rather than something random from page two of your resume.

What clarifying questions should I ask before coding on a phone screen?

Four, in one breath, in under a minute: what is the input size and range, what exactly should the function return, do you want a working solution first or the optimal one straight away, and can I run code in this pad or is it read-only. The last one matters most, because finding out at minute twenty-five that nothing executes leaves you no time to test by hand.

What should I say while I am coding in a phone screen?

Narrate the next line before you type it, and never go more than about fifteen seconds without speaking. The interviewer is on audio only, so a silent pause is total silence to them and reads as being stuck. If you genuinely need to think, say so out loud: give me twenty seconds on the index bookkeeping. Announced silence is fine, unexplained silence is not.

Should I use a Bluetooth headset for a technical phone screen?

Prefer wired. When a Bluetooth headset's microphone opens, most devices drop from the stereo audio profile to a hands-free profile, which narrows the channel in both directions for the whole call, so the interviewer hears a thinner version of you. A wired USB or 3.5mm headset avoids the switch and cannot run out of battery at minute twenty-two.

What questions should I ask at the end of a technical phone screen?

Two short ones, aimed at the engineer rather than the company. What does the next stage look like and how many rounds is it, and what is the thing about this codebase that surprises new joiners. Skip anything answered on the careers page. Saying you have no questions is the most common way to end a strong screen on a flat note.

Technical Phone Screen: What to Expect in a 30-Minute Call

Thirty minutes almost always splits the same way: about 3 minutes of introductions, 3 to 5 minutes on one project from your resume, 18 to 20 minutes on a single medium problem in a shared editor, and 3 minutes at the end for your questions. The interviewer has a hard stop and usually another call straight after, so the round really ends at minute 28. Nearly every failed screen is a budget failure rather than a knowledge failure: eight minutes of life story leaves thirteen minutes for a problem that needs eighteen. Here is the map, the specific way each slot goes wrong, and the sixty seconds of clarifying questions that buy the time back.

Where the thirty minutes actually goes

Read the calendar invite first. Thirty minutes with a named engineer and a pad link means one coding problem. Thirty minutes with a recruiter and no link means no coding at all. If the invite is 45 or 60 minutes, expect two problems or one problem plus extensions, and stretch the blocks proportionally.

Minutes	What is happening	The failure mode waiting here
0-3	Names, team, a short version of what you do now. The interviewer is also opening the pad and finding their notes.	The chronological life story from university onwards. Eight minutes here is the most common way to lose this round, and you will not feel it happening.
3-8	One project from your resume, picked by them or offered by you. Two or three follow-ups on a decision you made inside it.	Saying "we" for twelve sentences straight, so the interviewer cannot tell what you built and the block scores nothing. Also: listing the stack instead of naming a trade-off.
8-26	One medium problem, pasted into a shared pad. Sliding window, hash map counting, two pointers, a light tree or graph traversal. Rarely anything needing dynamic programming.	Silent coding, and typing before the approach is agreed. Both are recoverable at minute 10 and fatal at minute 22.
26-30	Your questions, then next steps and who contacts you. This is also where the interviewer decides how enthusiastic the write-up sounds.	"No, I think you've covered everything." Or a question the careers page answers in one line. Then not writing down the next step they named.

Glance at the clock twice only: at minute 8, to check the coding block is starting on time, and at minute 20, to decide whether you are testing or still writing. More than that carries down the line, because your speech rhythm changes every time you look away.

The sixty seconds of clarifying questions that buys back five

Ask these in one breath, straight after restating the problem, then stop talking and let them answer. The set takes under a minute and routinely saves five, because each one removes a rewrite.

"What size is the input, and what range are the values?" Decides whether an O(n^2) answer is acceptable, and closes off the negative-numbers ambush that arrives at minute 20.
"What exactly should this return, the value or the thing itself?" Length or the substring, the index or the element, true or the count. That ambiguity is deliberate in a lot of phone screen problems.
"Do you want a working solution first, or should I go straight for the optimal one?" The highest-value question in the round. Interviewers genuinely differ, and guessing wrong costs you either eight minutes of brute force nobody wanted or a stalled silence while you reach for something clever.
"Can I run code in this pad, or is it read-only?" Ask at minute 9, not minute 25. Pads built for interviews normally execute common languages, but a plain shared document runs nothing, and finding that out with four minutes left leaves you no way to test.
"Should I match a signature you have in mind, or pick my own?" Ten seconds, and it prevents the rename at minute 24.

One more, worth asking at minute 2: "Do you want to keep a few minutes at the end for my questions, or shall I code until we run out?" It sounds administrative. What it does is make the interviewer say the budget out loud, so you are both working to one clock instead of two private ones.

Inside the eighteen-minute coding block

Worked on a genuine phone screen staple, the longest substring without repeating characters. The problem is not the point. The shape of the eighteen minutes is.

0:00-0:45 · restate it in your own words

"So, given a string, I return the length of the longest stretch with no character repeated inside it." Forty-five seconds, and it catches the misunderstanding that would otherwise cost you fifteen. On an audio-only call it does a second job: it proves you heard the problem correctly over a compressed line.

0:45-2:00 · the clarifying set

ASCII or full Unicode, case sensitive or not, what an empty string returns, length or the substring itself. Then stop. Past the one-minute mark, more questions stop reading as thorough and start reading as stalling.

2:00-4:30 · brute force out loud, then the real approach, then buy-in

"The obvious version checks every substring for duplicates, so that is O(n^2) windows times O(n) to check each. I would rather slide a window and keep a map from character to the last index I saw it at, which is one pass, O(n) time and O(k) space where k is the alphabet size. Does that sound like the direction you want?" Say the brute force, do not type it. Then wait for the yes. That pause is the cheapest insurance in the round: if they wanted something else, you have lost fifteen seconds instead of nine minutes.

4:30-12:00 · code it, narrating one line ahead

Say what the next line does before you type it: "left pointer at zero, best at zero, and a dictionary from character to last index." Never go more than about fifteen seconds without speaking. When you need real thinking time, announce it: "give me twenty seconds on the index bookkeeping." Announced silence is fine. Unannounced silence on an audio-only call is a person who has disappeared, and the interviewer's only options are to wait awkwardly or interrupt you mid-thought.

12:00-15:30 · dry run on the input designed to break it

Not "abcabcbb", which passes almost anything. Run "abba" aloud, index by index. At i=3 you see a, last seen at index 0. If you set left = seen[c] + 1 you drag left backwards from 2 to 1, the window becomes "bba", and you return 3 instead of 2. The fix is left = max(left, seen[c] + 1). Finding that yourself, out loud, before the interviewer raises it, is worth more than the working solution was.

15:30-18:00 · edge cases, complexity, and what you would test

Empty string returns 0, a single character returns 1, all identical characters returns 1. State the complexity again now that real code exists, and name one thing you would change with more time, for example a fixed array of 128 counts instead of a dictionary if the input is guaranteed ASCII. If the pad executes code, run it here. If it does not, say "I have traced it by hand on three inputs," so the missing green tick is a stated fact rather than a gap in their notes.

If you hit minute 20 still writing, say so and triage out loud: "I am going to finish the main loop and then trace it, rather than adding input validation." A visible cut reads as engineering judgement. Running out of time in silence reads as not finishing.

The headset and audio checklist, run ten minutes before

This round is usually audio-only, which means sound quality is not a nicety. It is most of the signal the interviewer receives about you.

Wired headset, not Bluetooth. When a Bluetooth headset's microphone opens, most devices switch from the stereo profile to a hands-free profile, narrowing the channel in both directions for the whole call. Wired USB or 3.5mm avoids the switch entirely and cannot run flat at minute 22.
Record yourself first. Twenty seconds in Windows Sound Recorder: say two sentences, then type for five seconds. Play it back. If your keyboard is louder than your voice, move the boom mic to the side of your mouth rather than in front of it, or move the keyboard off the resonant desk.
Set the device twice. Pick input and output in Windows sound settings, then again inside the meeting app, which keeps its own selection and will happily fall back to the laptop speakers.
Never speakerphone. Open speakers plus an open mic means echo cancellation is running, and it clips the front of your words hardest exactly when you talk over your own typing.
Silence everything that can ping. Windows Do Not Disturb, Slack, Teams, Outlook, and the phone face down on silent, not vibrate, and not on the desk you are typing on.
If it is a real phone call, check signal and turn off call waiting. A second incoming call at minute 14 can drop the interview outright.
Keep a plain text file open with the pad link, the dial-in number and the recruiter's email. A dropped call then costs twenty seconds instead of four minutes of inbox searching.
Ask "am I coming through clearly?" once, in the first minute, then never again. Repeat audio checks eat the budget and make you sound rattled.

Where a live copilot fits this round, and where it does not

Audio-only screens are the format live assistance suits best, because there is no camera and the interviewer's voice is already coming out of your machine. Interview Copilot listens to that playback through system loopback, transcribes on-device and drafts a speakable answer in about a second, while Code Copilot pulls the problem off the pad with a screenshot. The overlay is excluded from screen capture at the operating system level, so it is absent from Zoom, Teams, Meet, OBS and screenshots while staying visible on your own monitor. Now the limits, plainly:

A literal phone call defeats the whole thing. If the interviewer's voice arrives through your mobile handset rather than your PC, there is no system audio to capture and the copilot has nothing to listen to. Loopback needs the call to be on the computer.
Capture exclusion covers screen sharing and screen recording, nothing else. It does not defeat a webcam, a lockdown browser, eye tracking, a second-device camera, or someone in the room. Plenty of rounds described as phone screens turn out to be a video call with cameras on.
Windows 10 and 11 only. No macOS, no Linux, no mobile, no browser extension.
Reading is not narrating. This round grades the commentary you produce while you type, and an answer read off a screen without owning it falls apart on the first follow-up. In an eighteen-minute block the follow-up always comes.
The rules belong to the company. Some interviews permit documentation and AI assistance, some do not. Read the instructions you were sent, and ask when they are ambiguous.
Budget check. Metering counts listening time only, so a 30-minute screen where the interviewer talks for eight minutes consumes about eight. The free tier is 5 minutes a day, which will not cover a real round. Paid plans start at $39 a month.

Rehearse the clock, not the problem list

Take three medium problems and run each to the blocks above, timer visible, using the exact audio setup you will use on the day. You are not practising sliding windows. You are practising the restate, the clarifying set, the buy-in pause and the dry run, because those four habits carry every problem you are likely to be handed. The question banks supply prompts to run against the clock, and the company Q&A generator builds a bank for a given company and role, which is what the 3 to 8 minute block needs: the follow-ups there are about their stack, not yours.

The 30-minute technical phone screen, minute by minute