The Technical Screening Interview: A Guide for Software Engineers (2026)

TL;DR

• The technical screening interview filters 60 to 70 percent of FAANG candidates and is the single most statistically important round in the pipeline.
• It is a 45-minute live coding session calibrated as do-not-waste-our-time, not solve-LeetCode-hard.
• You pass by executing a clean template: clarify, walk a small example, state brute force, propose optimal, code in 15 to 20 minutes, test against an edge case, and analyze complexity.
• Twenty-four problems across eight patterns is enough to be screen-ready.

Introduction

Everyone talks about the onsite. Nobody talks about the technical screen, which is the round that gates access to the onsite. In practice, the technical screen is where 60 to 70 percent of candidates are filtered out, which makes it the single most important round in the FAANG pipeline statistically. This guide breaks down exactly what it tests and how to pass it cleanly.

Table of Contents

• What the Technical Screen Actually Is
• The Format at Each Major Company
• The Problem You Will Get
• The 45-Minute Timeline
• Top 12 Screen Questions (with Patterns)
• The Answer Template
• What Interviewers Score
• Red Flags That Fail You
• A 14-Day Preparation Plan
• FAQ
• Conclusion

What the Technical Screen Actually Is

The technical screening interview is a 45-minute live coding session, usually over Zoom or Google Meet, on a shared coding pad (CoderPad, HackerRank CodeScreen, or Google Doc). It is conducted by a working engineer, not a recruiter.

The company's goal is to decide in 45 minutes whether to spend an entire day of engineering time interviewing you at the onsite. They are not looking for perfection. They are looking for the minimum signal that "this person is worth 5 more hours of our team's time".

This distinction matters because the interview is not calibrated as "solve LeetCode-hard". It is calibrated as "do not waste our time". You pass by being clean, not by being brilliant.

The Format at Each Major Company

The screen format is remarkably standard across FAANG, with minor variations:

• Google: One problem, 45 minutes. Problem difficulty calibrated to medium. Follow-up questions if you solve quickly.
• Meta: Two problems, 45 minutes. First easier, second medium-to-hard. Time pressure is real.
• Amazon: One problem + one Leadership Principle behavioral question, 60 minutes total.
• Microsoft: One problem, 45 to 60 minutes, with occasional OOP-design variations.
• Apple: Varies by team. One or two problems, sometimes with an OOP follow-up.

Before the screen, ALWAYS ask the recruiter: "How many problems will the interviewer likely cover? Is there a behavioral component?"

The Problem You Will Get

The technical screen problem is almost always LeetCode-medium or an easy variant with a twist. It is rarely a LeetCode-hard.

The problem will test one of these eight patterns 90 percent of the time:

1. Two pointers (classic arrays, strings, containers).
2. Sliding window (longest substring, minimum window).
3. Hash map lookup (two sum, subarray sums).
4. Tree traversal (DFS or BFS, level order, path sums).
5. Dynamic programming, 1D (climbing stairs, house robber, coin change).
6. Intervals (merge intervals, meeting rooms).
7. Binary search on sorted or rotated arrays.
8. Basic graph (number of islands, clone graph).

If you have solved three problems from each of these eight patterns out loud with a timer, you are screen-ready. 24 problems total, not 500.

The 45-Minute Timeline

A well-paced technical screen breaks down roughly like this:

• Minutes 0 to 2: Greeting, brief resume chat.
• Minutes 2 to 5: Problem statement + your clarifying questions.
• Minutes 5 to 8: Walk through a small example, state the brute force.
• Minutes 8 to 12: Propose the optimal approach, state its complexity.
• Minutes 12 to 32: Code the solution.
• Minutes 32 to 38: Trace through your code with the example and one edge case.
• Minutes 38 to 42: Discuss optimizations, follow-ups, or a second shorter problem.
• Minutes 42 to 45: Your questions for the interviewer.

If you are at minute 25 and still arguing about the approach, you have a problem. Coding has to start by minute 15 at the latest to have a chance at finishing.

Top 12 Screen Questions (with Patterns)

These 12 problems, or close variants, make up more than half of all 2025 and 2026 technical screens.

1. Two Sum (hash map). Warm-up at some companies.
2. Valid Parentheses (stack).
3. Best Time to Buy and Sell Stock (DP or single pass).
4. Longest Substring Without Repeating Characters (sliding window).
5. Merge Intervals (sort + sweep).
6. Meeting Rooms II (heap or sweep).
7. Binary Tree Level Order Traversal (BFS).
8. Number of Islands (DFS/BFS on grid).
9. Coin Change (1D DP).
10. Word Break (DP + string).
11. Rotate Image (matrix manipulation).
12. Reverse Linked List (classic).

If you cannot solve all 12 in 25 minutes each with clean code and correct complexity analysis, keep practicing.

The Answer Template

Every technical screen answer should follow this shape:

1. Restate the problem (30 seconds).

"So the input is an array of integers, and I need to return indices of two numbers that sum to the target. Is that right?"

2. Clarify (1 to 2 minutes).

• Can the array be empty?
• Are there duplicates?
• Can the answer include the same index twice?
• How large is n?

3. Walk through an example (1 minute).

Draw a small case on the shared editor. Trace the expected output.

4. State the brute force.

"A brute force is to check every pair — O(n^2) time, O(1) space. Let me see if I can do better."

5. Propose the optimal (1 to 2 minutes).

"If I store each element in a hash map as I scan, I can look up target - current in O(1). Total O(n) time, O(n) space."

6. Code (15 to 20 minutes).

Clean variable names, no clever one-liners, one function at most.

7. Test (3 to 5 minutes).

Walk through the example line by line. Then pick one edge case (empty input, negative numbers, exact-target).

8. Discuss complexity and follow-ups.

Say it explicitly: "O(n) time, O(n) space." If asked, discuss how you would handle streaming, unsorted output, memory-constrained environments.

What Interviewers Score

After the interview, the interviewer writes feedback on a fixed rubric. The axes are:

1. Problem solving — did you reason through the problem, not just guess?
2. Coding — was your code clean, correct, and complete?
3. Verification — did you test and catch your own bugs?
4. Communication — did you think out loud and respond to hints?

A strong "yes" on all four is a pass. A "no" on any one usually means a rejection unless the other three are exceptional.

Red Flags That Fail You

• Jumping into code with no clarifying questions. Instant downgrade.
• Coding in silence for more than 2 minutes. The interviewer cannot score what they cannot see.
• Submitting code that fails your own walk-through. Always trace before saying "done".
• Arguing with the interviewer's hint. Accept hints gracefully. Fighting them means you score low on "receptive to feedback".
• Running out of time without finishing. Always leave 5 minutes for testing.
• Skipping complexity analysis. Interviewers ALWAYS ask. Not stating it without being asked is a mild downgrade.
• Inflating your solution's elegance. "This is optimal" when it is not makes you look unaware.

A 14-Day Preparation Plan

• Days 1 to 3: Solve 3 problems per day across the 8 patterns. Out loud. With a timer.
• Days 4 to 6: Solve the top 12 problems above. Out loud. Review your code the next day.
• Day 7: One full mock interview with a peer.
• Days 8 to 10: Another 3 problems per day, focused on patterns you found weakest.
• Day 11: One full mock interview, video recorded.
• Day 12: Review the recording. Note verbal tics, rambling, silence gaps.
• Day 13: Light review only. Re-solve two medium problems you have already seen.
• Day 14 (interview day): See morning routine from our tech interview anxiety guide.

Frequently Asked Questions

Can I use my preferred language?

Yes. Pick one. Python or C++ are the most common. Do not switch languages mid-interview.

What if the problem is something I have never seen?

Treat it as a medium LeetCode you have not solved. Clarify, example, brute force, optimize, code. The process works even on unfamiliar problems.

Should I tell the interviewer if I have seen the problem before?

Yes. Omitting it is dishonest and interviewers can usually tell. Disclose briefly: "I have seen a similar problem before; let me walk through it as if from scratch."

What if I get stuck and the interviewer offers a hint?

Accept it gracefully. Say "thank you, that helps". Then use it. Refusing or ignoring hints costs you points on "receptive to feedback".

Does the interviewer give a pass/fail at the end?

Almost never. They write private feedback that goes to the hiring committee.

Conclusion

The technical screen is a filter, not a final exam. You pass by executing 45 minutes cleanly: clarify, example, brute force, optimal, code, test. Most candidates fail by skipping the process and diving into code. Follow the template, solve the top 12, and you will clear the screen and earn your onsite invite.

Frequently asked questions

What is the format of a typical technical screening interview at FAANG?

A 45-minute live coding session over Zoom or Google Meet on a shared editor like CoderPad or HackerRank, conducted by a working engineer. Google does one medium problem in 45 minutes, Meta does two problems in 45 minutes, Amazon adds a Leadership Principle question in 60 minutes total, and Microsoft and Apple vary by team. Always ask the recruiter the exact format before the call.

What kind of problems are asked in a technical screening interview?

Almost always LeetCode-medium or an easy variant with a twist, rarely LeetCode-hard. The problem will test one of eight patterns 90 percent of the time: two pointers, sliding window, hash map lookup, tree traversal, 1D dynamic programming, intervals, binary search, or basic graph problems like number of islands. Three problems per pattern is enough.

What does the technical screen interviewer actually score?

Four axes: problem solving (did you reason through it), coding (was the code clean and complete), verification (did you test and catch bugs), and communication (did you think out loud and respond to hints). A strong yes on all four passes; a no on any one usually means rejection unless the others are exceptional.

Should I tell the interviewer if I have seen the screening problem before?

Yes. Omitting it is dishonest and interviewers can usually tell from your speed and confidence. Disclose briefly: 'I have seen a similar problem before; let me walk through it as if from scratch.' Honesty is rewarded and you still demonstrate the full process from clarification to testing.

How long should I prepare for a technical screening interview?

Fourteen days is enough for an experienced engineer. Days one to three: three problems daily across the eight patterns out loud with a timer. Days four to six: the top twelve screen problems. Day seven and eleven: full mock interviews. Days eight to ten: focus on weakest patterns. Day thirteen: light review only. Day fourteen: warm up with one easy problem on the morning of.