It is not uncommon for EMs to be involved in technical decisions even in Big Tech. Many new EMs are pretty hands on and like to be close to technical details until they can't manage to be. However, just overriding a technical approach proposed by engineers is problematic. Finalizing a solution should be a team decision and the tech lead should be consulted with before deciding on a different approach. Totally agree with Alex about keeping the EM in loop from the beginning and seeking early feedback. It would help to have the solution approach in writing so that all the feedback is recorded and can be referred to later. 

Senior Software Engineer [SDE 3] at Amazon

Vaibhav Jain

Adding to the list provided by Rahul:

- Be attentive in meetings and contribute by asking good questions and providing suggestions
- Conduct knowledge sharing sessions on your work or other things you think would be beneficial to the team.

I have seen a lot of indie makers utilizing reddit and X (twitter) for promoting side projects. For X or any other social network, you'd need a following but you can use some popular hashtags to get initial attention. Another way is to start sharing your journey / progress on the side project on the X (twitter) to get people interested.

First of all, since you joined only an year ago, don't be demotivated by not getting promoted. If there are others in the team who have been there longer, they have an advantage over you. 

Secondly, looks like you already have some high-level feedback (" not assertive, opinionated, and take more time than usual to complete ambiguous tasks") It's time to dive deeper into it and figure out how you could improve on these. Ask specific questions to your manager like what you could have done better in a particular situation. Also, learn by observing other engineers.  This could be just an issue of perception as well which is critical for promotion. 

Some tips that might help you:

- Actively participate in meetings by asking good questions and suggesting solutions / improvements
- When you propose multiple solutions for a problem to the team, always go with a preferred solution (based on data of course). Be willing to change your approach later. But don't always depend on others to help you decide.
- For ambiguous problems, try to gather as much data as possible initially and come up with a solution. Don't wait until all the data is available because that might not happen. Make changes to your solution iteratively as more information becomes available
- Work on promoting / selling your work. 

Hope this helps.

I agree with Nicholas that you could be selling yourself short. Some of the things you can do to identify your strengths:

- Look at your past projects and achievements and reflect what qualities helped you achieve them. I am sure you will find atleast a few

- Talk to your coworkers to gather feedback.  Look at your forte review. 

- Think about what motivates you, what you are passionate about it. This could be code quality or customer experienece or something else. This might already be your strength or can become one if you focus on it. Strengths can be developed over time.
- While the leadership principles sound conflicting, think of them as guidelines and apply them based on the situation. You need not be demonstrating all of them but it's good to keep them in mind in your day to day work. 

Overall, as long as you are working on improving yourself, you will do great. 

Hope this helps.








It wouldn't harm to send a follow up email if you think it would increase your chances of getting an offer. Worst case they don't consider your responses for their decision. Best case you get the offer. In your email remember thank the interviewing panel for the experience and their questions.

From my personal experience, sometimes recruiters are willing to share more direct feedback on a call than on an email. I'd definitely use this opportunity and ask specific questions about where you could have done better and where you failed like Alex suggested.

Best of luck!

Casey provided excellent advice on increasing technical influence. I will try to address your other concern of trying to understand a large code base. Here are some tips:

- Use your product to understand what features it provides and how they relate to the codebase. This will improve your high-level understanding.

- Reading existing documentation on requirements and design. Even though these might be out of date, it'd help you understand the core concepts which will make reading the code easier.

- Read through the tests to understand the behavior of the code. Tests are the most up-to-date documentation of code.

- Start making minor refactors on the code base like renaming functions and variables, making functions smaller etc. This will make it more readable and can also help you understand it better.

- Pick small tasks (feature updates, bug fixes) dealing with a single feature/component. As you work through these tasks, your understanding will gradually improve. This is the most effective way to understand a piece of code thoroughly and make it stick.

Hope this helps.

Like Rahul mentioned, don't be shy or afraid to ask questions. Since you are onboarding, this is the best time to ask as many questions as you can until you understand the topic clearly.  Every engineer is in the same boat at some point in their career. Here the following things you can do:

- Ask the question right away
- Note down the question and ask it later
- Tell your teammate politely that you didn't understand the topic well enough due to missing context and ask for resources/ docs to help you. Then you get back to them later with better questions
- Reach out to other people to talk about the same topic. Sometimes the way of explanation makes a lot of difference 


Hope this helps!

You can utilize ChatGPT for getting an idea of the kinds of questions and follow-ups that can be asked but it can't simulate a real-world experience. As far as utilizing mock interviews is concerned, it depends on what you need help with. I'd suggest scheduling one of each type of interview and then evaluate your preparedness. 

Congratulations on the promotion! Here's my 2 cents:

- Amazon has a well-defined role guideline for all levels. Keep that in mind and evaluate your work against it periodically.
- In addition to thinking about individual deliverables, start thinking about the team. Think of ways you can help the team to be better - this could be by sharing knowledge, improving processes, promoting best practices.
- Maintain a journal for all the work that you've done. This would be handy during performance reviews.
- Learn to promote your work and gain visibility, especially outside of the team.
- Try to be a mentor to L4 engineers and help them grow
- Get a mentor for yourself if you don't already have one

I am not sure if expertise in a certain set of tools should be considered a transferable skill given that new tools keep popping up all the time in the software world and there's a lot of variation in toolset from one company to another. There's a reason big tech companies focus on problem solving and behavioral traits during interviews and not on the technologies you've worked with. For a software engineer, some examples of transferable skills are problem solving, good communication, responding well to feedback, ability to break down a problem into simpler tasks and quick learning. 

For an entry level job, I'd suggest keeping an open mind and exploring different areas. Apply to as many jobs as you can , talk to recruiters and hiring managers and see what interests you. If you like mobile development , by all means go for it. But I am sure for an entry-level job they won't expect you to be an expert in it. So instead of waiting around to gain expertise, keep giving interviews. That way you'd get a sense of what is expected of you and you'll get better at interviewing.

Best of luck!

If your goal is to grow as a Software Engineer, you'd be better served by finding opportunities for writing code and getting better at it. While working on side projects can be helpful, it's not a proxy for coding experience at the job.

In addition to the great advice provided by Jonathan, I would also recommend having team-level discussions and knowledge-sharing sessions about high quality PRs to establish best practices. This should reduce subjective disagreements about code quality and also help junior engineers in improving their PRs and commit less mistakes in future.

Looks like you are new-ish on this team and as such your first priority should be to gain trust of your manager and your team that you can deliver with quality and speed. This can be tough when you're blocked and pulled into different directions. I have a few suggestions:

- Make sure that your manager and your team knows that you're working on all these different tasks. 
  - Communicate more , both in-person and in other channels of communication. 
  - Make your undocumented tasks visible by adding them in your sprint board.  
  - Share your learnings with the team.
- Prioritize the tasks assigned to you and make sure that you maintain the quality. It's fine to help others when you're blocked but don't do it at the expense of your own tasks.
- Try to find ways in which you can help others without spending too much of your time. For e.g. documenting common knowledge or best practices instead of repeatedly having conversations about them.

I hope this helps. Best of luck.

Other answers have already provided excellent advice here. I am just adding my two cents here. You can add value to meetings not just by providing insights but also by asking good questions which can then help you and others get better understanding of the topic of discussion. Good questions can help uncover insights which were being overlooked before. Showing interest in the meeting is also participation. I'd recommend starting with a mindset of curiosity and letting your questions guide the way. 

I would also recommend selecting the "Open to new opportunities" (not the badge) option on Linkedin and optimizing your Linkedin profile so that you rank higher in searches done by recruiters. Also, put effort in your resume which you send out to recruiters to increase the chances of getting a call.

Best of luck!

Totally agree with Alex's advice here. If you think that you ultimately want to take an SDE role, better to start working on it now and start having conversations with your manager. Also, I have seen an L5 support engineer switching over to L5 SDE during my time at Amazon. He did have to work on some projects to present his case. As long as your manager is willing to work with you and provide you opportunities for the switch, you shouldn't have to downgrade your level. You also have the option to switch teams to make it happen. It would be helpful to talk to some other engineers who had made such role change.

I and I am sure a lot of people here will relate to your feelings. Whenever we are out of our comfort zone, we feel that things are out of control which can be quite scary. Additional responsibilities can be quite stressful. However we should embrace this as a learning and growth opportunity. Trust your abilities and rest assured that you'll get through this and come out stronger. Here are few recommendation that might be helpful in reducing stress:

- Try to gather as much information about the team and product as possible by going through documentation and talking to people. Take notes about what you understand and what you don't understand. Don't be afraid of asking questions. 
- Seek guidance from tech leads in other teams. Ask for samples of OKRs and roadmaps. This will give you some clarity on the expectation.
- Write drafts with your proposals based on what you know and seek feedback from your manager and other experienced tech leads. Revise the drafts based on feedback and based on new knowledge. 
- Talk to your manager frequently and update him on the progress you've made and any blockers you are facing. 

I hope this is helpful :)

I am not sure in what capacity you are working on the team because the answer might vary a little based on your role. However, you need to be clear on what level of abstraction you are working on. Being involved in code reviews for all the projects might be feasible for senior engineer but not for the SDM. If you want to get a good understanding of the systems being built, getting invited to design reviews can be really helpful. For changes happening later on, you can sync up with people owning the projects. This way you can have a good mental model of the systems and how they interact with each other. 

I would suggest having a clear communication with your manager about when he/she thinks you'd be ready for a promotion and what are the gaps (if any) and how can they be addressed. If the manager thinks that there are no gaps and that you're ready for promotion, you can mention that you would lose motivation if you are not promoted this time since you've been working hard for it. I am sure your manager would get the hint from that. You can be more direct with your manager if you already have an offer from another company but I am guessing you don't have enough time for that.

As a software engineer, you are more than just your code. As the person bringing the product to life, you are uniquely positioned to have a strong influence on its direction. In fact, it's extremely important for very senior engineers to get to know their PM and develop strong product intuition.