Tell me about a time you decided not to use a technology or framework.
- Technology:
- Behavioral
- Experience:
- Senior
Quick answer
Explain why the technology looked attractive, what problem it actually solved, and why its cost or complexity was not justified in your context.
What the interviewer is evaluating
- Pragmatism
- Technical judgment
- Trade-off reasoning
How to structure your answer (STAR)
- Situation: proposed technology.
- Task: decide whether it was justified.
- Action: compare actual needs and costs.
- Result: simpler solution and future criteria.
Example answer
The team considered adding a new state-management library for a feature with only a small amount of local and server state.
I mapped the actual data flows and found that existing patterns handled the requirement without the additional dependency. I suggested revisiting the decision if shared client state became substantially more complex.
We avoided extra dependency and setup cost while keeping a clear trigger for reconsideration.
Discussion
Knowing when not to add technology is an important engineering skill.
A strong answer compares the expected benefit against learning cost, operational complexity, team capability, migration cost and long-term maintenance.
Avoid making the decision sound ideological; show that you would reconsider if the constraints changed.
Key points
- Define the actual problem
- Compare total cost
- Avoid unnecessary complexity
- State when the decision could change
Common mistakes
- Saying a technology is bad in general.
- Ignoring future requirements.
- Choosing simplicity without evidence.
Follow-up questions
- When would you choose that technology?
- How did you convince the team?