Absolutely, remote work opportunities do exist, though they may be harder to find compared to traditional positions. Throughout my career, including as a junior, I've exclusively held full-remote roles. That's before covid. While the current market shows some resistance to remote work—largely due to the return-to-office (RTO) policies of major tech companies—there are still options available for those seeking fully remote positions. The trick is extreme flexibility in other areas. For instance, if you're on the east coast you might have to agree to holding standard PST hours, or if you normally might make 150k you may have to settle for 120 but a larger bonus if you hit your target goals. etc

First off, it's a good start! Welcome to the closed-source community. 😂

Here are some thoughts based on what I see:

If you have a LinkedIn profile, be sure to include it, and consider linking to your GitHub as well.

I really appreciate your GitHub; it clearly showcases your hard work and commitment to engineering. Your contributions to open-source projects are impressive and can attract attention from those who may not delve into your resume. To maximize visibility, consider adding a direct link to your GitHub and elaborating on your open-source work.

Additionally, some of your descriptions are a bit too technical and could benefit from clarification. For instance, terms like "refactored code" should include details about the codebase's size and the challenges you faced. Metrics can also significantly enhance your resume; while I understand they can be difficult to gather, even rough estimates can be useful. For example, if you gave a talk, mention how many people attended and whether it was well-received. Lastly, clarify phrases like "enabled mapping referenced content to correct URLs"—was this part of a web application? I'm not sure what this means.

Best of luck my friend!

Alex hit the nail on the head. If it helps to hear it from a Googler, this advice is spot on. Remember Google's mantra of small code commits; it's not just about the volume though! The quality of your CL (change list) comments is crucial, so ensure everything is addressed before submitting anything for review. Avoid submitting CLs prematurely, and focus on best practices for the programming language you’re using. Google's "Tip of the Day" series in Moma is an excellent resource for this.

Additionally, keep track of your average time to review others' CLs. Aim to make your reviews manageable, ideally within 24 hours. With these practices in place, you’ll be in great shape!

Good luck!

I think this is mostly just a framing issue. You could ask for challenging projects on day one, and it wouldn't be too early if you framed it correctly. The most important thing to keep in mind is how you frame it.

Instead of asking for more challenging projects that will help with a promo, consider looking into areas people don't like about the codebase and find meaningful ways to improve it. Does the testing architecture need work? How’s the CI/CD pipeline? Should a part of your app be asynchronous when it currently isn't?

These are the kinds of headaches you can solve for other people. If you come to your manager with a problem you've noticed and a solution to fix it, your manager will appreciate that.