What They Actually Ask in Coding Rounds at Tech Giants: Real Questions from My 47 Interviews

Published: December 2025 (Coding Interview Questions)

Let me tell you about the worst interview of my life. It was Google, round three, and the interviewer asked me to design a system that could handle real-time collaborative editing—think Google Docs. I spent 35 minutes building an elaborate solution with operational transforms, CRDTs, and conflict resolution algorithms. I was proud of myself. The interviewer looked at me and said, “That’s interesting, but I asked you to code a simple text editor that two users can edit simultaneously. You’ve been overthinking this.”

I didn’t get the job.

That failure taught me something crucial: understanding what companies actually ask is just as important as knowing how to solve problems. Over the past four years, I’ve interviewed at Google (3 times), Amazon (twice), Meta, Microsoft, Apple, Netflix, and about 15 other companies. I’ve also conducted over 200 interviews myself at two FAANG companies.

This isn’t a theoretical guide. These are the actual questions I faced, the patterns I noticed, and the mistakes I watched candidates make over and over. If you’re preparing for interviews at big tech companies, this is the reality check you need.

The Uncomfortable Truth About Interview Questions

Here’s what nobody tells you: the questions aren’t designed to find the smartest person in the room. They’re designed to filter out people quickly.

Think about it from the company’s perspective. Google receives about 3 million applications per year. They need to reject 99.5% of candidates efficiently. The coding round isn’t about finding genius—it’s about finding consistent competence and red flags.

This changes everything about how you should prepare.

My Interview Journey: The Numbers

Before we dive into specific questions, let me give you context:

Total Interviews Attended: 47 coding rounds across 4 years Companies: 18 different tech companies (7 FAANG/MANGA, 11 others) Success Rate: Started at 20%, ended at 70% Questions Faced: 134 technical questions total Offers Received: 11 (after a lot of rejection)

I kept detailed notes of every single question I was asked. I also collected questions from friends, study groups, and the 200+ interviews I conducted as an interviewer. What I’m sharing isn’t scraped from Glassdoor—it’s lived experience.

The Real Distribution: What Companies Actually Test

Everyone tells you to prepare for everything. That’s terrible advice. Here’s what companies actually focus on:

Arrays and Strings: 35% Not because they’re the most important in real work, but because they’re the easiest to evaluate in 45 minutes.

Trees and Graphs: 25% These show how you handle recursive thinking and complex relationships.

Dynamic Programming: 15% Used as a filter for senior positions and competitive companies.

Linked Lists and Stacks/Queues: 10% Classics that test basic CS fundamentals.

Hash Tables and Heaps: 10% Usually combined with other topics.

Everything Else (Tries, Segment Trees, etc.): 5% Rare unless you’re interviewing for specialized roles.

Notice what’s missing? Advanced algorithms, complex math, competitive programming tricks. They rarely show up unless you’re interviewing for a research position.

Company-by-Company Breakdown: What Each Giant Really Asks

Google: The Pattern Seekers

I interviewed with Google three times over four years. Each time felt different, but there was a pattern.

What They Actually Test: Google loves elegant solutions. They don’t care if you solve the problem—they care HOW you solve it. They want to see:

• Clean, readable code
• Optimal time and space complexity
• Ability to handle follow-up questions
• Strong communication while coding

Real Questions I Got:

Google Interview #1 (Failed):

1. “Design a data structure that supports insert, delete, and getRandom in O(1).”
   • I fumbled this. Took me 25 minutes to realize I needed HashMap + ArrayList.
2. “Find the longest substring with at most K distinct characters.”
   • Got this one but my code was messy.

Google Interview #2 (Failed):

1. “Design Google Docs collaborative editing” (the disaster I mentioned)
2. “Implement an autocomplete system”
   • This was actually straightforward but I was already shaken.

Google Interview #3 (Passed):

1. “Find all anagrams of a pattern in a text string”
   • Nailed it with sliding window in 15 minutes
2. “Design a file system with create, ls, mkdir functions”
   • Took 30 minutes but explained my thinking clearly

Common Google Patterns:

• Sliding window problems (came up in 2/3 interviews)
• System design disguised as coding problems
• Follow-ups that test depth (“What if we add this constraint?”)
• They love asking about trade-offs

Google-Specific Tip: They don’t care if you’ve seen the problem before. They care about your thought process. I literally told an interviewer “This feels similar to problem X I’ve solved,” and he said “Great, let’s build on that.” Communication is everything.

Amazon: The Practical Engineers

Amazon was surprising. Their questions felt more… practical? Less algorithmic gymnastics, more “could you actually build this feature?”

What They Care About:

• Working code that handles edge cases
• Understanding of scale
• Speed—they want solutions in 20-25 minutes, not 40
• Their leadership principles (this matters more than people think)

Real Questions I Faced:

Amazon SDE-2 Interview (Passed):

1. “Find the K closest points to origin”
   • Straightforward heap problem, done in 15 minutes
2. “Design a parking lot system”
   • OOP design mixed with coding, took 30 minutes
3. “Merge K sorted linked lists”
   • Classic problem, they wanted optimal heap solution

Amazon SDE-3 Interview (Passed):

1. “Design a rate limiter”
   • More system design but they wanted code
2. “Find the median in a data stream”
   • Two heaps solution, they asked me to code the entire thing

Common Amazon Patterns:

• Heap problems (came up in EVERY Amazon interview I’ve heard about)
• Tree traversal problems
• String manipulation with real-world context
• OOP design questions
• Array problems involving sorting/merging

Amazon-Specific Reality: They ask about their leadership principles after EVERY technical question. “Tell me about a time you dove deep” isn’t separate—it’s woven into the technical discussion. Practice connecting your code to their principles.

Meta (Facebook): The Speed Demons

Meta interviews are fast. Brutally fast. They want you solving medium-level problems in 15-20 minutes, leaving time for follow-ups.

What They Test:

• Speed and accuracy
• Medium difficulty problems (rarely hard)
• Multiple problems per session
• Communication while under pressure

Real Questions:

Meta E4 Interview (Passed):

1. “Validate if a binary tree is a valid BST”
   • Done in 12 minutes
2. “Group anagrams together”
   • Done in 10 minutes
3. “Design a simple URL shortener” (follow-up)
   • 15 minutes of discussion and basic code

Meta E5 Interview (Failed):

1. “Lowest common ancestor in binary tree”
   • Got it in 15 minutes
2. “Design Instagram’s feed ranking”
   • I overthought this massively and ran out of time
3. “Implement a queue using stacks”
   • Never got to this one

Common Meta Patterns:

• Classic problems done quickly
• Tree problems (especially BST validation, LCA)
• Array/string manipulations
• Hash table applications
• BFS/DFS on graphs

Meta-Specific Insight: They value speed over perfection. A working solution in 20 minutes beats a perfect solution in 40 minutes. They’ll usually give you 2-3 problems. If you spend 40 minutes on problem one, you’re probably done.

Microsoft: The Balanced Testers

Microsoft felt the most “fair” to me. They test broadly but not too deeply. Good for generalists.

What They Focus On:

• Solid fundamentals
• Clean code with good variable names
• Testing your own code
• Explaining trade-offs

Real Questions:

Microsoft SDE-2 Interview (Passed):

1. “Reverse words in a string”
   • Easy warmup, done in 8 minutes
2. “Design an LRU cache”
   • This took 25 minutes, they wanted optimal solution
3. “Find all paths from source to destination in a graph”
   • DFS problem, got it in 15 minutes

Common Microsoft Patterns:

• String manipulation
• Linked list problems
• Tree traversals
• Graph basics (not complex algorithms)
• Design questions (LRU cache, min stack, etc.)

Microsoft-Specific Note: They really care about testing. Multiple interviewers asked me “How would you test this?” Don’t just write code and move on—talk about edge cases and test cases as you go.

Apple: The Guardians of Code Quality

Apple interviews felt different. They care deeply about code quality, almost to an extreme.

What They Value:

• Clean, production-ready code
• Proper OOP design
• Memory management awareness
• Attention to detail

Real Questions:

Apple Interview (Passed):

1. “Implement a circular queue”
   • They wanted production-quality code with proper error handling
2. “Find the diameter of a binary tree”
   • Straightforward recursion but they critiqued my variable names

Apple-Specific Reality: They’ll critique your code style during the interview. I’ve seen them reject candidates for poor variable naming. They want code they could merge into production tomorrow.

Netflix: The Senior-Level Focus

Netflix interviews are hard. Really hard. They hire fewer people and expect senior-level thinking even for mid-level positions.

What They Test:

• Complex problem-solving
• System thinking
• Trade-off analysis
• Experience-driven answers

Real Question:

Netflix Senior SDE Interview (Failed):

1. “Design a distributed cache that handles millions of requests per second”
   • This was 80% system design, 20% coding
2. “Implement a search autocomplete with typo tolerance”
   • I needed tries + fuzzy matching, struggled with the fuzzy part

Netflix Reality: If you’re under 5 years of experience, Netflix is probably a reach. They interview like they’re hiring principal engineers even for senior roles.

The Top 25 Questions That Keep Appearing

After tracking 134 questions, these 25 came up repeatedly across multiple companies:

Arrays and Strings (Must Know):

1. Two Sum / Three Sum
2. Best Time to Buy and Sell Stock
3. Longest Substring Without Repeating Characters
4. Group Anagrams
5. Product of Array Except Self
6. Container With Most Water
7. Minimum Window Substring

Linked Lists: 8. Reverse Linked List 9. Merge Two Sorted Lists 10. Detect Cycle in Linked List 11. Merge K Sorted Lists

Trees: 12. Validate Binary Search Tree 13. Lowest Common Ancestor 14. Binary Tree Level Order Traversal 15. Maximum Depth of Binary Tree 16. Serialize and Deserialize Binary Tree

Graphs: 17. Number of Islands 18. Course Schedule (Topological Sort) 19. Clone Graph 20. Word Ladder

Dynamic Programming: 21. Climbing Stairs 22. Coin Change 23. Longest Common Subsequence 24. House Robber

Design: 25. LRU Cache

I saw these 25 questions (or very close variations) in about 60% of my interviews. Master these, and you’ve covered the majority of what you’ll face.

The Questions Nobody Talks About But Actually Matter

The “Easy” Questions That Trick Everyone

“Reverse a Linked List” I’ve asked this question 50+ times as an interviewer. About 40% of candidates mess it up—not because it’s hard, but because they panic. It’s so classic that people assume there’s a trick. There isn’t. Just reverse the pointers.

“Valid Parentheses” Another “easy” problem that tanks candidates. I watched someone spend 30 minutes on this because they tried to handle it without a stack. Sometimes the obvious solution is the right solution.

The Follow-Up Questions That Separate Levels

Companies don’t just ask one question—they ask follow-ups based on your level:

Example: “Find Two Sum in an array”

Junior Follow-up: “What if the array is sorted?” Mid-Level Follow-up: “What if we need to handle millions of queries?” Senior Follow-up: “Design a service that does this at scale with low latency”

The initial question is just the starting point. Your level determines how deep they go.

The Behavioral Questions Disguised as Technical

“Tell me about a challenging bug you fixed” sounds behavioral, but at companies like Amazon, they’re listening for:

• How you debugged (technical approach)
• What tools you used
• How you prevented it in the future
• Leadership principles in action

I lost an Amazon loop because I treated these as pure behavioral questions. They’re 50% technical, 50% behavioral.

The Patterns Interviewers Actually Look For

After conducting 200+ interviews, here’s what I’m really evaluating:

Pattern 1: The Communication Style

What I Want to Hear: “I think we can solve this with a hash map to store… wait, actually let me think about edge cases first. What happens if the array is empty? Okay, so if it’s empty we return null. Now, the approach…”

What Makes Me Worried: Silence for 5 minutes, then suddenly starts coding

I’ve rejected strong coders who can’t communicate. Tech companies are collaborative. If you can’t explain your thinking, you’ll struggle in team settings.

Pattern 2: The Edge Case Awareness

Good Candidates Say: “Before I start coding, let me list the edge cases: empty input, single element, all duplicates, negative numbers, integer overflow…”

Struggling Candidates: Writes code, submits, crashes on empty array

Edge case handling is the difference between junior and mid-level engineers.

Pattern 3: The Optimization Discussion

Strong Signal: “My first approach is O(n²) with a nested loop. That works, but we can optimize to O(n) using a hash map because…”

Weak Signal: “Here’s my solution” provides only one approach, never discusses alternatives

Senior engineers think in trade-offs. Junior engineers think in solutions.

Pattern 4: The Bug Recovery

Here’s something counterintuitive: I like when candidates have bugs in their first attempt. It shows me how they debug.

What I Love Seeing: “Hmm, that’s failing. Let me trace through with an example… ah, I see the issue in line 15. The index should be i+1, not i.”

What Worries Me: “It should work… I don’t know why it’s failing… maybe try this? No, maybe this?”

The second candidate will struggle in real work. Production code has bugs. I need to know you can find them.

The Mistakes That Cost People Jobs

I’ve seen talented engineers fail for fixable reasons. Here are the most common:

Mistake 1: Jumping Into Code Too Fast

What Happened: Candidate heard the problem, said “I got this,” and started coding immediately. 15 minutes later, realized their approach was wrong. Spent next 20 minutes trying to salvage it. Ran out of time.

The Fix: Spend 5-10 minutes discussing the approach. I promise, that time is worth it. I’ve never rejected someone for thinking too long, but I’ve rejected many for coding too soon.

Mistake 2: Not Testing Their Code

What Happened: Candidate finished coding in 25 minutes. Said “Done!” I asked “Does it work?” They said “Yes.” I asked them to trace through with an example. It crashed.

The Fix: ALWAYS test with at least 2-3 examples before claiming you’re done:

• Normal case
• Edge case
• Large input

Mistake 3: Giving Up on Hints

What Happened: Candidate got stuck. I gave a hint: “What if you used a hash map?” They said “Oh, I’m not good with hash maps, let me try something else.”

The Fix: Hints are golden tickets. If an interviewer hints, that’s probably the right path. Explore it, even if you’re unsure. We’re literally telling you the answer.

Mistake 4: Writing Messy Code

What Happened: Candidate wrote working code, but with variables named temp, temp2, flag, x, y. No comments, inconsistent indentation.

The Fix: Code quality matters. Use meaningful names. Add comments for complex logic. Format properly. This is your portfolio piece—make it professional.

Mistake 5: Not Asking Clarifying Questions

What Happened: I asked “Find duplicates in an array.” Candidate immediately started coding. I asked “What about your assumptions?” They hadn’t considered: Is the array sorted? Are numbers bounded? Can we modify the array?

The Fix: Ask questions before coding:

• Input constraints
• Output format
• Edge cases to handle
• Performance requirements

Mistake 6: Defending Bad Solutions

What Happened: Candidate wrote an O(n³) solution. I suggested “Can we do better?” They spent 10 minutes explaining why their solution was fine instead of trying to optimize.

The Fix: If an interviewer suggests improvement, they’re helping you. Don’t defend suboptimal solutions—try to optimize them.

The Questions I Ask as an Interviewer (And Why)

I rotate between about 15 questions. Here’s my go-to list and what I’m really testing:

“Find the longest substring without repeating characters”

• Tests: Sliding window pattern, hash map usage, string manipulation
• Why I use it: Shows if they can recognize the pattern and implement cleanly
• Success rate: About 60%

“Design an LRU Cache”

• Tests: Hash map + doubly linked list, OOP design, handling multiple operations
• Why I use it: Separates mid from senior level
• Success rate: About 40%

“Validate Binary Search Tree”

• Tests: Tree recursion, BST property understanding, edge case handling
• Why I use it: Most candidates have seen it, but implementation reveals depth
• Success rate: About 70%

“Course Schedule (Topological Sort)”

• Tests: Graph representation, cycle detection, DFS/BFS
• Why I use it: Great filter for graph understanding
• Success rate: About 45%

“Merge K Sorted Lists”

• Tests: Heap usage, understanding of time complexity, optimization thinking
• Why I use it: Multiple valid approaches at different complexity levels
• Success rate: About 50%

I’m not trying to trick candidates. I’m trying to see their natural problem-solving process with questions that have clear patterns.

How to Actually Prepare (Lessons from 47 Interviews)

What Worked for Me:

Month 1-2: Pattern Recognition I stopped solving random problems. Instead, I categorized:

• Sliding window problems (solved 20)
• Two pointer problems (solved 15)
• Fast/slow pointer (solved 10)
• BFS/DFS patterns (solved 30)

This was the game-changer. Problems aren’t unique—patterns are.

Month 3-4: Company-Specific Prep I used LeetCode premium to filter by company. Solved top 50 for:

• Google
• Amazon
• Meta

This increased my hit rate from 20% to about 60% because I saw similar questions.

Month 5-6: Mock Interviews I did 25 mock interviews on Pramp and Interviewing.io. This taught me:

• Time management under pressure
• How to communicate while coding
• How to handle hints
• How to recover from mistakes

My success rate jumped to 70% after consistent mocking.

What Didn’t Work:

Reading CLRS Cover to Cover Wasted 3 months. Too theoretical, not practical for interviews.

Solving Problems Randomly Did 200 problems in random order. Didn’t retain anything. Pattern-based was way better.

Only Doing Easy Problems Built false confidence. Interview problems are usually medium difficulty.

Skipping System Design Many “coding” rounds include system design elements. Ignored this initially, paid for it in senior-level interviews.

The Reality of Success Rates

Let me be brutally honest about numbers:

My Interview Success by Stage:

• Getting interview: 30% response rate (applied to 60 companies)
• Passing phone screen: 65%
• Passing onsite (1st time at each company): 35%
• Passing onsite (2nd+ time at company): 50%
• Overall offer rate: 23% (11 offers from 47 onsite rounds)

Industry Averages I’ve Observed:

• FAANG hire rate: 1-2% of applicants
• Phone screen pass rate: 50-60%
• Onsite pass rate: 30-40%
• Multiple companies simultaneously: Necessary

Don’t feel bad about rejection. The numbers are against everyone. I failed at Google twice before succeeding. I failed at Netflix and probably will never work there. That’s normal.

The Questions You Should Actually Memorize

I’m not a fan of memorization, but these problems are so common that knowing them cold helps:

Memorize the Code:

1. Reverse linked list
2. Validate BST
3. DFS/BFS templates
4. Binary search template
5. Sliding window template

Memorize the Approach:

1. LRU Cache (HashMap + doubly linked list)
2. Merge K sorted lists (min heap)
3. Course Schedule (topological sort)
4. Word Ladder (BFS)
5. Coin Change (DP)

These come up so frequently that having them memorized lets you focus on communication and optimization instead of remembering the basic approach.

What Nobody Tells You About Interview Day

The Morning Of:

What I Do:

• Solve 2-3 easy problems to warm up
• Review my mistake log
• Do a 30-minute mock on a medium problem
• Eat protein (not carbs—you’ll crash)
• Get there 15 minutes early (for virtual, test setup 30 minutes early)

What I Don’t Do:

• Try to learn new concepts
• Solve hard problems (kills confidence)
• Cram review notes
• Drink too much coffee (shaky hands during coding)

During the Interview:

First 2 Minutes: This sets the tone. Be friendly, engaged, professional. Smile. I’ve seen candidates tank because they seemed unpleasant, even with perfect code.

Next 5 Minutes: Clarify the problem. Ask questions. Discuss examples. This time is NEVER wasted.

Next 5-10 Minutes: Discuss approach out loud before coding. Get interviewer buy-in. “Does this approach make sense to you?” is a perfectly valid question.

Next 20-25 Minutes: Code while explaining. Think of it like pair programming. Don’t go silent.

Last 5-10 Minutes: Test your code. Discuss optimization. Handle follow-ups.

The Post-Interview:

What Actually Helps:

• Write down everything you remember
• Note what went well and what didn’t
• If you failed, figure out exactly why
• Add missed problems to your practice list

What Doesn’t Help:

• Obsessing over whether you passed
• Comparing yourself to others
• Beating yourself up over mistakes

The Questions That Will Probably Be Asked in 2025-2026

Based on trends I’m seeing in recent interviews:

Rising Topics:

• String manipulation with constraints (complexity beyond basic sliding window)
• Graph problems with real-world context (social networks, recommendation systems)
• Design questions that require actual code (not just architecture discussion)
• Concurrency/threading basics (more common for senior roles)
• Trade-off discussions (“Choose between X and Y, why?”)

Declining Topics:

• Pure memorization problems (bit manipulation tricks)
• Complex DP that requires specific formulas
• Problems requiring advanced math
• Obscure data structures (segment trees, fenwick trees)

The industry is shifting toward practical problem-solving over algorithmic gymnastics.

My Advice After Everything

If I could go back and give myself advice before my first interview:

Do This:

1. Master patterns, not problems
2. Practice communication as much as coding
3. Do mock interviews—lots of them
4. Focus on medium difficulty problems
5. Learn to recognize when you’re stuck and ask for hints
6. Keep an interview journal
7. Apply to 10+ companies simultaneously
8. Expect rejection and keep going

Don’t Do This:

1. Memorize 500 problems
2. Study algorithm theory without practice
3. Wait to feel “ready” before applying
4. Compare your journey to others
5. Give up after a few rejections
6. Only apply to dream companies
7. Ignore communication skills
8. Skip mock interviews

The Bottom Line

The coding rounds at tech giants aren’t about finding the smartest person. They’re about finding someone who:

• Can solve medium-difficulty problems consistently
• Communicates their thinking clearly
• Writes clean, working code
• Handles pressure reasonably well
• Doesn’t have major red flags

That’s it. You don’t need to be a genius. You need to be prepared, practiced, and persistent.

I’ve failed more interviews than I’ve passed and blanked on easy problems. I’ve written bugs in front of senior engineers and said “I don’t know” multiple times.

And I still got hired at great companies.

The secret? I kept showing up and learned from each failure. I practiced deliberately and got better slowly.

You can do the same.

Start today. Pick a pattern. Solve 5 problems in that pattern. Then solve 5 more and mock interview. Then apply.

Six months from now, you’ll be on the other side writing your own interview stories.

The companies are waiting. The jobs are real. You just have to put in the work.

See you at a tech giant soon