Google Interview Guide

Role: Software Engineer

Google's intern and new grad interview process is structured but variable by round count. The core emphasis is strong DSA fundamentals — Google runs its own internal question bank and actively purges leaked questions, so pattern recognition matters more than memorizing specific problems.

Process Overview

OA (some roles): 3 LC-style questions, easy to medium. Correctness prioritized over performance.

Technical Rounds (2–3): Two 45-minute back-to-back interviews. Each has 1–2 LC-style problems. If your results are borderline, you may get a third "tiebreaker" round.

Googleyness (Culture Fit): Usually a standalone 45-minute round. Behavioral questions about how you work with others, handle ambiguity, and align with Google's values. Can be scheduled with or separately from technicals.

Team Match: After passing technicals, you go through calls with teams who want to hire you. Teams ask about experience and project fit — not usually additional hard LC.

Technical Round Details

No IDE, no test cases provided. You code on Google Docs (or an internal tool). You must write your own test cases and walk through them. Practice this — it's a different skill from coding in an IDE.

Difficulty: Easy to medium. Google does ask hard problems (2D DP has come up), but the median is LC medium. Strong fundamentals beat memorized solutions.

Frequently tested topics across candidates:

Arrays and strings (two pointers, sliding window)
Graphs (cycle detection via DFS, BFS traversal)
Trees (LCA, path problems, distributing coins)
Dynamic programming — especially 2D DP (Google is known for this)
Class design / OOP problems
Concurrency / parallel computation (rare but has appeared)

What Google Looks For

Communicate constantly. Don't code in silence. Walk through your approach, explain why you're making choices, and flag trade-offs. Interviewers want to see how you think, not just that you got the answer.

Write your own test cases. After implementing, proactively test edge cases: empty input, single element, duplicates, negative numbers. Candidates who don't test themselves often get flagged.

Don't freeze on unfamiliar concepts. If you get a problem framed around something unfamiliar (e.g., parallel computation, specific domain terms), re-read the problem and extract what it's actually asking. It's usually a standard algorithm in disguise.

DP tip: If you're in a loop and stuck, ask yourself if there's overlapping subproblem structure. Google interviewers have explicitly told candidates "Google loves asking DP."

Googleyness Round — Sample Questions

Tell me about a time you had a conflict with a teammate. How did you resolve it?
Describe a situation where you had to work with someone whose style was very different from yours.
Tell me about a time you failed. What did you learn?
How do you handle feedback you disagree with?
Tell me about a project you're most proud of and why.

Common Mistakes

Jumping into code without explaining the approach first
Not testing your own solution — Google doesn't provide test cases
Optimizing prematurely before getting a working solution
Not asking clarifying questions at the start
Treating the Googleyness round as low-stakes — rejections happen here

Reported Questions (independent report)

Secondhand report of questions from a candidate's Google interviews:

Top K — Top K Frequent Elements / kth largest family
Design Hit Counter (LC 362)

Both were considered easy by the candidate. The same thread's difficulty read matches the variance noted above:

Google asks cancer LC / If you get unlucky 50% it's LC easy 50% it's LC hard

Source: community report, April 2026