It comes down to experience really.  The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates.<p>If you don&#x27;t have a spec, get a spec.  A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements.<p>Sometimes you need to do research to give an estimate.  If someone asks you in person, or over e-mail, and you honestly don&#x27;t know ask them if you can get back to them.  Do not give them a number.  Do the research, then reply.<p>If you&#x27;re relying on external APIs or Frameworks etc.  You need to factor in Risk Assessments that include what happens if the fit is wrong, or the interface changes mid project, etc.<p>When it comes to debugging a lot comes into play, system design, documentation, experience with the code.  &quot;I don&#x27;t know&quot; is an acceptable answer until you understand what is going on.   Once you understand what is going on, you then estimate the fix based on the code.   Giving a number before you understand what you are fixing in detail is a bad plan.<p>I am exceptionally experienced with a certain code base and system.   You may be experienced with a different code base.  You&#x27;re more qualified to handle estimation on what you know.  That said, if you honestly don&#x27;t know, say that.  Don&#x27;t low ball the amount of work if you actually have no idea how long it will take.<p>There are a few good books on estimation and debugging, look around maybe they&#x27;ll give you a few ideas.