A technical phone screen is usually a call of about 45 minutes (some run shorter, a few up to an hour), now more often video than phone, where one engineer gives you one or two coding problems (typically easy to medium data structures and algorithms) in a shared online editor and watches you solve them while you talk. You pass by clarifying the problem, agreeing on an approach and its complexity before you type, writing working code while you explain it, and testing it yourself before the interviewer has to point out a bug. It is a filter round: the interviewer is deciding whether you are worth a full loop, so a clean, well-explained solution beats a clever, silent one.
Below: the format at a few large companies, a plan for the clock, what the interviewer writes down, and the habits and setup that turn a “maybe” into a “yes.”
What a technical phone screen looks like
Despite the name, most “phone” screens now run on a video call with a shared editor: CoderPad, a company's own tool, or occasionally a plain shared document. The interviewer is usually a working engineer, and the round sits between the recruiter call and the full loop.
| Element | What is typical |
|---|---|
| Length | Often about 45 minutes on the calendar; some run 30 to 40 minutes, a few an hour. Roughly 30 to 40 minutes of it is coding |
| Problems | One or two, usually easy to medium, focused on data structures and algorithms |
| Editor | A browser-based shared editor; the interviewer sees every keystroke as you type |
| Running code | Varies by employer; some screens turn execution off or use an editor that cannot run code |
| Behavioral | A short intro about your background; some companies add one or two behavioral questions |
| Your questions | A few minutes at the end, if the coding stays on schedule |
| Outcome | Written feedback and a recommendation on whether to move you to the full loop |
How it varies by company
Processes change and differ by team, so read this as what official prep pages and candidate-reported guides say, and confirm the details with your recruiter.
| Company | Commonly reported format |
|---|---|
| Meta | Meta's careers site calls it a 45-minute conversation with an engineer. Interviewing.io reports about five minutes of introduction, then two easy-to-medium problems to finish in about 35 minutes, in CoderPad with code execution turned off. |
| Focused exclusively on data structures and algorithms, per interviewing.io. Historically a shared Google Doc rather than an IDE; some candidates now get an internal editor with syntax highlighting, depending on location. | |
| Amazon | Many candidates take an online assessment first, and strong results can mean skipping the screen. When there is one, interviewing.io reports 30 to 40 minutes for usually one problem in Livecode, Amazon's internal editor, which does not run code, sometimes with a Leadership Principles question or two. |
| Microsoft | Per interviewing.io, either a live LeetCode-style screen with easy-to-medium questions or an asynchronous Codility quiz instead; tooling and process vary by team. A quiz like that is an assessment you complete on your own, under the employer's rules. |
A minute-by-minute plan for the call
The usual way to run out of time is spending the first fifteen minutes in the wrong place: coding before you understand the problem, or talking in circles without committing. Decide how you will spend the clock before the call. These are targets for a 45-minute slot, not rules.
| Phase | One-problem screen | Two-problem screen |
|---|---|---|
| Introductions | 0–5 min | 0–5 min |
| Clarify and work one example | 5–10 min | 5–8 min |
| Agree on approach and Big-O | 10–15 min | 8–11 min |
| Write the code | 15–30 min | 11–19 min |
| Test and fix | 30–37 min | 19–22 min |
| Follow-up or second problem | 37–40 min (optimization or variant) | 22–40 min (same steps, faster) |
| Your questions | 40–45 min | 40–45 min |
Two habits make the plan work. Glance at the clock at every phase change; if you are still clarifying at minute twelve, commit to a direction. And on a two-problem screen, move on once problem one works and is tested. Polishing the first is how the second goes unfinished.
What interviewers write down
After the call, the interviewer writes up feedback, often in a structured form, and makes a recommendation. The exact form differs by company, but the Tech Interview Handbook's widely shared rubric groups the signal into four areas, and they line up with what most screeners record:
| Area | What earns a strong note | What earns a weak note |
|---|---|---|
| Communication | Asks good clarifying questions, explains the approach and trade-offs, keeps the interviewer following along while coding | Starts typing without explaining, goes silent, or cannot articulate the reasoning when asked |
| Problem solving | Reaches a workable approach quickly, states correct time and space complexity, needs few hints, compares alternatives | A disorganized or incorrect approach, repeated hints, wrong complexity |
| Technical competency | Clean, working code with clear names and idiomatic use of the language | No working code, major syntax errors, poor use of the language |
| Testing | Walks through normal and edge cases, finds and fixes their own bugs | Declares the solution done without testing; the interviewer has to find the bug |
Two things follow. The interviewer can only record reasoning they heard, so a correct idea you never said out loud does not exist in the feedback. And how much help you needed is part of the picture: taking a hint beats staying stuck, but acknowledge it and apply it quickly.
Feedback usually ends with a recommendation on a scale such as strong hire, hire, no hire, strong no hire. The handbook notes that advancing from a phone screen generally takes at least a leaning-hire signal, so a clean, complete answer to a moderate problem matters more than an ambitious one you do not finish.
Communication habits that move the needle
Communication comes down to a few repeatable moves. Here they are with sample lines, using a two-sum style problem as the example.
- Restate and clarify. Ask two or three questions about input, range and edge cases. “So I get an unsorted array of integers and a target, and I return the indices of two numbers that sum to it. Can the array be empty? Can values be negative? Is there always exactly one answer?”
- Work one example by hand. Type a small input as a comment and trace the expected output. It catches misunderstandings and becomes your first test.
- State the plan and its cost before typing. “Brute force checks every pair, which is O(n²). I can do one pass with a hash map from value to index: O(n) time, O(n) space. Does that sound good as a starting point?” Then wait for the nod.
- Narrate at the seams, not every keystroke. Short quiet stretches while you write a block are normal. Speak up when you start a new block, make a decision or notice a problem: “I check for the complement before inserting, so an element never pairs with itself.”
- Flag shortcuts out loud. If you skip input validation or a helper for time, say so: “I'll assume valid input here and come back to it if we have time.”
- Test before you say you are done. Trace your example line by line, then try the edge cases: empty input, one element, duplicates, negative numbers, very large input. Finish by restating the time and space complexity.
When you are stuck, keep thinking out loud. Say what you tried and why it fails: “Sorting would lose the original indices, so two pointers alone won't work here.” That gives the interviewer something to respond to, and the hint you get back is often aimed at exactly the gap you named. If you have nothing better, write the brute force: a working slow solution gives the interviewer something to evaluate, and a blank editor gives them nothing.
Setup checklist
Tooling trouble is the most avoidable way to lose minutes. Our live coding tips for Zoom and Teams cover audio, camera and screen sharing in depth; this is the short version.
The day before
- Confirm the format with your recruiter: length, number of problems, which editor, whether you can run code, and which languages are allowed.
- Try the editor. CoderPad, for example, offers a sandbox it describes as nearly identical to a real interview session. Its settings let you raise the font size and switch key bindings to Vim or Emacs if you use them.
- Use a laptop or desktop. CoderPad says it does not support phone-size devices and, if you must use a tablet, strongly recommends an attached keyboard and mouse. It also warns that some browser plugins can interfere, so test in the browser you will use.
- Pick your language. Choose the one you write fastest and most correctly, not the one you think sounds most impressive.
- Prepare your opener: a 60-second introduction and two projects you can discuss in depth.
Fifteen minutes before
- Restart, close apps and tabs you do not need, and silence notifications.
- Use headphones with a microphone in a quiet room. If it really is a phone call, the Tech Interview Handbook suggests earphones with the phone on the desk, so both hands stay free to type.
- Keep pen and paper nearby for sketching trees, graphs and indexes, and water within reach.
- Open the editor and call links, and join a minute or two early.
For more on the editor itself, including how a shared pad differs from your local IDE, see our CoderPad interview tips.
If the editor cannot run your code
Some screens disable execution, and some editors never run code at all. Amazon's own prep page tells engineering candidates to expect to write syntactically correct code, not pseudocode. Without a run button, the walkthrough is your test, so practice it:
- Practice in a plain editor: no autocomplete, no run button, one file.
- Trace with a small table of key variables per loop iteration, written as a comment.
- Check the usual suspects: off-by-one bounds, wrong initial values, a missing return, modifying a collection while iterating over it.
- If execution is on, still trace first. Guessing at fixes for code you have not reasoned about looks worse than catching the bug yourself.
The short behavioral part
Most screens open with a few minutes about you. For Meta, interviewing.io reports that the introduction does not meaningfully affect the outcome, but a rambling answer still eats coding time. Keep it to about a minute: current role or studies, one project with a concrete result, and why this role.
Some screens add a behavioral question or two; interviewing.io reports that Amazon screeners sometimes ask one or two Leadership Principles questions. Have two short stories ready in a situation, task, action, result shape: a hard technical problem you solved, and a disagreement or mistake you handled well.
How to prepare in the last two weeks
- Review patterns, not volume. Easy-to-medium screen problems tend to draw on familiar techniques such as hash maps, two pointers, sliding window, BFS and DFS, and binary search. Our guide to the core LeetCode patterns for interviews lays them out with the prompts that signal each one.
- Practice timed and out loud. Give yourself about 20 minutes per medium problem and talk the whole time. Record one session and watch it back to spot the silences.
- Match the format. If your target turns execution off or uses a shared document, practice that way.
- Do at least two mock screens. A friend who interrupts with questions is ideal. Without one, a free AI mock interview in CoPilot Interview builds technical and coding questions from the job description and your résumé, reads them aloud, and scores each spoken answer with what worked and what to improve.
- Prepare your closing questions. One or two specific questions about the interviewer's own work make a better last impression than “No, I think you covered everything.” See our list of questions to ask at the end of a technical interview.
After the call
- Write it down within the hour: the problem, your approach, where you got stuck and what you would change.
- Send a short thank-you to your recruiter, or your interviewer if you have a way to reach them.
- Do not over-read the interviewer's manner. A neutral interviewer tells you very little about the result.
- If it went badly, fix the specific gap: drill the clock plan if you ran out of time, pattern recognition if you froze, hand tracing if you missed a bug.
Rehearse the screen out loud before the real one
Paste the job description and your résumé, choose a technical and coding mix, and an AI interviewer reads each question aloud and scores your spoken answer. The free plan includes 15 minutes a day, with no credit card.
Try a free AI mock interviewFAQ
How long is a technical phone screen?
Most are scheduled for about 45 minutes, though some run 30 to 40 minutes and a few an hour. After introductions and time for your questions, you typically get 30 to 40 minutes of actual coding.
How many questions are in a technical phone screen?
Usually one or two easy-to-medium coding problems. Candidates commonly report two problems at Meta and one at Amazon, but the number varies by company and interviewer, so ask your recruiter.
Can I run my code during a technical phone screen?
It depends on the employer. Editors like CoderPad have a run button, but some companies turn execution off and some editors cannot run code at all, so practice testing by tracing your code by hand.
What happens if I do not finish the problem?
It depends on how far you got and on the company. A working brute-force solution with a clear plan to optimize usually counts for far more than an optimal idea left half-written, so get something working before you optimize.
Are there behavioral questions in a technical phone screen?
Usually only a short introduction about your background. Some companies add one or two behavioral questions, so have a one-minute introduction and two short project stories ready.