Who do you help, given there are only so many hours in the day?

This is a really interesting question, and I've actually seen this across several E5s. Here's my many thoughts:

Sometimes people would delegate grunt work like asking me to test their PRs that do library upgrades instead of testing them themselves.

This is pure laziness on their part: Definitely tell your manager about this, so they can pass along the feedback to these people or to their manager. If you have DMs, you have hard proof to support your case. DoorDash is a huge FAANG-level company: This behavior simply doesn't meet the engineering bar for an institution of this caliber.

As an E5, you need to be very selective about what you spend time on, looking for opportunities that are either wide (e.g. help 10+ engineers with some common technical issue) or deep (e.g. helping a junior engineer fix an extremely complicated bug they have 0 chance of figuring out themselves). Testing a PR is something the code author should be doing themselves when writing their test plan.

Or asking me to debug their dev environments because they heard I fixed another engineer's dev environment.

If you can do this at scale and have the time, this could be an E5-level project. Maybe you can make a wiki on common dev environment issues that you then route everyone too. The next level would be writing some sort of fixer script DoorDash engineers can run that auto-fixes common issues (we had this back at Meta, and it was awesome).

Sometimes it'll just be asking for expedited code reviews even though I have no domain knowledge on their PRs. We work on the same platform, but are not on the same team or often even the same org.

You should probably politely decline these, but if you aren't, here's a great discussion to help: "How to give better code reviews without full business context?"

How do you decide who to help and under what circumstances?

We cover this in-depth here: [Masterclass] How To Build Deep Relationships Quickly In Tech

In a nutshell, you should help:

1. People who have really helped you before (obvious)
2. People critical to your execution (e.g. an E6 engineer who needs to sign off on your system design decisions)
3. People you're formally mentoring

These 3 groups are often overlapping (e.g. an E4 mentee who you need to delegate work to on projects, so you can focus on the higher-level).

Advice on how to push back without damaging the relationship?

Saying some variation of this should work: "Sorry, I really wish I could help, but I'm just way too busy right now shipping project X. Try checking out this wiki or reaching out to person Y for help instead!"

I recommend going through this for more tactics here: [Course] Effective Communication For Engineers

Alex has a great answer, I just wanted to comment on this:

asking me to test their PRs that do library upgrades instead of testing them themselves

This feels bad, and I'd strongly suggest you not to spend time on these kinds of requests. The way I'd push back on these is to say something like: "You have a lot more context here than me. If you have questions, add them in the PR and I'll make sure I take a look."

This way you're making clear that they can't simply offload their grunt work to you, but you're available to support them if they put in some effort.

On a separate note, I went through something similar-ish back when I was the Android tech lead at Instagram Ads and we went through a hiring boom. The request quality was probably higher than yours, but the core point was that I had a lot of people asking me for help all the time, and it was overwhelming.

The main mechanism I used to alleviate this was holding group office hours, similar to what I do for Taro. For 45 minutes each week, all the Instagram Ads Android engineers would come together and ask me questions. I would make someone in the audience take meeting notes, and I would share the meetings notes afterwards. After ~1.5 months, the newbies were pretty onboarded, so I stopped doing them.

This is a multiplicative, communal way of solving the "Too many people want help from me" problem and is the kind of behavior I would expect from an E5 or higher engineer. I got a good amount of credit from the team and my manager for doing these office hours, and the time investment was pretty minimal. This is something you can consider as well - You can run it by your manager.