What Technical Interviews at Indian Product Companies Are Actually Like

I've sat on both sides of technical interviews at Indian product companies. As a candidate and, later, as someone who conducted them. The gap between how candidates prepare and what interviewers are actually evaluating is significant.

Let me try to close that gap.

What the interview structure actually looks like

At most Indian product companies — your Swiggy, Razorpay, CRED, PhonePe, Meesho tier — you're looking at:

An online assessment first, usually on HackerRank or a company-specific platform. Typically two to three DSA problems in 90 minutes. This round is genuinely about your coding ability, not much else. If you can't solve medium-level LeetCode problems at reasonable speed, you won't clear this.

Then one or two technical rounds with engineers. These are almost never purely DSA. They might start with a problem, but they'll quickly pivot to: your past projects (and they'll go deep), system design (even for mid-level roles now), and how you think through problems you haven't seen before.

Then an engineering manager or bar-raiser round. This is where cultural fit and communication matter. The bar-raiser's job is to ask "would I be comfortable if this person made a call without me in the room?" If the answer isn't a clear yes, they pass.

Then HR. Usually formality, sometimes a values fit check, always salary.

DSA — what to prepare and what not to

The honest answer is you don't need to solve 800 LeetCode problems. You need to really understand maybe 150, spread across: arrays and strings (sliding window, two pointers are everywhere), trees and graphs (BFS, DFS, they come up constantly), dynamic programming (the classic patterns, not exotic variations), binary search (including binary search on the answer, which trips people up), and hashmaps (basically every problem uses one).

The mistake most people make is grinding problems without actually understanding the patterns. They see a problem, can't solve it, look at the solution, go "okay I get it," and move on. Then they fail when they see a slight variation. Slow down. After you solve a problem (or look up the solution), explain it out loud to yourself. If you can't explain why the approach works, you haven't actually learned it.

System design — the real differentiator

This is where most candidates lose interviews they should win. They've done DSA prep, they can code, but when asked to design a food delivery platform or a payment processing system, they either go silent or start listing buzzwords without structure.

What interviewers want to see is a thought process: clarify requirements, estimate scale, define the core data model, identify the bottlenecks, then discuss trade-offs. You don't need to give a perfect answer — you need to show you think like an engineer who's built real systems.

The companies you're interviewing at have real scale problems. Swiggy processes thousands of orders per minute. Razorpay handles payment at a scale where milliseconds of latency cost crores. The people interviewing you built those systems. They can tell immediately whether you understand distributed systems or whether you just read a few blog posts about them.

The project deep dive — people underestimate this

Every interviewer will ask you to walk them through a project you worked on. Most candidates give a 2-minute summary and think they're done. The interviewer then asks: why did you choose that database? How did you handle concurrent writes? What would you do differently now? What was the hardest bug you dealt with?

If you can't answer those questions about your own project, it looks worse than if you'd picked a simpler project. Before any interview, pick your two or three most technically interesting projects and think through every decision you made — and every decision you'd make differently today. Showing that you've reflected on your own work is one of the strongest signals you can give.

One practical tip

When you match to a job on Uplio, you get role-specific interview questions generated from the JD and your profile gaps. These aren't generic — they're based on what the specific company is likely to probe given where your resume is weak relative to their requirements. Worth going through them the night before.