How you choose technologies
Last Updated: June 4, 2026
Medium Priority
5 min read
AI Mock Interview
Practice this question in a realistic, spoken behavioral interview.
Question
How do you decide which technologies to use for a new project or feature?
This question is about engineering judgment: whether you can pick technology based on the project's actual constraints rather than novelty or personal preference. Pick a decision where the boring option had real advantages and the exciting option had real appeal, then walk through how team expertise, operational load, timeline, cost, rollback path, and the expected lifespan of the system shaped your choice.
What Makes the Choice Defensible
The answer should make it clear that the choice served the project, not your personal preferences:
- Start with the job the technology had to do: State the workload, scale, latency, reliability, security, or integration constraint before naming the tool.
- Make the trade-off explicit: Every choice buys something and costs something: speed now, maintainability later, performance, hiring, operability, or vendor dependence.
- Include the team cost: A technically elegant choice can still be wrong if nobody can debug, deploy, or maintain it six months later.
- Tie it to business constraints: Timeline, budget, existing platform standards, customer commitments, and strategic direction all belong in the decision.
- Prefer boring when boring works: New technology needs a real reason. Simplicity is a feature when the system is meant to do a job, not to be a place to experiment.
Where This Answer Usually Goes Wrong
- Picking what you wanted personally: It shows. Be honest about whose interests the choice served.
- Skipping who maintains it: If you picked a tech your team did not know, name the ramp-up plan.
- The "cutting edge" framing: Newer is not stronger. Frame the choice in terms of fit, not novelty.
- No exit plan: A good story includes the "if this goes wrong, here is how we back out" thinking.
- Resume-driven development: If the tech choice mainly helped your resume, that comes through. Ground the decision in the team's needs.
Decision Criteria, from Inside Out
Structure your thinking by moving outward: from the problem itself, to the team context, to the broader business context.
- The Core Problem: What are the fundamental technical requirements of the project? (e.g., "Does this need to handle massive concurrency?" "Is low latency the most critical factor?" "Is data consistency paramount?")
- The Team Context: What is our team's existing expertise? How steep is the learning curve for a new tool? What is our operational capacity to maintain this new thing?
- The Company/Business Context: What are our business constraints (time, budget)? Are there existing company standards or "paved roads" we should follow? Does this decision align with our long-term technical strategy?