How to run a technical phone screen

A technical phone screen should take 30 to 45 minutes and filter on one or two signals, not five. Its only job is to decide whether the candidate is worth a full loop, so you are looking for a clear yes or a clear no, and you are treating the call as the candidate's first real impression of your company. Most early-stage screens fail in one of two ways: they are an unstructured chat that tells you nothing, or they are a brutal puzzle round that scares off the exact senior engineers you cannot afford to lose.

This post is the founder's operating manual for the screen itself: the minute-by-minute structure, the questions that actually separate candidates, what to cut, and how to score so two interviewers agree. For the wider loop that comes after, see how to run a fast engineering interview loop and structured interviews and scorecards.

What is a technical phone screen actually for?

It is a filter, not a final verdict. You are answering one question: is there enough signal here that spending three or four engineer-hours on a full loop is a good bet? That framing matters because it tells you what to skip. You do not need to assess system design depth, culture, or leadership on a 35-minute call. You need to confirm the person can write working code, reason about it out loud, and talk concretely about something they have built.

Run the screen as a one-step gate with two possible outcomes: advance to the loop, or pass. Resist the urge to invent a 'maybe' bucket. A maybe almost always means your screen was not sharp enough, and maybes quietly clog your pipeline. If you are unsure, that is usually a no, because a strong screen produces clear signal.

How should you structure a 35-minute screen?

Time-box it. The single most common mistake is letting the intro and the project chat eat 25 minutes, leaving no room to see code. Here is a structure that fits in 35 minutes with a few minutes of buffer.

1. 01Minutes 0 to 3. Set the frame. Tell them the plan out loud: a few minutes on their background, about 20 minutes on a coding exercise, then time for their questions. Candidates do better when they know the shape of the call.
2. 02Minutes 3 to 10. One project, in depth. Pick the most relevant thing on their resume and ask them to walk you through it. Push past the summary to the decisions: what they owned, what broke, what they would change.
3. 03Minutes 10 to 30. Live coding. One small, real problem. Watch them work, not just the answer. This is the core of the screen.
4. 04Minutes 30 to 35. Their questions, and next steps. Leave real time here. A senior engineer judges you by the questions you can answer well.

What coding exercise should you use?

Use one small problem that a competent engineer can finish in 15 to 20 minutes, with room to extend if they are fast. The goal is to watch them think, so pick something with a naive solution and an obvious follow-up. Avoid anything that hinges on a single trick or a memorized algorithm. You are screening for working engineers, not competitive programmers.

Good screen problems share a shape: a simple core, a clarifying question or two hidden in the prompt, and a natural extension. Examples that work well:

• Parse a small log or CSV and answer a question about it (group, count, find the top N). Tests data handling and edge cases.
• Implement a rate limiter or an LRU-style cache with a basic interface. Tests data structures without being a puzzle.
• Take a messy function and refactor it, or add a feature to 30 lines of code you provide. Closest to the actual job.
• Build a tiny in-memory key-value store with get, set, and expiry. Extends naturally into concurrency or persistence talk.

Let them use their own editor and their real language, and share a link to a collaborative pad (CoderPad, CodeSandbox, or a shared doc) so you can see keystrokes. Tell them to talk as they go and to look things up the way they normally would. You are simulating a Tuesday, not an exam. The way they handle a vague prompt, an off-by-one bug, or a missing test case tells you more than whether they reach the optimal answer.

What about AI assistance during the screen?

Decide your policy before the call and state it in the first three minutes. Banning tools entirely is increasingly artificial, because the job involves them. A reasonable middle ground: allow autocomplete and lookups, but ask the candidate to drive and explain, and probe whatever a tool produces. If you want a view on how this is reshaping the work itself, see AI and software engineering jobs. The signal you want is unchanged: can this person reason about correctness and explain their choices.

What should you ask, and what should you cut?

The fastest way to improve a screen is to delete the parts that do not filter. Trivia, brain teasers, and big system-design questions belong in the loop or nowhere. Here is the split.

For the project conversation, two questions do most of the work. First: 'What was the hardest decision in this project, and what did you choose?' Second: 'If you rebuilt it today, what would you do differently?' Both reward people who actually owned the work and expose people who narrated a team's effort as their own. They also scale across levels, which matters because your screen should not be senior-only.

How do you keep a strong candidate warm?

The best engineers are usually in three or four processes at once, and a phone screen is where you either earn the next conversation or lose them to a faster competitor. Treat the screen as recruiting, not just filtering. Three things keep strong people engaged:

• Be on time and prepared. Read their resume before the call, not during it. Nothing signals a chaotic company faster than an interviewer skimming in the first five minutes.
• Sell for two minutes, specifically. Near the end, tell them one concrete reason this role is interesting: the problem, the stage, who they would work with. Generic pitches read as noise. If you just raised, say so, because funding recency is a real signal candidates weigh.
• Close the loop within 48 hours. Tell them on the call when they will hear back, then beat that deadline. Silence after a good screen is how you lose your top candidate.

If the screen goes well, do not end with a vague 'we will be in touch.' Say what happens next and when: 'You did well, the next step is a 3-hour loop, I will send times tomorrow.' For how to carry that energy through to an offer, see how to close an engineering candidate.

How should you score the screen?

Write your assessment within 10 minutes of hanging up, while it is fresh, and score against a fixed rubric so two interviewers actually mean the same thing by a pass. A loose 'felt good' note is worthless a week later when you are comparing five candidates. Score three dimensions on a simple 1 to 4 scale, where 1 is clear no and 4 is clear yes.

1. 01Code quality and correctness. Did they produce working code, handle obvious edge cases, and structure it readably?
2. 02Reasoning out loud. Could they explain their choices, catch their own mistakes, and respond to a hint without being led by the hand?
3. 03Ownership signal. In the project chat, did they talk like someone who made decisions, or someone who was nearby when decisions were made?

Add one required field: a recommendation (advance or pass) and a one-line reason. Force the binary. A useful default rule: advance if code quality and reasoning are both 3 or higher, otherwise pass. The ownership score breaks ties and flags people to probe harder in the loop. Keeping the rubric this tight is what makes it possible to compare candidates fairly and to defend a no later. It also feeds the broader pipeline discipline in common startup hiring mistakes.