Technical Screening Preparation Checklist: A 45-Minute Round Playbook

TL;DR

• A 45-minute technical screen is won on process, not algorithmic depth.
• Run a T-minus 60 environment checklist (Ethernet, headset, lighting, IDE backup), a T-minus 10 warm-up writing one short function out loud, a tight zero-to-five intro confirming format, a 5-to-35 minute problem budget with explicit clock callouts, and a specific-question close.
• Five patterns cover roughly 70 percent of first-round screens: hash map counting, two pointers, sliding window, BFS/DFS on grids, and heap.

Introduction

The 45-minute technical screen is the most leverage-dense round in the entire interview pipeline. You spend six weeks grinding algorithms, polishing your resume, and prepping stories, and then a stranger on a video call decides in under an hour whether the rest of the loop is worth anyone's time. Ship the screen, and you get five more rounds. Flunk it, and you go back to the queue.

It is also the round candidates most often misprepare. Engineers treat it like a mini onsite and rehearse five different problem types, forgetting that 45 minutes is barely enough for one problem plus intro plus questions. They forget to check their microphone. They let the interviewer watch them fumble with IDE setup for four minutes. They spend twenty minutes on a brute force because they did not want to "skip ahead" to the good solution.

This checklist is the sequence of things you do before the call, in the first five minutes of the call, during the main problem, and during the close. It is not a crash course in algorithms. It is a process playbook that keeps the algorithm you already know from getting squandered by logistics.

Table of Contents

• What a 45-Minute Screen Is Actually Testing
• The T-Minus 60 Environment Checklist
• The T-Minus 10 Warm-Up Routine
• Opening the Call: Minutes 0 to 5
• The Problem: Minutes 5 to 35
• The Common First-Round Patterns You Must Have Ready
• Pacing Per Phase: A Minute-by-Minute Budget
• Handling Trick Questions and Intentional Ambiguity
• The Close: Minutes 35 to 45
• After the Call
• FAQ
• Conclusion

What a 45-Minute Screen Is Actually Testing

Interviewers are not looking for a globally optimal solution in 45 minutes. They are looking for four signals, and each one is weighted more than the one before it.

Signal one is that you can code. You can declare variables, use the language's standard library confidently, and write a loop without a syntax error. This signal is the floor. If you miss it, nothing else matters.

Signal two is that you can reason out loud. You take a problem, restate it, think about the inputs, pick a strategy, and narrate as you go. Silent coders fail screens even when they solve the problem, because the interviewer cannot tell if the solution came from thinking or from memorization.

Signal three is that you can handle feedback mid-problem. The interviewer drops a hint; you take it without ego. The interviewer pushes back on your complexity; you engage rather than defend. This is the signal that predicts whether you will be a functional teammate.

Signal four is that you can recover from being stuck. Every screen has a moment where you are stuck. Strong candidates have a visible method: try a smaller example, write it brute force, look for a data structure fit. Weak candidates freeze or flail.

If you frame the screen around these four signals instead of around "did I solve it," your preparation becomes much more targeted.

The T-Minus 60 Environment Checklist

One hour before the call. Run this as a literal list.

Hardware

• Laptop plugged in, not on battery. Battery mode throttles on some machines and your cursor will lag.
• External monitor disconnected if your camera is on the laptop. Video in one place, code in the same place.
• Headset on and tested, not AirPods. AirPods hit 60 percent battery during interviews and die loudly.
• Microphone set as default input. Record yourself saying "checking one, two, three" and play it back. If you hear yourself tinny or echoey, fix it now.
• Camera at eye level. Raise the laptop on books if needed. Looking down at the camera reads as low engagement.
• Backup device ready. A phone with the interview link open, muted, in case your laptop crashes.

Network

• Ethernet if you have it. Wi-Fi is fine but worse than Ethernet.
• Household internet users notified. Tell roommates, family, partners that you are on a call.
• VPN off unless the interview platform specifically requires it.
• Speedtest run once. 20+ Mbps up is plenty.

Software

• Video app updated. The worst time to discover a required update is 30 seconds before the call.
• Shared coding environment bookmarked. CoderPad, HackerRank, Google Docs, whatever the recruiter told you. Open it in a clean tab now.
• Your own IDE open in parallel. If the shared editor breaks, you have a backup and you can paste over.
• Notifications silenced. Do Not Disturb on. Slack, Discord, email, calendar pings all muted.
• Browser: close every tab you do not need. Leave the interview link, the coding env, and a scratchpad. That is it.

Environment

• Water within arm's reach. Plain water, not coffee. Coffee makes you talk fast.
• A snack nearby for after. Low blood sugar after a screen is real and makes the debrief writing worse.
• Lighting: a lamp in front of you, not behind. Backlit candidates look like witness protection.
• Background: clean or blurred. Not a beach. The interviewer should be looking at you, not at your decor.

Physical

• Bathroom before the call. Obvious, skipped often.
• Clothing: whatever makes you feel competent. You do not need a blazer. You need to not fidget with your collar.
• Posture: sit up, not recline. Your voice changes when you slouch.

Print this list. Literally print it and tape it next to your monitor during the prep week. The worst screens are lost on logistics, not on algorithms.

The T-Minus 10 Warm-Up Routine

Ten minutes before the call, do this.

Write one short function in your interview language. Not from memory; actually open a blank file and write a working function. It can be "reverse a string" or "count vowels." You are not practicing algorithms. You are flushing the cold-start error out of your hands. The first function of the day is always the worst one.

Speak out loud. Describe what you wrote as if you are in the interview. "This function takes a string, iterates character by character, and appends to a new string in reverse." Say it to the wall. You need to hear your own voice before the interview starts. Cold-start voice is even worse than cold-start code.

Read one piece of code you wrote recently that you are proud of. Not to refresh technical memory, but to restore confidence. You are a person who writes code that works. The screen is not a referendum on that.

Close every pre-call tool except what you need. No Twitter, no HN, no last-minute leetcode. Cramming a ninety-second read of "two-pointer patterns" is negative value. You lock in an anxious mental state and displace the working memory you actually need.

Start the video call three minutes early. Not one minute, not on the dot. Three minutes early, camera off, audio muted, gives you a chance to test that the link works. When the interviewer joins, you are already there.

Opening the Call: Minutes 0 to 5

The first five minutes of the call are where candidates overthink and where interviewers form durable impressions. Run the open like a script.

Greet in one sentence. "Hi, good to meet you." Do not launch into a monologue. Let the interviewer drive.

Expect introductions. Most interviewers will introduce themselves first, usually in 30 to 60 seconds. When they hand off, your intro should be tighter than theirs, about 30 seconds. Role, what you work on, one specific thing you have shipped recently. Not your life story.

Do not ask "tell me about the team" in the intro. That is an end-of-call question. If you ask it now, you eat problem time and the interviewer will resent it.

Confirm the format. "Just so I know, are we doing one problem or two today, and should I optimize for reaching a working solution or for exploring tradeoffs?" This one question is gold. You now know whether to hustle or to dawdle, and the interviewer perceives you as a professional who manages their own time.

Expect the problem statement around minute three to four. When it lands, your first job is to repeat it back. "So you want me to take a list of intervals and return the minimum number of meeting rooms needed. Intervals are (start, end) pairs, endpoints are inclusive or exclusive?" That question is not filler. It is the test of whether you parsed the problem.

The Problem: Minutes 5 to 35

Thirty minutes on the main problem. Here is the budget.

Minutes 5 to 8: Clarification and examples. Ask at least two sharp clarifying questions. Then write a small example. Show the interviewer how you think. If the example is not given, invent one. "Let me try with intervals [(0, 30), (5, 10), (15, 20)]. I expect two rooms." The interviewer nods or corrects.

Minutes 8 to 13: Approach. State a brute force out loud. "The simplest thing is to check every pair of intervals for overlap, which is O(n squared)." Then state a better idea. "If I sort by start time and sweep, I can process events in order and maintain a count." Ask the interviewer before you code. "Does this direction work, or do you want me to optimize further first?"

This check-in is critical. Some interviewers want you to code the first reasonable solution; others want you to get to optimal before coding. Reading it wrong costs you the screen.

Minutes 13 to 28: Coding. Fifteen minutes of actual coding. Narrate as you go. "I am sorting the intervals. Now I am iterating and pushing end times into a heap." Short sentences. Do not explain every variable; explain every decision.

If you hit a sub-problem inside the main problem, acknowledge it. "I need to check if the interval overlaps. I will write a helper." Do not silently go down a rabbit hole.

Minutes 28 to 32: Testing. You are not done when the code compiles. You are done when you have walked through your own example. Pick a concrete input, trace it through your code line by line, verbally. If you find a bug during this walk, congratulations: you are now the candidate who catches their own bugs, which is a stronger signal than the one who writes bug-free code first pass.

Minutes 32 to 35: Complexity and alternatives. State the time and space complexity without being asked. "This is O(n log n) for the sort, O(n) for the sweep, O(n) space for the heap." Offer one honest tradeoff. "We could drop the heap in favor of a simple counter if we sort events separately; it would be the same complexity but easier to read."

The Common First-Round Patterns You Must Have Ready

First-round screens draw from a tight pool of patterns. You do not need to master every algorithm in the textbook. You need five patterns deeply internalized, so that when the problem statement lands, your brain goes "oh, that is a sliding window" rather than "let me think from scratch."

Hash map counting. "Given an array and a target, return..." Almost always a hash map gets you from O(n squared) to O(n). Anagram grouping, two-sum, first-non-repeating-character. If the problem involves counting or fast lookup, default to a hash map.

Two pointers. Arrays, strings, especially sorted ones. Finding pairs, reversing, partitioning, palindromes. If the problem has two ends, two pointers is the first thing to try.

Sliding window. Contiguous subarray or substring problems. Longest substring without repeating characters, minimum window containing some set, maximum sum subarray of size k. Variable or fixed window, but always a left pointer, a right pointer, and a running statistic.

BFS and DFS on a graph or grid. Islands, connected components, shortest path in an unweighted graph, ancestor problems. You should be able to write both iteratively without looking anything up. Grid BFS uses a queue and a visited set; tree DFS uses recursion or an explicit stack.

Heap. Top-k problems, meeting rooms, streaming medians. If the problem asks for the kth anything, think heap.

That is it. Five patterns cover probably 70 percent of first-round screens. If you know these cold, you will recognize them in the first ninety seconds of the problem statement and save yourself fifteen minutes of exploration.

Pacing Per Phase: A Minute-by-Minute Budget

Here is the budget on one line, in order.

Introductions, 0 to 5. Clarifying and examples, 5 to 8. Approach discussion, 8 to 13. Coding, 13 to 28. Testing on paper, 28 to 32. Complexity and tradeoffs, 32 to 35. Interviewer follow-ups and candidate questions, 35 to 45.

If at minute 20 you have not started coding, you are behind. If at minute 30 you are still writing the happy path, you are behind. Say out loud "I want to make sure we have time to test, let me pause and walk through an example" and move to the next phase. Interviewers reward candidates who manage the clock visibly.

Candidates who run over time and never test are dinged more than candidates who get 80 percent to working plus complete testing. The screen is about demonstrating a full software engineering loop in miniature, not about solving every edge case.

Handling Trick Questions and Intentional Ambiguity

Some interviewers are kind. Some are testing whether you will accept a misleading hint. Both exist, and you should have a method for each.

The misleading hint. Interviewer says "have you considered a hash map here?" Weak candidate immediately pivots to a hash map even if they were on a good path. Strong candidate says "I have, and I want to check: do you see a specific benefit I am missing, because my current approach is O(n) already." That question is polite and resistant. It also reveals whether the hint was genuine or a probe.

The ambiguous input. "The input is an array of numbers." Great, but are they integers? Can they be negative? How big can the array get? Can it be empty? You should ask these without being prompted. If you do not ask and the interviewer later gives you an input that breaks your code because you assumed positives only, they will note it as sloppy.

The deceptively simple question. Some problems sound trivial and hide a twist. "Reverse a singly linked list." You should recognize this as textbook, state the iterative approach, state the recursive approach, pick one, and execute. Do not spend three minutes on clarifying questions for a problem that does not need them. Speed on the trivial questions is itself a signal.

The problem that expands mid-interview. "Nice, now can you do it if the input is a stream?" This is the interviewer probing your ability to adapt. Do not panic. Say what breaks about your current solution. "Streams mean I cannot sort. I need an online approach." Then explore. Adaptation under pressure is one of the most valued screen signals.

The problem you have seen before. You should not pretend to discover it fresh; that is a lie that lasts for six seconds before the interviewer sees through it. Say "I have seen a version of this before, the key idea is X; I will work through the specifics." Interviewers prefer honesty and you still have to write the code.

The problem you have never seen. You break it down to the smallest input. Can I solve it for a list of length one? Length two? What changes as n grows? The willingness to work from small cases to general cases is the single most reliable recovery strategy.

The Close: Minutes 35 to 45

The last ten minutes are when you either reinforce the positive impression or burn it.

When the interviewer says "nice, that works, let me give you some time for questions," you should be ready with two or three specific questions. Not "what is the team culture." That is a nothing question. Ask something like:

"What is one thing about this team that would surprise a new hire in their first month."

"How is technical debt handled, specifically, who decides when a paydown project happens."

"What is the deploy cadence and how do rollbacks work."

Each of those is a question with information content. The interviewer's answer tells you something, and their response tells them you have thought about engineering life beyond the interview.

Do not ask about compensation or promotion timelines. Save those for the recruiter. In a technical screen, those questions read as misplaced.

When the call ends, say thank you clearly. "Thank you, that was a good problem, I appreciated the hint about the heap." Specificity beats politeness. The interviewer now remembers you as someone who paid attention.

After the Call

Within fifteen minutes of hanging up, write a short self-debrief. Not to the recruiter. For yourself. Three bullets.

What went well. One or two specifics. "I stated the brute force before optimizing." "I caught my off-by-one on the trace."

What went poorly. One or two specifics. "I stalled for two minutes on the heap syntax." "I forgot to ask about empty input until the interviewer brought it up."

One thing to fix before the next screen. "Re-drill heap syntax in my interview language." Not a vague goal; a specific drill.

The candidates who improve fastest between screens are the ones who debrief in writing. Memory of the screen decays within a day. Writing freezes it.

Send a one-line follow-up to your recruiter within a few hours. "Screen went well, ran through a meeting-rooms problem, comfortable with the outcome, looking forward to the next step." Do not editorialize. Do not speculate on whether you passed. Short, factual, forward.

FAQ

Should I use my preferred language or the one the team uses?

Your preferred language. Screens are about signal per minute, and fighting with an unfamiliar language burns minutes. The rare exception is if the role specifically requires the team's language and the recruiter has flagged that the screen will test it. When in doubt, ask the recruiter before the call.

What if I finish the problem in twenty minutes?

Two things. First, double-check your tests; you probably missed an edge case. Second, ask the interviewer "would you like me to extend this, or would a different problem be useful." Offering to extend shows initiative. Most interviewers have a follow-up problem ready for fast candidates.

What if I cannot solve the problem at all?

Do not freeze. Communicate where you are stuck. "I see that I need to avoid re-traversing the same cells. I am not sure what data structure to use." Interviewers sometimes give a hint, and the hint is usable only if you have already demonstrated where you are stuck. A candidate who is stuck and silent fails harder than a candidate who is stuck and specific.

How much does IDE fluency matter?

A lot, and it is the easiest thing to improve. You should know how to run, rename a variable, set a breakpoint, and navigate between files without thinking. If you are fumbling with shortcuts during a screen, fix it this week. It is pure preparation tax.

Is the 45-minute screen harder than a 60-minute onsite round?

Different, not harder. The screen is under time pressure; the onsite is under stamina pressure. Screens reward speed and clean process; onsites reward depth and recovery. Prepare for each accordingly.

Conclusion

The 45-minute screen feels high-stakes because it is a gate. But gates are solvable. Nail the logistics, run the warm-up, open with a tight intro, budget your minutes, name the pattern early, narrate as you code, test on paper, and close with a specific question. That sequence does not guarantee an offer. It guarantees that the algorithm you already know gets a fair shot at the signal it needs to produce.

Print the environment checklist. Run the warm-up before every practice screen. Time your mock interviews with a real clock. The candidates who clear screens reliably are not the ones with the deepest algorithm knowledge. They are the ones with the most rehearsed process. Build the process now, and the algorithm does the rest.

Frequently asked questions

What does a technical screen interviewer actually look for in 45 minutes?

Four signals weighted increasingly: that you can code without syntax errors, that you can reason out loud, that you can take feedback and hints without ego, and that you can recover from being stuck with a visible method. Framing your prep around these four signals beats grinding random problems.

How should I time a 45-minute coding screen minute by minute?

Intros zero to five, clarification and a small example five to eight, approach discussion eight to thirteen, coding thirteen to twenty-eight, walk-through testing twenty-eight to thirty-two, complexity and tradeoffs thirty-two to thirty-five, follow-ups and your questions thirty-five to forty-five. If at minute twenty you have not started coding, say so out loud and pivot to writing.

What patterns must I have ready for a first-round technical screen?

Five patterns cover about 70 percent of first-round screens: hash map counting (two-sum, anagrams), two pointers (palindromes, sorted arrays), sliding window (longest substring, max sum size k), BFS/DFS on graphs and grids (islands, components), and heap (top-k, meeting rooms, streaming median). Internalize these five so the pattern lights up in the first ninety seconds.

How do I handle a misleading hint from the screen interviewer?

Do not pivot reflexively. Say 'I have considered that, and I want to check: do you see a specific benefit I am missing, because my current approach is already O(n).' This is polite, resistant, and reveals whether the hint was genuine or a probe testing whether you accept misleading suggestions.

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

Specific ones with information content: 'What would surprise a new hire about this team in their first month?' 'Who decides when a tech-debt paydown project happens?' 'What is the deploy cadence and how do rollbacks work?' Avoid compensation, promotion timeline, and generic 'tell me about the culture' questions; save those for the recruiter.