PM technical depth: rating yourself, a technical decision you shaped, and a system diagram

The interviewer wants to gauge how technical you are as a product manager and asks for three things in a row. First, how technically deep are you? Second, walk through a project in which you had a large influence on its technical direction. Third, pick a system you know well and draw its architecture diagram, going into as much detail as you can. ### Clarifying Questions - Does the system I diagram have to be one I worked on, or may I choose a widely used product whose architecture I understand well? - For the project, does it count if engineers owned the final technical call and I shaped it through requirements, data and how the trade-off was framed? - Is the team I would join building infrastructure and developer-facing products or consumer features, so I can calibrate how deep my examples go? - Should I draw on a whiteboard as I talk, or describe the components and connections verbally? ### Part 1 — Rate your own technical depth Give a short, honest assessment of your technical depth: what you can do yourself, what you can follow and challenge in an engineering discussion, and where your knowledge stops. ```hint Activities, not adjectives "Very technical" tells the interviewer nothing. Describe things you actually do, and choose a level you can still defend once the next two parts probe it. ``` #### What This Part Should Cover - A self-rating expressed through concrete activities rather than labels. - A clear boundary between hands-on work, work the candidate can evaluate, and work they leave to engineers. - A claim that the project story and the diagram can back up. ### Part 2 — A technical decision you shaped Describe the project, the technical decision or decisions at stake, the options that were considered, what you specifically did to influence the outcome, and what happened as a result. ```hint Name the fork in the road Build the story around one concrete technical choice with at least two real options, and be ready to say why the losing option lost in technical terms, not only in schedule terms. ``` #### What This Part Should Cover - A clearly stated technical decision, the alternatives on the table, and the criteria used to compare them. - An honest split between the candidate's contribution and the engineers' contribution. - Reasoning in terms of system qualities such as latency, cost, reliability or maintainability, connected to user and business impact. - A measured outcome and what the candidate would revisit. ### Part 3 — Diagram a system you know well Choose a system and draw its architecture: the clients, the entry points, the services, the data stores, any asynchronous processing, and the outside services it depends on. Keep adding detail for as long as the interviewer lets you. ```hint Follow one request Boxes and arrows alone stay shallow. Pick one user action and walk it through every component it touches, noting where data is written and read and what happens when one hop is slow or down. ``` #### What This Part Should Cover - Correct major components and the connections between them. - The data flow for at least one concrete user action, separating reads from writes and synchronous from asynchronous work. - Depth on request for at least one component: data model, caching, scaling or failure handling. - A clear line between what the candidate knows and what they would be guessing. ### What a Strong Answer Covers - Precise, consistent technical vocabulary across all three parts. - Technical choices tied back to user experience, cost and delivery risk, which is the product manager's lens. - Calibration: the Part 1 self-rating matches the depth shown in Parts 2 and 3, and the candidate is clear about what they built, decided, influenced or only observed. - The ability to go one level deeper whenever the interviewer pushes, on the project and on the diagram. ### Follow-up Questions - If this system's infrastructure bill had to drop by half, which component in your diagram would you change first, and what would users notice? - What technical debt did your project decision create, and how would you explain it to an executive who wants the next feature sooner? - An engineer on the team disagrees with your reading of a trade-off. How do you decide whose judgment carries the decision?