technical questions for pms

Let me settle this upfront: the internet has confused an entire generation of aspiring PMs about how much technical depth interviews actually require.

I have watched thousands of candidates prepare for PM interviews. The ones who fail the technical round fall into two camps. Camp one overprepares — they spend three weeks learning data structures and algorithms, show up, and get asked to draw a system diagram on a whiteboard. Camp two underprepares — they assume “PMs don’t need to be technical,” walk in, and cannot explain what an API does when the interviewer asks.

Both camps lose. The truth is narrower and more practical than either extreme.

The real question interviewers are asking

When an interviewer asks you a technical question, they are not testing whether you can write production code. They are testing whether you can have a credible conversation with your engineering team without slowing them down.

There are two distinct PM roles at most companies, and the technical bar is different for each. A generalist/functional PM interview tests whether you are technically literate — you understand how systems work, you can read a dashboard, you can write basic SQL. A technical PM interview goes deeper — you may be asked about database schemas, API design tradeoffs, or how you would architect a specific feature. Know which role you are interviewing for before you prepare.

The four technical areas that actually come up

In Indian PM interviews — across startups, growth-stage companies, and large tech — the technical questions cluster into four areas. Not twenty. Four.

1. SQL and data querying

This is the most common technical question in PM interviews, and the one with the highest ROI to prepare. You will be asked to write or interpret SQL to answer a product question.

What they ask: “We have a table of user events. How would you find the percentage of users who completed onboarding in the last 30 days?”

What they are testing: Can you translate a product question into a data query? Do you understand filtering, aggregation, and joins at a basic level?

The bar: You need to be comfortable with SELECT, WHERE, GROUP BY, ORDER BY, JOIN, COUNT, SUM, AVG, and subqueries. You do not need window functions, CTEs, or query optimization. If an interviewer asks you to optimize a slow query, you are in a technical PM interview and should say so — “I would partner with the data engineer on optimization, but my hypothesis would be adding an index on this column.”

A worked example:

Question: “Here is a table called orders with columns user_id, order_date, amount, and status. Find the top 10 users by total order value in the last 90 days, only counting completed orders.”

SELECT user_id, SUM(amount) AS total_value
FROM orders
WHERE status = 'completed'
  AND order_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY user_id
ORDER BY total_value DESC
LIMIT 10;

Then explain what you would do with this data: “These are our power users. I would cross-reference this with their acquisition channel to understand which channels bring high-LTV users, and check whether their order frequency is increasing or plateauing.”

The query is half the answer. The product thinking you layer on top is the other half. Interviewers care about both.

2. APIs — what they are, how they work

API questions separate PMs who have worked with engineering teams from those who have only managed backlogs in Jira. You do not need to build APIs. You need to understand the contract they represent.

What they ask: “How does the Swiggy app know what restaurants are near you?” or “Explain how a payment gateway integration works at a high level.”

What they are testing: Do you understand client-server communication? Can you describe the flow of a request? Do you know what request parameters and response codes mean?

The bar: Know that an API is a contract between two systems. Know the difference between GET (retrieve data) and POST (send data). Know that APIs have endpoints, parameters, and responses. Know what 200 (success), 400 (bad request), 401 (unauthorized), 404 (not found), and 500 (server error) mean. Know what latency is and why it matters for user experience.

The PM angle: When you spec a feature, you are implicitly defining API contracts. “The user enters their pincode and sees nearby stores” means there is an API call with the pincode as a parameter, returning a list of stores with distance, name, rating, and estimated delivery time. A PM who understands this writes better PRDs, catches edge cases earlier, and earns engineering trust faster.

3. System design — boxes, arrows, and tradeoffs

System design questions for PMs are fundamentally different from system design questions for engineers. An engineer is expected to design the internal architecture. A PM is expected to understand how the major components interact and where the tradeoffs live.

The bar for system design: Draw the major components — client, server/API, database, cache, third-party integrations. Know what each does. Explain the data flow for a specific user action. Identify where things can break and what the user impact would be. Talk about tradeoffs: speed vs. consistency, real-time vs. batch processing, storing data locally vs. fetching every time.

You do not need to know about load balancers, sharding strategies, or CAP theorem proofs. You need to know that if the system goes down, users lose trust — and that your job as PM is to define what “failure” looks like from the user’s perspective and what fallback the system should provide.

4. Technical depth questions — the “how much do you know” test

These are the questions that vary most by company and role. At Amazon, you might be asked about technical concepts specific to their infrastructure. At a startup, you might be asked how you would evaluate build vs. buy for a specific capability.

Common patterns:

• “What is the difference between a relational database and a NoSQL database? When would you choose one over the other?”
• “How does caching work? Why would you cache something?”
• “What is a webhook? How is it different from polling?”
• “Explain how search works at a high level — what happens between the user typing a query and seeing results?”

The bar: You do not need to implement any of these. You need a one-paragraph explanation of each concept and — critically — you need to connect it to product decisions. “We would use a NoSQL database here because the data schema changes frequently as we add new merchant attributes, and a rigid SQL schema would slow down our iteration speed” is a PM-grade answer. “NoSQL is faster” is not.

The company-by-company reality in India

Not every company tests the same way. Here is what to expect:

Amazon India — Has two explicit tracks: PM (functional) and PM-T (technical). PM-T interviews include system design and may ask about database schemas. Functional PM interviews are lighter on technical depth but still expect data literacy. The bar has been rising every year.

Flipkart — System design is part of the loop for PM3 and above. They expect you to think in terms of capabilities and platform architecture, not just features. Expect questions about scale — Flipkart’s systems handle Big Billion Day traffic, and they want PMs who understand what that means for architecture decisions.

Google, Microsoft — The technical round weight has been decreasing globally. But for India roles, basic system design and data analysis are still standard. Google may ask you to write SQL on a whiteboard.

Series A-C startups — The CTO interviews you directly. They are not following a rubric. They want to know: can you discuss a technical problem without hand-waving? Can you write a spec that an engineer can build from? Have you shipped something where you had to make a technical tradeoff?

Fintech (Razorpay, PhonePe, PayU) — Higher technical bar than most. Payment systems have real consequences for errors. Expect questions about idempotency, failure handling, and data consistency — at a conceptual level, not implementation.

The branching point: how deep should you go?

How to prepare — the 80/20 approach

You do not need three months. You need two focused weeks, if you target the right things.

Week 1: Foundations

• SQL — Complete one online SQL tutorial (Mode Analytics or SQLZoo). Focus on SELECT, WHERE, GROUP BY, JOIN, and subqueries. Practice translating product questions into queries: “What percentage of users who signed up last month made a purchase?” should become a query in your head within 30 seconds.
• APIs — Read one clear explainer on REST APIs. Then open any product you use daily — Swiggy, Zepto, PhonePe — and trace a single user action through the system: what request goes where, what data comes back, what could fail.
• System components — Learn what these do in one sentence each: client, server, database, cache, CDN, load balancer, message queue, API gateway. You do not need to go deeper than one sentence each.

Week 2: Application

• System design practice — Take three products you know well. For each, draw the system diagram for one core user flow. Where does data live? What calls what? Where is latency?
• Technical tradeoff practice — For each diagram, identify one tradeoff: speed vs. accuracy, real-time vs. batch, local storage vs. server fetch. Practice articulating why you would choose one over the other in a specific product context.
• Mock technical round — Find an engineer friend. Ask them to interview you for 20 minutes. The feedback will be more valuable than another week of solo study.

The meta-skill: knowing your boundary

The single most important technical skill for a PM is not SQL or system design. It is knowing where your expertise ends and communicating that boundary with confidence instead of insecurity.

“I would partner with the data team on the query optimization” is a strong answer. “I have no idea about performance” is a weak one. Both acknowledge the same gap — one frames it as collaboration, the other as ignorance.

In every technical interview question, there is a boundary between what you should know (the requirement, the constraint, the user impact) and what you should defer (the implementation, the technology choice, the architecture pattern). The best PMs I have worked with — at scale-ups in Bangalore, at FAANG in Hyderabad, at startups in Delhi — all share this quality. They know where the line is, and they operate confidently on their side of it.

That confidence does not come from pretending. It comes from actually understanding the concepts at the level your role requires. The preparation in this page gives you that level. Not more, not less.

Where to go next

• Start with the interview landscape: Interview Types & What to Expect
• Nail the product question: Product Sense Questions
• Get your data skills sharp: SQL & Data Tools for PMs
• Understand the engineering relationship: Working with Engineering
• See the behavioral side: Behavioral Interviews & STAR