Question

What is your advice for a fresh engineer starting his career as an SDE at Amazon?

Answer 1

I joined Amazon as a new grad and have been with the company for 3.5 years. I have learned the following things.

1. Delivery is everything: Nobody takes you seriously until you deliver results that matter. Your manager/co-workers won’t care about your opinions unless you have shown them that you can deliver.
2. Trust is everything: Earn your manager’s trust within the first couple of months ( by delivering results ) and never let him/her down. Once your manager has lost trust in your delivery capabilities, you won’t get assigned any important work. And once that happens, whatever you deliver doesn’t matter.
3. Tasks with deadlines = Tasks that matter: Initially, you will be assigned tasks that don’t come with a deadline. These are most likely minor bugs which don’t affect customer experience or tests that the team has skipped while launching a feature. I advise you to have your own deadline and strive to complete these initial tasks before that deadline. Once you have delivered on these initial tasks, push your manager to assign you feature-related tasks that come with a deadline. If you have quickly transitioned from tasks without deadlines to always working on tasks with deadlines, you are on your way to being successful.
4. Don’t be a perfectionist: Getting a reasonable job done on time is more important than doing a perfect job that goes past the deadline. Since you are a new grad, you will be under the impression that you have to do a great job on every small task. That is not the case. Amazon is not the place for the perfectionist.
5. Be assertive: Amazon’s culture is for Type-A people. So if you are not an assertive, get-it-done person, you will eventually lose out on opportunities and feel neglected. If you are a Type-B (creative) person who is more interested in delivering less quantity but more quality, you will need to inhibit those qualities in the workplace and make sure you are delivering more quantity with an acceptable quality.
6. “Ownership” is a tricky term: One of the leadership principles of Amazon is “Ownership”. This does not mean you have to say “yes” to anything that comes your way. Learn to push back on ad-hoc requests. If you don’t push back you will eventually lose out. Don’t try to be a good citizen and help others out before you have helped yourself. Just say “no” if someone is seeking your help at the cost of your progress. People have to figure out how to get their job done on their own and if you don’t have the time to help them, they will have to figure out other ways of getting the job done. You are being a better “owner” by not responding to ad-hoc requests. Remember, you are the only one working on the task assigned to you.
7. Don’t figure out everything on your own: People truly don’t care how well you know about the build system or deployment system at Amazon. They just care about the results you deliver. So if you don’t know how to use a certain tool that is internal to Amazon, just ask the guy sitting next to you. Even if you are interested in learning more about the tool, pursue it only after you have used it to deliver the results. If you are doing code reviews for someone and don’t understand what the heck the code does, ask them to explain what’s happening in the code review instead of diving into the codebase.
8. Use your “new grad” status smartly: Ask as many questions as possible when you are a “new grad”. This is the time when you won’t be judged based on your questions. Ask people a lot of questions and push them to their limits. It is only a matter of time before people start asking you questions.
9. Don’t learn but build: You should only learn as much as you can while you build a product. Don’t learn at the cost of time to deliver. Deliver first, then learn, if you are really interested. Amazon is not a place where learners can learn. It is a place where builders can build.
10. Don’t be fooled by “geeks” you work with: There may be a certain number of hyperactive people in your team who always know too much, are delivering 10x and quality is as good as quantity. Don’t allow their work style to influence your own. Your job is to set certain expectations with your manager and meet them.
11. Knowledge that is not spontaneous doesn’t matter: If someone asks you a question, and you can’t answer it immediately or at least pull up the information that can answer the question, your knowledge doesn’t matter. If you have the option of using a brute-force method to solve the problem immediately versus spending a couple of days to figure out the ideal way, simply go for the brute-force method. You are not good enough to apply that ideal method if you can’t apply it right now. You could always send out a code review first using the brute force method and then work on the ideal approach while to code is being reviewed.
12. Participate actively in meetings and design reviews: A lot of decisions are made in a hurry at Amazon. You will be drawn into design reviews where entire designs will be decided. Learn to ask questions and actually understand what is being presented. If you are a reflective person who needs time to process stuff, make sure you read the design document that will be reviewed and make a list of questions to clarify the design. If you don’t plan to actively participate in the design review or meeting, you are better off not attending it.
13. Treat 1:1s with your manager seriously: Be very clear about what will be discussed in each 1:1. The information exchanged during a 1:1 should be meaningful and deterministic. If your manager does not take your questions seriously and is providing vague answers that don’t come with a clear timeline or functional action item, your manager is just wasting time. A manager who is always providing vague answers is a bad manager. Especially, detest managers who don’t treat your first year performance reviews seriously.
14. Don’t get caught up in the “nice”ties of your team: Your team may be nice and polite but don’t ever let that get in the way of you being able to deliver results. Don’t commit to extra work just to seem “nice”. People will exploit you mercilessly.
15. Don’t laze around in your first 2 years: The worst thing you can do when you join as a “new grad” is to just do what you are being assigned and not figure out what you should do to get to the next level. I know, it’s the first time you are making big money, you just want to enjoy life and take it easy. Don’t do that.
16. Don’t spend any time with a team that does not allow you to grow: Around the 1.5 - 2 year mark, you will have a decent idea of whether your team allows you to grow in your career. If that is not the case, jump teams/companies while you are considered a relatively inexperienced engineer. Interviews will be easier ( limited to algorithms and won’t include system design) when you are relatively young in the industry. Jump to another team, if your team’s work is not interesting. Jump to another company, if you are a misfit for the company’s culture.
17. Have a clear idea about the promotion criteria: There are docs/wikis that talk about the criteria for an SDE-1 to get to SDE-2. Learn these by heart, and then make sure that your every action is aligned with these docs. Make sure you push your manager to point you to these docs in your 1:1s.
18. Deliver results in “days” and not “weeks”: Always deliver results in units of days and not weeks. Even if you are assigned a task that takes a week to understand and complete, break it down into individual tasks that you will achieve each day. You will most likely have a daily stand-up and you will gain points if you always delivered something yesterday and are working on the next thing today.
19. Don’t hesitate to put people on the spot: If someone is not providing a clear answer, don’t hesitate to put people on the spot. Don’t give people too much time to “get back to you”. If people are not doing your code reviews, call out their names during standup after you have given them 2 days ( may vary depending on your team) to do the review. If someone is holding you back, make sure you draw attention to the fact with your manager. And conversely, make sure you don’t block others from progressing in their tasks. If you are not able to do their code reviews since you have work to do, just ask them to switch reviewers immediately. If you are on call for the first time and get paged in the middle of the night, don’t be afraid to page your secondary immediately.
20. You won’t be fired in your first year: Except under extreme circumstances (breaking production stuff every time you ship code ?), you won’t get fired in your first year so stop being insecure and learn to think about how you can actually deliver value to your team and grow in your career.
21. Continue to hone your interviewing skills for the first couple of years: Keep your options open. Continue to prepare for interviews the first couple of years or at least until you have established yourself as a good contributor in your team. Be ready to interview with another team/company at a moment’s notice.
22. Observe what people “do” and not what they “say”: People may pay lip service to a lot of things but only trust them based on what they “do” and not what they “say”. Your manager will say a lot of stuff to appease you in your 1:1 but if he/she does not take any functional steps to fix issues in the next week/month, it will never happen.
23. “Bias for action” and “Deliver results” are the most important leadership principles: The rest don’t matter, especially for an SDE-1.
24. Amazon is not the place for work-life balance: Work-life balance is not what you should be worried about as a new grad. If you seriously worry about your work-life balance, work hard for the first 2 years and jump companies. If an Amazon employee says he/she has good work-life balance, that just means he/she is either compromising on quality to deliver faster at work or is a hyperactive Type-A personality who actively prioritizes work in his/her personal life.