Ambiguity, Prioritization and Delivery
Senior engineers are handed problems, not tasks. Learn how to turn a vague goal into a plan, which prioritization techniques to use when, how to say no well, and how to deliver under pressure by cutting scope rather than quality.
🎯 What you'll learn
- A method for handling ambiguity
- Prioritization techniques and when to use each
- Saying no without damaging relationships
- Delivering under pressure
📚 Before you start
Senior engineers are handed problems, not tasks: "checkout conversion dropped", "our infra costs are too high", "make onboarding faster". These questions test whether you can turn a vague goal into a plan, choose what not to do, and deliver under pressure.
1Typical Questions
- "Tell me about a project with unclear requirements."
- "How do you prioritize when everything is urgent?"
- "Tell me about a time you had to say no."
- "Tell me about a time you delivered under a tight deadline."
- "Tell me about a time you had to change direction mid-project."
2Handling Ambiguity
- Clarify the goal: who is the user, what outcome matters, how will we measure success? Write it down and get agreement.
- List unknowns and risks and rank them by how much they could change the plan.
- Reduce the biggest unknowns first: talk to users, look at data, build a spike.
- Slice the work so each slice delivers value or learning on its own.
- Communicate the plan and its assumptions, and revisit when assumptions change.
3Prioritizing
| Technique | When to use it |
|---|---|
| Impact vs effort | Many small candidate items; pick high-impact, low-effort first. |
| Cost of delay | Deadlines, contracts, seasonal traffic: what does waiting a week cost? |
| Must / should / could / won't (MoSCoW) | Scoping a release with stakeholders. |
| Risk first | New technology or integrations: do the riskiest piece early. |
| Tie to goals | "Which of these moves this quarter's metric?" |
Saying no well: explain the trade-off ("if we take this, the migration slips two weeks"), offer alternatives (a smaller version, a later date), and let the right person decide when it isn't your call.
4Delivering Under Pressure
Good stories show that you cut scope rather than quality, communicated risk early, protected the team from thrash, and made a plan for the work you deferred.
⚠️ Common Pitfalls
- Waiting for clarity: "requirements were unclear so we waited for product" is not ownership.
- Diving into code before clarifying the goal.
- Everything is priority 1: no evidence of trade-offs.
- Cutting quality silently (skipping tests) to hit a date.
- Late surprises: telling stakeholders about a slip on the deadline day.
📋 Quick Reference
Ambiguity: clarify goal + metric → list unknowns → kill the biggest first → slice → communicate assumptions
Prioritize: impact/effort · cost of delay · MoSCoW · risk first · tie to goals
Say no: show the trade-off, offer alternatives, let the right person decide
Pressure: cut scope not quality, flag risk early, plan the deferred work🧠 Key takeaways
- Turn vague asks into a goal with a metric, then kill the biggest unknown first.
- Prioritize with an explicit technique: impact/effort, cost of delay, MoSCoW, risk first.
- Say no by showing the trade-off and offering alternatives.
- Under pressure, cut scope, not quality, and flag risk early.
🛠️ Practice exercises
Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.
✅ Check yourself
Answer the questions — feedback is instant.