🚀 Cleartrip SDE Interview Experience | LLD + Concurrency | Food Ordering System | July 2026

Round 1 (90 Minutes) - Low Level Design (LLD)

Problem Statement

Design a Food Ordering System similar to a simplified Swiggy/Zomato.

The system needed to support:

• User Registration
• Restaurant Registration
• Restaurant Catalog Management
• Search Items (sorted by price)
• Place Orders
• Get Order History
• Bonus: Cancel Orders

Everything had to be implemented using in-memory data structures (no database).

A driver program demonstrating multiple test cases was mandatory.

What the Interviewer Expected

The focus was much more than just making the code work.

They were evaluating:

• Object-Oriented Design
• Proper entity relationships
• Clean code structure
• Separation of responsibilities
• Handling edge cases
• Demoable code

Entities I Designed

• User
• Restaurant
• MenuItem
• Order
• OrderStatus
• Catalog
• FoodOrderingService

Along with:

• HashMaps for fast lookups
• Collections for catalog management
• Order history per user
• Inventory updates during order placement

Bonus Feature

Implement:

cancelOrder(orderId)

The interviewer expected handling cases like:

• Already cancelled orders
• Invalid order IDs
• Inventory restoration
• Updating order status correctly

Demo

At the end, I demonstrated:

• User Registration
• Restaurant Registration
• Menu Creation
• Search
• Order Placement
• Order History
• Cancellation Flow

using multiple hardcoded test cases.

Round 2 - LLD Follow-up + Concurrency

The next day was a discussion round based almost entirely on my submitted design.

The interviewer asked questions around:

LLD

• Why did you choose these entities?
• Why this class hierarchy?
• Could any class be split further?
• Where would you use interfaces?
• How would you extend the system for multiple restaurants?
• How would you support multiple items in one order?
• How would you persist data if a database was introduced?
• How would you redesign this for production?

Concurrency

Most of the discussion shifted towards concurrent scenarios.

Some examples included:

• Two users ordering the last item simultaneously.
• Preventing negative inventory.
• Race conditions during order placement.
• Thread safety of HashMap.
• Synchronization strategies.
• Locking at item level vs restaurant level.
• Optimistic vs pessimistic locking.
• Concurrent collections in Java.
• Making order placement atomic.

The discussion was practical and focused on real backend engineering challenges rather than theory.

Verdict

Unfortunately, I wasn't able to make it to the next rounds.

Nevertheless, it was a valuable interview experience that highlighted areas where production‑grade thinking matters just as much as coding.

Key Takeaways

• Practice complete LLD problems within 90 minutes.
• Don't stop after implementing the happy path—think about extensibility and edge cases.
• Be prepared to justify every design decision.
• Learn Java concurrency fundamentals thoroughly:
  • synchronized
  • ReentrantLock
  • ConcurrentHashMap
  • Atomic classes
  • Race conditions
  • Deadlocks
  • Thread safety
• Always keep your code demoable with a clean driver program.
• Think beyond "it works" and explain how your design would scale in a real‑world production system.

Overall, it was a well‑designed interview that tested practical backend engineering skills, object‑oriented design, and concurrency concepts. Hopefully this helps anyone preparing for Cleartrip or similar backend interviews.