Company questionsGroundworkMeesho

India · interview process

Meesho

Readable reports describe a timed online test, live coding interviews, a machine-coding or low-level-design build, and, in one SDE-3 report, a high-level design round. Campus SDE-1 loops lean on DSA plus fundamentals; backend and SDE-3 loops add machine coding.

  • 6 rounds
  • 2 coding answers
  • 7 more reported prompts
  • 2 well-reported rounds
  1. OA
  2. DSA
  3. Machine coding
  4. System design
  5. CS basics
  6. HR
  7. People rounds

The process, round by round

Reported by candidates and, where we found one, the company itself. Each round shows how well it is reported. Processes change by team, level and year.

  1. Online test with coding and MCQs

    Online assessment

    One report

    Three coding problems (two easy, one medium) plus 20 easy-to-medium MCQs on OS, networks, C/C++ and Java. Only a small group advanced to interviews.

    • arrays and strings
    • dynamic programming with binary search
    • OS and networks MCQs

    Varies: Reported for campus SDE-1 hiring only.

    What can be asked in a online assessment round

    A timed test on a coding platform, taken alone. Usually two or three coding problems, sometimes with multiple-choice questions on CS basics, aptitude or SQL.

    • Array and string problems that need a hash map, two pointers or a sliding window

      Read the constraints first, because they point to the technique. If n is 100,000, an O(n^2) scan will time out, so look for a hash map, two pointers on a sorted array, or a window that moves forward only. Sketch the brute force, find the repeated work, then remove it. For two-sum style pairs you might say: I store each value's index as I scan, so the complement lookup is O(1) and the whole pass is O(n).

      DSA course →
    • Greedy and sorting problems with a catch in the constraints

      Greedy problems hide behind a sort. Ask what ordering makes the locally best choice safe, then try to argue why swapping two adjacent choices never helps. Interval scheduling is the classic case: sort by end time and take every interval that starts after the last chosen one. Check the catch in the constraints, such as overflow, ties or equal values, and test a tiny case by hand before submitting.

      DSA course →
    • A medium dynamic programming or graph-on-a-grid problem

      Decide whether the problem is a graph walk or a recurrence. On a grid, a shortest path with equal step cost is breadth-first search from the start, with a visited set so each cell is processed once, giving O(rows x cols). For dynamic programming, define the state in one sentence, write the transition, set the base cases, then see if only the previous row is needed to save space.

      DSA course →
    • SQL queries with joins and group by

      Start from the table that holds the thing being counted, join the others on their keys, filter rows with WHERE, group, then filter groups with HAVING. Remember that WHERE runs before grouping and HAVING after. Use LEFT JOIN when rows with no match must still appear, and COUNT of a column rather than star when nulls matter. Example: customers with more than three orders is GROUP BY customer_id HAVING COUNT(*) > 3.

      Databases →
    • Multiple-choice questions on OOP, operating systems, databases and networks

      These reward quick, accurate recall rather than long reasoning, so revise the short list of definitions that recur. Know the difference between a process and a thread, the four ACID properties, what an index trades for faster reads, TCP against UDP, and the four pillars of OOP. Eliminate two wrong options first, then choose. Do not spend more than a minute on any single question, and flag it to return to if time remains.

      Mock interviews →

    Prepare with: Book · Online assessmentDSA course

    1 source for this round
  2. Live coding interview

    Data structures and algorithmsScheduled for 1.5 hours (campus report)

    Several reports

    Campus report: live coding on HackerRank CodePair after a resume walkthrough, with one very easy and one harder problem that had to pass all test cases, then OS and DB questions. Backend report: a technical round built around one dynamic-programming problem with 14 test cases; its format is not stated.

    • greedy
    • dynamic programming
    • resume projects
    • OS and DBMS basics

    Varies: Campus SDE-1 versus a backend candidate with 2+ years.

    Practise for this round

    • ReportedFewest edits to make two strings anagrams, or report impossible Online test problem; close to, but not identical to, a LeetCode anagram task.Candidate write-up ↗
    • ReportedFind common elements in two arrays Easy online test question.Candidate write-up ↗

    Reported prompts have no written answer yet. Read the linked page for context.

    What can be asked in a data structures and algorithms round

    A live coding round of 45 to 60 minutes with one or two problems. You are judged on how you clarify, reason, code, test and state the complexity, not on the answer alone.

    • Arrays, strings and hashing: pairs, windows, frequency counts, prefix sums

      Name the pattern from the shape of the question. Pairs with a target use a hash map of seen values. A contiguous range with a condition uses a sliding window that grows on the right and shrinks on the left, so each element enters and leaves once, giving O(n). Range sums over many queries use a prefix sum array so each query is O(1) after O(n) setup. Count characters with a fixed-size array or map.

      DSA course →
    • Linked lists, stacks and queues, including design-a-structure problems such as an LRU cache

      For an LRU cache, combine a hash map from key to node with a doubly linked list ordered by recency. Get moves the node to the front, put inserts at the front, and when over capacity you remove the tail node and its map entry. Both operations are O(1), and you say why: the map finds the node, the list reorders it without a scan. For stacks, mention a monotonic stack for next greater element.

      DSA course →
    • Trees and BSTs, graphs (BFS, DFS, topological sort, shortest paths) and grids

      Decide the traversal from what is asked. Level by level or shortest path in an unweighted graph is BFS with a queue. Exploring all paths, components or cycles is DFS. A dependency order is topological sort: Kahn's algorithm repeatedly removes nodes with in-degree zero, and leftover nodes mean a cycle. Weighted shortest path with non-negative edges is Dijkstra with a heap, O((V + E) log V). On a BST, an in-order walk is sorted.

      DSA course →
    • Heaps and top-K, intervals, binary search on the answer

      For the K largest items keep a min-heap of size K: push each element and pop the smallest when the heap exceeds K, so the cost is O(n log K) and memory is O(K). For intervals, sort by start, then merge by comparing the next start with the current end. For binary search on the answer, define a yes or no check that is monotonic, such as can ship within D days, and search the capacity range.

      DSA course →
    • Dynamic programming from one dimension up to knapsack and string DP

      Define the state in a sentence, write the recurrence, fix the base cases, and decide the order of filling. Start with the recursive version with memoisation, then convert to a table. For 0/1 knapsack, dp[w] is the best value at capacity w, and in the one dimensional form you loop capacity downward so each item is used once. For string problems such as edit distance, the state is a pair of prefix lengths.

      DSA course →
    • Follow-ups: optimise space, handle streaming input, make it thread-safe

      Treat follow-ups as a chance to show depth, and answer in the same calm order each time. To save space, ask which previous rows or values the recurrence actually reads and keep only those. For streaming input, say what summary you can keep, such as a heap of size K or a running count. For thread safety, name the shared state, guard it with a lock, and keep the critical section short.

    Prepare with: Book · DSA roundDSA course

    2 sources for this round
  3. Machine coding / low-level design

    Machine coding120 minutes (SDE-3 report)

    Several reports

    Build working features for a small product, such as a ride-sharing app or an inventory service. The SDE-3 report included a payment-flow simulation; one backend candidate finished only one of two features.

    • object-oriented design
    • working code under time pressure
    • feature completeness

    Varies: Seen in backend (2+ years) and SDE-3 reports, not in the campus SDE-1 report.

    Practise for this round

    • ReportedDesign an inventory service: add product, add stock, block stock, payment flow 120-minute machine coding; blocked stock is consumed or released by payment outcome.Candidate write-up ↗
    • ReportedBuild two features of a ride-sharing app Machine coding; candidate finished one feature and was rejected.Candidate write-up ↗

    Reported prompts have no written answer yet. Read the linked page for context.

    What can be asked in a machine coding round

    You build a small working system in your own editor in 60 to 120 minutes, then walk through it. Clean entities, extensibility, a runnable demo and tests matter more than clever algorithms.

    • Parking lot, library or inventory system with several entity types

      Spend the first ten minutes on requirements and entities, not code. For a parking lot you might list Vehicle, Slot, Ticket and Lot, with slot types as an enum and the allocation rule hidden behind an interface so a nearest-slot strategy can be swapped. Keep the code runnable early, write a small demo in main, and add a few tests. Say what you would add with more time, such as pricing rules.

      Whiteboard →
    • Splitwise-style expense sharing, a wallet or a ledger

      The core of expense sharing is a balance ledger: for each pair or each user, store the net amount owed. An expense has a payer, an amount and a split type such as equal, exact or percent, handled by a split strategy per type. Validate that exact splits sum to the total and handle rounding explicitly. To simplify debts, compute each person's net balance and match the largest creditor with the largest debtor.

    • Snake and ladder, tic-tac-toe, chess or another game engine

      Model the board, players, dice or moves, and a game controller that owns the turn loop, with rules kept out of the board class. For tic-tac-toe, keep counters per row, column and both diagonals, so a win check is O(1) per move instead of scanning the grid. For snake and ladder, store jumps in a map from square to destination. Make board size and number of players configurable rather than hard coded.

    • An in-memory cache, key-value store, rate limiter or job scheduler

      Start with the public interface and the invariants. For a rate limiter, a token bucket stores tokens and a last refill time per key, refills lazily on each call and allows the request if a token remains. For an LRU or key-value store, say the data structure and the complexity. For a scheduler, a priority queue ordered by run time with a worker that waits for the earliest job.

    • Elevator, vending machine or ATM as a state machine

      Draw the states and transitions before coding. An elevator is idle, moving up, moving down or doors open, and each event such as a button press or arrival is handled by the current state. A vending machine moves through idle, has money, dispensing and out of stock. Implement it with a state interface or an enum and a transition table, so invalid actions are rejected in one place instead of with scattered if statements.

    • Follow-ups: add a new rule without rewriting, make it concurrent, add persistence

      Show that your design bends without a rewrite. For a new rule, say you add a new class that implements the existing interface and register it, leaving old code unchanged. For concurrency, name the shared state and protect it with a lock per resource, or atomic operations, keeping check-and-update in one critical section. For persistence, put a repository interface in front of storage so an in-memory version can be replaced by a database.

      Mock interviews →
    2 sources for this round
  4. High-level design round

    System design90 minutes

    One report

    One SDE-3 candidate was asked to design a Google Drive-like system with shared folders and cross-device sync, and was rejected after this round.

    • system design
    • data sync
    • sharing model

    Varies: Senior-level report only.

    Practise for this round

      • ReportedDesign a Google Drive-style shared-folder system with device sync 90-minute design round.Candidate write-up ↗

      Reported prompts have no written answer yet. Read the linked page for context.

      What can be asked in a system design round

      A 45 to 60 minute discussion of how to build a system at scale: requirements, numbers, APIs, data model, components, bottlenecks and trade-offs.

      • Short links, chat, news feed, notifications, search, rate limiting

        Use one repeatable path: clarify scope and scale, estimate load, define the API, sketch the data model, draw the main components, then probe bottlenecks. For short links, store a mapping from a generated short id to the long url, generate ids with a counter encoded in base 62, cache hot links, and note reads far outnumber writes. For chat, mention persistent connections and a store ordered per conversation.

        System design course →
      • Payments, wallets and ledgers where money must never be lost or doubled

        Money systems put correctness before speed. Use a double-entry ledger where entries are append-only and every transfer writes a debit and an equal credit in one transaction. Protect against doubled charges with an idempotency key stored with the result, so a retry returns the original outcome. For lost updates use a database transaction, and reconcile with the payment provider's records on a schedule.

        System design course →
      • Ride matching, maps and anything with live location

        Split the problem into location ingestion, a geospatial index and matching. Drivers send updates every few seconds to a write-optimised store, often in memory, keyed by a grid cell such as a geohash or S2 cell. To find nearby drivers, query the rider's cell and its neighbours, then rank by distance and estimated time. Say how you handle a stale location and a driver who accepts two rides.

        System design course →
      • File storage and sync, video streaming and content delivery

        For file sync, split files into chunks, hash each chunk and upload only chunks the server lacks, so a small edit transfers a small amount. Keep metadata in a database and chunks in object storage. For video, upload the original, transcode into several resolutions, store segments and serve them through a content delivery network with adaptive bitrate streaming, so the player switches quality as bandwidth changes.

        System design course →
      • Fundamentals: caching, sharding, replication, queues, consistency, failure handling

        Treat each as a tool with a cost. A cache cuts read latency but adds staleness and invalidation. Sharding spreads write load but makes cross-shard queries hard. Replication gives availability and read scale but introduces lag. Queues smooth spikes and decouple services but require idempotent consumers. For failures, name timeouts, retries with backoff and a fallback. State what you give up whenever you choose.

        System design course →
      • Back-of-envelope estimates and what they decide

        Estimates are there to choose a design, so finish each one with a decision. Use round numbers: a day has about 100,000 seconds, so 10 million requests a day is roughly 100 per second on average, with a peak of a few times that. Multiply object size by count for storage, and compare against one machine's capacity. If one database handles the load, say so and avoid sharding.

        Capacity estimation →

      Prepare with: Book · System designSystem design course

      1 source for this round
    • Second technical: projects, DB and CS

      CS fundamentalsAbout 1 hour

      One report

      Role in a team project, its database tables and SQL queries, one DFS-based coding problem, then networking, OS and DBMS questions.

      • project design
      • SQL
      • networking
      • operating systems
      • DBMS

      Varies: Campus SDE-1 report.

      Practise for this round

      • ReportedNetworking, OS and DBMS fundamentals Covered DNS, OSI, semaphores vs mutexes, paging, SQL vs NoSQL, ACID.Candidate write-up ↗

      Reported prompts have no written answer yet. Read the linked page for context.

      What can be asked in a cs fundamentals round

      Questions on the subjects every engineer is expected to know: operating systems, databases, networks and object-oriented programming. Common for campus and early-career hiring.

      • Process vs thread, scheduling, deadlocks, virtual memory

        A process has its own address space, while threads in one process share memory, so threads are cheaper to create and switch but need synchronisation. A deadlock needs four conditions at once: mutual exclusion, hold and wait, no pre-emption and circular wait. Break any one, for example by taking locks in a fixed order. Virtual memory maps pages to frames, and a page fault loads a missing page from disk.

        Operating systems →
      • ACID, isolation levels, indexes, normalization, joins

        ACID means atomicity, consistency, isolation and durability. Isolation levels trade anomalies for speed: read committed prevents dirty reads, repeatable read also stops a row changing under you, and serializable behaves as if transactions ran one at a time. An index, usually a B-tree, speeds lookups at the cost of slower writes and more space. Normalisation removes duplicated facts, and joins put the pieces back.

        DBMS →
      • TCP vs UDP, the TCP handshake, HTTP and HTTPS, DNS, load balancing

        TCP is connection-oriented, ordered and reliable, using a three-way handshake of SYN, SYN-ACK and ACK. UDP sends datagrams without those guarantees, so it suits low latency uses such as voice or DNS queries. HTTPS is HTTP over TLS, which adds encryption and server identity. DNS resolves a name to an address through a chain of resolvers. A load balancer spreads requests across servers using a policy such as round robin or least connections.

        Networks →
      • OOP: polymorphism, abstraction, interfaces, SOLID

        Answer with a definition and a small example each time. Polymorphism means one interface with many behaviours, such as a Shape with an area method that each subclass implements. Abstraction hides detail behind a contract. An interface states what, a class states how. Mention that you prefer composition over inheritance when behaviour varies, and tie SOLID to one real choice from your own code.

      • How would you debug a slow query or a hung process

        Work from symptom to cause, measuring before changing. For a slow query, run the execution plan, look for a full scan, a missing or unused index, or a bad join order, and check row counts. For a hung process, check whether it uses CPU, is waiting on I/O or a lock, and read a thread dump or stack trace. State the order: reproduce, observe, form one hypothesis, change one thing.

        Databases →

      Prepare with: Book · Databases & RedisOperating systemsDBMSNetworks

      1 source for this round
    • HR round

      HR and offer

      One report

      Described by the one campus candidate as a formality with no questions asked.

      • none reported
      What can be asked in a hr and offer round

      The closing conversation: motivation, expectations, notice period, compensation and how the offer is structured. Prepared answers and a clear number help here.

      • Current and expected compensation, and how to answer without boxing yourself in

        Be honest and avoid giving a single number too early. Share your current pay only if you are comfortable, and make clear what is fixed and what is variable. For expectations, say you are flexible for the right role, and offer a researched range based on level and market. If pushed, state a figure you can justify. Never state a number you cannot support, because offers are often checked.

        HR and the number chapter →
      • Notice period, joining date and relocation

        Give the facts exactly as they are in your contract. State the notice period, whether early release or a buy-out is truly possible, and the earliest honest joining date. Do not promise a date your employer has not agreed to. For relocation, say whether you can move, how soon, and whether you would need support. Clear, early information helps the recruiter plan and shows you are reliable.

        HR and the number chapter →
      • Why you are leaving and what you are looking for

        Keep it positive and forward looking. Talk about what you want more of, such as larger scale, ownership or a stronger team, rather than criticising your current employer. The listener checks that you will not leave this job for the same reason. Opening line: I have learned a lot in the current role, and I now want to work on problems at a bigger scale.

      • Levels, equity and how the offer is built

        Ask for the structure rather than only the total. Find out the level and title, base salary, bonus and whether it is guaranteed, equity amount, vesting schedule and cliff, joining bonus and any clawback. Compare offers on a yearly total with the same assumptions. If equity is in a private company, ask how it is valued and what happens on leaving. Asking calmly is normal and expected.

        Levels and equity chapter →

      Prepare with: Book · HR & the numberBook · Levels & equity

      1 source for this round

    Preparing for the people rounds at Meesho

    The hiring manager, behavioural and offer conversations. Candidate reports shape the themes; the answers and frames are written for this site, so use them as a structure and bring your own stories.

    What Meesho says it valuesOfficial ↗

    • Tech-first organizationTechnology sits at the centre of the company, built problem first and at large scale.
    • Building for a billion IndiansA stated promise about the scale and audience of the work, so think about reach and cost.
    • Exceptional people, high autonomyA promise of strong colleagues and independence, so be ready to show self-direction.

    Themes candidates report being probed

    • Situational questions, then a project deep dive
    • Teamwork and disagreement
    • Tech-stack choice
    • Why Meesho and improving a feature
    • Task prioritisation and deadlines
    • Failure and long-term goals at HR

    Questions to rehearse

    1. Walk me through your project after a few situational questions about how you work.One report

      What is being checked. A candidate on an intern-titled page reports a 45 minute hiring manager round of introductions, situational questions and a project deep dive. The listener is checking that your answers to the scenarios and your project line up.

      How to frame it. Keep the introduction short, then give the project in order of goal, your role, the hardest decision and the outcome. Example opening: 'The project was a recommendation feed, my part was the ranking service and the hardest call was how to cache it.'

    2. Take me through your best project and explain why you chose that stack.Prep guides

      What is being checked. A guide to the campus loop lists this prompt. The listener checks whether you chose the tools for reasons and understand what the alternatives would have cost.

      How to frame it. Name the requirement that pushed you to the stack, one alternative and why you set it aside. Example opening: 'We needed fast reads at low cost, which is why I picked this store over the relational option.'

    3. Tell me about a time you disagreed with a teammate.Prep guides

      What is being checked. A guide to the campus loop lists teamwork and disagreement. The listener is checking that you can disagree without making it personal, which matters in a high-autonomy culture.

      How to frame it. Describe the question you disagreed on, what each of you wanted, how you tested it and what you learned. Example opening: 'My teammate wanted to rewrite the module and I wanted to refactor, so we compared the effort on one small part.'

    4. Why Meesho, and how would you improve one of our features?Prep guides

      What is being checked. The same guide lists both. The listener is checking whether you have used the product and can reason about users who are very different from you, which ties to the stated focus on reach.

      How to frame it. Pick one feature, name the user problem, your change and how you would know it worked. Mention price or connectivity constraints if relevant. Example opening: 'Many users are on slow connections, so I would test a lighter product page and measure drop-off.'

    5. How do you prioritise across several projects, and what do you do when a deadline is tight?Prep guides

      What is being checked. A compilation of candidate accounts lists prioritisation and tight deadlines in the hiring manager round. The listener checks that you have a method and communicate trade-offs rather than quietly working longer.

      How to frame it. Describe how you rank by impact and urgency, who you tell and what you cut. Example opening: 'When two things collide I ask which one has a customer or a date attached, then I tell the owner of the other what will slip.'

    6. How do you handle failure, and what are your long-term goals?Prep guides

      What is being checked. The same compilation places these in the HR round. The listener checks resilience, honesty about mistakes and whether your goals are compatible with the role.

      How to frame it. Give one failure with its cost and a change you made, then a goal that links to skills this role builds. Example opening: 'I once shipped a change without a rollback plan, and now I never merge without one.'

    7. Tell me about a time you worked with little direction and decided for yourself what to do.Prep guides

      What is being checked. The official Life page promises high autonomy. The listener is checking that you can pick a direction, explain it and ask for help at the right moment.

      How to frame it. Describe the vague goal, the choice you made, how you checked it and when you asked for input. Example opening: 'I was told to improve search quality with no brief, so I started by listing the failing queries.'

    The offer conversation

    • A virtual-campus SDE-1 candidate describes the HR round as just a formality in which nothing was asked; this is a single campus account and may not match experienced hiring.
    • No account of a compensation or notice-period conversation for experienced hires was found, so treat this as general advice: ask for the full breakdown in writing and ask which level and band the role sits in.
    • Know your notice period and any buy-out before the call, and give a total compensation range only if the recruiter asks first.

    What we could not verify. The company's named values (mantras) were not found on a readable page, so the three entries are promise headings from the Life page (five promises are listed, three used here). The GeeksforGeeks pages show only a last-updated date, campus and intern reports dominate, and the two guides give no first-hand detail. No experienced-hire HR or compensation account was read.

    What we could not verify. Only three Meesho pages were readable (two GeeksforGeeks posts and one Blind thread). GeeksforGeeks pages show only last-updated dates (2024, 2025), not interview years, and neither labels the level beyond campus SDE-1 or 2+ years. LeetCode, Naukri Code360, Glassdoor and Interview Query returned 403/429/timeouts, so SDE-2 DSA and hiring-manager rounds are unverified.