Android and mobile development as a whole is something I'm very interested in. For example, I see the Taro Android app, and it's pretty smooth and performant while being built quickly. What can I do to get to this level?

This half I've been assigned to a new greenfield project and I'm having a tough time believing in the product idea and I think the product team is being overly optimistic.

I'm concerned the problem the product solves isn't important enough, that the solution won't be adopted and that the business value isn't clear. They're also pushing for rushed timelines even before we've decided on what will be delivered.

I'm worried if this thing doesn't get traction and we end up having layoffs that it would make our team a target.

How should I think about this situation? Try to make the best out of it? Try to get out of it?

What to do when you don't believe in a new product you're assigned to?

Here are some thoughts from me:
1. Freshly promoted to Staff - This means they are very close to the same path that I'm on.
2. Not within my org - To remove bias
3. Smooth conversation - So it's easy to talk with them

Do these make sense or is there something I'm missing?

How do I find a proper mentor within my company?

My goal is get promoted to senior [5A], and I'm currently working remotely. My manager is okay with me working remote only, but the promo committee might not be as Uber leadership overall is investing into RTO, and my team has gone back to the office for the most part. Do you think this will hurt my chances, and if so, any tips on how to navigate the situation?

My work will often times span across multiple services within Uber, which means that I need to write code in codebases outside of my team's. Sometimes when I do this, it takes a long time for my commit to land as there's many rounds of follow-up questions, leading to a lot of rebases, revisions, and time spent on my end. I understand that they're trying to be the best stewards of their codebase, but this can be a bit frustrating sometimes. How can I make this process smoother and land these kinds of changes more quickly?

How to get commits merged in faster when changing other teams' codebases?

So within my own area of the codebase and tech stack I own, I'm very comfortable and confident leaving feedback and sharing thoughts. However, I know that in order to grow to senior, I need to expand past my immediate area into other spaces like the components and services built by other teams in my org like sister teams. For those areas, I'm unsure how to share my thoughts since I'm not an expert in those codebases. So let's say I come across a code review from one of these more "separate" areas from my own and the engineer behind the diff is more senior than me - How can I leave my feedback in a way that respects the situation?

How can I share my thoughts on domains I know less about?

Additional questions:
1. What tactics can I use to get buy-in?
2. Who do I need to win over? Do I need to convince the director?

How do I sell the vision behind a large, org-level project?

Uber is an American mobility as a service provider, allowing users to book a car and driver to transport them in a way similar to a taxi. It is based in San Francisco with operations in approximately 72 countries and 10,500 cities in 2021. Its services include ride-hailing, food delivery (Uber Eats and Postmates), package delivery, couriers, freight transportation,[2] electric bicycle and motorized scooter rental.

Uber

Mid-Level Software Engineer [4]

Start with what you know. Sometimes the best code reviews I received were from an engineer coming in from another part of the stack, since their perspective was novel. For example, you could say "In the Android side, we centralize the JSON validation in one place at the networking layer, so the product teams don't have to do null checks. I'm curious how you handle that here?"

Another tactic I like to use is to end almost every code review comment with a question mark. This leaves room for you to be wrong, and is much more about learning rather than a declaration. This is especially important in this scenario since you're entering into a new codebase where you may not be as familiar.

Meta, Pinterest, Kosei

Rahul Pandey

At the end of the day, working in tech, or anywhere really, is all about working with other human beings. Communication is the core skill necessary to make this collaboration effective.

Mid-level engineers have very strong technical proficiency, able to execute on small to medium-sized projects with minimal hand-holding, leveling up from junior engineers.

How can I share my thoughts on domains I know less about?

Uber

Discussion

Uber