Meituan Backend Developer Interview 3-Round Real Questions Collection: Complete Review for 3-Year Java Experienced Hire

Background

Let me start with my situation: 3 years of Java backend development experience, currently working at a mid-sized internet company on food delivery related systems. My tech stack is Spring Boot + MyBatis-Plus + MySQL + Redis + RabbitMQ. I applied to Meituan in early April this year, targeting a backend developer position in the In-Store Business Group through their official career site.

To be honest, I'd always admired Meituan — after all, if you build food delivery systems, Meituan is the gold standard in this space. But what held me back was that my current company, while not large, works on business highly relevant to Meituan's in-store segment, and I worried the interviewer might think I was just there to "copy homework." Then a college classmate who works in tech at Meituan's In-Store group told me, "Your business experience is directly relevant — that's an advantage, not a disadvantage." That convinced me to apply. I spent about two weeks preparing, focusing on Spring source code, MySQL index optimization, advanced Redis usage, distributed systems, and algorithm problems.

I submitted my application on April 3rd, a Wednesday afternoon. The very next day I received a call from HR — their efficiency was impressive, much faster than I expected. HR chatted briefly, confirmed my work experience and salary expectations, and said they'd schedule a technical interview.

Round 1: Technical Interview 1 (Video Call, ~60 minutes)

Round 1 was on April 8th, Tuesday at 10 AM, using Meituan's own video conferencing tool. The interviewer looked about 30, spoke gently, asked me to introduce myself, then said "Let's get started."

1. What's the difference between == and equals in Java

I explained that == compares reference addresses while equals compares content values. Object's equals defaults to ==, and String overrides equals to compare character by character. The interviewer followed up on the relationship between hashCode and equals — I said if equals returns true, hashCode must be equal, but equal hashCodes don't guarantee equals returns true, so you must override hashCode when overriding equals. This part went smoothly.

2. Difference between HashMap and ConcurrentHashMap

I said HashMap is not thread-safe while ConcurrentHashMap is. In 1.7, ConcurrentHashMap used Segment-based segmented locking; in 1.8, it switched to CAS + synchronized locking on individual bucket Nodes. The interviewer asked why 1.8 uses synchronized instead of ReentrantLock — I explained that after JDK 6, synchronized received significant optimizations (biased locking, lightweight locking), making its performance comparable to ReentrantLock without the need for manual lock release. I'd studied this specifically before, so it went okay.

3. Are Spring Beans thread-safe

I said Spring Beans are singletons by default and not inherently thread-safe. If a Bean is stateless (no mutable member variables), it can be considered thread-safe; if it has state, you need to handle thread safety yourself. The interviewer asked about solutions — I mentioned prototype scope, ThreadLocal, and synchronization. The interviewer nodded.

4. What are the Spring transaction propagation mechanisms

I listed 7: REQUIRED, SUPPORTS, MANDATORY, REQUIRES_NEW, NOT_SUPPORTED, NEVER, NESTED. I focused on REQUIRED (default — join existing transaction or create new one) and REQUIRES_NEW (always create a new transaction, suspending the current one). The interviewer asked about the difference between NESTED and REQUIRES_NEW — I stumbled a bit, only saying NESTED is a nested transaction where outer rollback causes inner rollback, while REQUIRES_NEW is completely independent. I felt my explanation wasn't clear enough, but the interviewer didn't press further.

5. When do MySQL indexes fail

I listed several cases: 1) using functions or arithmetic on indexed columns; 2) implicit type conversion, like querying a varchar column with an int; 3) LIKE starting with a wildcard; 4) OR conditions with non-indexed columns; 5) composite indexes not satisfying the leftmost prefix rule. The interviewer asked about a composite index (a,b,c) with WHERE a=1 AND c=3 — I said a can use the index but c cannot, because skipping b violates the leftmost prefix rule.

6. Redis persistence methods

I covered RDB and AOF. RDB takes snapshots at intervals, writing memory data to disk — fast recovery but potential data loss. AOF appends logs, recording every write operation — safer data but larger files. The interviewer asked about AOF's fsync policies — I mentioned always, everysec, and no, recommending everysec. They also asked about hybrid persistence — I explained RDB + AOF hybrid, writing an RDB snapshot first then appending AOF increments, balancing recovery speed and data safety.

7. How to handle Redis cache penetration, breakdown, and avalanche

Penetration: querying non-existent data that's in neither cache nor DB. Solutions: Bloom filter, cache null values. Breakdown: massive requests hitting DB when a hot key expires. Solutions: mutex lock, hot keys never expire. Avalanche: large number of keys expiring simultaneously. Solutions: add randomness to expiration times, multi-level caching, rate limiting and degradation. I'd memorized this well and rattled it off.

8. Algorithm: Reverse Linked List (LeetCode 206)

This one was simple — iterative three-pointer reversal, finished in 5 minutes. The interviewer asked about the recursive approach — I explained recursing to the end of the list then reversing next pointers layer by layer. The interviewer said "solid fundamentals."

9. How do you use RabbitMQ in your project

I described two scenarios: first, delivery status change notifications — rider acceptance, pickup, and delivery status changes are published to MQ, consumed by the order service and notification service; second, auto-cancellation for unaccepted orders — if no rider accepts within 15 minutes, the order is automatically cancelled to free up delivery capacity. The interviewer asked about handling message loss — I mentioned publisher confirms, message persistence, and consumer manual ACK.

Round 1 Summary

Round 1 was mostly fundamentals — not too deep but broad coverage. The Spring transaction propagation question about NESTED vs REQUIRES_NEW didn't go well — I was a bit nervous and my logic wasn't clear. Received the Round 2 notification on April 11th, a 3-day gap.

Round 2: Technical Interview 2 (Video Call, ~70 minutes)

Round 2 was on April 15th, Monday at 11 AM. The interviewer was clearly more senior, spoke fast, asked deeper questions, and often tied them to real scenarios.

1. Difference between G1 and CMS garbage collectors

I said CMS is an old-generation collector using mark-sweep, with floating garbage and memory fragmentation issues. G1 divides the heap into equal-sized Regions, no longer strictly separating young and old generations, using mark-compact without memory fragmentation. The interviewer asked about G1's Mixed GC — I explained G1 prioritizes reclaiming Regions with the highest value (high garbage ratio), and Mixed GC collects both young and some old generation Regions simultaneously. The interviewer asked when G1 triggers Full GC — I said when Mixed GC can't keep up with object allocation, it degrades to Serial Old for Full GC, which should be avoided at all costs.

2. MySQL's MVCC implementation

I explained that each row has two hidden columns: trx_id (most recent modifying transaction ID) and roll_pointer (pointer to undo log). Snapshot reads are implemented through undo log version chains and ReadView. ReadView contains m_ids (active transaction list), min_trx_id (minimum active transaction ID), max_trx_id (next transaction ID to be allocated), and creator_trx_id (creator's transaction ID). The interviewer asked about visibility rules — I said trx_id < min_trx_id is visible, trx_id >= max_trx_id is not visible, and for min_trx_id <= trx_id < max_trx_id, check if it's in m_ids. I'd organized this specifically before, so it went smoothly.

3. How do you handle distributed transactions

I said our project mainly uses local message tables + eventual consistency: business operations and message writes are in the same local transaction, then a background thread periodically scans the message table to send unsent messages to MQ, with idempotent processing on the consumer side. The interviewer asked why not Seata — I said Seata's AT mode has low business intrusion but high performance overhead, and for our scale, local message tables suffice. They asked what happens if the consumer fails — I mentioned retry mechanisms + dead letter queues + manual fallback.

4. How to implement distributed locks

I described using Redis's SET key value NX EX command for distributed locks, with UUID as the value to prevent accidental deletion. When releasing the lock, a Lua script ensures atomicity: check if the value matches first, then delete only if it does. The interviewer asked about lock loss during Redis master-slave failover — I mentioned the Redlock algorithm, requesting locks from multiple independent Redis instances, with success requiring more than half. Honestly, I couldn't remember Redlock's details clearly, so I only gave a rough overview. The interviewer didn't press further.

5. Scenario: Design Meituan's in-store coupon system

I broke it down into several layers: 1) Coupon creation and distribution — backend ops system creates coupon templates supporting multiple types (discount, percentage off, flat reduction); 2) User claiming — Redis pre-deduction + Lua scripts for atomicity to prevent over-distribution; 3) User redemption — validate coupon expiry, usage conditions, and whether already used during checkout; 4) Coupon settlement — settle the coupon after order payment succeeds. The interviewer asked how to prevent over-distribution during high-concurrency claiming — I said Redis pre-deduction + MQ async persistence, using Lua scripts for atomic deduction in Redis, then publishing MQ messages for async MySQL writes. They asked about Redis-MySQL data inconsistency — I said eventual consistency with MQ retry on consumption failure, and dead letter queues with manual handling after exceeding retry limits. This went well since, working on food delivery systems, I'm familiar with coupon scenarios.

6. Algorithm: Binary Tree Level Order Traversal (LeetCode 102)

Implemented with queue-based BFS, recording node count per level then dequeuing one by one. Finished in 7 minutes. The interviewer asked me to analyze time and space complexity — I said O(n) for both. They said that works.

7. Your most challenging project

I described the delivery dispatch system optimization: originally, rider assignment used round-robin, which was inefficient and unbalanced. I participated in transforming it to distance-and-load-based intelligent dispatch, introducing Geohash for spatial indexing, Redis for real-time rider positions, and a dispatch service matching orders to the nearest available rider. After the overhaul, average rider pickup distance decreased by 35% and delivery timeliness improved by 20%. The interviewer asked about Geohash boundary issues — I said we search the surrounding 8 cells together. They asked about Redis pressure from high-frequency position updates — I said batch writes + Pipeline, accumulating position updates before writing. I answered this honestly because I actually built it.

Round 2 Summary

Round 2 was significantly harder than Round 1. Scenario questions and project deep-dives were the focus. The distributed lock Redlock part didn't go well — I couldn't remember the details. The coupon system design went smoothly since the business was relevant to me. Received the Round 3 notification on April 18th, a 3-day gap.

Round 3: Technical Interview 3 + HR Interview (~50 minutes)

Round 3 was on April 22nd, Friday at 3 PM. The interviewer was the department's tech lead, asking questions偏向 architectural thinking and soft skills. HR also joined for a chat at the end.

1. How do you think about microservice decomposition granularity

I said microservice decomposition isn't "the finer the better" — you need to consider team size, business boundaries, and call chain complexity. Over-decomposition leads to excessively long inter-service call chains, high operational costs, and difficult distributed transactions. My experience is to decompose by business domain, referencing DDD's bounded contexts, with one bounded context corresponding to one microservice. The interviewer asked how we decomposed our system — I said by delivery lifecycle: order dispatch, rider management, route planning, and delivery tracking as four core services.

2. How to design a high-availability architecture

I covered several dimensions: 1) Service layer — stateless design + multi-instance deployment + health checks + automatic removal; 2) Data layer — master-slave replication + read-write separation + database sharding; 3) Cache layer — Redis Cluster + multi-level caching + cache warming; 4) Rate limiting and degradation — gateway rate limiting + core API degradation + circuit breakers; 5) Monitoring and alerting — full-link monitoring + anomaly alerts + log aggregation. The interviewer asked about circuit breaker working principles — I described three states: closed, open, and half-open, where after opening, a small number of requests are allowed through after a timeout to probe, and if successful, the circuit closes. This went okay.

3. What role do you play in your team

I said I'm the owner of the delivery dispatch module, responsible for requirement reviews, technical solution design, and code reviews. I gave an example: last year's Double 12, we did a delivery timeliness optimization project where I led the solution design, changing synchronous rider position queries to async preloading + caching, reducing API RT from 500ms to 80ms. The interviewer asked what to do if a team member disagrees with your approach — I said first understand their concerns, use data to make your case, and if data isn't sufficient, do a small-scale experiment first.

4. Your 3-year career plan

I mentioned three directions: 1) Technical depth — hoping to deeply understand high-concurrency, high-availability architecture at a major platform like Meituan; 2) Technical breadth — currently mainly doing business development, wanting to expand toward middleware and infrastructure; 3) Team leadership — currently leading a small group of 2-3, hoping to lead larger teams in the future.

5. HR question: Why Meituan

I gave three reasons: 1) Business alignment — I build food delivery systems, and Meituan's in-store and food delivery are industry benchmarks where I can learn cutting-edge business practices; 2) Tech culture — Meituan's tech blog and open-source projects are high quality, showing the company values technology; 3) Growth space — Meituan has diverse businesses across in-store, food delivery, and travel, offering broad exposure.

6. HR question: What would you like to ask

I asked two questions: What's the biggest technical challenge for the In-Store Business Group right now? — The interviewer said real-time inventory and price synchronization on the merchant side. How do new hires get up to speed quickly? — They mentioned a mentorship program and new-hire projects.

Round 3 Summary

Round 3 had a relaxed atmosphere overall. The interviewer focused more on your thinking process and growth potential, with fewer technical details. The HR portion wasn't difficult either, lasting about 15 minutes. Received the offer on April 29th — 26 days total from application to offer.

Interview Questions Summary

1. == vs equals — Java Fundamentals — Easy
2. HashMap vs ConcurrentHashMap — Java Concurrency — Medium
3. Spring Bean thread safety — Spring — Medium
4. Spring transaction propagation — Spring — Medium
5. MySQL index failure scenarios — MySQL — Medium
6. Redis persistence methods — Redis — Medium
7. Cache penetration/breakdown/avalanche — Redis — Medium
8. Reverse Linked List — Algorithm — Easy
9. RabbitMQ usage and message loss handling — Middleware — Medium
10. G1 vs CMS — JVM — Hard
11. MySQL MVCC implementation — MySQL — Hard
12. Distributed transaction solutions — Distributed — Hard
13. Distributed lock implementation — Distributed — Hard
14. Coupon system design — Scenario — Hard
15. Binary Tree Level Order Traversal — Algorithm — Easy
16. Delivery dispatch system optimization — Project — Medium
17. Microservice decomposition granularity — Architecture — Hard
18. High-availability architecture design — Architecture — Hard
19. Team role and career planning — Soft Skills — Medium

Insights and Advice

1. Meituan Java interviews emphasize practical project experience and scenario design: Unlike Alibaba's focus on deep theoretical principles, Meituan cares more about whether you can apply technology to real scenarios. The Round 2 coupon system design and Round 3 high-availability architecture were both tied to Meituan's own business. I recommend organizing your project experience clearly and ideally connecting it to Meituan's business scenarios.

2. Distributed systems are mandatory: Distributed transactions, distributed locks, and high-availability architecture are almost guaranteed to come up. I didn't answer the Redlock part well, but in retrospect, the interviewer wasn't looking for you to recite every detail — they wanted to see if you understood the core problem and solution approach.

3. Algorithm requirements aren't too high: Meituan's experienced-hire algorithm questions tend to be on the easier side — both I encountered were LeetCode Easy level. But I've heard different departments vary significantly — In-Store is relatively easier, while Meituan Platform might be harder. I recommend at least practicing common LeetCode Medium problems.

4. Business alignment is a plus: Working on food delivery systems gave me a natural advantage when interviewing for Meituan's In-Store group. When the interviewer dug into my project, I could provide very specific details and data. If your business is relevant to the target department, make sure to prepare that thoroughly.

Final Result: Received the offer on April 29th, leveled at L7. 26 days total from application to offer. Salary increased about 40% from my current compensation. Overall, quite satisfied.

FAQ

Q: How many rounds are in Meituan's Java experienced-hire interview?
A: Typically 3 rounds: Technical Round 1 + Technical Round 2 + Technical Round 3/HR Interview. Some departments may have cross-team interviews. The In-Store Business Group was 3 rounds.

Q: How long does it take to get Meituan interview results?
A: Usually 2-4 days after each round. Offer approval after Round 3 takes about 1 week. My entire process was 26 days, which is on the faster side.

Q: What does Meituan's backend interview focus on?
A: Java fundamentals and concurrency, Spring, MySQL, Redis, distributed systems, middleware, algorithms, and scenario design. Meituan puts significant weight on scenario design questions, so prepare accordingly.

Q: Is the Meituan Java interview hard?
A: I'd say moderate difficulty, somewhat easier than Alibaba. More fundamental questions, lower algorithm requirements, but scenario design questions require real-world experience — just memorizing won't cut it.

Q: Can I get into Meituan without big company experience?
A: Yes — I came from a mid-sized company. The key is having impressive projects and clear technical thinking. Business alignment gives you an even bigger advantage.