Walk Through a Past Frontend Project: Problems Solved and Tech Stack Choices

In a project and product management conversation for a frontend engineering role, the interviewer asks about your past work in two directions: the problems you ran into on a past project and how you solved them, and how you decided which tech stack to use. Prepare an answer to both. ### Clarifying Questions - Should both parts draw on the same project, or may each part use a different one? - Is the interviewer more interested in technical problems, or in problems of scope, schedule and coordination with other people? - For the tech stack, does the question concern choosing a stack for a new project, or changing the stack of an existing product? ### Part 1 — A problem you hit and how you solved it Describe a significant problem from a past frontend project: what went wrong, how you found the cause, what you did about it, and what happened as a result. ```hint Pick a problem with stakes Choose a problem where the right move was not obvious, so that you can explain what you weighed and not only what you did. ``` #### What This Part Should Cover - The situation, its constraints and why the problem mattered to users or the business - How the cause was diagnosed, with evidence rather than guesses - The actions taken, the options rejected, and your own role - A measured result and what changed afterwards to prevent a repeat ### Part 2 — How you chose the tech stack Explain how you decided which frameworks, libraries and tools to use on a project: what you considered, what you chose, and how you knew it was the right call. ```hint Criteria before tools Before naming any framework, list the requirements and constraints that the choice had to satisfy. ``` #### What This Part Should Cover - Criteria derived from product and team requirements - The alternatives considered and why each was rejected - How the choice was validated and when it would be revisited - The team and organizational factors: skills, hiring, maintenance, agreement ### What a Strong Answer Covers - Concrete, specific examples in which your own role is clear - Decisions tied to user and product outcomes, not only to engineering taste - Honest trade-offs, including what you would do differently now ### Follow-up Questions - If you started that project today, would you choose the same stack? What would make you switch? - How did you win agreement on the stack from people who preferred something else? - How did you balance fixing the problem properly against a delivery deadline? - How do you decide when migrating to a new framework is worth its cost?