Walk Through a Past Frontend Project: Problems Solved and Tech Stack Choices
xAIFrontend Engineer · OnsiteLast updated
A behavioral question from a project and product management round for a frontend role: describe a problem you hit on a past project and how you solved it, then explain how you chose the tech stack. It tests structured storytelling, trade-off reasoning, and decisions tied to product needs.
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.
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.
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
Hints
Hint 1
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.
Hint 2
Criteria before tools: Before naming any framework, list the requirements and constraints that the choice had to satisfy.
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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.