Scope and Time Management Questions

Covers prioritization, time boxing, and communication strategies to manage limited time during design interviews, sprints, or engineering work. Topics include identifying core user flows versus edge cases, setting a minimum viable solution, planning and communicating what will be built within a time budget, explaining trade offs and next steps when work is incomplete, showing realistic time awareness and delivery sequencing, and demonstrating the ability to focus on high value deliverables under tight deadlines.

MediumTechnical

80 practiced

Process improvement: Your team's pull request review cycle averages 48 hours, slowing delivery. Propose at least four specific process or tooling changes to reduce review time to under 12 hours, explain how you'd pilot each change, and what metrics you'd use to evaluate success.

EasyTechnical

91 practiced

Compare two prioritization frameworks: RICE and MoSCoW. For a feature backlog of 10 items, explain when you'd prefer one over the other and provide a short example of scoring a single feature using RICE (include reasonable numeric values).

MediumSystem Design

135 practiced

Release planning: You have to deliver a core checkout flow in two sprints (2-week sprints). Describe the minimal set of features you'd deliver in sprint 1 and sprint 2, include acceptance criteria, key tests, rollout strategy (feature flags/canaries), and metrics to watch after release.

Sample Answer

Requirements / constraints:- Deliver core checkout (cart → payment → confirmation) in 2 two-week sprints. Must be PCI-lite (tokenized payments), mobile + web, basic fraud checks, rollback-safe.

High-level splitSprint 1 (MVP checkout flow — end-to-end happy path + basics)- Features: - Cart summary & checkout button - Shipping address form (basic validation) - Payment input using 3rd-party tokenization (client-side token) - Order confirmation page & simple order record persistence - Feature flags around new checkout to enable/disable- Acceptance criteria: - User can go from cart to confirmation and see order ID - Payment token is generated and stored (no raw card data) - Response times < 2s for checkout submit 95th percentile- Key tests: - Unit tests for form validation & payment request flow - Integration test with payment sandbox (successful charge) - E2E test: cart→checkout→confirmation - Security scan for secrets and dependency checks- Rollout: - Internal canary: enable for 5% of internal users via feature flag - Monitor for errors for 24–48h before expanding

Sprint 2 (hardening, edge cases, UX & monitoring)- Features: - Shipping options + cost calculation, taxes - Guest vs authenticated checkout and order history link - Payment failure handling & retry UI - Basic fraud rules (velocity, address mismatch) - Analytics events and detailed monitoring dashboards - Automated rollback via feature flag- Acceptance criteria: - Correct shipping/tax calculation in 3 sample regions - Payment failures produce clear UI and no duplicate orders - Fraud rules block or flag suspicious orders- Key tests: - Integration tests covering payment failure/retry, duplicate prevention - Load test at expected peak + 2x - Security/PCI checklist review- Rollout: - Progressive ramp from 5% → 25% → 100% with automated health gates (error rate, latency, payment success rate) - Canary region deploys and rollback via flag if thresholds exceeded

Metrics to watch (during canary and after full rollout)- Business: Checkout conversion rate (cart → order), revenue per session- Reliability: Payment success rate, order duplication rate, server error rate (5xx)- Performance: p95 latency for checkout submit, time-to-confirmation- Fraud/security: blocked orders count, chargeback rate (post-release)- Operational: feature-flag toggles, rollback events

Rollback & safety- Keep old checkout route active behind flag for instant rollback- Idempotency for order creation (client-side idempotency key) to prevent duplicates- Alerts: automated PagerDuty if payment success rate drops >3% or error rate increases >1% absolute

This plan delivers a functioning, safe checkout in sprint 1 and production-quality hardening in sprint 2 with controlled rollouts and clear metrics for decision making.

HardTechnical

72 practiced

Algorithmic scheduling with dependencies: Formal problem — you have N unit-time tasks, each with a deadline and value; some tasks have dependencies (a DAG). On a single worker, schedule tasks to maximize total value of tasks completed by their deadlines. Describe an algorithm, discuss optimality or approximation bounds, and propose a practical implementation approach for engineering planning (N up to hundreds).

Sample Answer

Summary: The problem — unit-time, deadline and value per task, precedence DAG, single worker — is NP-hard (generalizes weighted scheduling with deadlines and precedence). For N ~ hundreds, use an exact time-indexed ILP/CP model (practical) or a good heuristic (fast, near-optimal).

1) Hardness and implications- This is NP-hard (reduces from scheduling/knapsack variants). So polynomial-time optimal algorithms unlikely for large N; we either use exponential DP for tiny N, pseudo-polynomial DP if deadlines small, or exact solvers (MIP/CP) for N up to a few hundreds.

2) Exact practical approach (recommended for engineering planning)- Time-indexed integer programming (variables y[t, s] = 1 if task t scheduled at slot s, s ∈ {1..T} where T = max deadline or N)Constraints: - ∑_s y[t,s] ≤ 1 (each task at most once) - ∑_t y[t,s] ≤ 1 (one task per slot) - y[t,s] = 0 for s > deadline[t] - Precedence: for edge u→v, for all s: ∑_{i≤s} y[u,i] ≥ ∑_{i≤s} y[v,i] (enforces u scheduled no later than v)Objective: maximize ∑_t value[t] * ∑_s y[t,s]- Complexity: O(N*T) variables (≤ O(N^2)), O(N^2) constraints — solvable by CP-SAT (OR-Tools) or commercial MIP (Gurobi) for N~hundreds in reasonable time.- Advantages: exact optimal (within solver tolerance), easy to add business constraints (resource calendars, task durations >1).

3) Heuristic/approximation (fast, often good)- Greedy + latest-slot assignment with precedence-aware release: - Topologically process availability: maintain set A of tasks whose predecessors are scheduled. - Use a max-heap keyed by value (or value/(slack+1)) over A. - Maintain a DSU or boolean array of free slots 1..T; when picking task t, place it in the latest free slot ≤ deadline[t]. If none, skip (can't schedule). - When you schedule t, add its successors to A if all their predecessors are scheduled.- Rationale: latest-fit maximizes chances to place high-value tasks; precedence-awareness prevents violating dependencies.- Complexity: O(N log N + N α(T)) with union-find for slots.

4) Pseudo-polynomial DP (when deadlines small)- If max deadline T is small (e.g., ≤ 500), dynamic programming over topological order with state = bitset of occupied times or DP over subsets of time used is possible but can blow up. Time-indexed DP: for each node in topo order, update DP[mask] — feasible for small T.

5) Which to pick in practice- Use time-indexed CP/MIP if you need optimality, auditability and N ≤ a few hundreds. Implement with OR-Tools CP-SAT; add warm-starts and time limit (e.g., 60s) for predictable run-time.- Use the precedence-aware greedy for fast runs and what-if scenarios (interactive planning, many variants). Compare greedy to solver on representative instances to gauge gap.

6) Example heuristic sketch (Python-like pseudocode)

python

# high-level outline
# compute topo order and predecessor counts
available = [t for t in tasks if indeg[t]==0]
heap = MaxHeap(key=lambda t: value[t])
free_slot = DSU(T)  # find latest free slot <= d
while heap or available:
    push newly available into heap
    if heap.empty(): advance time or break
    t = heap.pop()
    s = free_slot.find(deadline[t])  # find latest free slot <= deadline
    if s == 0: continue
    assign t to slot s; free_slot.union(s-1, s)
    mark successors and if ready push to available

7) Metrics and validation- Compare heuristic vs solver on sample instances: total value, number scheduled, average slack.- Use time limits and incremental solving for planners (first-feasible quickly, improve with more time).

Takeaway: For engineering planning with N up to hundreds, the time-indexed ILP/CP model is practical and gives optimal or near-optimal solutions within solver time limits; for fast interactive planning use the precedence-aware latest-fit greedy heuristic and validate its gap empirically.

MediumTechnical

87 practiced

Scenario: Mid-sprint you learn an upstream API will change breaking your current implementation and no backward compatibility will exist. Walk through the triage steps, how you estimate impact on scope/time, choices you present to product, and how you communicate schedule changes to stakeholders.

Sample Answer

Situation: Mid-sprint I discovered the upstream API our feature depends on will change without backward compatibility, breaking our current implementation.

Triage / immediate steps:- Reproduce & assess: I ran failing calls to confirm exact breakage and captured error messages/contract diffs.- Scope impact: Mapped all places (service calls, DTOs, tests, docs) that directly use the API and flagged indirect consumers.- Prioritize risk: Classified impact as Blocker (feature unusable), Partial (degraded), or Minor (noncritical).- Quick consult: Notified the upstream team to confirm timeline and ask for migration guidance; checked if a compatibility shim is possible on their side.

Estimating scope & time:- I broke work into small tasks: API contract changes, client adapter, integration tests, backward-compat shim (if feasible), and deploy steps.- For each task I used relative sizing (1–3 story points) and added a 20–30% buffer for unknowns (auth, edge cases).- I validated estimates with one peer to reduce optimism bias and produced a short implementation plan with best/worst-case durations.

Choices presented to Product:1) Pause and fix now (deliver later this sprint) — gives full functionality but delays other sprint commitments.2) Ship degraded experience (feature with fallback) — retains partial user value; requires smaller effort.3) Re-scope/remove feature from sprint and defer to next release — keep sprint commitments intact.For each I provided clear trade-offs: user impact, delivery time, QA effort, and rollback complexity.

Communicating schedule changes:- I immediately updated the sprint board and created a concise incident note summarizing impact, options, recommended choice, and estimates.- I held a 15-minute sync with Product and the Tech Lead to recommend an option and get a decision.- Once decided, I sent a stakeholder update (Slack + email) with new expected delivery date, mitigation steps, and a follow-up checkpoint time.- During execution I posted daily short updates and flagged if estimates changed.

Result / learning:This approach minimized surprise, let Product choose a trade-off with clear data, and kept stakeholders informed. I learned to add automated contract tests for upstream APIs and to request versioning SLAs to reduce future risk.

Unlock Full Question Bank

Get access to hundreds of Scope and Time Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.