Amazon shouldn’t have hired me. Here’s how I became an SDE2.
Disclaimer: I’m not representing Amazon in any way. Opinions written here are strictly my own.
Today I celebrate my 5 year anniversary at Amazon.
I’ve contributed more than 500,000 lines of code to production systems. I’ve authored and shipped more than 500 code reviews.
I’ve designed, developed, deployed and maintained large scale software systems used by thousands of customers all over the world.
I’m recognized as one of the key technical leaders on my team.
It wasn’t always this way, though.
In 2015, I was hired as a Software Development Engineer 1.
I shouldn’t have been hired. I was an impostor.
Despite my technical limitations, I eventually earned a promotion to Software Development Engineer 2.
I share my story to help other impostors achieve success in FAANG (or elsewhere).
How I sneaked in to Amazon
I admire every person who has passed a software engineer interview loop at a FAANG company. It’s a full-day set of interviews where the candidate gets grilled on technical and behavioral questions from 5 different interviewers.
Passing requires several hundred hours of preparation. One must tenaciously study complex data structures and algorithms. They must practice coding problems for months on end.
It takes patience, determination and grit on par with an author trying to launch a book.
My path had no such difficulties.
Back in 2014 Amazon performed on-campus interviews for summer internships.
I had classmates who interviewed before me. They told stories of how difficult their technical questions had been.
I had 4 exams that week. I was sleeping 4 hours per night, on average. I only had time to study for 3 hours.
There were 2 interviews. My technical questions were unusually simple. One on bit manipulation, one utilizing a Linked List, and one asking to explain a HashMap.
That’s it. I got lucky.
Amazon interns earn a full-time offer as an entry level SDE1 upon graduation, if they perform well. They don’t have to re-interview.
I spent the internship in Seattle. I worked hard, developing a greenfield Ruby on Rails website.
I earned the offer and started as an SDE1 in Virginia in 2015.
My limited skills
SDE1’s are expected to know advanced data structures like heaps, graphs and tries.
I wouldn’t have been able to tell you a simple definition for any of them.
SDE1’s are expected to understand the time and space complexities of sorting, searching, inserting and partitioning algorithms.
I wouldn’t have been able to tell you the time complexity of a simple depth first search of a binary tree.
So, why didn’t I know this stuff? 2 reasons.
First, my educational background was in Computer Engineering, not Computer Science. The focus was geared towards the integration of software and hardware. Not large scale software development. While it did push me to continuously solve challenging problems in ambiguous spaces, the curriculum simply did not cover those data structures/algorithms topics in detail.
Second, I had not gone through the full-time software engineering interview process. I had not studied those several hundred hours to learn.
I knew that I was ill-equipped. I had major “impostor syndrome” when I started.
A rough start
My code reviews were a disaster. I would submit a code review (e.g., pull request), and receive 50+ comments on it.
Do better.
I’d correct it, and post another revision. Only to receive another 30+ comments.
Do better.
Over, and over, and over again.
There were times that my code was so bad, my peers couldn’t effectively explain it to me in a way that I could understand. They had to download my code and rewrite it.
While their actions were friendly and helpful, my face turned red with shame and embarrassment.
I was living in constant paranoia that somebody would figure out that I didn’t belong.
I thought I would be fired on any given workday.
An impostor exposed
I improved, slowly. I was eventually hitting deadlines and consistently delivering to production.
About 9 months in, my confidence grew. I wanted to kick my “impostor syndrome” to the curb. I started to take a stab at some coding problems on LeetCode, just to prove to myself that I belonged.
I remember thinking, “I’m a legitimate Amazon software engineer now. I have commits running in production. I can handle these simple problems.”
I picked a problem that LeetCode classified as Easy.
I couldn’t solve it.
I picked another one.
I couldn’t solve it.
Over, and over, and over again.
That’s when I realized, there was no “syndrome.” I was an impostor.
Making it, not faking it
2 and a half years in, I was promoted to SDE2. The SDE2 is capable of independently developing and maintaining a large scale software system with little guidance.
So, how did I do it? How did I play the promotion game to my favor?
Well, at Amazon, there are no tricks. No gimmicks. No ways to game the system.
“Fake it till you make it” is common, horrible advice. It doesn’t work. The only way to get promoted to SDE2 is to be an SDE2.
The promotion process is strenuous. You must sell yourself and your work to your manager and peers in 20+ pages of documentation. You must persistently collect metrics and evidence indicating that you’re performing at the next level.
Promotions don’t happen until you have a consistent track record of performing at the next level for 6 months. Sometimes a year.
You’ve probably heard the phrase, we are what we repeatedly do. I’ll cover what I did to overcome being an impostor to achieve the next level.
What I Did
I empathically listened to feedback with a radically open mind.
New FAANG hires often have a big ego.
This ego limits their ability to receive and implement constructive feedback from their peers. All of whom are highly intelligent individuals with unique backgrounds of industry experience.
I had no ego. I didn’t deserve to be there.
When I received feedback, I listened empathically.
A peer’s feedback is either correct, debatable, or incorrect.
When correct, I implemented the feedback without reservations.
When debatable, I sought first to understand their viewpoint, then make mine understood.
Here’s the kicker: I listened, even if the feedback was incorrect.
The thought process is: “How do I know I’m right? What caused this person to say this? How can I clarify my work to prevent this feedback?”
This is radical open-mindedness. Intelligent people say things for a reason, even when they’re wrong. I found that reason, and used it to improve my own work.
I asked stupid questions.
New FAANG hires often avoid asking questions. They fear they’ll be judged. It’s an element of impostor syndrome that contrasts nonsensically with the ego.
Being an actual impostor, I knew my questions were stupid. I didn’t care.
Examples:
“I don’t understand what those words mean. Can you explain them, or point me to a resource which does?”
“What search tool could I have utilized to independently figure out how to solve this problem?”
“I didn’t understand what was being discussed in that meeting. Can I schedule a follow up meeting with you to get clarification?”
Pretty soon I had hundreds of bookmarks, was able to fish for more information and participate in meetings.
I sought the relentless reviewer.
Early on, it’s important to get a variety of peers to review your code and designs. Every reviewer has their own preferences, nitpicks, and pet peeves.
Even more important is to seek the relentless reviewer.
There’s always that one reviewer on every team. Nobody’s work is ever good enough. They nitpick every variable name, every log message, every API parameter chosen.
I made it a point to find that person, and get that person to review my work as much as possible.
Why?
Because I knew that the more constructive feedback I received, the faster I would learn.
I leveraged existing examples to do things the right way.
Junior engineers often reinvent the wheel.
Most coding tasks are not new.
Before starting a coding task, I searched for existing solutions using the internal tools. I read a few different examples and understood the code structure that had been used. Then, I’d look at my own team’s code and decided how to best introduce my new code into the system.
I followed a similar process for design documents and post-mortem reports.
Examples first, do second.
I focused on correctness and intent.
I avoided sunk cost fallacy. It didn’t matter if I spent 4 hours doing something the wrong way. I knew that I needed to scratch that work and do it the right way.
For every 100 lines of code that I submitted for code review, there were 250 crappy lines I had written and discarded.
I made sure there was purpose, intent and clarity behind every one of those 100 lines.
These days, my code reviews usually ship in 1 or 2 revisions.
I threw myself into the fire.
You will never be “ready” to work on big features, execute production deployments, perform interviews, or go on call.
The best way to be ready to do them is… to do them.
As early as possible, I just told my manager that I was ready. Even if I hadn’t done the recommended shadows. I needed help at times, or needed my peers to reverse shadow me. But ultimately this expanded my comfort zone and accelerated my growth.
I took initiative on the mundane.
I noticed opportunities to improve my team’s operational excellence, processes, and developer experience. I repeatedly volunteered to take on mundane tasks.
I automated manual procedures. I improved documentation in runbooks. I mentored interns. I improved my team’s CI/CD pipeline. I refactored legacy code.
I became a coding Professional.
Coding is a form of logic-based creativity. Every task, every new feature was a blank canvas opportunity for me to demonstrate the mastery of my craft and produce art.
The SDE2 is a software craftsperson — a Professional, from Steven Pressfield’s War of Art.
I focused on writing Clean Code (mandatory reading) and producing elegant, beautiful solutions.
I was transparent about my promotional desires.
A FAANG company is not going to give you a promotion. You need to ask for it — repeatedly. If you don’t, the promotion will keep getting delayed for months on end.
In 1-on-1 meetings with my manager, I was transparent about my promotional desires. I asked for feedback to determine where the gaps in my skills were. I objectively reflected on my past performance and accepted criticism when it came my way. I brainstormed opportunities to improve my skills and cover gaps.
After demonstration of skills, I made sure to get written feedback. You never know when a reorganization could result in a manager change.
I prioritized promotional work.
I realized I couldn’t only work on things that would get me promoted. If everyone did this, it would undoubtedly lead to a toxic team environment.
However, I did prioritize the work that would contribute towards my promotion.
If I needed to focus on delivering a high impact feature because of an imminent deadline, I’d start work on that first thing in the morning. This gave me myself enough time to produce quality work.
If I needed to perform more code reviews, I would do so first thing in the morning.
If I needed to perform more interviews, I would sign up for interview time slots first thing in the morning.
I persistently documented promotional evidence.
It’s critical to learn how to sell your work through quantitative and qualitative metrics.
Before starting a task, I searched for metrics that would show the current state of the system.
After working the task, I referred back to those metrics and performed a calculation to measure impact.
Then, I documented everything about the task in my promotion documents. I included a STAR write-up, quantitative metrics, and links to code reviews, graphs, or other work artifacts.
I understood what was under my control.
I realized that sometimes, there are no big features to work on. Sometimes, projects get cancelled. Reorganizations force manager changes. Sometimes, the team has a perfect CI/CD process, and there’s just nothing to improve.
I understood that if I focused on doing my best, professional work I would be prepared for opportunities when they came.
Opportunities came.
I executed professionally.
More opportunities came.
I executed professionally.
Over, and over, and over again.
Reflecting Questions
Is the “Leetcode culture” of the interview process flawed?
I was able to achieve success at Amazon, despite my inability to complete Leetcode problems when I first started.
When I started interviewing candidates for Amazon, I did make sure to learn those data structures and algorithms so that I could properly assess candidates in interviews.
I don’t think the process is flawed.
Companies want to hire people who have the persistence and determination to learn something new and apply it to their existing skills. The current process does a pretty good job of that.
Is it easier to be hired as an SDE1 through the internship program?
Not necessarily.
The 2 interviews are usually just as challenging as the 5 for full time. I got lucky with my interviews back in 2014. Anybody expecting to get the same easy questions that I did is setting themselves up for failure.
In the internship itself, you’re treated like a full time SDE1. Every aspect of your work gets put under a microscope for evaluation. I know many engineers who have gone through the internship and failed to earn a full time offer.
I’ve mentored several interns at Amazon over the years, so I know how high the bar is from a hiring perspective. Reflecting back on my past performance as an intern, it’s clear that I performed well. I deserved to earn the SDE1 offer that summer in 2014.
Did Amazon make a mistake by hiring me?
My answer to this was yes, until recently. It’s true that I shouldn’t have been hired, based on my technical skill set at the time.
But over time I stopped believing that the decision to hire me was a long term mistake.
There’s no doubt that I’ve had tangible impact at Amazon.
I’ve contributed to AWS security, education, and sales software. I’ve served both external and internal customers at massive scale. I’ve instructed on-boarding classes for hundreds. I’ve coached many engineers within the company to reach their SDE2 goals.
Before Amazon, I was the captain of my basketball and soccer teams in high school. Both teams went to the Virginia state quarterfinals.
In college, I built and led student organizations from scratch. I was an ambassador for the department of Computer Engineering.
My leadership and soft skills have been refined over my lifetime. They translate well into Amazon’s Leadership Principles.
I’m now hoping to give back to the developer community at a larger scale.
Because I know what it’s like to be an impostor.
