If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements.
Sometimes you need to do research to give an estimate. If someone asks you in person, or over e-mail, and you honestly don't know ask them if you can get back to them. Do not give them a number. Do the research, then reply.
If you'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.
When it comes to debugging a lot comes into play, system design, documentation, experience with the code. "I don't know" 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.
I am exceptionally experienced with a certain code base and system. You may be experienced with a different code base. You're more qualified to handle estimation on what you know. That said, if you honestly don't know, say that. Don't low ball the amount of work if you actually have no idea how long it will take.
There are a few good books on estimation and debugging, look around maybe they'll give you a few ideas.