Interview experience
Meesho Interview Questions and Answers (2026)
Overview
Section titled “Overview”Meesho’s fresher loop combines a long, multi-problem online assessment with a dedicated low-level-design machine-coding round, then closes with a hybrid round that mixes core CS fundamentals (OS, networks, SQL) back in alongside behavioral questions.
Meesho interview process at a glance
Section titled “Meesho interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | Up to ~165 min | 3 medium-hard coding problems |
| Machine Coding / LLD | ~60 min | Build a working system - class design, clean executable code |
| Technical Round(s) | 45-60 min each | DSA + system design (orders/logistics) + project discussion |
| Managerial / HR | 30-45 min | OS/networks/SQL fundamentals + behavioural fit |
Online Assessment
Section titled “Online Assessment”A long, timed coding test - up to roughly 165 minutes - with 3 medium-hard problems, noticeably more time pressure than a typical single-hour OA.
Common questions
- Array/string manipulation problems at medium-hard difficulty
- Tree and graph traversal problems
- Top-K / heap-based problems (e.g. top-K frequent elements)
Machine Coding / Low-Level Design
Section titled “Machine Coding / Low-Level Design”Roughly 60 minutes building a working system from scratch - candidates report tasks like a car-pooling system. The interviewer cares more about how you structured your classes and modules than how fast you finished.
Common questions
- Design and implement a car-pooling or booking-style system with clean class boundaries
- Justify your object-oriented design choices and how you’d extend the system
- Handle edge cases (capacity limits, cancellations, conflicting bookings) in your design
- Explain why the code is clean and executable, not just functionally correct
Technical Round(s)
Section titled “Technical Round(s)”Further DSA problems combined with system-design questions scoped to Meesho’s marketplace domain, plus a detailed walkthrough of a resume project.
Common questions
- Shortest path / BFS-style problems on a grid or graph
- System design for order or logistics flows at marketplace scale
- Discussion on catalogue search, reseller workflows, or recommendation systems - inputs, outputs, what breaks at scale
- Your project’s architecture, hardest bug, and what you’d rebuild
Round-by-round narratives are on the Meesho interview experience page.
Managerial / HR round
Section titled “Managerial / HR round”A closing round that blends core CS fundamentals with behavioral questions - candidates describe being asked about OS, networking, and SQL here, not just motivation and culture fit.
Common questions
- OS fundamentals (processes, scheduling, memory) and basic networking concepts
- SQL query and schema-design questions
- Tell me about a time you made a call with incomplete data in a fast-moving situation
- Describe a conflict with a cross-functional partner (ops, a reseller, or another team) and how you resolved it
Sample answer frameworks for each of these are on the Meesho HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Find the top K frequent elements in an array. What is the optimal approach?
First build a frequency map in one pass, which is O(n) time and O(n) space. Then push entries into a min-heap of size K, popping the smallest whenever the heap exceeds K, so the heap always holds the K most frequent seen so far - that is O(n log K) time and O(K) extra space, better than sorting all distinct elements at O(n log n). If the interviewer pushes for strictly linear time, use bucket sort: create an array of n+1 buckets indexed by frequency, place each element in the bucket matching its count, and walk the buckets from the highest index collecting until you have K, giving O(n). Edge cases to state are K larger than the number of distinct elements, and ties in frequency, where you should ask whether any valid answer is acceptable.
Q: Find the shortest path from a source to a destination cell on a grid with blocked cells.
Because every move costs the same, use breadth-first search rather than Dijkstra. Push the source into a queue with distance 0 and mark it visited, then repeatedly pop a cell and push its unvisited, in-bounds, unblocked neighbours with distance plus one; the first time you pop the destination, that distance is the shortest path. It is O(rows times columns) time and space since every cell is enqueued at most once. Marking a cell visited at enqueue time rather than dequeue time is what stops duplicates blowing up the queue. If edge weights differed you would need Dijkstra with a priority queue at O(E log V), and if some moves cost 0 and others 1, a deque-based 0-1 BFS is the right tool.
Q: In the machine coding round, how would you structure the classes for a car-pooling system?
Model the nouns first, then the service that coordinates them. Entities: User (id, name, contact), Vehicle (registration, model, capacity, owner), Ride (id, driver, vehicle, source, destination, seatsAvailable, status), and Booking (id, ride, rider, seats, status). Behaviour goes into a RideService that offers createRide, searchRides and bookRide, backed by repository interfaces so the in-memory store can be swapped later. Keep matching logic behind a MatchingStrategy interface (nearest-source, cheapest, fewest-detours) so a new rule is a new class rather than an edit to an if-else chain - that is the open-closed principle the grader is looking for. Seat availability must be decremented atomically and validated against capacity, and cancellations must return seats, since those are the edge cases Meesho interviewers probe.
Q: Write a SQL query for the top 3 selling products in each category.
Use a window function to rank within each partition, then filter on the rank in an outer query, because window functions cannot be used in a WHERE clause: SELECT category, product, units FROM (SELECT category, product, units, ROW_NUMBER() OVER (PARTITION BY category ORDER BY units DESC) AS rn FROM product_sales) t WHERE rn <= 3; Use RANK() instead of ROW_NUMBER() if tied products should all be returned, and DENSE_RANK() if you do not want gaps in the ranking numbers. On a large sales table an index on (category, units DESC) lets the engine feed rows to the window in order and avoids a full sort.
Q: What is the difference between preemptive and non-preemptive scheduling, and what happens during a context switch?
Under non-preemptive scheduling a running process keeps the CPU until it blocks or exits, as in first-come-first-served or plain shortest-job-first; under preemptive scheduling the kernel can take the CPU away on a timer interrupt or when a higher-priority process becomes ready, as in round-robin and preemptive shortest-remaining-time-first. Preemption gives much better response time for interactive workloads at the cost of more switching overhead. On a context switch the kernel saves the current process’s registers and program counter into its process control block, updates its state, selects the next process, restores that process’s saved context, and switches the page-table base register - which also flushes or invalidates TLB entries. That TLB and cache cost is why an excessively small round-robin time quantum destroys throughput.
Q: Compare TCP and UDP, and explain the TCP three-way handshake.
TCP is connection-oriented and reliable: it numbers bytes, acknowledges them, retransmits what is lost, delivers in order, and applies flow control through the receive window plus congestion control such as slow start and AIMD. UDP is a thin datagram wrapper with no connection, no ordering, no retransmission, and an 8-byte header instead of TCP’s 20, so it is used where late data is worthless - live video, voice, DNS queries, telemetry. The handshake establishes sequence numbers: the client sends SYN with its initial sequence number, the server replies SYN-ACK carrying its own sequence number and acknowledging the client’s, and the client sends ACK. Three messages are needed because both directions must have their starting sequence number acknowledged before data can be reliably tracked.
Q: How would you make order placement idempotent so a retried request does not create duplicate orders?
Have the client generate an idempotency key - a UUID created once per checkout attempt and reused across retries - and send it as a header. On the server, write that key into a table with a unique constraint in the same database transaction that creates the order, so a duplicate request loses the race on the unique index and can be answered with the stored original response instead of creating a second order. Store the response body and status against the key with a TTL of about 24 hours so retries after a network timeout are safe. Relying on a read-then-write check instead of the unique constraint is the common wrong answer: two concurrent retries can both read no-existing-order and both insert. Downstream events should also carry the order id so consumers can deduplicate.
Q: How does catalogue search actually work at marketplace scale?
The core structure is an inverted index: each product’s title and attributes are tokenised, normalised (lowercased, stemmed, synonyms applied), and each token maps to a posting list of the product ids containing it. A query is tokenised the same way, the posting lists are intersected or unioned, and candidates are scored - classically by BM25, which rewards term frequency in the document and rare terms, and penalises long documents. That candidate set is then re-ranked with business signals such as popularity, price competitiveness, seller rating and conversion rate, which is where a marketplace differs from generic text search. At scale the index is sharded across nodes and queried in parallel, results are merged, and a cache fronts the head queries, since search traffic is heavily skewed towards a small set of popular terms.
Frequently asked questions about Meesho interviews
Section titled “Frequently asked questions about Meesho interviews”What is the Meesho interview process for freshers?
Meesho’s process typically runs 4-5 stages: 1. Application (on-campus via college placement cell, off-campus via Meesho Careers, or referral). 2. Online Assessment (up to ~165 min) - 3 medium-hard coding problems. 3. Machine Coding / Low-Level Design round (~60 min) - build a working system from scratch (e.g. a car-pooling or booking system), judged on class design and clean, executable code. 4. Technical Interview(s) - further DSA, system design, and project discussion. 5. Managerial/HR round - technical-cum-behavioral questions covering OS, networks, SQL, plus culture fit and offer. Total duration is roughly 2-3 weeks.
What questions are asked in Meesho interviews?
The Online Assessment leans on medium-hard array, string, tree, and graph problems. Machine coding rounds ask you to design and build a working system - candidates report tasks like a car-pooling system - graded on class structure and whether the code runs cleanly, not just the approach. Technical rounds also probe domain topics like catalogue search, reseller workflows, and recommendation systems in plain language. The closing round mixes OS, computer networks, and SQL fundamentals with behavioral questions on ownership and ambiguity.
How many rounds are there in the Meesho interview?
Meesho typically runs 4-5 touchpoints: an Online Assessment, a Machine Coding/LLD round, one or two further Technical Interviews (DSA, system design, project deep-dive), and a closing Managerial/HR round that often blends technical fundamentals with behavioral questions. Some drives compress stages depending on role and experience level.
What is the Meesho technical interview like?
The Machine Coding round (about 60 min) focuses on low-level design - candidates report being asked to build a working car-pooling or similar system, with the interviewer more interested in class/module structure and whether the code is clean and executable than in raw speed. Later technical rounds add system-design questions scoped to Meesho’s marketplace domain (orders, logistics, catalogue search) plus a deep project discussion. The closing round often circles back to OS, networking, and SQL fundamentals alongside behavioral questions.
How should I prepare for Meesho interviews?
Practice medium-hard DSA across arrays, strings, trees, and graphs for the OA. For the machine coding round, practice designing and building small systems end-to-end with clean class boundaries rather than just getting something to run. Revise OS, computer networks, and SQL fundamentals, since Meesho’s later rounds test them directly alongside behavioral questions. For domain questions, be ready to explain catalogue search or reseller workflows in plain language - inputs, outputs, what breaks at scale.
What mistakes do candidates commonly make in Meesho interviews?
Coding before clarifying constraints in the OA, treating the machine-coding round as a race instead of a design exercise (Meesho graders explicitly weigh class structure over speed), and treating the closing HR/managerial round as a formality when it still tests OS/networking/SQL fundamentals. Candidate reports consistently note that a clear, working low-level design beats a fast but disorganised one.