Technical Product Manager Interview Questions & Prep

An application programming interface (API) defines the rules a software system follows to communicate with other applications programmatically. Most web and mobile products rely on Representational State Transfer (REST) APIs, which allow two computer systems to exchange information securely over the internet. In a REST architecture, a client requests a resource, and the server sends back a representation of that resource's current state, most commonly formatted in JSON (JavaScript Object Notation) because it is lightweight, human-readable, and easy for programming languages to parse (Google Cloud REST API documentation). Interviewers frequently test the architectural constraints that make an API RESTful and scalable. The most important constraint is statelessness. In a stateless system, the server completes every client request independently of all previous requests and stores no client session context between calls. Because any server can handle any request, your engineering team can add servers horizontally without creating communication bottlenecks. REST also enforces a uniform interface, a layered system where intermediaries like load balancers and security gateways remain invisible to the client, and total client-server separation so the frontend and backend can evolve independently. When you propose an API contract during an interview, walk through the request, the authentication method, and the server response.

1. 1. Unique resource identifie

   Unique resource identifiers (URIs)

   Identify each resource with a clean URL endpoint using plural nouns rather than verbs, such as /users for a collection or /users/123 for a specific item.

2. 2. HTTP methods

   HTTP methods

   Standard verbs tell the server what action to take. GET retrieves a resource and can be cached. POST creates a new resource, and sending the same POST request multiple times creates the resource multiple times. PUT updates an existing resource and is idempotent, meaning sending the same PUT request multiple times gives the exact same result. DELETE removes a resource.

3. 3. Parameters and headers

   Parameters and headers

   Clients pass path parameters for URL details, query parameters to filter, sort, and paginate large datasets into manageable chunks, and HTTP headers for metadata like content format.

4. 4. Authentication and securi

   Authentication and security

   APIs verify client identity using HTTP Basic authentication (username and password encoded in base64), Bearer authentication (encrypted tokens sent in headers), API keys (unique generated values that are less secure because they are vulnerable to network theft during transmission), or OAuth (combining passwords and tokens with specific scope and longevity). Traffic is encrypted with TLS/SSL.

5. 5. Status codes and

   Status codes and versioning

   The server replies with a three-digit HTTP status code: 2XX for success (200 generic success, 201 POST creation success), 3XX for URL redirection, and 4XX or 5XX for errors (400 bad request, 401 unauthorized, 404 resource not found, 500 internal server error). Protect existing clients from breaking changes by adding a version number to the URI, such as /api/v2/users.

Choosing how to store and query data is one of the most common technical trade-off questions in a PM interview. Developed by E.F. Codd at IBM in the 1970s, the relational database model organizes structured data into tables made of rows (records or tuples) and columns (attributes that specify a data type) (Google Cloud Relational Database documentation). Every table has a primary key that uniquely identifies each row, and tables link to one another using foreign keys that reference a primary key in another table.

1. Part 1

   In the mid to late 2000s (1)

   In the mid to late 2000s, non-relational or NoSQL databases emerged to handle indeterminate, unrelated, or rapidly changing data from social media, smart sensors, and third-party sources (AWS NoSQL documentation). NoSQL databases relax some ACID consistency restrictions in favor of flexible schemas and horizontal scaling across distributed hardware clusters. For example, Snapchat serves more than 290 million users sending billions of picture and video messages daily and used NoSQL database systems to reduce its median message-sending latency by 20%. Similarly, Disney+ uses Amazon DynamoDB to deliver features like Continue Watching and Watchlist to over 150 million subscribers.

2. Part 2

   You do not have to pick (2)

   You do not have to pick one database for an entire product. A hybrid approach combining SQL and NoSQL is standard in modern architecture, mapping each workload to the engine built for its access pattern.

When an interviewer pushes deeper into your system design, saying "we will use NoSQL" is rarely specific enough. Name the exact type of non-relational or vector database that matches your product feature.

1. 1. Key-value stores

   Key-value stores

   Store data as key-value pairs using a unique identifier for high-concurrency gaming, ad tech, and ecommerce. Amazon DynamoDB delivers single-digit millisecond latency at scale.

2. 2. Document databases

   Document databases

   Store semi-structured, hierarchical data as JSON-like objects that match application code for product catalogs, user profiles, and content management systems.

3. 3. Graph databases

   Graph databases

   Use nodes for entities and edges (with a start node, end node, type, and direction) for relationships in fraud detection, social networking, and recommendations. Cloud security company Wiz uses Amazon Neptune to traverse interconnected security risk factors in seconds.

4. 4. In-memory databases

   In-memory databases

   Eliminate disk access to deliver microsecond read latency and single-digit millisecond write latency for gaming leaderboards, real-time bidding, and session stores.

5. 5. Wide-column stores

   Wide-column stores

   Use tables, rows, and columns where column names and formats vary across rows for industrial equipment maintenance, fleet management, and route optimization, such as Google Cloud Bigtable or Amazon Keyspaces (designed for up to 99.999% availability).

6. 6. Time-series and search

   Time-series and search databases

   Time-series databases collect data over time for IoT and DevOps telemetry (Amazon Timestream processes trillions of events per day up to 1,000 times faster than relational databases). Search databases like Amazon OpenSearch Service index and aggregate semi-structured logs and unstructured media.

7. 7. Vector databases

   Vector databases

   Store, index, and query vector embeddings (numerical representations of unstructured text, images, or audio). Systems like Google Cloud Spanner, Cloud SQL with pgvector, and AlloyDB AI use exact nearest neighbor (KNN) or approximate nearest neighbor (ANN) search to power similarity search and Retrieval Augmented Generation (RAG).

A cache is a high-speed data storage layer that stores a transient subset of data in fast-access hardware like Random-Access Memory (RAM) so future requests are served faster than querying the primary disk-based database. Disk-based database queries generally return in double-digit milliseconds at best under steady load, whereas reading from an in-memory cache takes sub-millisecond or nanosecond times (AWS Caching and Well-Architected documentation). Under steady load, a disk-based database returns query responses in double-digit milliseconds at best. An in-memory database like Amazon MemoryDB or a remote Redis cache serves reads in sub-millisecond or microsecond times, which is orders of magnitude faster. On the throughput side, a single remote cache node provides hundreds of thousands to up to a million requests per second. This replaces a number of database read-replicas and cuts database costs by dozens of percentage points when databases charge by throughput. When you propose a cache in an interview, address the trade-offs: a cache has smaller capacity than persistent storage, and your system maintains two copies of the data. You measure effectiveness by the cache hit rate (when requested data is present) versus a cache miss (when the app falls back to the database). To prevent serving stale data, apply a Time to Live (TTL) expiration policy to every cached key. If you use an in-memory engine as a standalone store, define the Recovery Time Objective (RTO, the time needed to recover from an outage) and Recovery Point Objective (RPO, the last transaction captured in recovery).

1. 1. Client-side, DNS, and

   Client-side, DNS, and CDN caching

   Browsers cache HTML, CSS, and images locally via HTTP cache headers, while DNS servers cache domain-to-IP lookups. A Content Delivery Network (CDN) like Amazon CloudFront or Google Cloud CDN copies static web assets and videos to global edge locations nearest to the user.

2. 2. API and session

   API and session caching

   API gateways cache responses that change infrequently, such as a daily product category list. Centralized in-memory session stores track user logins and shopping carts across elastic fleets of web servers.

3. 3. Database-integrated vs lo

   Database-integrated vs local vs remote caches

   Integrated caches (like inside Amazon Aurora) update automatically via write-through when table data changes, but are limited to instance memory. Local caches live inside an application node and avoid network hops, but cannot share state across servers and lose data during an outage. Remote side-caches (like Redis or Memcached) run on dedicated clusters shared across all application servers with sub-millisecond latency.

4. 4. Write-through vs lazy

   Write-through vs lazy population

   In write-through, the app writes data to the cache immediately when updating the database. In lazy population (cache-aside), the app checks the cache first, and on a cache miss, queries the database and writes the result into the cache with a TTL.

Product managers are regularly asked to diagnose why an app feels slow or how to stream media to millions of concurrent users. To answer cleanly, separate latency, throughput, and bandwidth (AWS Throughput vs Latency documentation). Latency is the time delay in network communication, showing how long a data packet takes to travel from source to destination. It is measured in milliseconds (ms) using ping time or round-trip time (RTT). Latency is driven by geographical distance (propagation delay when servers are in a different region from the user), network congestion forcing packets onto longer routes, security protocol handshakes, and overloaded network infrastructure dropping packets. Throughput is the average volume of data that actually passes through the network successfully over a specific period, accounting for packet loss and retransmission. It is measured in kilobytes per second (KBps), megabytes per second (MBps), or gigabytes per second (GBps), where one byte equals eight bits. Bandwidth is the theoretical maximum volume of data that can be transferred over the network medium (measured in MBps). Bandwidth sets the ceiling, while throughput measures what actually gets delivered based on hardware processing power, network topology, and packet loss.

1. 1. How they interact

   How they interact

   High latency lowers throughput because systems wait longer for packet confirmations before sending more data. Low throughput can also make an application feel like it has high latency because large files take longer to arrive.

2. 2. TCP (Transmission Control

   TCP (Transmission Control Protocol)

   Establishes a connection and checks that every packet arrives without errors, retransmitting lost packets. This creates higher latency but reliable throughput for financial transactions, file transfers, and REST API payloads.

3. 3. UDP (User Datagram

   UDP (User Datagram Protocol)

   Skips error checking and packet loss recovery, sending duplicate packets instead. This delivers minimal latency and high throughput for live video streaming, voice calls, and multiplayer gaming.

4. 4. Quality of Service

   Quality of Service (QoS) and edge routing

   Prioritize latency-sensitive traffic using QoS rules or route traffic over private cloud backbones (such as AWS Global Accelerator, which improves user traffic performance by up to 60%, or AWS Local Zones placed near large population centers).

Modern technical PM loops test how you design and evaluate generative AI features. Large language models (LLMs) are pre-trained deep learning models built on the Transformer neural network architecture developed by Google in 2017 (Google Cloud LLM and AWS LLM documentation). A transformer consists of an encoder and a decoder with self-attention capabilities that extract meaning and relationships between words across a sequence of text. Unlike earlier recurrent neural networks (RNNs) that processed words sequentially one by one, transformers process entire sequences in parallel on GPUs, which cuts training time and allows models to scale to hundreds of billions of parameters. For example, OpenAI's GPT-3 has 175 billion parameters, AI21 Labs' Jurassic-1 has 178 billion parameters and a 250,000-word-part token vocabulary, Cohere's Command model works across more than 100 languages, and Claude 2 accepts prompts up to 100,000 tokens. Models are pre-trained on massive datasets such as Common Crawl (more than 50 billion web pages) and Wikipedia (about 57 million pages). Under the hood, LLMs convert words into multi-dimensional numerical vectors called word embeddings, placing words with similar contextual meanings close together in vector space. During training, the network iteratively adjusts its parameters (weights, biases, and embeddings) through self-learning to predict the next token from a previous sequence of input tokens.

1. 1. Zero-shot and few-shot

   Zero-shot and few-shot prompting

   In zero-shot learning, you pass a prompt to the base model without explicit training examples, which is fast to launch but varies in accuracy. In few-shot learning, you include a few relevant input-output examples inside the prompt to improve accuracy on a specific task.

2. 2. Retrieval Augmented Gener

   Retrieval Augmented Generation (RAG)

   To answer questions using private enterprise data, store domain documents as vector embeddings in a vector database (such as AlloyDB, Cloud SQL with pgvector, or DynamoDB integrated with OpenSearch). At query time, the system runs a KNN or ANN similarity search to retrieve relevant context and passes it into the LLM prompt.

3. 3. Fine-tuning

   Fine-tuning

   Data scientists train a base foundation model on a smaller set of supervised, application-specific data to adjust the model's underlying parameters (weights and biases).

4. 4. Multimodal pipelines

   Multimodal pipelines

   Models like Google's Gemini process text, code, images, audio, and video natively. In production pipelines, PMs combine deterministic services with LLMs, such as using Cloud Vision Optical Character Recognition (OCR) to extract text from PDFs in Cloud Storage, summarizing the text with Gemini, and storing the structured output in BigQuery.

1. Overview 1

   Use the prompt and example answer (1)

   Use the prompt and example answer below to practice structuring a complete architectural trade-off response out loud.

Why this answer works: It separates the read-heavy workload from the write-critical transaction, names the exact REST endpoints and status codes, uses official Redis IOPS and sub-millisecond latency benchmarks to solve the hotspot problem, and relies on relational ACID isolation to prevent overselling.

1. 1

   We are launching a global flash-sale checkout page for an ecommerce app. During a sale, 500,000 users refresh the product inventory page every second, and 5,000 users submit purchase orders per second. How would you design the API, database, and caching architecture so the site stays fast without overselling inventory?

   Show the sample answer

   Sample answer. Example answer written by our team. The applicant is invented. I would split this into two distinct access patterns: the read-heavy product catalog view and the write-critical order transaction. First, for the API layer, I would expose a stateless REST endpoint, GET /api/v1/products/123, for checking inventory, and a POST /api/v1/orders endpoint secured with OAuth bearer tokens for purchases. Because 500,000 users are refreshing every second, hitting a disk-based database directly will create a hotspot and drive latency well above double-digit milliseconds. I would place a Content Delivery Network at the edge for static product images and a remote in-memory Redis cache cluster in front of the database for the inventory count. A single Redis node can handle up to a million requests per second at sub-millisecond latency. I would set a short Time to Live of 2 seconds on the cached inventory key so users see near-real-time stock without overwhelming the database. Second, when a user clicks buy, accuracy matters more than microsecond speed. I would route the POST request over TCP to a relational database like PostgreSQL or Amazon Aurora that enforces full ACID transactions. Using atomicity and row-level isolation ensures two buyers cannot claim the last item simultaneously. If the transaction commits, the backend returns an HTTP 201 status code. If stock hits zero, it returns a 400 error and triggers an immediate cache update.

   Why this answer works: It separates the read-heavy workload from the write-critical transaction, names the exact REST endpoints and status codes, uses official Redis IOPS and sub-millisecond latency benchmarks to solve the hotspot problem, and relies on relational ACID isolation to prevent overselling.

Use this 5-step checklist to structure any technical PM architecture answer in 5 to 8 minutes: 1. Clarify the user workflow, read-to-write ratio, and latency or consistency constraints. 2. Define the API contract and authentication model. 3. Select the primary database (SQL vs NoSQL) based on the data model and ACID requirements. 4. Add caching or CDN layers to protect the database and meet latency targets, specifying the TTL. 5. Name the main failure mode and how you will measure success. If your loop is two weeks away, divide your prep into concept fluency in week one and spoken drills in week two. Practice behavioral and technical storytelling out loud on our behavioral interview practice page, and when you are ready to test your pacing under pressure, practice a case free, no sign-up with an AI interviewer that pushes back on your logic.

1. 1. APIs and networking

   APIs and networking

   Write sample REST URI endpoints, HTTP methods (GET, POST, PUT, DELETE), JSON bodies, and status codes for a familiar app. Review TCP versus UDP and how CDNs cut propagation latency.

2. 2. Databases and caching

   Databases and caching

   Map out when to use relational databases (ACID transactions, primary and foreign keys, normalization) versus purpose-built NoSQL stores (key-value, document, graph, wide-column, time-series). Practice explaining write-through versus lazy-population caching and how to pick a TTL.

3. 3. LLMs and AI

   LLMs and AI architecture

   Practice explaining how transformers use encoders, decoders, self-attention, and word embeddings. Walk through an end-to-end RAG architecture using a vector database with KNN or ANN search, contrasting it with zero-shot prompting and fine-tuning.

4. 4. Spoken system design

   Spoken system design and behavioral drills

   Pick one system prompt per day and speak your answer out loud in 6 minutes using the 5-step checklist. Prepare behavioral stories around engineering trade-offs, system incidents, and scope negotiation.

   From AWS: What is RESTful API?.