Definition
- Early detection – Notice the gap between planned and actual effort within the first days, not at the deadline.
- Honest communication – Raise the underestimate immediately with the revised timeline and root cause.
- Sensible re-plan – Ship the critical path on time and defer the rest to a later iteration.
- Process improvement – Track estimate versus actual and derive a calibration factor for future estimates.
- Root cause understanding – Hidden complexity (edge cases, integrations, compliance) is the usual culprit.
Imagine a developer at National Bank of India thought adding multi-currency support to Priya's account would take two days, but it turned out to need three weeks because of rounding, exchange-rate storage, and regulatory rules. What matters is how fast you tell the stakeholder, re-plan honestly, and estimate better next time.
Understanding the Concepts
What is this question really testing?
Estimation skill, honesty, and recovery. The interviewer wants to see that you recognize a bad estimate early, communicate quickly, re-plan sensibly, and improve your estimation process afterward.
package com.bank.interview;
public class EstimationTest {
enum Signal { HONEST_IMPROVER, SILENT_HOPER }
public static Signal evaluate(boolean detectedEarly, boolean communicated, boolean improved) {
return (detectedEarly && communicated && improved) ? Signal.HONEST_IMPROVER : Signal.SILENT_HOPER;
}
public static void main(String[] args) {
System.out.println(evaluate(true, true, true)); // HONEST_IMPROVER
}
}
What was the underestimate?
Adding multi-currency support to the account service at National Bank of India. I estimated two days. It took far longer because of hidden complexity I had not considered.
package com.bank.interview;
public class TheUnderestimate {
public static void main(String[] args) {
System.out.println("Task: add multi-currency support");
System.out.println("Estimate: 2 days");
System.out.println("Actual: 2+ weeks");
System.out.println("Hidden complexity: decimal rounding per currency, exchange rate storage, compliance checks");
}
}
How did you detect the gap early?
Within the first day of real work, it became clear the task was far bigger than two days. I did not quietly hope to catch up.
package com.bank.service;
import java.util.logging.Logger;
public class EarlyDetection {
private static final Logger log = Logger.getLogger(EarlyDetection.class.getName());
public static void main(String[] args) {
int estimatedDays = 2;
int discoveredSubtasks = 8; // rounding, rates, compliance, tests, migration...
log.warning("Day 1: discovered " + discoveredSubtasks + " sub-tasks vs " + estimatedDays + " day estimate");
log.info("Action: raised it immediately, did not wait for deadline");
}
}
How did you communicate and re-plan?
I went to my manager, explained the hidden requirements, and proposed delivering the most critical currency path first.
package com.bank.interview;
public class CommunicateAndReplan {
public static void main(String[] args) {
System.out.println("To manager:");
System.out.println(" Root cause: hidden complexity in rounding, rates, and compliance");
System.out.println(" Revised plan: deliver INR + USD path first (critical)");
System.out.println(" Defer: rare currencies to next sprint");
}
}
How did you improve your estimation process?
I started recording estimates versus actuals and calculated a historical optimism factor. Now when my gut says two days, I adjust by the factor before committing.
package com.bank.service;
import java.math.BigDecimal;
import java.math.RoundingMode;
public class EstimationCalibration {
public static void main(String[] args) {
BigDecimal totalEstimated = new BigDecimal("40"); // hours across 10 tasks
BigDecimal totalActual = new BigDecimal("64");
BigDecimal optimismFactor = totalActual.divide(totalEstimated, 2, RoundingMode.HALF_EVEN);
System.out.println("Optimism factor: " + optimismFactor);
BigDecimal nextEstimate = new BigDecimal("16"); // gut says 16 hours
BigDecimal calibrated = nextEstimate.multiply(optimismFactor).setScale(0, RoundingMode.HALF_EVEN);
System.out.println("Gut estimate: " + nextEstimate + "h, Calibrated: " + calibrated + "h");
}
}
Optimism factor: 1.60
Gut estimate: 16h, Calibrated: 26h
Why is hidden complexity the usual culprit?
Edge cases, integration points, and compliance requirements are invisible at first glance. A spike task to explore unknowns before committing prevents the worst surprises.
package com.bank.interview;
public class HiddenComplexity {
public static void main(String[] args) {
System.out.println("Visible: API endpoint for currency conversion");
System.out.println("Hidden: exact decimal rounding per currency pair");
System.out.println("Hidden: storing historical exchange rates for audit");
System.out.println("Hidden: regulatory compliance checks for cross-currency");
System.out.println("Fix: always add a spike task for unknown dependencies");
}
}
What is the lasting improvement?
Later estimates became dramatically more reliable because I calibrated with real data instead of trusting an optimistic gut.
package com.bank.interview;
public class LastingImprovement {
public static void main(String[] args) {
System.out.println("Before calibration: off by 60% on average");
System.out.println("After calibration: off by 15% on average");
System.out.println("Process: spike unknowns + calibration factor + daily tracking");
}
}
What are common interview follow-up questions?
package com.bank.interview;
public class EstimationFollowUps {
public static void main(String[] args) {
System.out.println("How accurate now? -> Within 15% on average");
System.out.println("What if you cannot spike? -> Add buffer explicitly and communicate the uncertainty");
System.out.println("Team adopted? -> Yes, we all track estimate vs actual now");
}
}
Visual Overview
┌────────────────────────────────────────────────────────┐ │ Underestimation Recovery Flow │ ├────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────┐ │ │ │ 1. DETECT EARLY │ Day 1: discovered 8 sub-tasks │ │ │ │ vs 2-day estimate │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 2. COMMUNICATE │ Tell manager immediately │ │ │ honestly │ with root cause + revised plan │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 3. RE-PLAN │ Critical path first │ │ │ sensibly │ Defer rare currencies │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 4. IMPROVE │ Track estimate vs actual │ │ │ PROCESS │ Derive calibration factor │ │ │ │ Add spike tasks for unknowns │ │ └──────────────────┘ │ └────────────────────────────────────────────────────────┘
Key Takeaway
At National Bank of India, I estimated that adding multi-currency support to our account service for Priya would take about two days. I was badly wrong because of hidden complexity: exact decimal rounding across currencies, storing historical exchange rates, and additional compliance checks. The impact was a slipped internal date.
The most important thing I did was detect the gap early and speak up immediately. Within the first day it was clear the task was far bigger, so I did not quietly hope to catch up. I went to my manager, explained the hidden requirements, and proposed a revised plan with the critical currency path first.
The lasting change was to my estimation process. I started recording estimates against actuals and derived a calibration factor so future estimates adjusted for my historical optimism.
What I learned is that underestimating is normal, but repeating the same optimism is a choice. The professional move is to detect early, communicate honestly, and use real data to calibrate future estimates.
Remember one sentence: Detect estimation misses early, communicate honestly, re-plan the critical path, and calibrate future estimates with tracked data so the same optimism does not repeat.
---