Technical Interviews
Engineering estimation interviews in Japan: make uncertainty useful
Turn a vague delivery request into scoped work, explicit assumptions, a range, risk drivers, and a date for re-estimation.
Sources
What you can use right away
- Define the decision and scope before producing a number.
- Estimate a range with named assumptions and risk drivers.
- Set a checkpoint where new evidence will replace the first estimate.
First identify which estimate is being requested
An interviewer may ask for effort, elapsed time, team capacity, infrastructure cost, or a rough order of magnitude. These are not interchangeable. Ask who needs the estimate, what decision it supports, what "done" includes, and which deadline, scope, or quality constraint can move.
Avoid converting a vague request directly into person-days. State the confidence appropriate to the information available. An early estimate is a planning range, not a promise.
Decompose around deliverable work
Break the request into discovery, design, implementation, data or migration, testing, rollout, and operational follow-up. Then mark dependencies, unfamiliar areas, and work that can happen in parallel. Include integration and review instead of estimating only code writing.
Use historical work when it is genuinely comparable. Explain what differs in domain, team familiarity, data volume, or external dependencies rather than copying the old number.
Try this checklist
- Write an explicit in-scope and out-of-scope list.
- Name the three unknowns most likely to move the estimate.
- Separate effort from calendar time and waiting time.
Present a range and its assumptions
A useful answer can be: "With the existing authentication service and no data migration, I estimate two to three engineer-weeks. The range becomes four to six if we need a new identity flow or approval from the external provider." The assumptions explain why the range moves.
Do not add a hidden blanket buffer. Attach uncertainty to specific work, then say how you will reduce it through a spike, prototype, sample migration, or dependency check.
Worked example: add calendar synchronization
Scope a first version as one provider, create and cancel events, encrypted token storage, retry, user-visible sync status, tests, and staged rollout. Exclude recurring events and bidirectional conflict resolution. Estimate the known path, then isolate the provider approval and token-refresh behavior as risk items.
Offer a checkpoint: after a two-day integration spike, replace the initial range with an implementation estimate and decide whether recurring events remain out of scope. This is more credible than pretending the first number will survive new evidence.
Handle pressure for one date
If the interviewer asks for a single date, give the planning date together with confidence and conditions: "I would plan for 30 September at roughly 70 percent confidence, assuming provider approval by 15 August. If approval slips, the fallback is manual export or a later launch."
Then show the trade: reduce scope, add experienced capacity where work can parallelize, or change the date. Adding people does not automatically shorten tightly coupled or unfamiliar work.
Practice estimation as a reviewable artifact
Choose a feature you shipped and estimate it again without looking at the actual duration. Record scope, work breakdown, range, assumptions, and checkpoint. Compare with what happened and classify the miss: omitted work, changed scope, dependency delay, technical surprise, or execution variance.
In interviews, finish with how you track actuals and re-estimate. Teams need an estimate that improves as they learn, not a confident number that becomes harder to question.
Try this checklist
- Practice one feature estimate and one capacity or scale estimate.
- Prepare an example where you changed an estimate after learning something.
- Explain the estimate in two minutes without hiding the range.