How do you effectively work on multiple projects at once?

Multi-tasking is a spectrum that is denominated by time-span. Extreme multi-tasking is literally switching between multiple tasks within the same hour, which is what you're doing. A more reasonable multi-tasking level which I think you should aim for is dedicating certain days to tasks, making your multi-tasking at a weekly level (Monday/Tuesday is Project A, Wednesday - Friday is Project B). As a junior engineer, it will be a lot tougher to multi-task.

If you are going to aim for a daily multi-tasking throughput, try to spend at least a couple hours on a single task before moving off as Charlie mentioned. Focus blocks are tremendously powerful at your career stage for deep productivity and learning.

My suggestion is for those 10-15 minute waits, you should review someone else's pull request (this was my go-to when I had these small time blocks). Other things you can do are going for a walk around the office (given that you're at Amazon, I'm accounting for 5 day RTO here), talking to a teammate (small talk, task alignment), or doing some writing (updating brag journal, setting 1:1 meeting agenda).

Here's another good thread as well: "How to improve at multi tasking at work?"

If you have 10-15 minutes between builds, I'd recommend spending your brain cycles in anticipating what will happen next. Like, literally write down on paper:

• If the build succeeds and has the functionality you expect, what will be the next step?
• If the build succeeds but is functionally incorrect, what will be the likely reasons?
• If the build fails, what will be the likely reasons?

I did this while waiting for very long build times at Facebook (the Portal org), and it was very effective 🫡

There can be many ways people would prefer, but I doubt any of them would be jumping and changing context every 10/15 mins.

Personally, depending on the type of the tasks, urgency, and size, I would give say a fixed percentage per day, then split the days accordingly. If the build/deployment times are taking an hour or more, it makes sense then to switch, otherwise I would invest this small time into pushing my changes to an unpublished CR, getting the hosts ready for testing, etc...

Context switching is expensive, do it wisely, as en entry level SDE, you need to deliver work, too much of that will prevent you from even delivering the smallest tasks, and getting accounted for that.

I agree with @amazonsde about trying to limit the context switching. If you are juggling two work streams in your head at the same time, can you really focus on one of them? In the past, I've tried to parallelize two different work streams because one had a long build time, and probably 50% of the time, I would be too focused on the other work stream and forget to check when the build was finished. And, if I did try to keep both in my head, it would prevent me from getting fully focused.

If you have split up the tasks for each work stream into tasks that take 1-3 hours each, you can finish a task first before switching to another work stream.

There were periods of time in my Staff engineer role when my work day got extremely fragmented. Here's how I used 10-15 min blocks:

1. Read some code that was recently merged.
2. Familiarize myself with new Datadog dashboards to learn more about my own systems or adjacent ones.
3. Read TDDs/ADRs from adjacent teams that asked for my inputs or to learn about other systems at the company.
4. Catch up on eng-excellence type channels and read an article or two shared there.
5. Catch up on shipped type channels and take stock of the newly shipped features.
6. Respond to backlogged DM's with coworkers discussing topics of interests outside of the immediate workstreams.

You will notice that, in none of these tasks, I was actively accomplishing a parallel/competing task. OTOH, I was using this time to squash other myriad misc tasks that would otherwise keep me from focusing on my primary tasks.

These tasks are "small" in nature, so they keep you from getting sucked too deep and losing track of your original task. Left unattended, these tasks pile up and create backlogged requests from others/anxiety/FOMO, all of which are detrimental to mental health—and erode the feeling of being "in control" of your surroundings.

As an entry-level SDE, your list of misc tasks will look very different, but the above list should give you an idea of what it should look like for you.

A few other finer points in what you wrote:

1. You mentioned "silly mistakes." Can they be avoided using a linter, etc?
2. Also, are you in the habit of doing a static walkthrough of the final version of your code before putting up your PRs? Doing this does take an extra 10-15 mins (or more depending on the size of the changeset), but it has almost always helped me catch typos, unfit variable names, incomplete comments, etc. that reviewers would otherwise comment on (and I'd feel bad about). Sometimes, static code walkthrough has helped me catch minor bugs that I'd missed in both logic and unit tests! I can't emphasize the ROI on static code walkthrough enough.
3. When multi-tasking, switching between multiple codebases is almost never a good idea as there's just too much context to carry in your head. Mistakes are inevitable. It also breaks your flow very badly if the different codebases are in different languages!

Hope this helps.