What do I do if I don't understand the task at work regularly?

Can you bullet list the actions that you take from the time that you receive a task to the time that you meet for the second time?

You might be having a mental roadblock where you are feeling completely frozen and not sure what to do at all because the task sounds overwhelming. You might just need to do something, anything. I would start by taking 10 minutes to just summarize what you think you need to do to accomplish the task with the expectation that you could be completely wrong. The goal is to just have some path you can take and execute on rather than keeping everything in your head. When you do this, it's easy to dwell on the imagined impossibility of the task.

Once you have this path, I would have a casual conversation with your senior engineer to make sure you are on the right path.

1. You'll have done the work by taking the initiative since you came up with a plan. If you didn't do the prior steps, you won't grow as an engineer, and your senior engineer might get irritated because you've just unloaded all of the work to them.
2. They can help you identify any flaws or mistakes in your plan.

Now, you'll have the high level idea figured out, you just need to execute.

Do you find yourself just frozen in your code editor, not sure what to do? Start by just adding log statements and trace through the code. This is better than just doing nothing. Remember that you are coding in a local environment, so you can treat it as a sandbox where nothing bad can happen.

You need to clearly define what you are trying to do. Write down the different approaches you've taken, why you think they should have worked, and why they ended up not working. Then, you can bring this to your senior engineer to try to figure out where your assumptions might have led you astray. You can categorize where your deficits are: not understanding the codebase, not understanding the programming language, etc.

It also sounds like there's a sense of imposter syndrome. Try not to get too caught up in where you are now, but try to look at where you could be in 5 years if you just get the reps in and learn a little bit more each day.

Can you keep a diary of all the questions you ask the senior engineer in the next 2 weeks? And also write down the answer you received.

Then do some reflection and ask yourself the question, "Was there anything I could have done to have answered this on my own? What resources could I have used?"

I highly recommend going through my answer here as well: How should I respond when I have no idea what a person is talking about?

Resource: [Masterclass] How To Learn Quickly In Tech

Building on top of the existing advice, I'd also recommend that you start narrowing down on where you're publishing your paper trails at. Often times, if there's no visibility (no easily accessible public artifacts like comments on tickets, design docs, documented weekly updates) on what your process/progress is, your broader stakeholders will often assume the worst case scenario that you're slow and inefficient. Try to identify how you can communicate/document your progress in a more public manner: whether it's by posting regular comments in tickets, asking more clariying questions in public channels in your company's internal messaging app, or providing more granular updates in standups. This will also benefit you individually in the long term as information you've encountered in the past will be more readily available to you (and anyone else who's interested), allowing for a quicker turnaround time when you need information from the past.