Pick a frustrating product problem, compare tech fixes and define success metrics

Choose a product you use, physical or digital, that has a problem you find genuinely frustrating. Explain the problem, show how technology could fix it, weigh the strongest candidate fixes against each other, and describe how you would prove after launch that your fix is doing its job. ### Clarifying Questions - May the product be anything I use, or should it be one that the interviewer's company builds or sells? - Does "technology" have to mean a software change inside the existing product, or can the fix use new hardware, sensors or a different service model? - Should the comparison be among my own candidate fixes, or should it also cover how competing products already handle this problem? ### Part 1 — Pick the problem and show it is worth solving Name the product and the problem. Describe who runs into it, how often, what it costs them, and why the product has not already fixed it. ```hint Make the pain concrete A problem that annoys only you is a weak pick. Choose one you can size: who hits it, how often, and what they do today to get around it. ``` #### What This Part Should Cover - A specific, observable problem rather than a general complaint about the product - The affected users and a rough sense of how many people hit it and how often - The underlying cause that keeps the problem alive today ### Part 2 — Solve it with technology and compare the best options Generate several technology-based fixes, compare the strongest two or three on criteria you state, and pick one. ```hint Vary the mechanism Options that are all small variations of one technique make a thin comparison. Look for fixes that attack different causes, then judge them on the same yardstick. ``` #### What This Part Should Cover - Candidate fixes that differ in how they work, not only in their feature lists - Stated comparison criteria such as user impact, coverage, cost, feasibility and risk - A clear choice and the reason it beats the runner-up ### Part 3 — Prove the fix is working Explain how you would know, once the fix ships, that it is solving the problem you described in Part 1. ```hint Tie the metric to the pain Your main metric should move only if the Part 1 problem actually shrinks. Then ask what could get worse because of your fix. ``` #### What This Part Should Cover - A primary metric that maps directly to the problem from Part 1 - Guardrail metrics that catch harmful side effects - A way to attribute the change to the fix, such as a controlled experiment ### What a Strong Answer Covers - One consistent thread from the problem to the chosen fix to the metric - Judgment about technology fit, including when a simpler non-technical change would be enough - Risks such as privacy, cost and what happens when the technology gets it wrong - A phased plan: what ships first and what must be learned before a bigger bet ### Follow-up Questions - Your primary metric improved, but complaints about the same problem did not fall. How would you explain the gap? - Your preferred fix needs data many users may not want to share. How would you change the plan? - If engineering could give you a quarter of the effort you asked for, which part of the fix would you ship first?