Google Software Engineer Interview Review: Complete Record of 5 Rounds with Real Questions

Google Software Engineer Interview Review: Complete Record of 5 Rounds with Real Questions

Background

Let me start with my background — 4 years of Java backend development experience, currently working at a fintech company building payment systems. My tech stack is primarily Spring Boot + MyBatis + MySQL + Redis, with some microservices work as well. In February 2026, a former colleague referred me for a Software Engineer position at Google.

Why Google? Honestly, after 4 years at a fintech company, the business was stable but tech stack evolution was slow — microservice governance and containerization hadn't really taken off. Google's engineering culture needs no introduction. Their distributed systems and infrastructure are industry benchmarks, and I wanted to learn from the best. Plus, the compensation at Google's L5 level is genuinely competitive — that's a practical consideration too.

Preparation took about 3 months. For Java fundamentals, I re-read "Understanding the JVM" and "The Art of Concurrent Programming in Java." For frameworks, I studied Spring source code analysis and MyBatis internals. For distributed systems, I reviewed distributed transactions, distributed locks, and message queues. I solved around 150 LeetCode problems, focusing on the Top 100 and Google's frequently asked questions. I also prepared a detailed project portfolio documenting architecture diagrams, technology selection rationale, and production incidents for each system.

Round 1: Technical Fundamentals (Phone Screen, 65 minutes)

The interviewer sounded fairly young — likely a senior engineer on the team. After a brief project overview, we jumped straight into fundamentals.

1. HashMap implementation internals

This classic question was well-prepared. I covered the evolution from JDK 1.7's array + linked list to JDK 1.8's array + linked list + red-black tree. I detailed the put process: compute the hash, locate the bucket, insert if empty, traverse the linked list if occupied — overwrite value if key matches, or append via tail insertion. When linked list length exceeds 8 and array length exceeds 64, convert to red-black tree. I also covered the resizing mechanism — load factor of 0.75, doubling capacity, and the rehash process.

The interviewer followed up with why the load factor is 0.75. I explained it's a time-space tradeoff — too low wastes space, too high causes excessive hash collisions. 0.75 is a reasonable threshold based on Poisson distribution collision probabilities.

2. ConcurrentHashMap implementation

I covered the evolution from JDK 1.7's Segment-based locking to JDK 1.8's CAS + synchronized approach. In 1.8, put operations first attempt CAS insertion; if that fails, synchronized locks the head node for insertion. Resizing supports multi-threaded data migration, much more efficient than 1.7. The interviewer asked about the size() method implementation — I explained the baseCount + CounterCell array approach, similar to LongAdder.

3. Thread pool core parameters

I listed all 7 core parameters: corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, and handler. Then I detailed the task submission flow: check if core threads are full — if not, create a core thread; if full, add to the queue; if queue is full, create a non-core thread; if all full, execute the rejection policy. The interviewer asked about the four rejection policies: AbortPolicy, CallerRunsPolicy, DiscardPolicy, and DiscardOldestPolicy — I covered all of them.

4. The volatile keyword

I explained two effects: ensuring visibility (modifications immediately flushed to main memory) and preventing instruction reordering. I detailed memory barriers — StoreStore before volatile writes, StoreLoad after; LoadLoad before volatile reads, LoadStore after. The interviewer asked if volatile guarantees atomicity — I said no, using i++ as a counterexample, explaining that AtomicInteger or synchronized is needed.

Round 1 Summary: Overall felt good. Fundamentals were solid, HashMap and ConcurrentHashMap were explained in depth. The interviewer said "solid fundamentals" at the end and told me to wait for the next round.

Round 2: Technical Deep Dive (Video Call, 78 minutes)

Got the Round 2 invite 5 days later. The interviewer was a Staff Engineer (L6) who asked deeper questions with relentless follow-ups.

1. JVM memory model

I covered both thread-private and thread-shared areas. Thread-private: program counter, VM stack, native method stack. Thread-shared: heap, method area (metaspace in JDK 8+). I detailed heap generational structure: young generation (Eden + Survivor0 + Survivor1) and old generation. The interviewer asked about object allocation: new objects first go to Eden, surviving objects copy to Survivor after Minor GC, objects reaching the age threshold (default 15) promote to old generation. Large objects go directly to old generation.

2. GC algorithms and garbage collectors

I covered four algorithms: mark-sweep, mark-copy, mark-compact, and generational collection. Then discussed common collectors: Serial, ParNew, Parallel Scavenge, CMS, G1, and ZGC. I focused on CMS's four phases and its drawbacks (floating garbage, memory fragmentation), and G1's Region-based design and Mixed GC. The interviewer asked about ZGC — I explained colored pointers and read barriers enabling sub-millisecond pauses.

3. Spring AOP internals

I explained two implementation approaches: JDK dynamic proxies and CGLIB proxies. JDK dynamic proxies are interface-based, creating proxy objects via Proxy.newProxyInstance; CGLIB is inheritance-based, generating subclasses of the target class. Spring defaults to JDK proxies when the target implements interfaces, otherwise CGLIB. The interviewer asked about AOP use cases — I covered transaction management, logging, authorization, and performance monitoring.

4. MyBatis caching mechanism

I covered first-level and second-level caches. First-level cache is SqlSession-scoped, enabled by default — identical queries within the same SqlSession hit the cache. Second-level cache is Mapper-scoped, requires manual enablement, and is shared across SqlSessions. The interviewer asked when first-level cache invalidates — DML operations clear it, as does manually calling clearCache().

5. Algorithm: LeetCode 215 Kth Largest Element in an Array

I used a min-heap approach — maintain a min-heap of size K, replacing the top when encountering a larger element. Time complexity O(NlogK), space O(K). The interviewer asked for a more optimal solution — I explained QuickSelect based on quicksort's partition, with average O(N) time. I wrote the QuickSelect code, stumbling a bit on partition boundary conditions but ultimately completing it.

Round 2 Summary: Significantly harder than Round 1. JVM and GC were covered in depth, Spring AOP was decent. Algorithm was completed but not fluently. The interviewer's follow-up depth was noticeably greater than Round 1.

Round 3: System Design (Video Call, 85 minutes)

Got the Round 3 invite a week after Round 2. The interviewer was another Staff Engineer, focusing on system design and distributed systems.

1. Distributed transaction solutions

I covered several approaches: 2PC (Two-Phase Commit), TCC (Try-Confirm-Cancel), Saga, local message table, and MQ-based eventual consistency. I focused on the local message table approach we used — business operations and message records are committed in the same local transaction, then a scheduled task scans the message table for compensation. The interviewer asked about 2PC's problems — I covered synchronous blocking, single point of failure, and data inconsistency.

2. Redis clustering solutions

I covered three approaches: master-slave replication, Sentinel mode, and Cluster mode. I focused on Cluster mode — 16,384 hash slots distributed across nodes, with clients locating specific nodes via CRC16(key) % 16384. The interviewer asked about Cluster scaling — I explained slot migration: set the target node to importing state, source node to migrating state, then migrate keys one by one.

3. Message queue selection

I compared RocketMQ and Kafka. RocketMQ supports transaction messages, delayed messages, and message backtracking — suitable for business scenarios. Kafka offers high throughput and big data ecosystem integration — suitable for logging and stream processing. The interviewer asked about our project's selection — we chose RocketMQ because payment scenarios require transaction messages and strict message ordering.

4. System design: Design a flash sale system

I'd prepared this in advance, covering multiple layers: Frontend — duplicate click prevention, CDN for static assets, CAPTCHA for bot prevention. Gateway — rate limiting (token bucket), IP blacklisting. Application — pre-deduct inventory (Redis atomic operations), async order creation (MQ for peak shaving). Data — optimistic locking for inventory deduction, fallback with database row locks. The interviewer asked about overselling — I explained Redis DECR atomic operations with Lua scripts, and optimistic locking at the database level (version number mechanism).

5. Algorithm: LeetCode 200 Number of Islands

Classic DFS problem — traverse the grid, when encountering '1', DFS to mark all adjacent '1's as visited, increment island count. Completed smoothly in about 10 minutes. The interviewer asked for time complexity — O(M×N).

Round 3 Summary: System design went well — flash sale system was prepped in advance. Distributed transactions and Redis clustering were decent. Overall felt about 70-30 positive, more confident than previous rounds.

Cross-functional Interview (Video Call, 60 minutes)

Got the cross-functional invite 4 days after Round 3. The interviewer was a Staff Engineer from another team, primarily validating previous interview results.

1. Project architecture design

I detailed the payment system's overall architecture across three dimensions: gateway layer (routing, rate limiting, authentication), service layer (payment service, account service, settlement service split by business domain), and data layer (read-write separation and sharding). The interviewer asked about sharding strategy — we hash by merchant ID across 16 databases with 16 tables each.

2. Technology selection rationale

Several "why A instead of B" questions: why RocketMQ over Kafka, why Spring Cloud over Dubbo, why sharding over TiDB. I answered each from three dimensions: business requirements, team capabilities, and operational costs. The interviewer seemed satisfied.

3. Production incident troubleshooting

I shared an OOM incident — during a promotional event, surging order volume caused memory overflow. Troubleshooting: GC logs showed frequent Full GC, then jmap heap dump analysis with MAT revealed the order query API was returning full datasets without pagination limits. Temporary fix: added pagination parameter validation. Long-term: introduced query rate limiting.

Cross-functional Summary: More about validating whether your project experience is genuine. Questions were open-ended, mainly testing whether you can articulate your projects clearly. Felt okay overall.

HR / Hiring Committee Review (Video Call, 30 minutes)

Got the HR interview invite 3 days after the cross-functional. The HR interviewer was friendly with standard questions.

1. Career planning

Short-term: deepen expertise in distributed architecture and middleware at Google. Long-term: become a tech lead capable of independently owning system architecture design.

2. Googleyness and culture fit

Asked about "focus on the user" — I explained that in payment systems, stability and user experience embody this principle: the system can't go down, transactions can't be lost, settlements can't be slow. Also asked about "adaptability" — in fintech, regulatory policies change frequently, and technical solutions must adjust accordingly.

3. Compensation expectations

I stated L5 as my target level with compensation around $180K base. HR said they'd provide feedback after leveling and compensation committee review.

Interview Questions Summary

Round 1:

1. HashMap implementation internals
2. ConcurrentHashMap implementation mechanism
3. Thread pool core parameters and task submission flow
4. volatile keyword effects and limitations

Round 2:

1. JVM memory model and object allocation
2. GC algorithms and garbage collector comparison
3. Spring AOP internals (JDK proxy vs CGLIB)
4. MyBatis first-level and second-level caching
5. LeetCode 215 Kth Largest Element in an Array

Round 3:

1. Distributed transaction solution comparison
2. Redis clustering and scaling
3. Message queue selection (RocketMQ vs Kafka)
4. System design: Flash sale system
5. LeetCode 200 Number of Islands

Cross-functional:

1. Project architecture design details
2. Technology selection rationale
3. Production incident troubleshooting experience

HR / Hiring Committee:

1. Career planning
2. Culture fit and values alignment
3. Compensation expectations

Key Takeaways and Advice

1. Java fundamentals must be rock-solid. Google's Java fundamentals assessment is extremely thorough — HashMap, ConcurrentHashMap, and JVM are almost guaranteed questions. Don't just memorize talking points — understand the underlying principles and design rationale.

2. Distributed systems and system design are the focus. From Round 3 onward, it's mostly system design and distributed systems. Prepare several common system design problems (flash sale, URL shortener, news feed) and develop your own answering framework.

3. Project experience must withstand deep probing. Google interviewers will keep following up to deeper levels. If your project experience is fabricated or insufficiently deep, you'll be caught. Prepare "why did you design it this way" answers for every project.

4. Don't neglect algorithms. While Google interviews aren't purely algorithm-driven, each technical round typically includes one algorithm problem. Medium difficulty primarily — I recommend 100-150 problems.

5. Referrals matter. I was referred and got a phone screen within 3 days of submitting. Cold applications can take much longer and may not even pass resume screening.

Result: Received an L5 offer 2 weeks after the HR round, with compensation slightly above my expectation. Overall very satisfied.

FAQ

Q: What does each of the 5 Google interview rounds cover?
A: Round 1 fundamentals (HashMap, concurrency, JVM), Round 2 deep dive (GC, Spring source code, algorithms), Round 3 system design (distributed systems, architecture), Cross-functional project validation, HR/culture fit and compensation.

Q: How long does the interview process take?
A: About 6 weeks from application to offer. Round 1 to Round 2 was 5 days, Round 2 to Round 3 was 7 days, Round 3 to cross-functional was 4 days, cross-functional to HR was 3 days, and HR to offer was 2 weeks.

Q: Is L5 achievable with 4 years of experience?
A: Possible but not easy. L5 requires demonstrated ability to independently own systems and technical depth. With strong project highlights and solid system design answers, 4 years can land L5.

Q: How high is Google's algorithm bar?
A: Moderate. Not a pure algorithm interview, but each round typically has one problem at LeetCode medium difficulty. The focus is on thought process and code quality.

Q: What is the cross-functional interview?
A: An interviewer from another team validates previous interview results for objectivity. Questions are more open-ended, focusing on project authenticity and technical depth.