But it was not always so. In 2015, I got a job as a first rank software developer. And in vain. I was a real impostor. But my meager engineering skills didn’t stop me from getting promoted to second rank in the end. I want to share my story to help other impostors succeed in FAANG companies - well, or any others.
How I sneaked into Amazon
I admire the people who managed to go through the full selection cycle at one of the FAANG companies. This is a series of interviews from morning to evening, during which the candidate is questioned for technical knowledge and personal qualities by five different employees of the company. To pass this exam, you need to spend hundreds of hours on preparation, thoroughly study complex data structures and algorithms, solve problems for months. All of this requires as much patience, determination and persistence as the process of publishing a book.
My path went around all these difficulties. In 2014, Amazon was doing job interviews on campus for summer interns. Some of my fellow students went there before me. They all came back with tales of puzzling programming questions they had been asked.
I had four exams that week and slept an average of four hours a day. I managed to carve out three hours for preparation. There were two interviews. The programming questions I got are incredibly easy. One was about bit manipulation, the other was about using linked lists, and I also had to talk about hash tables. That's all. I was just lucky.
Interns at Amazon, if they do well, receive an offer to move to a full-time developer of the first entry-level rank. They don't have to repeat interviews. I was doing my internship in Seattle - painstakingly sculpting a Ruby on Rails site from scratch. Got an offer and started as a software developer in 2015 in Virginia.
About the scarcity of my knowledge
Rank 1 developers should be well versed in advanced data structures: heaps, graphs, prefix trees. I didn't even know the meaning of these words. Rank 1 developers should be able to estimate the temporal and spatial complexity of algorithms for sorting, searching, inserting, and splitting. I would not tell you the time complexity of a banal depth-first search in a binary tree.
Why did I have so many knowledge gaps? There were two reasons.
First of all, I studied computer engineering, not computer science. The focus was on the integration of software and hardware rather than the development of large systems. This orientation taught me to solve complex problems in dubious conditions, but the program did not provide for a detailed analysis of data structures and algorithms at all. Secondly, I didn’t go through a full-fledged preparation process, I didn’t spend hundreds of hours studying - that’s why I didn’t learn.
I myself realized that I was not keeping up. At first, the impostor syndrome tormented me with terrible force.
First pancakes
Every code inspection was a disaster. I submitted a snippet for review (in the form of a request to accept changes, for example), it was returned to me with eighty comments. It won't do. I corrected and submitted a new version. Fifty more comments. It won't do. And so on and so forth.
With some fragments, things were so bad that colleagues simply did not know how to explain the essence of the problem for me to understand. They had to download the code and rewrite it. They wanted to help me and were quite friendly, but I literally burned out with shame. I lived in fear that people would understand: I don't belong here. Not a single working day passed without the thought that today I would be fired.
Exposing the impostor
Little by little I pulled myself up. Finally, I began to meet the deadlines and consistently give the code to production. About nine months later, I developed self-confidence. I decided it was time to get rid of the impostor syndrome once and for all. I turned to problems on LeetCode, just to prove to myself that I was in my place. I remember thinking, “I'm now a full-fledged developer at Amazon. I have commits in production. Why, I can't cope with these simple tasks? "
I chose one of the easy ones on LeetCode - and I couldn't solve it. I chose another - and I couldn't either. And the third and the fourth. Then it became clear to me that I did not suffer from any syndrome. I am an impostor.
Be, not seem to be
After two and a half years, I was promoted to the second rank developer. A developer of the second rank is able to create and maintain a large system on his own with minimal assistance from outside. So how did I do it? How did I manage to reinterpret the rules of the game in my favor?
Well ... no way. At Amazon, shenanigans don't work. The system cannot be replayed. “Pretend to be a specialist until you succeed” is a very common and very bad advice. This does not work. The only way to get yourself appointed as a tier 2 developer is to become a tier 2 developer.
Promotion is a grueling process. You need to describe your merits and achievements on more than twenty pages of documentation, so much so that colleagues and bosses believe. You need to constantly collect metrics and evidence that your success is at a higher level. You can count on an increase only if you consistently hold the bar of the next level for six months, or even a whole year.
You've probably heard the phrase: "Our personality is made up of what we do regularly." Below I will tell you what actions I took to stop being an impostor and establish myself as a higher-level developer.
What did I do
Tuning in to maximize feedback acceptance
Newcomers to FAANG often have inflated egos. This deprives them of the ability to accept and take into account constructive criticism from colleagues. But these colleagues are smart people, each of whom has their own unique experience in the field of IT behind them.
I didn't have any problems with self-esteem. For me, in an amicable way, there was nothing to do in the company. Therefore, when I was given feedback, I listened, and listened thoughtfully.
Colleagues' comments were true, controversial, or incorrect. If the remark was correct, I followed the advice without reservation. If it was about something controversial, I first tried to understand the point of view of another developer, and only then - to convey my own. And, all of a sudden, I was listening to even the wrong remarks.
In this case, the train of thought was: “Why am I sure I’m right? What led a person to such an idea? Can I somehow clarify so that such a reaction does not arise? " This is what I call maximum openness. Smart people, even when they are wrong, proceed from something in their conclusions. I figured out what it was from and improved my code with this information in mind.
Asked stupid questions
Newcomers to FAANG companies often try not to ask questions - they are afraid that they will be thought badly. This element of the impostor syndrome paradoxically coexists with inflated conceit. Well, I, as a true impostor, understood perfectly well that my questions were stupid. It didn't bother me.
For instance:
« , . , ?»
« , ?»
« , . - ?»
Very soon, I got hold of hundreds of bookmarks, collected tons of additional information, and became very successful at participating in meetings.
Found a Restless Code Inspector
At first, it is very important that as many other developers as possible review your code. Each employee conducting an inspection will have their own preferences, nagging, pet peeves. But it is even more important to figure out the restless inspector.
There is one in any team. His job is never satisfied. It clings to the name of every variable, every log, every selected API parameter. I made a special effort to find this person and toss my code to him as often as possible. Why? Because I understood: the more constructive comments I receive, the faster the training will go.
Used existing patterns to avoid mistakes
Juniors often try to reinvent the wheel. Most development tasks are nothing new. Before starting to write the requested code, I was looking for similar solutions on internal resources. I looked through several different examples, delving into how the code is structured in them. Then I turned to my team's code and figured out how best to tie the new fragment to the general system.
I took the same approach when writing design documentation and post mortem reports. Samples first, then actions.
Focused on correctness and appropriateness
I avoided the sunk cost trap. If I am doing something wrong, it doesn't matter that I have already spent four hours on it. I knew that I would have to brush aside what I had developed and redo it in the right way.
For a hundred lines of code sent for inspection, there were two hundred and fifty lines of garbage that I wrote and threw away. I tried to ensure that each of these hundred lines was understandable, written purposefully and was needed for something. Now my code usually gets greenlit after one or two revisions.
Throwing yourself into the heat
You will never feel "ready" to work on key functions, deploy projects to production, conduct interviews, and eliminate emergencies. The best way to prepare for all this is to take it and do it.
At the first opportunity, I simply told my boss: I am ready. Even if before that I did not have the opportunity to observe in detail the actions of others, as is usually advised. Sometimes I had to ask for help or for someone from my colleagues to follow my work. But ultimately, it allowed me to expand my comfort zone and accelerate my growth.
Taking initiative in the little things
I noticed opportunities to improve the operational excellence of the team, work processes, development experience. More than once or twice, I voluntarily took on boring tasks: I automated procedures that were performed manually, finalized the documentation, improved the CI / CD pipeline, refactored the legacy code.
I tried to be professional
Programming is a type of creativity based on logic. Each task, each new function, I perceived as a blank sheet on which you can show your skill and leave the creation.
The second tier developer must be a software engineer, or a professional, according to Stephen Pressfield, author of The War of Art. I threw all my strength into writing clean code (you should definitely read the book of the same name) and create beautiful, elegant solutions.
He clearly indicated his desire for an increase
In FAANG companies no one offers an increase - you ask them yourself, and more than once. If this is not done, the process will drag on for many months.
In private conversations with the boss, I made it clear that I wanted to be promoted. I asked for feedback to understand which areas were sagging. I objectively evaluated the results of the completed work and accepted criticism when it came to me. I looked for opportunities to hone skills and close the gaps. If I was able to show off some skills, I tried to keep the feedback in writing. After all, you cannot predict when the next restructuring will take place and your boss will change.
Putting job for promotion ahead of other
I understood: you cannot work only and exclusively for promotion. If everyone does this, the team atmosphere will definitely become unsuitable for life. But at the same time, I literally put the tasks that I needed for promotion in the first place.
That is, if I needed to focus on an important function, the deadlines for which were tight, I took on it from the very morning. That way I could be sure that I had enough time to do the job well. If I needed to more actively conduct code inspection, then the morning hours were spent on it. If I needed to attend interviews more often, I started my working day by signing up for the upcoming ones.
Constantly collecting evidence of my success
One cannot do without the ability to present one's achievements through a combination of quantitative and qualitative indicators.
Before taking the task to work, I looked for metrics that outlined the current state of the system. Upon completion of the work, I looked at the new indicators and performed calculations to understand to what extent my actions influenced the situation. And finally, I recorded everything related to the task in the documentation that was supposed to serve as a justification for the increase: STAR analysis, quantitative indicators, links to code inspection results, graphs and other relics of work.
I realized what depends on me and what does not
I came to understand that anything can happen. Sometimes a team is missing important functions. Sometimes projects are closed. Sometimes, due to restructuring, management changes. Sometimes the CI / CD pipeline is already perfect and there is simply nothing to improve in it.
And at the same time, I realized that if I focus on working to the limit and approaching tasks professionally, I will be ready for the moment when the opportunity to show myself appears. The opportunity arose - he showed himself to be a professional. This brought a few more opportunities - again I did everything on the level. Etc.
Reflections
Is the “Leetcode culture” that has developed in the hiring process harming the business?
I managed to successfully gain a foothold in Amazon, although when I first arrived, tasks with Leetcode were too tough for me. Then, when I myself began to conduct interviews, I, of course, purposefully disassembled all the necessary algorithms and data structures in order to be able to evaluate the candidates' responses.
I think the current approach pays off. Companies are interested in people who have the perseverance and motivation to learn new things and use this information in conjunction with existing skills. The established processes do a good job of selecting such people.
So it's easier to get into rank 1 developers through an internship?
I wouldn't say that. These two interviews are usually no easier for interns than five interviews for full-time employees. When I interviewed in 2014, I left out of luck. If someone decides that they will definitely get the same simple questions as me, then they are sabotaging themselves.
In the company, the same requirements are imposed on interns as for developers of the first rank. Every aspect of the work is examined almost under a microscope. I knew a lot of programmers who had completed their internship, but they never got a job offer.
During these five years, I myself have trained several interns and now, looking at the process from the other side, I understand how high the bar is set for them. Now, looking back and evaluating my internship work, I realize that I did a good job that summer and really deserved to be promoted to developer.
So Amazon shouldn't have hired you?
Until recently, I was inclined to answer in the affirmative. There is no doubt that my programming knowledge at that time did not meet the requirements. But gradually I came to the conclusion that in the long term, the company made the right decision to hire me. I've definitely brought tangible benefits to Amazon.
I made AWS safer, had a hand in education and sales programs. I have provided solutions to a large number of both internal and external clients. I have given introductory courses to audiences of several hundred people. I became a mentor to many programmers who aspired to get into second-tier developers. Before joining Amazon, I was the captain of the soccer and basketball teams, both of which made it to the quarter-finals in Virginia. Over the years I've honed my skills in working with people and leading people - these skills came in handy at Amazon. In the future, I hope to give the developer community even more because I know what it is like to be an impostor.