Meesho Software Engineer Interview: Questions, Experience & Prep (2026)

Meesho is one of India's fastest-growing social commerce platforms, connecting resellers and small businesses with buyers across the country. As of early July 2026, Meesho has 63 open Software Engineer roles tracked by knok jobradar, making it one of the more active tech hirers right now.

Candidates typically go through three to five rounds. The process commonly starts with an online coding screen, moves into one or two technical interviews covering data structures, algorithms, and system design, and ends with a hiring-manager or bar-raiser round. Some candidates also report a machine coding or take-home assignment round, though this varies by team.

Meesho's engineering culture is product-first and scale-focused. Interviews lean into how you think about real e-commerce problems, how you handle ambiguity, and whether you can build systems that hold up under the kind of traffic a large consumer app generates. Being familiar with Meesho's product (seller tools, logistics, discovery) helps you frame answers with relevant context.

These questions come up repeatedly in candidate reports across online forums and review platforms. Specifics can vary by team and level.

1. Given an array of integers, find the two numbers that add up to a target. Walk me through your approach and its complexity.
2. Design a URL shortener (or a similar stateless, high-traffic service). How would you handle a sudden spike in traffic?
3. Meesho has millions of small sellers uploading products daily. How would you design a product catalogue ingestion system?
4. Tell me about the most complex bug you debugged. What was your process?
5. How do you decide when to refactor old code versus leaving it as-is?
6. Describe a time you disagreed with a tech decision made by a senior engineer. What did you do?
7. How would you design a notification system that sends order updates to both buyers and sellers at scale?
8. You have a service that is slow under load. Walk me through how you would diagnose and fix it.
9. Given a binary tree, write code to find the lowest common ancestor of two nodes.
10. How do you prioritise technical debt when your team is also shipping new features every sprint?
11. Tell me about a time you had to learn a new technology quickly to deliver a project.
12. What excites you about Meesho's mission, and how does that connect to the work you want to do as an engineer?

Q: Tell me about a time you improved the performance of a service under load.

*Situation:* At my previous company, the product listing API was timing out for sellers during peak hours, causing cart abandonment and seller complaints.
*Task:* I was assigned to diagnose the root cause and bring response times down to an acceptable level before the next sale event.
*Action:* I profiled the service and found repeated database calls inside a loop fetching product attributes one by one. I rewrote the logic to batch the queries, added a caching layer for category metadata, and moved a heavy image-resizing step to an async background worker. I also set up latency dashboards so the team could monitor the improvement in real time.
*Result:* Response times dropped substantially during load testing, and the service handled the next sale event without any timeouts. The approach became the team's standard for similar optimisations.

---

Q: Describe a time you disagreed with a technical decision and what you did about it.

*Situation:* My team decided to implement a feature using a third-party library that I felt was poorly maintained and would introduce a long-term dependency risk.
*Task:* I needed to raise my concern without blocking the sprint or coming across as obstructionist.
*Action:* I wrote a short internal doc comparing the library against a lightweight in-house alternative, covering maintenance status, bundle size, and migration cost. I shared it in the team channel and asked for a brief discussion slot in the next planning meeting rather than escalating immediately.
*Result:* The team agreed to pilot the in-house approach for the first milestone and revisit. It worked well and we avoided the external dependency. My lead appreciated that I brought data rather than just an opinion.

---

Q: Tell me about a time you had to learn a new technology quickly to deliver a project.

*Situation:* Our team was handed a project to build a real-time order tracking feature. The existing stack was REST-based but the feature needed WebSocket support, which none of us had shipped in production before.
*Task:* I volunteered to own the WebSocket integration and had a tight deadline to get a working prototype ready for demo.
*Action:* I spent the first couple of days going through official documentation and reading production post-mortems from other companies to understand failure modes. I built a small proof-of-concept, shared it with the team for feedback, and iterated. I also wrote a short 'lessons learned' doc so the knowledge would not stay with just me.
*Result:* The prototype was ready on time, the demo went well, and other engineers picked up the doc and extended the feature in the following sprint without needing me to walk them through it.

STAR (Situation, Task, Action, Result) is the standard format for behavioural questions. Keep the Situation short (one to two sentences), spend most of your time on Action, and always close with a concrete Result.

For coding rounds: Think out loud before you type. Clarify constraints and edge cases first, then state your approach, then code. After coding, walk through your solution with a simple example and state the time and space complexity.

For system design rounds: Start by clarifying scale and requirements (read/write ratio, expected user count, latency expectations). Sketch the high-level architecture first, then drill into the components the interviewer probes. Cover data storage choices, how you handle failures, and how you would monitor the system.

For product-context questions (common at Meesho): ground your answer in the seller or buyer experience. If you can reference how a design choice affects a small business owner in a Tier-2 city, interviewers typically respond well to that framing.

Candidates who have interviewed at Meesho commonly report that interviewers look for the following:

Clear thinking under ambiguity. Meesho's problems are messy and real-world. Interviewers want to see you ask the right clarifying questions before diving into a solution, not jump to the first answer that comes to mind.

Scale awareness. Meesho serves a very large user base. Interviewers tend to probe whether you have thought about what happens when your solution needs to handle a much larger load than you originally designed for.

Product empathy. Because Meesho's users are often first-time internet shoppers or small-business owners, answers that account for simple UX, low-bandwidth conditions, or seller trust tend to land better than purely technical answers.

Ownership mindset. Interview questions often have a behavioural component even when they look technical. Showing that you followed a problem through to resolution, rather than handing it off, is valued.

Communication. Candidates report that interviewers interrupt to ask 'why did you choose that approach?' regularly. Being able to explain trade-offs in plain terms matters as much as getting the right answer.

Week 1: Coding fundamentals. Practise arrays, strings, hashmaps, trees, and graphs. Focus on problems involving two pointers, sliding window, and BFS/DFS since these come up frequently in candidate reports. Aim for clean, readable code rather than clever one-liners.

Week 2: System design. Study how to design high-traffic services: caching strategies, database sharding, message queues, and rate limiting. Practise designing systems relevant to e-commerce: product catalogues, order tracking, notification systems, and search.

Week 3: Behavioural prep. Write out three to five stories from your work history using the STAR format. Cover at least one story each for: conflict resolution, technical problem-solving, learning under pressure, and a time you pushed back on a decision.

Week 4: Meesho-specific context. Use the Meesho app as a seller and as a buyer. Read their engineering blog (publicly available) to understand the scale challenges they have written about. Think about how your past experience connects to those problems.

Ongoing: Mock interviews with a peer help more than solo practice. Explaining your thinking out loud to someone else surfaces gaps that silent practice hides.

Jumping to code before clarifying the problem. Candidates who start typing immediately often solve the wrong version of the question. Take a couple of minutes to clarify inputs, outputs, and constraints.

Ignoring scale in system design. Designing a system that works for a small user base but breaks for a much larger one is a common signal that a candidate lacks production experience. Always ask about expected load before drawing your architecture.

Vague STAR answers. Saying 'the team improved performance' without explaining what you personally did is a missed opportunity. Interviewers are assessing your contribution, not the team's.

Not knowing your own resume. Candidates sometimes cannot explain technical decisions from projects they listed. If it is on your resume, be ready to go deep on it.

Skipping the trade-off discussion. Picking one approach without acknowledging why you did not pick another signals black-and-white thinking. Interviewers at product companies usually want to hear 'I chose X over Y because...'.

Ignoring Meesho's context. Generic answers that could apply to any company miss the chance to show genuine interest. Grounding even one answer in Meesho's seller or reseller ecosystem makes a noticeable difference.