Amazon.com, Inc. is an American multinational technology company which focuses on e-commerce, cloud computing, and much more. Headquartered in Seattle, Washington, it has been referred to as "one of the most influential economic and cultural forces in the world".
My team has a really great manager who I've been working under for past 3~ years who has aided me in fast tracking my career growth, however there will be change in structure, and our team will be led by a new Manager. As a result, I'll be required to relationship with the new manager, earn trust, etc. However, at the same time I'm worried that all the progress I've put forwards to build a good case for my promotion might get lost as I've been doing a lot of work that doesn't directly reflect in overall Team's Yearly planning such as drastic improvements in OE (Saving multiple SDE weeks yearly), Many architectural upgrades to existing systems (As a clean up activity while working on my main project) etc. I feel these data points might get lost, how can I ensure that the transition between managers will not end up affecting my long term growth plan? I still have 3-4 weeks till the transition is compelte.
Not a manager here but I strongly feel like understanding my manager's perspective is essential for me to successfully navigate my tech career.
I understand that if a software engineer wants to become promoted, they need to complete projects with increasing scope involving increased technical depth, ambiguity, impact, etc in addition to many other things.
I entered the company as an L4 Frontend Engineer and it is my first tech job, so I started with 0 experience. Our team has a lot of frontend tasks, but also has a lot of backend work as well. As a result, I have been doing a lot of backend work when it is necessary and there isn't much difference betwee an SDE and FEE in our team in terms of the work we do.
My manager knows that I had 0 experience prior to coming here and recognizes that that I'm able to do both backend and frontend work. He mentions that I could always transition into the SDE role if I wanted to.
My question is, would there be any huge benefits of changing my role to be an SDE for my career? At this point, I wouldn't say that my skillset is more geared towards Frontend since I'm doing both and this is my first job.
My original intention was to stay a Frontend Engineer as I find frontend work more fun and it was what I studied the most for when preparing for interviews. But my friends were telling me that SDE would probably give me more opportunities in the future, so I've been thinking about this lately.
I'm an incoming SDE intern and will be joining the team at the end of this month. I'm eager to get started and make the most of this opportunity. Last summer, I feel like I didn't perform up to my own expectations and left some room for improvement. I was fortunately to have a return offer but I think I don't really deserve it. This summer, I am committed to learning from my past experiences and striving to do my best. As part of my preparation, I'm planning to have a meeting with our manager to discuss my goals for this summer.
I was recently laid off from AWS. I see few open roles for SDE-1s but descent number for SDE-2 roles.
Should I study system design and apply for SDE-2 roles or focus on SDE-1 roles?
I have not studied for system design interviews. I estimate that I will need 2-3 months of studying before I can pass the interviews. My YOE is low for SDE2 and I might be wasting my time applying for SDE2.
Here is a breakdown of my experience:
My manager at AWS was telling me that I should apply for promo in the next few months (after finishing a project). I got laid off before I could apply.
Is there anything I can do now to make me stand out as an SDE2? For example, contributing to open source. I want to try being an entreprenuer but I know few ventures make more money than working at FAANG so maybe it's not a good idea.
I am an SDE1 that was recently laid off from AWS (~2 YOE total). Lately, I have been reflecting on what I wanted to do/what really excites me. I really enjoy software development and while I do want to get another job one day, I wanted to use this opportunity to scratch my entrepreneurial itch and create apps/websites/side-projects for fun or for many small business owners I know that need someone to create software for their business. I'm not sure how long this "break" will be but I would say ~2 to 3 months time. Part of this is inspired by Alex Chiou's love for side projects.
I understand that finding a job will take some time as well, so the total gap on my resume that will be filled by this freelance work/applying might be ~6 months total. I understand that there are other posts on Taro that talk about the impact of a career break but this won't necessarily be a break per se. On my resume I will put this down as freelance work I completed for clients and will be prepared to show potential employers a portfolio of what I did.
I was wondering if this would negatively reflect on my application when applying for SDE jobs again/will make it harder for me to land a job. Alternatively, I could begin applying and interview prep now and only work on these projects on the side. Thanks.
I had an internship with Amazon last summer and was lucky enough to have the return internship offer for this summer. I am quite nervous because my tech stack skills are so weak. I am just good at technical interview because I do competitive programming and leetcode a lot, thats why I land my internship offer with Amz.
I forgot almost everything from my last internship. I have to admit that I was a very bad intern, not to say the worst intern. My mentor and the senior engineer of my team did the most of my last project so I got the return offer.
Please suggest me any sources to improve my tech stack skills, projects, open sources, ... so I can perform well at this summer. My team last year used Kotlin for backend codebase.
I see many experienced developers finding flaws in the existing architecture and also refactoring them to make it much better. I don't think I have yet gained the ability to identify loop holes in complex projects. However, I am able to fix issues if someone else calls them out pretty quickly.
How can I improve on this? What are some good resources to develop this skill?
I have a SDE 3 mentor who is very nice and helpful. I started working with them a while ago because I am trying to get promoted to SDE 3 but I don't always have great questions to ask. I also want to be respectful of their time.
What are some questions that will be most beneficial to ask? How can I make the most of this mentorship?
I'm pretty good at leetcode (was able to pass some 3 to 5 rounds of interviews), I got good at by practicing and continuous learning. Now I want to be good at software engineering in general like debugging, building components, understanding complex things/systems, etc. I see one of the suggestions is to improve on fundamentals of software engineering, how do I do that? and What action items can I follow consistently? Any concrete suggested steps will be great instead of just some general bullet points. Thank you all.
Sometimes I sit in meetings that I feel aren't really necessary. How can I better identify whether these meetings are necessary and propose a better asynchronous form of communication (slack post, quip doc, etc) if they aren't?
Some of these meetings include status update meetings (besides standup), and meetings where people are there just to absorb knowledge. Is it a general rule of thumb to have meetings primarily to get alignment on decisions? Are there cases where we can get alignment asynchronously as well via commenting on a slack post/quip doc, etc.
For context - I have recently left Amazon and I'm actively looking for another role that suits my lifestyle in terms of work/life balance as well as the interest during the job role. Given how the market is right now - I was wondering if it is better to get a contract role until you can get the opportunity that you find interesting or go for a full-time opportunity regardless?
I've always been the one to dive into problems and solve them without thinking about how difficult they are but recently I've been running into this failure mode where many of the problems I work on involve using old tools that are cumbersome to work with. The result is that it takes much longer to deliver my work compared to those that work on packages with newer tools (I'm talking about native AWS lambda, s3, dynamo, etc) and sometimes I wonder if I'm doing what's best for my career.
Some cumbersome tool examples include
My company has at least acknowledged the issues with the above first two bullets and has slowly started deprecating those tools. Oftentimes the senior and mid-level engineers work with newer tools and therefore aren't as familiar with the older ones, which is fine. I could just avoid working with these packages altogether and only work on the packages that involve the shiny new aws tools but I'm not sure if that mentality is what's best for my career.
Amazon is well-known for its design doc reviews, which appear to be small-scale system design reviews. However, I'm having trouble understanding them, let alone recommending modifications.
I'm aware of Alex Xu's Byte by Byte go course, but I'm skeptical using it as it's specifically for interview preparation. I want to learn for the workplace. I can definitely look at blog posts and current design documentation, but I'd prefer something more structured. How can a novice learn system design and grow to the advanced/intermediate level? What books or resources would you suggest?
See relevant discussions involving Amazon engineers on Taro.
Engineers are actually evaluated on two dimensions: performance and potential. Performance is backward-looking: what did you achieve in the past few months? Potential is forward-looking: how will you perform in the future, given your ambition and growth rate?
Managers decide a rating for each engineer on these two dimensions, which results in a final "performance summary" (described in the calibration section):
Managers make determinations about potential based on various criteria like willingness to act on feedback, initiative to improve workflows, and demonstrations of strategic thinking.
Evaluation at Amazon is coupled to their 16 leadership principles (LPs):
Mention the Amazon LPs you championed across the cycle to add more weight to your self-review.
The input is free-form, but you should anchor your self-assessment against the Amazon LPs.
Your manager's feedback is very important because they will stack rank you. All of the feedback is collated under your director level.
Amazon is big on collaboration, so you can request feedback from a huge amount of peers. There is effectively no limit to the amount of peers you can get feedback from - You can go as high as 15-30 peers.
You should reach out to a minimum of 5-6 peers for feedback, even if you're SDE 1.
When someone requests peer feedback from you, you write about the following 2 categories:
Make sure to be concise with your peer feedback as you only have 60 words per section!
On top of the above 2 fields, you can also choose up to 3 options each for:
This means that you can tie up to 6 total LPs to your peer feedback. These selections are made across checkboxes.
You will be able to see your peer feedback with names removed. However, this can be reverse engineered based on the author's writing style. Write peer feedback with the expectation that the peer will know the feedback is coming from you.
Amazon targets to cut the bottom 6% of its engineers every performance cycle for low performance. 💀
Amazon is different than most other companies because there are 2 different ratings:
The real rating is generated through a separate process called OLR (Organization And Leadership Review).
Here are the real ratings:
|TT - Top Tier||Exceeds||This means that you are a rockstar for your level, massively exceeding expectations. You generally need to be here to get promoted. Only 1-2% of engineers get this rating.|
|HV3 - High Value 3||Exceeds||This means that you're doing extremely well.|
|HV2 - High Value 2||Meets||This means that you're doing quite well, exceeding expectations.|
|HV1 - High Value 1||Meets||This is the average rating. 35-40% of engineers are placed within this bucket.|
|LE - Least Effective||Needs Improvement||This means that you're doing poorly, not meeting expectations at your level. 10% of engineers get this rating every cycle.|
Amazon's frugality shows here as your compensation doesn't increase significantly with a good performance review rating.
|Rating||Salary Increase (%)|
If you want a significant compensation increase, you need to get a promotion. A promotion often increases your base salary by at least 30%.
Amazon's offers equity to employees over a 4 year period, but the vesting schedule is biased toward the end of the 4 year grant. Generally you'll get a signing bonus over years 1 and 2 to "make up" the initial TC difference.
Amazon defines a "target comp" for each level which dictates your pay in subsequent years. If your previous equity grants have appreciated significantly in value, your equity refresh could be 0!
Unlike most other Big Tech companies, Amazon doesn't pay out a cash bonus.
Amazon shells out the big bucks retaining top-caliber talent with "dive and save", which can increase your TC by $75k+. However, this is really hard to attain as it requires VP approval.
Before, you could "boomerang", leaving Amazon for another company and then quickly come back to Amazon with a better package. However, policy recently changed so that boomerangs would get the same package they had before.
There is a high risk of getting a PIP if you get an NI (Needs Improvement) rating.
There is a target for 10% of engineers to receive the NI rating each cycle.
PIPs are effectively a death sentence at Amazon. 🪦
If you're a low performer, the process is as follows:
You should be operating at 80%+ of the next level's guidelines to have a real case for your promotion.
You need to write a summary of your work for your promotion packet. The summary needs to include information about the following 5 core scopes of work:
There is another section where you need to talk about how your work corresponds to Amazon's LPs; however, this section isn't as important as the others.
You need a minimum of 4 peer feedbacks to support your promotion case, but 6+ is recommended.
You should always be generating a large paper trail with every project you ship at Amazon. This saves you a lot of time putting together your promotion case as you don't need to write everything from scratch - You can simply compile everything you already have.
The documentation requirements at Amazon are pretty onerous:
You generally need a TT (Top Tier) or HV3 (High Value 3) rating to get promoted.