Because you are a SWE, your first though would be technical, ditch that, the problem is there. If the requirements are not defined, this is your first job then.

You have to reach out to the stakeholder, identify main headlines, fill with assumptions, and split into milestone.

What you have now is something that may be 20-40% correct, then use it to circle back to the stakeholders, challenge what they say, let them correct it,  it's a lot easier going with something already written, even if far from what they want, other than going with nothing and asking for requirements.

I can guarantee you, by this point, you might have something that's \~70% accurate. Go back again, and get their signoff. At this point, they will be willing to agree on that.

You will not get 100% complete requirments from the first phase, or even the tenth! So live with what you will have at that point, buffer for some last minute changes, and iteratively start the design. Good luck!

SDE @ Amazon

anamazonsde

Be natural, honest, and prepare carefully all situations you can think of.

Every interviewer will normally have backup questions in case you don't answer the main one, and they will try to gather all data points they need by followup questions.

I wouldn't say you must do the STAR method or anything, but as long as you show the situation 20%, your role 60%, and the impact/results/metrics/feedback 20%. That will be more than enough!

I would be very clear and honest, just state things as they were, the question seems to assess your ability to deliver tasks, but it also assesses things like how you overcome obstacles, how you communicate progress to stakeholders, etc...

So, just being clear and direct helps you and the interviewer, not every questions is bombed with hidden targets.

I think you need to separate 2 things here, imposter syndrome, and manager transparency.

About the imposter syndrome, I think it's totally normal to feel this way being a new grad and a new member in the team, if this stays with you after 1 year, then you may want to address it, otherwise, just keep learning from everyone around you, and take every chance to do so.

Regarding manager transparency: IMO, it all depends on 2 things, **Trust** and **Respect**.

If you fully trust your manager, and you both have a good respectful relation, then I would be totally open with things I would not be with other managers, think looking for other opportunities, looking for outside mentors, etc... This ensures you gets a sincere advice, and makes sure he is also in the know to make sure he reaches out to hire a replacement etc.. And most importantly, it helps keeping the bridge solid.

I am sure you will get a lot of good suggestions from other Taro members shortly. But I wanted to comment on one thing.

I saw all the issues that you mentioned as a **HUGE** opportunity for you, you don't need new members to mentor, you can mentor existing members by just enforcing/encouraging the code review culture, and helping ease/automate it.

You could build small tools for your team to automate the tasks that you don't want other team to do, so even though you execute them yourself, it can take seconds instead of minutes/hours.

Regardless for your decision to leave or stay, I would look very positively into these gaps and start investing time into that from now -and may be also involving some like-minded SWEs to participate with you-, leave your touch and signature. Will be a great legacy if you leave, or a huge accomplishment if you decide to stay.

Congrats on getting the offer!

First of all, don't worry, you will have enough opportunity to learn as you join and onboard correctly. 

Normally you get training materials when you join, sometimes that will include also courses on technologies,  languages, etc... It depends on the team, but generally you get some room.

I would advise you to reach out to hiring manager that you will be joining for, ask for what to learn/study, he will most probably be happy to provide some pointers for you, or at least mention the key technologies that you will be working with.

Good luck

Yes, it happens, but I would say it's more common to transition to TPM.

It always doesn't hurt to try. I would attempt it for sure.

Thinking from a future perspective, higher pay helps in your plans for entrepreneurship.

But, you leaving on the table Amazon name in your resume, huge learning opportunity, and most importantly, **exposure to product**.

I would not worry about team culture, leave that to when you actually get placed there, and it's not hard to change teams inside Amazon.

Regarding your questions:

1. It matters a lot, it gives you relatively high pay, and possible exposure to product teams, and working closely with them.
2. You typically don't have control over placement once you get in, but if you are in good standing it's very easy to transfer internally.
3. I haven't moved to entrepreneurship role, but I have worked in both FAANG and smaller companies. Smaller companies best trait is speed, FAANG companies excel in all (Learning chances, higher exposure, huge scale...)
4. Typical oncall load, average time for SDEs in level within the team, and type of product they work on (product/cost centre)

Interviews are not coding competitions. Many interviews don't even run the code. 

Interviewers want to know your thought process, want to know if you know all the ways this can be done, and that you know how you would choose between them depending on the need, and then you are able to implement at least 1 approach.

I think knowing and dealing with constraints might be more helpful in the initial online assessments that include a problem or two from hackerrank or similar platforms. 

SDE @ Amazon www.anamazonsde.com

You were taught wrong. What they are doing is right. 

Helping others, among all other benefits, ensures better advancements for all parties, unleashes sharing other point of views and experiences, and helps people know someone who they trust their opinion.

Everyone is different, sharing some knowledge doesn't mean others will take better advantages of it, and even if they do, that means they can learn, which is something you can do well by learning from them.

Above all, it brings personal joy, you can't imagine how it feels when you help someone and you see what your help has got them. 

I don't think there will be significant shortcuts here. The 5 items you added above are basically the core skills as you mentioned, to learn them, it takes time, practice, and failure. It's a good thing to not only rely on tutorials/reading code, but also just paying to  pair with someone it not going to cut it as well.

Given your current circumstances, I would try to look for opportunities for participating in open source projects, get involved, create PRs, get pushed back, ask for clarifications, and learn from all that and iterate.

Look for internship opportunities, volunteer to work on a project you like, all these will give you the real ladder you need to step up, **practice**!

Here are some tips to start with each of the items:

- **Break down ambiguous problems**: Understand the problem first at a higher level, what is the problem? What are you trying to solve? What are the KPIs for success? Then try to break it into meaningful components/sections, the for each one, iterate and do the same.
- **Debug systematically**: Start by reading about different ways, you will be surprised to know that the most efficient is still the `printline()` calls!
- **Research and evaluate solutions**: When you break down the problem into meaningful sections, each of these sections needs ways to solve it, find 2 or 3 ways, write pros and cons, make sure you get a balanced list, then compare these pros/cons with the original problem, what is the most important aspect? Time? support for X options? These questions will help you choose the right decision for each component.
- **Think about edge cases and architecture**: These are 2 different things, architecture comes at a higher and more abstract level, edge cases are more common at lower levels. Try not to mix it, otherwise you will complicate the architecture and end up with over engineered solution.
- **Navigate and understand large codebases**: Generate class diagrams for the code, it will help you visualize it, try to write a documentation for the code, try to add some small refactors.

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.

If the best language you know supports basic data structures and classes, use it without hesitation. If that best language was python, a lot better. But don't use python on it's own unless it's your best skill.

In the interview, you are expected to produce code, and communicate your thought process to the interviewer, having to do so with a language that you don't touch daily, and only use for interviews, might send negative signals about how comfortable you are implementing code.

You **will not** be judged in the interview by which language you use, but you **will be** judged if you use one as your best, and then struggle to remember how to add items to a stack.

**The best interview skill to acquire is to be a great SDE.**

Interview preparation is something you need every now and then, and for a limited time period. While being in possession of great SDE skills, is a lifetime benefit.

So I would say, work on your self, get better, and prepare for interviews in the same time, just don't get sucked too much into it, that you forget the actual goal: **Change companies to help you be a better SDE.**

First off, you can start by exploring the [system design topic courses](https://www.jointaro.com/topic/system-design/).

But, it's also not common to have new grad tested for system design, so I would also study and practice on LLD/UML/Class diagrams, in case your question ends up being lower level design for a system.

I think you need to separate 2 things here, getting a job at FAANG companies, which are available in many locations not just the US, and getting a job in a FAANG in US.

Getting a job in one of the FAANG companies is indeed hard enough, but doable, you just have to 1) Prepare and learn needed skills, and 2) Understand exactly what they are looking for.

I see a common problem where people train for Leetcode for months, then say I did great in the interview, and still got rejected. That is mainly because they don't realize that behavioural is equally important in FAANG companies as the technical skills, they also fail to see that knowing how to solve the problem is one thing, and showing your thought process and sharing it with the interviewer is the key there.

So, I would advice you to:

1. Decide the goal that your looking for first.
2. Continue working on your technical skills (DSA, problem solving, etc...)
3. Start applying NOW!
4. If you fail in the next interview, assess, and repeat.

I can assure you, starting to apply while learning is the best mechanism to know where you stand and get a real-world assessment for yourself. 

SDE @ Amazon - www.anamazonsde.com

Yes, don't limit your self to planned work! For every SW team, there is a constant effort in operational work, tech dept, and unplanned migrations.

Book a constant percent of your time, look around, there will be a lot of areas for optimizations, new ideas, and great POCs, just keep mining for impactful changes, look for cost optimizations, operational enhancements, or new unfunded ideas that you think will have great impact.

Don't spend too much time on that though, if it succeeds, you will be having all the credit, but if it goes bad, you will be asked for that time.

Failures is how we learn.

I guess the biggest lesson I would see, is that, being senior, it's a part of your job to lead the team to success and lead by example, now there are cases where hardest work with certain teams would not get results as well, but I have seen in many times that just applying that effort into making sure the tech team does their best, and gets an opportunity to learn and deliver impact always pays off.

I don't know the exact specifics of that work your team did, and I trust you already are judging in a fair way, but I would also advice to be cautious of falling the trap of blaming others for dropping the ball etc..

Tbh, I don't think this is a bad feedback, it's an honest one, and shows also you deliver good results with high speed, and after identifying a problem (keeping stakeholders out of loop) you managed to align/fix that as well and deliver high quality work.

There is no perfect feedback or reference, and you won't be there listening to what every reference will say about you, I think your manager cared for you to let you know as well.

Good luck! And take it easy, it's a minor step, you already passed the hard ones.

Yes, it's said that people can get PIPed as well to fill the quota. It's also said that they do their best to ensure only really low performing people get it.

However, again, I think this should not prevent you from getting there, you are leaving a lot of benefits on the table out of fear of something that happens to a few people with very specific conditions.

I can help answering the Amazon part. First of all, as you mentioned you are a hard worker, that means you should not fear getting PIPed, as mostly hard workers are safe from that.

On the other hands, one of the main reasons to get PIPed, apart from not working of course, is **lack of good communications** and **bad relations with the team** members. I have witnessed these traits cause many people to go into Focus, then end up being PIPed.

At the end, I wouldn't worry if I were you, I feel like in Amazon you will be pretty safe, as also L5 is a terminal level. Good luck!

I would say you should look into the option to get into bigger companies, FAANG is not the only group to join, but definitely there are things to get there you would not get anywhere else in terms of scale and communications, also to use the fact that you are still early in your career.

On the other hand, you can also look into startup option, faster movement, great exposure to recent trends, yet a bit pressure more than average.

Getting to work with proper methods, learning automation, deployments, and better software engineering are things not everyone get exposed to early in their career.

Hearing office hours for team members felt weird when I read it. However, reading Alex's comment, I think that is a very good way to look at it.

I would however start by having recorded knowledge transfer sessions, upload them to the team's channel for future members, and taking Q/A at the end of each, this way you do it 1 time, and the rest of support can be an ad-hoc one.

Everything should be written in wiki, or readme files, I suggest you do all the onboarding tasks once at least to make sure they are clear, instructions are correct, and no hidden issues are there, this will reduce the back and forth, and save you a lot of time. (If this is done in the video sessions, that would be better).

After the onsite loop is finished, the interviewing team gathers to take the decision. This meeting has multiple parties involved:

- **The recruiter:** He is your defending partner inside the loop, he does his best to make sure you are hired if you deserve that.
- **The HM:** He is the manager that has a position open, he interviews you, and if he thinks you are a good candidate, it’s in his best interest to hire you as well.
- **The Bar Raiser:** He can be one of the technical interviewers, or a non-technical with just all-LP round, or even just an observer in the meeting without actually interviewing you, his job is to defend the company’s policy, and make sure to hire you only when you raise the bar for the company. This is the only person that has veto power to reject a person.
- **The interview team:** This includes all other SDEs that interviewed you.

The bar raiser starts by going around, taking any high level comments, then commencing with all the competencies that Amazon measures against. Every interviewer gets to show his feedback, gets asked on it, tries to convince the team with his decision.\
Prior to the meeting, every interviewer must input his feedback, that includes if he agrees with hiring you or not, then the bar raiser challenges each person to make sure the feedback is fair, and that the decision the interviewer chose is justified.

This is basically the summary of how it's done, but more details can be added if needed..

I think you should first decide, in case you have 2 offers, which one you would join, if that's the AWS, then you have your answer.

If you still want to explore both, you can reach reach out to the recruiter telling him you already have an offer and would like to accelerate the process.

The recruiter for amazon might not push the start date or decision deadline too far, but you should try.

I would avoid setting a start date, then eventually joining another place, it will be perceived negatively, as the team might stop their search once they hire you.

Congrats on securing the offer to join!\
Joining as L5 with 3 YOE means you will be at the very first stage of L5 bar, that means expectations will be of higher bar that what you are used to.

Still, to navigate the first few months there, be sure to look around and learn from everyone, don't be afraid to ask if you need anything, as long as you do your research as well, it will be taken negatively if you expect answers to everything and not lookup yourself and do some research before asking.

Amazon is a very big company, but teams are of sizes less than what you are used to, the challenging part is to cope with the knowledge scale, and getting used to all the tools, but your onboarding plan should be enough to get you past the first few months.