How do you estimate how long a task will take?
Break the task into small pieces, estimate each based on similar past work, add time for testing, reviews and unknowns, and share the estimate as a range with your assumptions. Update it as soon as you learn more.
Explain it simply
Freshers usually underestimate, because they think only of writing the code and forget understanding the requirement, testing, review comments and surprises.
List the steps, estimate each, compare with something similar you have done, and add a buffer for the unknown parts. Give a range ("three to four days") and say what it depends on. If you find something unexpected, update your lead early rather than at the deadline.
Example
Situation: In her internship, Snehal was asked how long it would take to add a "download invoice as PDF" button.
Task: Give an estimate she could actually meet.
Action: She broke it into understanding the invoice data (half a day), trying a PDF library (one day, since she had never used it), building the button and API (one day), testing with different invoices (half a day) and review fixes (half a day). She told her lead "three and a half to four and a half days, depending on how easy the PDF library turns out to be".
Result: She finished in four days, within her range, and her lead started asking for her estimates in planning.
What to say in the interview
"I break the task into steps, estimate each from past experience, add time for testing, review and unknowns, and give a range with my assumptions. If something changes, I update early."
Common mistakes
- Estimating only coding time.
- Giving a single optimistic number.
- Not updating the estimate when you discover a problem.