Katkat

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

xAIFrontend Engineer · Onsite

Last 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?