How I Became a Tech Lead at Amazon Despite Lacking Technical Skills – Business Insider

This month would’ve marked my 7th year at Amazon. I left last year. Looking back, I’m quite proud of my accomplishments.
I authored and shipped over 550 Pull Requests. I designed, developed and deployed large scale software systems used by thousands of customers. I taught hundreds as an internal course instructor. I was recognized as one of the key technical leaders of my team.
It wasn’t always this way, though. In 2015, Amazon hired me as a Software Development Engineer 1 (SDE1). I shouldn’t have been hired — I was an impostor.
Despite my technical limitations, I eventually earned a promotion to Software Development Engineer 2.
My journey from SDE1 to SDE2 is similar to many, but rarely told. It’s one of my favorite stories from my early career. I share it to help other impostors achieve success, whether in big tech or elsewhere.
I admire every software engineer who’s passed an interview loop at Amazon. In a full-day, 5 different interviewers grill you on technical and behavioral questions. Passing requires several hundred hours of preparation.
You have to tenaciously study complex data structures and algorithms. You have to 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 frightening stories of their difficult technical questions. Recursion, traversals, dynamic programming — yikes.
I had 4 exams that week. I was barely sleeping and only had a few hours to study for the Amazon interview.
Back then, intern candidates didn’t go through full-day loops. There were only two 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.
If they perform well, Amazon interns earn a full-time offer as an entry level SDE1 upon graduation. They don’t have to re-interview.
I spent the internship in Seattle and worked hard, developing a greenfield Ruby on Rails website. 
I ended up earning the offer — and started as an SDE1 in Virginia in 2015.
Amazon expects SDE1s to know advanced data structures like heaps, graphs and tries. They’re also expected to understand the time and space complexities of sorting, searching, inserting and partitioning algorithms.
I didn’t know any of this.
My educational background was in computer engineering, not computer science. The focus was the integration of software and hardware — not large-scale software development. The curriculum pushed me to solve challenging problems in ambiguous spaces. However, it didn’t cover those topics of advanced data structures and algorithms in detail.
I knew I was ill-equipped. I had major “impostor syndrome” when I started.
I’d submit a code review (a.k.a, Pull Request), and receive over 50 comments on it. I’d correct it, and post another revision, only to receive another 30 comments. Over, and over, and over again.
Sometimes my code was so bad, my peers couldn’t 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 felt hot with shame and embarrassment. I was living in constant paranoia that somebody would figure out that I didn’t belong. I thought I’d be fired on any given workday.
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.
LeetCode is a platform with hundreds of coding questions, designed to help developers prepare for technical interviews. I logged in, wanting 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 marked as Easy. I couldn’t solve it. I picked another one. I still couldn’t solve it. Over, and over, and over again.
That’s when I realized, there was no “syndrome” about it. I was an impostor.
Yet, two and a half years in, I earned an SDE2 promotion. An SDE2 is capable of independently developing and maintaining a large scale software system with little guidance.
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 have to sell yourself and your work to your manager and peers with over 20 pages of documentation. You have to persistently collect metrics and evidence. Promotions don’t happen until you have a consistent track record of performing at the next level for six months to a year.
First, I put my ego away. I recognized that my peers are intelligent individuals, with unique backgrounds and industry experiences.
I listened empathically with a radically open mind. 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: “How do I know I’m right? What caused this person to say this? How can I clarify my work to prevent this feedback?”
Even when they’re wrong, intelligent people say things for a reason. I sought to find that reason and use it as leverage to improve my own work.
1. I asked stupid questions
I didn’t care if people judged me — I was an impostor, after all. Out of the thousands of tech terms out there, I knew I wasn’t expected to know every one of them. 
Examples of questions:
“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 could confidently fish for information, and participate in discussions.
2. 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. I knew that the more constructive feedback I received, the faster I’d learn.
3. I leveraged existing examples
Before starting a coding task, I searched for existing solutions using the internal tools. I read a few different examples and understood their code structure. Then, I’d look at my own team’s code, and decide how to best introduce my changes.
I followed a similar process for design documents and post-mortem reports. Examples first, do second.
4. I focused on doing the right thing, with intent
For every 100 lines of code that I submitted for code review, there were 250 crappy lines I’d written and discarded. I made sure there was purpose, intent and clarity behind every one of those 100 lines.
Over time, I started shipping code reviews in one or two revisions.
5. 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 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.
6. 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.
7. 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 and producing elegant, beautiful solutions.
8. 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 delay for months on end.
In one-on-one 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 demonstrating my skills, I made sure to get written feedback. You never know when a reorganization could result in a manager change.
9. I prioritized promotional work
I didn’t want to get caught up in the day-to-day minutiae, where I’d end up forgetting to grow my career. Instead, I started each day with a high impact task that would inch me towards a promotion. Whether that’s signing up to interview, performing code reviews, or adding to my brag document.
10. 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.
11. I understood what was under my control
I realized that sometimes, there are no big features to work on. Sometimes, projects get canceled. 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.
And when they came, I executed. Over, and over, and over again. I’ve since grown my career through Amazon, and as an independent freelancer. I’ve had some time to reflect over the years.
I felt like an impostor because of my inability to solve LeetCode-style coding questions. But I achieved success at Amazon, even though I couldn’t do them.
The “LeetCode culture” style of interviewing is popular across the big tech industry. Its existence is a particularly nuanced topic of debate in recent years. Many people want to eradicate it, for reasons of gatekeeping, and incongruence to a developer’s day-to-day. As of this writing, many companies have moved away from it. Others remain, Amazon included. (When I started interviewing candidates, I had to get good at LeetCode to properly assess them.)
But alas, this isn’t a piece to debate interview processes. Rather, it’s a piece to describe my feelings as an impostor, and how I overcame them. Many junior engineers in our industry experience similar feelings. For people like me, it’s the LeetCode questions. For others, it’s their inexperience with Git. Or a fear of speaking up in meetings. Or staring at a code review, not knowing what to look for, or how to comment.
I stopped believing that Amazon hired me by mistake. Even thinking back to the internship itself — that’s no walk in the park. 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.
And as a full-time employee, there’s no doubt that I had a tangible impact at Amazon.
I contributed to AWS security, education, and sales software. I served both external and internal customers at a massive scale. I earned “Exceeds” ratings. I took the role of tech lead in several projects. And I’ve coached many engineers within the company to reach their SDE2 goals.
My leadership and soft skills have been refined over my lifetime. They translate well into Amazon’s Leadership Principles.
Through my writing, I now hope to give back to the developer community at a larger scale. Because I know what it’s like to be an impostor.

Disclaimer: I’m not representing Amazon in any way. Opinions written here are strictly my own.
Curtis Einsmann is a freelance software engineer, course creator and author.

Keep reading
For you

source