📓 Cabinet of Ideas

How I Got a Job at Aws Dev Community

How I got a job at AWS - DEV Community #

Excerpt #

Background I had been working at my first software job for 3.5 years and in that time I…

Background #

I had been working at my first software job for 3.5 years and in that time I moved from junior to mid. It was obvious that if I were to keep growing my skills, I would need to move companies.

First thing, I changed my status on LinkedIn to “Open to Work.” About three months later, an AWS recruiter reached out to me. Working at AWS was my dream job. She said I could interview for a couple of different teams and we decided I would interview with API Gateway.

I had two months to prepare.

Step 0: Study coding challenges #

I read two books and would only recommend Cracking the Coding Interview. This is common advice, but it prepares you well for coding challenges. I read through it, doing at least one problem per chapter and then reviewed as many additional questions per chapter as I had time for.

Step 1: Go to Amazon’s interviewing workshop (if available) #

AWS provides a number of resources for candidates. They want people to succeed, If I had not attended the hour workshop offered to me by my recruiter, I wouldn’t have gotten the job. Most of the advice in this article just echoes their recommendations.

Step 2: Find two stories for each LP #

Amazon holds tightly to the Leadership Principles. These are a set of short phrases used to guide decision making.

Choose two stories per Leadership Principle. Each story should:

  • Follow the STAR technique.
  • Be short (3-5 minutes max) to explain.
  • Be tied to a professional experience. If you’re fresh out of college, tie it to a collegiate experience or side project.

Write enough of the story down that you’ll be able to look at your notes in the interview and remember the story.

This took me around 10 hours. At the time, there were 12 Leadership Principles, which meant 24 stories. I tried my best and came up with around 20 stories with 4 overlapping between principles.

Note: During the interview, I pivoted which stories I told according to the questions asked. Don’t be rigid in the interview, but find as many stories as you can and be ready to share any of them.

Step 3: Find useful design patterns and be able to apply them. #

The book “Design Patterns” by Erich Gamma is a great resource for this. Don’t memorize the entire book (unless you’d like to). Instead, pick 4 diverse patterns that you could see helping you solve problems.

I picked:

  • Abstract Factory
  • Builder
  • Singleton
  • Decorator
  • Proxy
  • Observer
  • Iterator

I only used one of these as part of the software design portion of the interview. However, I referenced more in passing as the interviews progressed.

Step 4: Look into trees #

This is in Cracking the Coding Interview. Please look into it. Even if it’s just BFS/DFS.

Step 5: Know O(n) notation #

Some people already do but just in case, it’s really important. Not just for interviews.

Step 6: Have at least 4 thoughtful questions to ask #

Asking questions that show you know what you would like out of a job and want to work with the company can be very helpful. Ask software specific things you care about. One example I like is: “What is your oncall schedule like?” or “What does releasing software look like on your team?”

Figure out what you care about in a job and write down these questions beforehand.

Essential Step: Take too many notes #

The picture for this post above is my setup for my interview. This was something that was mentioned in the class - that notes are allowed. Always be up front about your notes. If you’re going to reference them and you happen to be remote, mention casually, “hey, do you mind if I reference my notes on this?” Or “let me just scan my notes real quick for a story that matches that.”

To be honest, I memorized everything except for the 20 LP stories. But those 20 stories were incredibly useful to have written down and I’m glad I took the time to write more down because it stuck in my brain better.

The interview format #

This may have changed since I interviewed, but here are the rounds I had to get though:

  1. Phone screening with a recruiter
  2. Two short, at-home leetcode style tests
  3. Connection with the recruiter for interview timing and training opportunities
  4. 4, hour long in-person interviews: system design, software design (patterns), 2 coding exercises. In each, I was asked a behavioral question

How long did this take? #

I didn’t have any leetcode experience before I started preparing. My first job didn’t contain a coding challenge. I had read the Design Patterns book, but I didn’t have a list memorized. This was my first time applying for a FAANG roll.

This was my dream job, so I spent multiple hours most nights studying for it. My guess is that I spent 100 hours preparing for the interviews.

How much of this is luck? #

There’s always luck involved with interviewing. In my current role at LTK, I was rejected the first time and accepted the second.

What would you have done differently? #

I didn’t handle the offer stage very well. They ended up offering me 30k more than I asked for because I didn’t trust the research I had done on what Amazon typically pays. If I had believed things, I may have been able to negotiate for 10k more in my salary.

When you join, you get to choose which OS you use. I wish I would have asked what OS the people on my team use. There is also an unlisted third option of getting a Linux laptop. I switched to that after 8 months and had a wonderful experience.

What happened after you got the job? #

I joined AWS working on API Gateway for 1.5 years. In that time, I was put on an S-Team project where I led various parts of the initiative to great success. I’m being intentionally vague as I’m not sure how much of that I can share.

Then, AWS required everyone to come back to the office. I was asked to choose a location or (by default) move to Colorado. They did it in the best way possible - giving me a year to decide. I’m very grateful for the time frame.

I decided to move on, but working at AWS was one of my favorite professional experiences. The people I worked with were some of the most practiced engineers I’ve met and when my son grows up enough to where me being at home is not as impactful, I would consider rejoining.

If you want to be an encouraging voice and/or read these posts before they’re public, buy me a coffee and let’s start a conversation.

Buy Me a Coffee at ko-fi.com

Backlinks

  • No backlinks found

Interactive Graph