Becoming a builder

On August 15th, 2022, I joined AWS RDS, as a Software Development Engineer. Now, in reflection of my time so far, I thought it would be a good idea to collate my thoughts, reminisce about the journey here, and share some knowledge.

Everything written here is strictly my own opinion and is not representative of any external entity and/or company.

Everyone says to shoot your shot. For there to be something to gain, you must at least try. That "You miss 100% of the shots that you don't take". I really do wish it was that easy to do.

It's so easy for an engineer (or any professional) to fall into a pit of imposter syndrome. These days, knowledge, learning, and sharing are so accessible. But this all comes at a cost. Because everything is so available, It is very easy to get into a pattern of comparing yourself, and downgrading your accomplishments to become "this thing that I also found on the internet that was better".

At the very least, this is how software engineering was for me. I simply thought I was incapable of improving, striving and performing at the highest level, and to be frank, think this is how probably I'll be for the rest of my career; in a continual cycle of imposter syndrome.

And that's why this application was so important to me.

As much as I believed that I couldn't, for some reason I felt compelled to be told I wasn't. To be told means to be told you've not made the bar, and that's okay.

This is the sense of validation that I wanted to attain and ultimately wanted to achieve. I wanted to learn what it meant to contribute to a team creating the most advanced systems. To learn what It takes to create something at a scale at Amazon. To learn what engineering at the highest level meant.

Never did I expect to even get past screening, let alone get interviewed but at the very least, I had a shot to learn what it meant to be a builder.

Unfortunately, I won't be able to disclose much of what happened in these stages but will still be able to share my learnings and externally available material that you can use as a reference.

What?
No Way.
Is this a typo?
This doesn't seem right
I haven't even touched Leetcode!

Those were (somewhat) the words that spat out of my mouth when I got an email to be phone screened. You can possibly understand my surprise when Amazon considered my application and gave me a shot to make their bar. Everything seemed counter-intuitive and wrong but in the thick of it all, it was there. So I booked my time and sat down in amazement.

After this revelation and a small sense of fulfillment that I had made it past screening, a huge sense of anxiety kicked in when I realized one major major issue; I have literally never Leetcoded. Heck, I don't even know how to do a depth-first search right now. What is even a Heap? Hash map? Is that the pattern that hash browns make when they're fried? What am I even doing?

Of course, this is not a post of failure (but I definitely did feel like one at times 😅). You can read about my Leetcode experience here.

At this point, I was just confused. For me, someone who only had ever done technical interview loops once, to make it this far and still be in one piece felt somewhat like a miracle. Not only could I achieve what I wanted when applying, that is to learn and inevitably get rejected, but I had a real shot to actually make it all the way.

"This is nuts!" - me at some point lmao

As aforementioned, I will not actually write about what went on in those interviews, but there were a few personal learnings that I can share.

1. Those who have done it know best but those who conduct know better. This was my number one takeaway from my preparation for the onsite. When I realized this, I realized there were only a few sources that I could use as good preparation material to understand what I meant for an engineer to pass these interviews. Some of these include
   1. A Life Engineered
   2. CRACKING the CODING INTERVIEW
   3. Interview preparation forums
      1. Leetcode
      2. TeamBlind (be careful!)
      3. Cs Career Questions (OCE Version)
2. It's not about the result but the journey. Anyone could get an answer but I don't think that this is how anyone should be approaching these on-site interviews. I believe that a good engineer should be able to articulate and explain their approaches just as well (and oftentimes better) as the performance of the final outcome.
3. It is a learning experience. In situations like these, engineers are taking their time out to not just evaluate you as a candidate, but to answer your questions as well! It is a two-way street. I was able to set out and learn things like what it meant to operate at Amazon's scale, the standards of development, engineering philosophies, etc... These engineers are amongst the best in the world and have seen it all!
4. More resources directly from amazon.jobs
   1. Interviewing at Amazon
   2. How to prepare for remote interviews
   3. FAQ

Yes, It actually happened.

To be honest, I don't remember too much about this. I do however, remember that it was a lot of disbelief, crying, heart-racing adrenaline, and even more disbelief. It still feels quite surreal. I even remember the song that brings me back to the moment every time (it's really random but it's a bop lol).

As someone who never even expected to make it past screening, to have the chat about the offer and my role at AWS, it all seemed quite too much. That being said, when asked the question "What excites you most about Amazon?", my response has always remained the same; the people.

Being able to work amongst the best engineers in Australia and the world, learn from their experiences and work with them to deliver the world's most complex and high-performing systems (and solve a lot of problems along the way!) is something of a dream for me.

Every now and again (probably until the end of time), I feel like an impostor. One who never should be here. Perhaps that is due to a lack of self-confidence, or just a fact. Though one thing is for sure is that even in trying, you should be proud of the things that you learned and embrace failure and your deficiencies.

Some day, those failures will somehow make you trip and fall past the finish line, no matter how impossible this may seem.

Now that we've covered my character-building arch, I guess it now is a good time to go through all my learnings. In good Amazon spirit, I will use Amazon's Leadership Principles and dissect a few key things that I have picked up in my time.

It is so easy to make things for yourself. You know what you want, what you like, and what you need. However, when you are engineering something that is used by many other people, it's important to work backwards.

This is something that I've grown to see personally as quite a challenge to undertake. Logically, anyone making something for someone else must account for their needs and their wants, but the challenge becomes so much more difficult when your user base is large and/or doesn't even know what they want out of a solution (i.e something greenfield).

There are so many problems to be solved and new innovations to be made, and as an engineer, I want to be in the depths of making new things, solving these complex problems, and writing code.

But ultimately there's no point in solving problems for customers that don't need to be solved, or even worse, don't even exist!

Not all problems are made equal, and it's your job as an engineer to find this priority list and make impacts that will make the most positive difference.

Prior to joining, it was very easy to try to be excited about the first half of this Leadership Principle; Invent. There are so many new technologies to use, new innovations to find, and challenges to tackle. It is what makes my job so exciting and continually drives me to become better at my craft.

But what about that second part; simplify?

At first, it seems quite counter-intuitive. Often we equate Invention to complexity but that doesn't have to be the case. If anything, the best inventions and impacts that I have seen so far are to simplify a complex structure or problem.

Personally, I have discovered 2 two reasons/sources to represent this

• Enabling deeper invention through a reinvented but simplified solution. This could be something like Canva and their vision to simplify design for everyone.
• The developer is a customer too! We don't write code and create solutions for computers, but for people. The more simple something is, the better developers can work on it and the better impact that it has on the people that will use the product.

I think these types of improvements are definitely taken for granted. It's so easy to say that something just works, but is that really enough? Is the fact that a product works enough for it to be a good product? It's definitely easy to think so, and I did for a good time too.

Now I think developers should celebrate simplifications as much as they celebrate new inventions. Positive change doesn't always announce itself straight after but undertaking these positive changes is what should be done.

Unfortunately, these impacts don't get as much recognition (or support) as they may not don't often drive immediate "value". This is why learning how to work backwards and identify what positive changes are worth their value is so valuable.

Achieve invention by striving for simplicity I say.

"That'll do" won't do.

Often In my early career, I have heard "it is what it is" when referring to any struggles and challenges that appear to be solvable, but are often not and are left the way that they are, continuing to inhibit productivity and progress.

There are so many ways to approach creating a new solution. Every engineer has their own preference, style, technique, and knowledge. However, as things change, pressure is put on us, or solutions are rushed, everyone is affected.

As someone who has had this drilled into my head in my time working in the kitchen during university, standards are the be-all and end-all. I think that any good engineer understands that you can only be as good as your standards. This feeling has been amplified more than ever since joining Amazon and I have become more committed to not compromising on my own standards.

This is not to say that compromises cannot be made and that all design decisions should be altered so that the "best" and "most cutting-edge" solutions must be used. What I am instead indicating is that these compromises are often dictated according to the standards and requirements that you are operating at. You should always look towards making the best contextual solutions that comply with your standards, not just the best solution objectively.

Solve problems that will help others and continue to elevate the standard by working backwards and taking ownership of problems that fall below your standards. Reinforce these ideas with factual and objective statistics to formulate the requirement and evaluate the impact that can be achieved.

Hold yourself accountable and do what needs to be done. You will feel so much better that you did what you set out to do to improve the standards.

Oh gosh.

This was, and still is, the most challenging thing to get down right.

It's so easy to follow the flow of a decision. It's easier, less dramatic and less stressful.

But is it the right thing to do?

Building up the courage to make these calls has been, and still remains, the largest challenge of my career thus far. Sometimes I will stay silent for the sake of moving on, or just because I'm nervous to question a decision or provide input.

But it stands as the most useful skill I have continued to actively develop in my time thus far.

The insights that probing has provided me have been extremely valuable. Being able to question and/or disagree about a decision leads to more insights into the drive behind these decisions and allows me to understand larger and deeper perspectives behind a rationale. In some situations, you may even be able to identify fundamental errors or issues by simply initiating that conversation as well!

For those that feel down (like me) when they themselves are questioned, I always try to remember that it is not an input on you personally but rather your solution. Solutions should be molded and adapted by what is shown to be right and should never be absolute!

It's okay to be wrong! Eventually, you'll be wrong so many times that you'll start becoming right, a lot.

It's been a lightning 3 months and I've been able to see, learn and perceive so much. Working at AWS has been an absolute blast and I've been able to not just improve, but realize so many things that I thought were just dreams.

Although long, these are just a snippet of what I've been able to learn in my time here at RDS. There are just so many things to do, so many things to accomplish and so many things to learn.

For anyone who is interested in working at Amazon, please visit Amazon.jobs or reach out to me. There are many opportunities open for people from all kinds of backgrounds so don't hesitate to take that next step.

I know I'm glad that I did.