#mypathtoamazon #part1

My path to Amazon: from math notebooks to 'Hello World'

It has been 3 years since I have been working at Amazon, but I realized I have never talked about my path towards Amazon.

This is Part 1 of 3 in a series of articles detailing my journey to Amazon.

Read Part 1 of the article: https://abdullaev.dev/my-path-to-amazon-1/

Stay tuned for Part 2! 🤝

#mypathtoamazon #part2

My path to Amazon: breaking into the tech industry

In this part of the journey, I share how I landed my first programming job early on the path to Amazon, the impact of having a strong mentor, and how the power of networking opened new doors.

This is Part 2 of 3 in a series of articles detailing my journey to Amazon.

Read Part 2 of the article: https://abdullaev.dev/my-path-to-amazon-2/

Stay tuned for Part 3! 🤝

If you're into AI and LLMs, and want to hear from a PhD researcher in AI at National University of Singapore (QS rating #8), you can join a live session on the topic:

Applied Math: Real-World Use Cases in AI & Robotics

A little bit on the speaker, Laziz Abdullaev (Google Scholar):

- Published cutting edge scientific papers on the top AI conferences: NeurIPS, ICLR
- International Olympiads medalist on Mathematics
- Current Research Science intern at Rakuten

You can join the live session starting in ~5 minutes.

Earn trust of the two

One of the most important lessons I’ve learned as a software engineer:

You need to earn the trust of two people on your team:
your manager, and the most senior engineer.

These two people quietly shape your entire career in that team and beyond.

Your manager decides what projects you work on —
but before assigning anything meaningful, they’ll often ask the senior engineer:

Do you think he/she can handle it?

That conversation usually happens when you’re not in the room.
So if you want to grow, you need both of them to believe in you.

For managers, trust comes down to one thing:
Don’t let them down.
If you say something will take two weeks — mean it.
Don’t casually underestimate timelines just to sound fast.

And if you hit a roadblock, communicate it as soon as possible.
Managers don’t need you to be perfect — they need you to be dependable.

For senior engineers, trust is technical and long-term.
They know what shortcuts look like — and they know who leaves tech debt behind.
If you consistently choose the “just ship it” path, they won’t recommend you for more responsibility.

What earns their trust?
Taking initiative. Automating the painful stuff. Thinking about how your decisions impact the system months from now.
They want to see that you care about the health of the codebase — not just closing tickets.

When you have both their trust, everything changes.
You get better projects. More autonomy. Promotions start feeling possible.

The Software Engineering Triangle: pick 2 out of 3

Software engineering is the science of trade-offs. As engineers, we design, build, and ship software — and stakeholders almost always want it fast, cheap, and good... But can you make all three happen at the same time?

Read the article: https://abdullaev.dev/the-software-engineering-triangle-pick-2-out-of-3/

#projectmanagement #projectdelivery

High velocity decision making: one-way door vs. two-way door decisions

For any successful company, making high quality decisions is required but not sufficient.
You must make high quality decisions and make them fast.

Amazon developed a mental model to help achieve this. One of the well known concepts introduced by Jeff Bezos is "one way door vs. two way door decisions".

Imagine a decision as a room with a door. If it is one-way door decision, you enter a room, but there is no way (or cheap way) out. If you pick a two way-door decision, you can go into the room, evaluate, and if not as you expected, you can just go out via the door again (revert easily).

As an example, say you decide to migrate your entire backend to a new cloud provider, migrate terabytes of data, educate ops team, rebuild the tools. All of this costs significant money and time. It could have been better to spend time upfront clarifying the strong "why’" and recognizing early if it’s a one-way door decision.

But something like changing the retry policy on a downstream service call from 3 to 5 is a two way door decision. You don't need to waste time doing days of analysis, just go do it. If it improves availability - keep it, otherwise revert your commit - as cheap as that.

Key takeaway: use the door (decision) type to decide how much time to invest — not every decision deserves a week of analysis.

#monitoringatfaangscale

No Monitoring, No Launch

This is an introductory article from my series of articles (a mini-course) on ‘Monitoring at FAANG scale’.

Monitoring is the practice of collecting and analyzing system metrics, logs, and events so you can spot issues early, understand performance, and get alerted when things go wrong.

When there is no monitoring, there is no launch… also, there is no lunch 🥘😁. Ship a service without monitoring (or with bad monitoring), and while everyone else enjoys their lunch, you’ll be fire-fighting production issues.

Read the article: https://abdullaev.dev/no-monitoring-no-launch/

See you in the next articles as I dive deep into Monitoring at FAANG scale!

My 3 years at Amazon (so far): 3 key lessons learned

I joined Amazon on September 1, 2022 — and today celebrating my 3 years of Day 1’s 🎉.

These 3 years have been AWSome — full of growth and valuable experiences, some shaped by lessons learned from mistakes.

Today I wrote an article on the most important lessons I learned along this journey so far.

👉🏻 Read the article: https://abdullaev.dev/my-3-years-at-amazon-3-key-lessons-learned/

A conversation with a Senior engineer about a broken code library

Me: Hi, do you know who owns this library? I need some help with an issue.

Senior engineer: "Remember: success has many fathers, but failure has none"

Me: 🫠

🔎 The Search Engine of AWS

When I first started using AWS (as a customer) back in early 2020, I was super eager to try out many of the services in different AWS regions. Honestly, it's hard not to - just look at the gallery of shiny service icons!

I was cautious with my resource usage to not to breach my free tier limits. Luckily, almost each AWS service has its own AWS Console UI that I used to search for my created resources in that service and delete them when not needed. But over time, I experimented with multiple services and regions and I forgot which specific service console and in which region I needed to go to delete the unnecessary resources.

I had noticed the search bar on the top, but it had only worked for searching AWS service names and the documentation.
So I couldn't get an easy answer to a question like "What are all my EC2 instances created across all regions in my account?"... back in 2020.

In 2022, AWS launched a service called AWS Resource Explorer, which gave customers the Google-like search experience for the actual AWS resources. It supports search across all regions, and across all accounts in your AWS Organization in a single console, and also via the search bar on the top 🎉.

Today, I'm proud to say that I currently work (as my 2nd team) in one of the teams part of AWS Resource Explorer powering core functionalities like resource discovery, helping AWS customers (like myself from 5 years ago 🙂), to search and discover their AWS resources.

React with 👌 if you'd like to read a similar post about my first team at AWS.

🚨 The Police of AWS

When I joined AWS, my very first team was AWS CloudTrail – the service that records API activity across your account, giving you visibility into who did what, when, and how.

As a customer back in 2020, I often asked myself questions like:

Who created this IAM role?

When was this S3 bucket policy changed?

Why do I have EC2 instances running when I don’t remember starting them?


At that time, I discovered CloudTrail and realized it’s basically the “security camera system” of AWS. It tracks every API call across services, whether from the console, CLI, SDKs, or even from services acting on your behalf.

When I joined CloudTrail as an engineer as my first team at AWS, I got to work in the Integrations Monitoring team. As soon as I joined, I started designing a new proactive integration health monitoring system between AWS services and CloudTrail and led its design, implementation and global deployment across 30+ AWS regions worldwide.

Today, I’m proud that my AWS journey started with CloudTrail, building the foundation for visibility and accountability in the cloud. Without observability, there is no security (which is "job zero" at AWS) – and CloudTrail gives customers that critical lens into their AWS activity.

Root cause analysis of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region on Oct 20, 2025:

https://aws.amazon.com/message/101925/

How AWS raises the bar for Code Reviews (CRs)

In my first team at AWS CloudTrail, we had the CR Bar Raiser mechanism.

CR Bar Raisers are a group of engineers handpicked by senior and principal engineers within the org. The selection is based on your past code reviews: 1) the technical depth of your comments, 2) evidence that you are steering code authors to produce high quality, well tested and the right changes for our customers.

Every CR/PR submitted is automatically required to have at least 1 approval from the CRBR group before merging.

I was fortunate to be also elected as one of the CloudTrail Code Review Bar Raisers (CRBR).

In the upcoming few posts, I will be sharing some of my own review practices as a CRBR at AWS, so that you can also bar raise your team's codebase.

#aws #cr #pr #codereview #crbr

Code Review Bar Raiser Series, Part 1
Separate Behavioral and Refactoring Changes

Similar to everything else in Software Engineering, the code review (CR) process is all about trade-offs.
As a CR author, you probably care about 2 things:
1) ensuring your reviewers catch any bug you might have missed
2) helping them do it fast, so that you ship faster for your customers.

But in reality, you submit a two-page CR and either get an instant "LGTM!" (Looks Good To Me) in two minutes, or if you’re lucky, some thoughtful comments two days later. So you realize you’re only getting half of what you wanted, not both!

As a CRBR, it was my responsibility to help CR authors achieve both. So whenever I got a review request, the first thing I checked was: are these changes focused purely on business logic, or are they mixed with refactoring and cleanups? If it was a mix, I'd immediately ping the author and ask them to split it into two CRs: one for behavior changes, one for refactoring.

As an example, look at the following diff. At a glance, it looks like a refactoring change: a big chunk of reformatting, introduced User class, renamed parameters. But looking deeper the author is also modifying the behavior: added a duplicate check and a new exception "User already exists".

--- a/src/user_service.py
+++ b/src/user_service.py
@@ -1,22 +1,31 @@
-class UserService:
-    def __init__(self, db):
-        self.db = db
-
-    def create_user(self, username, email):
-        if not username or not email:
-            raise ValueError("Invalid input")
-        user = {"username": username, "email": email}
-        self.db.insert(user)
-        return user
-
-    def get_user(self, username):
-        return self.db.find_one({"username": username})


+import logging
+
+class User:
+    def __init__(self, name, email):
+        self.name = name
+        self.email = email
+
+class UserService:
+    def __init__(self, database):
+        self.database = database
+
+    def create_user(self, name, email):
+        if not name:
+            raise ValueError("Username cannot be empty")
+
+        # new: check for duplicates
+        if self.database.find_one({"name": name}):
+            raise ValueError("User already exists")
+
+        user = User(name, email)
+        self.database.insert({"name": user.name, "email": user.email})
+        logging.info("User created: %s", name)
+        return user

A reviewer now has to mentally separate what logic actually changed from what was just cleanup or renaming, which increases review time and risk of missing subtle behavior bugs.

And that’s exactly why I started insisting on separating behavior changes from refactors. It keeps reviews focused, and everyone (including future you and your customers) ends up happier.

#aws #crbr #cr #pr #codereview