Uber Backend Engineer Interview: Complete Review of 3 Technical Rounds with Real Questions

Background

Let me introduce myself first. I have 3 years of Java backend development experience, currently working at a mid-size e-commerce company. Our tech stack is mainly Spring Cloud + MySQL + Redis + Kafka, and I handle order and payment-related business. Honestly, after 3 years in e-commerce, I was very familiar with the business, but I felt like I'd hit a technical ceiling and wanted to challenge myself at a bigger platform.

In March this year, I saw Uber was hiring backend engineers on a job platform and submitted my resume. Surprisingly, I got an HR call the very next day to schedule an interview. Uber's interview process consists of three technical rounds plus one HR round, and it took me about 2 weeks to complete the entire process. Here's a detailed breakdown of each round's real questions and my responses.

Complete Interview Process Review

Round 1 (About 1 Hour, Fundamentals + Algorithms)

The first-round interviewer was relatively young, seemingly a senior developer on the team. The pace was tight — questions came one after another with almost no small talk.

Spring-related:

The first question was about Spring IOC principles. I explained the Bean lifecycle — from instantiation, property population, initialization to destruction — and mentioned the three-level cache for resolving circular dependencies. The interviewer followed up on AOP implementation principles, and I explained the differences between JDK dynamic proxies and CGLIB proxies, along with Spring's default selection strategy (JDK for interfaces, CGLIB otherwise).

MySQL-related:

Heavy focus on index principles. I explained why B+ trees are suitable for indexes (compared to B-trees and hash indexes), then the difference between clustered and non-clustered indexes — clustered index leaf nodes store complete row data, while non-clustered indexes store primary key values, requiring a table lookup for non-indexed columns. The interviewer followed up on covering indexes and index failure scenarios (function operations, implicit type conversions, violating leftmost prefix rule, etc.).

Redis-related:

Asked about Redis data structures and their underlying implementations. I covered SDS, ziplist, skiplist, and hashtable. The interviewer focused on ZSet's underlying implementation — I explained the two encoding methods: ziplist and skiplist+hashtable, and when it converts from ziplist to skiplist (element count exceeds 128 or single element exceeds 64 bytes). Then came questions about cache penetration, cache breakdown, and cache avalanche — their differences and solutions.

Algorithm Problems:

Two algorithm problems were given. The first was reversing a linked list — simple, done in 5 minutes. The second was merging K sorted linked lists. I used a min-heap approach with O(NlogK) time complexity, finishing in about 15 minutes. The interviewer asked me to analyze time and space complexity, and whether there was a better solution — I mentioned the divide-and-conquer approach, also O(NlogK) but with better space usage.

Round 2 (About 1 Hour, Architecture + System Design)

The second-round interviewer was the tech lead, asking more architecture and system design questions with emphasis on the thought process.

Microservice Architecture Design:

The interviewer asked me to draw my current project's microservice architecture diagram, then drilled into details about inter-service call relationships, API gateways, and service registration/discovery. I explained that we use Spring Cloud Gateway as the API gateway, Nacos for service registry, and OpenFeign for inter-service calls. The interviewer followed up: "What if Nacos goes down?" I explained local caching and service instance heartbeat mechanisms, but honestly, my answer wasn't deep enough.

Distributed Transactions:

This is a high-frequency topic. The interviewer asked how we handle distributed transactions in our project. I explained Seata's AT mode and the eventual consistency solution we actually use — based on Kafka messages + local message tables. The interviewer followed up on the differences between TCC and Saga patterns and their respective use cases. I was well-prepared for this and answered well.

Kafka-related:

Heavy focus on message loss and duplicate consumption. For message loss: I explained using acks=all + retries on the producer side, min.insync.replicas on the broker side, and manual offset commits on the consumer side. For duplicate consumption: I explained idempotency design — using unique IDs + database unique constraints. The interviewer also asked why Kafka is so fast — I covered sequential writes, zero-copy, page cache, and partition parallelism.

System Design: Design a Food Delivery Search System

This was an open-ended question where the interviewer asked me to design from scratch. I first clarified requirements — is the search scope national or local? Does it need real-time updates? The interviewer said local search, no strict real-time requirement. Then I expanded on these dimensions:

1. Storage layer: ES for search engine, MySQL for persistent storage, Redis for hot query caching

2. Index design: Index by city, full-text indexes on restaurant names, categories, and addresses, with ratings and sales as sort fields

3. Search flow: User input → tokenization → ES retrieval → filtering and sorting → return results

4. High availability: ES cluster deployment, read-write separation, cache warming

The interviewer was generally satisfied with my design but pointed out that I didn't consider search recommendations and personalized ranking — a genuine oversight on my part.

Round 3 (About 50 Minutes, Project + Soft Skills)

The third round was with the department director. Questions were more macro-level, focusing on technical vision and depth of thinking.

Project Architecture Evolution:

The interviewer asked me to describe the most challenging project I'd been involved in. I described our company's migration from monolithic to microservice architecture, including service decomposition principles (by business domain), data migration strategy (dual-write + reconciliation), and canary deployment process. The interviewer followed up: "What was the biggest problem during decomposition?" I discussed distributed transaction and data consistency issues and our solutions.

Technology Selection Trade-offs:

The interviewer asked an interesting question: "If you could choose the tech stack again, what different decisions would you make?" I shared several reflections — for example, we chose Seata but found the performance overhead significant in practice; if I could redo it, I'd prioritize message-based eventual consistency. Also, we used Eureka for service registry, but Nacos had more features and the migration cost wasn't high — we should have chosen Nacos from the start.

Production Incident Troubleshooting:

The interviewer posed a scenario: "A production API suddenly becomes slow — how do you troubleshoot?" I explained my approach — first check monitoring to see if it's isolated to specific machines, then check GC logs for Full GC, then check database slow query logs, and finally check for network issues. The interviewer followed up: "If it's a slow database query, how do you optimize?" I covered adding indexes, optimizing SQL, and database sharding.

Team Collaboration:

Finally, some soft skill questions — how to handle disagreements about technical solutions, how to drive cross-team collaboration, and how to mentor juniors. I gave real examples from my work, and the interviewer seemed to appreciate them.

Result

Five days after the third round, HR called to discuss compensation, and I ultimately received the offer. The salary increase was about 30% — not spectacular, but considering Uber's technical culture and growth opportunities, I was quite satisfied.

Real Interview Questions Summary

Round 1 Questions:

1. Spring IOC principles and Bean lifecycle

2. Three-level cache for circular dependency resolution

3. Spring AOP implementation (JDK dynamic proxy vs. CGLIB)

4. MySQL B+ tree index principles

5. Clustered vs. non-clustered index differences

6. Covering indexes and index failure scenarios

7. Redis data structures and underlying implementations

8. ZSet underlying implementation (ziplist vs. skiplist)

9. Cache penetration, breakdown, and avalanche — differences and solutions

10. Algorithm: Reverse a linked list

11. Algorithm: Merge K sorted linked lists

Round 2 Questions:

1. Microservice architecture design (gateway, registry, service calls)

2. What to do when Nacos goes down

3. Distributed transaction solutions (Seata AT/TCC/Saga/Eventual consistency)

4. Kafka message loss prevention

5. Kafka duplicate consumption idempotency design

6. Why Kafka is high-performance

7. System design: Design a food delivery search system

Round 3 Questions:

1. Project architecture evolution (monolith to microservice migration)

2. Technology selection reflections and trade-offs

3. Troubleshooting slow production APIs

4. Database slow query optimization

5. Team collaboration and conflict resolution

Takeaways and Advice

1. Fundamentals must be solid, but more importantly, you need to connect the dots. Round 1 tests fundamental knowledge — each topic isn't hard on its own, but the interviewer will chain multiple topics together. For example, after asking about Redis data structures, they'll immediately ask about cache penetration, breakdown, and avalanche. If you've only memorized facts, you'll easily get stuck.

2. Proactively clarify requirements for system design questions. In the Round 2 system design question, I confirmed the requirement boundaries upfront — this is crucial. Don't start designing immediately; first understand what the interviewer wants. During the design process, talk and draw simultaneously so the interviewer can see your thought process.

3. Project experience needs depth. Round 3 cares less about what you did and more about why you did it, what problems you encountered, and how you solved them. Before the interview, organize your projects using the STAR method, preparing 3-5 deep-dive points for each.

4. Don't neglect algorithms. While social recruitment algorithm problems aren't extremely difficult, you must be able to quickly write classics like reversing a linked list or merging K sorted lists. I recommend at least 1-2 problems daily to maintain your skills.

5. Don't be afraid to say "I don't know." When you encounter an unfamiliar question, it's better to honestly say "I'm not very familiar with this, but my understanding is..." and then share your reasoning process. Interviewers value your thinking approach more than the standard answer.

FAQ

Q: How many rounds does the interview typically have?

A: For social recruitment backend roles, it's usually three technical rounds plus one HR round. For higher levels (L8+), there might be an additional cross-team interview.

Q: How should I prepare for system design questions?

A: I recommend reading "System Design Interview" and thinking deeply in the context of your actual projects. Focus on common design patterns: load balancing, caching strategies, message queues, database sharding, and search engines.

Q: Are the algorithm questions difficult?

A: Social recruitment algorithm problems are roughly LeetCode medium difficulty — not extremely hard. But you need to write them quickly and correctly, and analyze complexity. Focus on linked lists, trees, dynamic programming, and sorting.

Q: How long until results come out?

A: Usually 1-3 days after each round. I got the HR call 5 days after Round 3, with the entire process taking about 2 weeks.

Q: Can I pass without big company experience?

A: Yes. I came from a mid-size company. The key is deep project understanding and solid fundamentals. Interviewers won't lower standards because of your company size, but they won't raise them either.