Describe how you prevent project delays
Company: Remitly
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: easy
Interview Round: Technical Screen
Answer the following behavioral questions.
## 1) How do you ensure your project won’t be delayed?
Explain your concrete methods, habits, and mechanisms you use to keep delivery on track.
## 2) Give an example where you used a different approach to finish a project
Describe a situation where you changed your approach (e.g., process, technical plan, collaboration model, execution strategy) to successfully complete a project. Explain why you changed, what you did, and the outcome.
Quick Answer: This question evaluates a candidate's project management, leadership, risk mitigation, communication, and adaptability skills by probing methods for preventing delays and examples of changing approaches to complete work.
Solution
## How to answer (high-signal structure)
Use **STAR** (Situation, Task, Action, Result) plus a brief “**Reflection**” at the end.
- **Situation/Task:** scope, deadline, stakeholders, why it mattered.
- **Action:** what *you* did (not “we”), include decision points and trade-offs.
- **Result:** measurable outcomes (time, quality, cost, reliability), and what you learned.
- **Reflection:** what you’d repeat vs. improve next time.
---
## 1) “How do you ensure your project won’t be delayed?” (what interviewers look for)
They want to hear that you can (a) plan realistically, (b) manage risk/dependencies, (c) communicate early, and (d) protect the critical path.
### A strong answer usually includes these tactics
1. **Clarify scope and success criteria early**
- Write a short spec: goals, non-goals, user flows, acceptance criteria.
- Identify unknowns and convert them into explicit investigation tasks.
2. **Break work into milestones with measurable deliverables**
- Define “thin slices” that can ship (MVP → hardening → polish).
- Create checkpoints (e.g., design review by Week 1, prototype by Week 2).
3. **Identify the critical path + manage dependencies**
- Call out external dependencies (other teams, data sources, vendor approvals).
- Create fallback plans (mock services, feature flags, staged rollouts).
4. **Risk management (pre-mortem + buffers)**
- Maintain a top risks list (likelihood × impact) and revisit weekly.
- Add buffers for integration/testing, not just coding.
5. **Tight feedback loops**
- Early prototypes/spikes to de-risk architecture/performance.
- Frequent demos to stakeholders to prevent late requirement changes.
6. **Execution hygiene**
- Define “Definition of Done” (tests, monitoring, docs, rollout plan).
- Track with a lightweight system (Jira/Linear/weekly status doc).
7. **Communicate early when schedule risk appears**
- Don’t hide bad news. Provide options: descope, add resources, split launch.
- Frame updates as: current status → risk → recommendation → ask.
### Pitfalls to avoid
- “I just work harder” (signals poor planning and unsustainable process).
- Vague claims without specifics (no milestones, no risk examples).
- No mention of dependencies, testing, or integration (common delay sources).
### A concise template you can reuse
> “I prevent delays by clarifying scope and acceptance criteria up front, then planning milestones around the critical path. I de-risk early with spikes/prototypes, track top risks weekly, and manage dependencies with explicit owners and fallback plans. If risk emerges, I communicate early with options like descope or phased delivery, so we protect the deadline while keeping quality acceptable.”
---
## 2) “Example where you used a different approach to finish the project”
This question tests adaptability, problem diagnosis, and decision-making under constraints.
### What counts as a “different approach” (pick one)
- **Execution model:** waterfall → iterative delivery; big-bang → phased rollout.
- **Technical strategy:** batch → streaming; synchronous → async; monolith → modular.
- **Quality strategy:** add automated tests, canary releases, feature flags.
- **Collaboration:** embed with another team, redefine ownership, create an RFC process.
- **Scope strategy:** MVP-first, descope non-critical features, split into two launches.
### How to craft a strong story
1. **State the original plan and why it was failing**
- E.g., unclear requirements, integration risk, performance unknowns, stakeholder churn.
2. **Describe the pivot and why it was the right choice**
- Tie to constraints (deadline, reliability, compliance, headcount).
- Mention alternatives you considered.
3. **Detail execution steps**
- What you changed (milestones, architecture, process), how you got alignment.
- Include risk mitigation (feature flags, rollback, testing strategy).
4. **Quantify results**
- On-time delivery, reduced incidents, improved latency, fewer manual ops, etc.
### Example outline (you can adapt)
- **S:** Launch deadline in 6 weeks; initial plan was full feature set with big-bang release.
- **T:** Deliver core user value by deadline with low incident risk.
- **A:** Noticed integration/testing was the bottleneck → proposed phased rollout:
- Week 2: MVP behind feature flag
- Week 4: expand to internal users + monitoring/alerts
- Week 6: gradual production ramp (canary) + rollback playbook
- Descope non-critical UI polish; add it post-launch
- **R:** Hit deadline; reduced release risk; measurable improvement (e.g., 0 sev-1 incidents, 30% faster cycle time).
- **Reflection:** Earlier risk spike would have surfaced the testing bottleneck sooner.
### Common mistakes
- The “different approach” is superficial (e.g., “I used a different library”).
- No rationale for the change.
- No measurable outcome.
- You changed approach but didn’t bring stakeholders along (alignment is key).
---
## Quick checklist before you deliver your answer
- Did you mention **milestones + critical path**?
- Did you cite **one concrete risk** and how you handled it?
- Did you show **communication/expectation management**?
- Did you provide **numbers** (timeline, impact, quality metrics)?
- Did you clearly say what **you** did?