Today marks exactly four years since I joined Amazon as a fresh graduate. February 28, 2022 β I remember the date because I remember the feeling. I was sitting in my apartment in Dallas, TX, the night before my first day, with a laptop and a badge that had been mailed to me. No office to walk into β I was fully remote. I had moved from Pakistan to the US a couple of years earlier for my master's at UT Dallas, survived a pandemic, grinded through internships at Copart and Text-Em-All, and now I was about to start at one of the biggest tech companies in the world. From my apartment. In sweatpants and t-shirt, probably. I didn't feel ready. I don't think anyone does.
Four years later, I'm writing this from Seattle, WA. I started working remotely from my Dallas apartment, then a few months later started going to the Dallas office, and ultimately relocated to Seattle β a city I've grown to love. Same team. Same manager. Same org. At a company as large and fast-moving as Amazon, it's common for engineers to switch teams, for orgs to restructure, and for managers to rotate. That's not a bad thing β it's the nature of operating at this scale. But my experience has been different. Four years of consistency, and I don't take that for granted.
I work in Amazon Shopping Videos, specifically on the video distribution team. If you've ever watched a product video on a detail page, search results, best sellers, homepage, or buy again β chances are my team's code served that video to you. We own the video players and the distribution layer that puts videos β from sellers, vendors, influencers, third parties, and customers β in front of hundreds of millions of customers. It's not the flashiest work. It's not AI. It's not what makes headlines. But it's the kind of work that quietly powers a massive part of the shopping experience, and I'm proud of it.
Over these four years, I've launched video experiences in new marketplaces across three continents. I've built the backend for conversation history workflow on Rufus, Amazon's AI-powered shopping assistant. I've migrated 25 million video votes between systems. I've set up load test infrastructure for Prime Day and Black Friday traffic. And much more. I've even done a bunch of frontend work β which, I'll be honest, I didn't always respect as much as I should have with my MS CS degree. But shipping a feature that millions of people interact with humbles you pretty quickly, regardless of whether it's backend or frontend.
But this blog isn't about listing my accomplishments. My resume does that. This blog is about what I actually learned β the things that no one tells you when you're starting out, the things I wish someone had told me when I was a student at NUST in Pakistan wondering if I could ever make it to a place like this.
Lesson 1: Be Self-Driven
This is the difference between engineers who grow and engineers who plateau. And I learned it the hard way.
When you're in college (especially in Pakistan) the system trains you to follow instructions. There's a syllabus. There are assignments. There's an exam at the end. You do what's asked, you score well, you move forward. That model works in school. It does not work at Amazon. Nobody is going to hand you the right project. Your manager has their own problems, their own deliverables, their own meetings that eat up the day. If you sit around waiting for someone to tell you what to do, you'll end up working on whatever falls through the cracks β and then wonder why you're not growing.
I have noticed the engineers who grow fastest are the ones who identify gaps before they're assigned. Who look at the roadmap and say, "this thing is missing, and I think I can build it." Who write a one-pager for a project that doesn't exist yet. Who volunteer for the work that's ambiguous and undefined β not because it's easy, but because that's where the most learning happens.
I observed the top engineers look beyond their immediate sprint stories and ask: What are the major pain points where team is spending the most time? What's the problem manager keeps mentioning in standup but never has time to tackle? That shift in mindset β from "what's my next task?" to "what's the next problem worth solving?" β will change everything for you.
If you're a young engineer reading this, especially from South Asia where we're often taught to defer to authority and wait for direction: stop waiting. The direction is yours to set.
Lesson 2: Be Competent
This sounds obvious. It's not.
Competence isn't about being the smartest person on the team. It's not about writing the most clever code or knowing every design pattern. Competence is about being reliable. When your name is on a project, people should trust that it will be done right. The code will be tested. The edge cases will be handled. The oncall will be covered. The documentation will exist. The deployment won't break at 2 AM.
I think about the video votes migration I led β moving 25 million video votes from one system to another. Nobody cared whether I used an elegant algorithm. What mattered was: did I have a rollback plan? Did I test at scale? Did I think about what happens when something goes wrong in the middle of the migration? Did I communicate the risks upfront? That's competence. It's not glamorous. It's earned trust.
At Amazon, there's a LP (Leadership Principle) called "Earn Trust." Of all the LPs, it's the one I embody most β not just at work, but in life. Earn Trust means you listen attentively, speak candidly, and treat others respectfully. It means you're honest about your mistakes instead of hiding them. It means you benchmark yourself against the best, not the average. I've found that when you consistently show up with integrity β when you admit what you don't know, when you own your failures as loudly as your wins β people trust you. And trust, once earned, opens every door that talent alone cannot.
There's a myth in tech, especially among new grads, that the engineers who get ahead are the genius 10x coders who write brilliant solutions. In my experience, that's not true. The engineers who get promoted are the ones whose systems don't break, whose designs are clear enough for anyone to understand, whose PRs don't need five rounds of review, and whose operational issues are minimal because they built things properly in the first place.
Be the engineer that people want on their project. Not because you're the most talented β but because they know that if you're on it, it's going to be done right. That reputation compounds over time, and it's worth more than any individual technical feat.
Lesson 3: Build Great Relationships β Be the Visibility Champion
This is the lesson that engineers β especially introverted immigrants who might feel culturally hesitant to self-promote β resist the most. I know because I resisted it too. Growing up in Pakistan, I was taught that hard work speaks for itself. That if you put your head down and deliver, people will notice. That self-promotion is boastful and unnecessary. It's not true. Not at a company with 1.5 million employees. Your code will not walk into your director's office and introduce itself.
I've had the same manager for four years. That's unusual at Amazon, and it's been a blessing. But even with a supportive manager, I had to learn that managing up matters. Keeping your manager informed. Making their job easier. Ensuring your work is visible at the right levels β not just to your immediate team, but to stakeholders, skip-levels and partner teams. Writing documents that get read. Presenting at team meetings. Volunteering for cross-team work that exposes you to new people.
When I started mentoring junior engineers at Amazon, it wasn't just about giving back. It built my reputation beyond my immediate scope. When I worked on the mobile native application, it connected me to teams and people I would never have met if I'd stayed in my lane. Every relationship you build is a door that might open later β for a project, for a recommendation, for an opportunity you didn't see coming.
I'm also training to become a bar raiser for A/B testing experiments, which pushes my visibility even further across the org. None of this happened by accident. It happened because I learned, slowly and sometimes painfully, that great work in isolation is invisible work.
To the young engineers from Pakistan and South Asia reading this: learn to talk about your work without feeling like you're bragging. There's a difference between arrogance and visibility. Arrogance is claiming credit you don't deserve. Visibility is making sure the credit you do deserve actually reaches the people who make decisions about your career. Get comfortable with that distinction. Your career depends on it.
Lesson 4: Be a Strong Communicator β Especially in Writing
Amazon is a writing culture. The 6-pager. The PRFAQ. The design document. The weekly status update. The operational review. Everything starts with a written document. And I'll be honest β when I first joined, this was hard. English is not my first language. Writing a technical document that's clear, concise, and persuasive is a different skill from writing code. It takes practice. A lot of practice.
But here's what I discovered: writing is not just communication. Writing is thinking. When you force yourself to write down your design, your reasoning, your trade-offs β you discover gaps in your own understanding. You find the questions you hadn't thought to ask. You realize that the approach you were so sure about has a flaw on page three that you wouldn't have caught if you'd just jumped into code.
The best engineers I've worked with at Amazon are not necessarily the strongest coders. They're the clearest writers. They can take a complex, ambiguous problem and distill it into a document that makes the solution feel obvious. That's a superpower. And it's learnable.
This lesson extends beyond Amazon. In a world where AI can generate code, the engineer who can clearly articulate what to build and why becomes more valuable, not less. AI can autocomplete your function. It cannot write your strategy document on its own. It cannot convince a room full of senior engineers that your approach is the right one. It cannot write a crisp escalation email at 2 AM when your system is down. The ability to communicate complex ideas clearly β in docs, in code β is the most durable skill you can build.
If you're starting your career, start writing. Blog posts. Internal design docs. Even Slack messages. A book that helped me tremendously is "On Writing Well" by William Zinsser β it taught me that good writing is about clarity, simplicity, and stripping away everything unnecessary. That lesson applies to code, to docs, to emails, to everything. Every time you write, you're training yourself to think more clearly. You're not just communicating to others β you're organizing your own understanding. And that compounds in ways you can't imagine yet.
On the Fear of AI β A Message to Young Engineers
I can't write this blog in 2026 without addressing the elephant in the room. Every week, I see posts from engineers β especially from Pakistan and South Asia β asking if it's still worth pursuing software engineering. If AI is going to take all the jobs. If the dream of working at a big tech company is dying.
I understand the fear. It's real. AI tools are genuinely changing how we write code. I use them myself. They make me faster. They help me prototype. They write boilerplate I used to write by hand. That part is true.
But here's what I've learned in four years of building software at scale: code is the easy part. The hard part is understanding what to build. The hard part is designing a system that handles thousand(s) transactions without breaking. The hard part is navigating ambiguity when three teams have conflicting requirements. The hard part is debugging a production issue at 2 AM when the dashboards are all red and you need to make a judgment call. The hard part is writing a document that convinces leadership to invest in your idea. AI, on its own, can't do most of that today β and even as it gets closer, the engineers who understand these problems will be the ones guiding it.
Will AGI Eventually Do All of This?
Maybe. I honestly don't know. But here's what I do know: the engineers who will feel the impact first are the ones who only know how to write code in isolation β take a well-defined ticket, write a function, submit a PR. AI can already do that faster than you. The engineers who understand systems, who own products, who communicate clearly, who build relationships, who drive decisions β they, in my opinion, have more runway. Not because they're irreplaceable forever, but because those skills are the hardest to automate and the most valuable while the transition happens.
And if AI Does Eventually Do Everything?
Then the people who understand how to work with it, guide it, and ask the right questions will still be the last ones standing. Either way, these skills are your best bet.
So to the student at NUST, or FAST, or LUMS, or UTD who is reading this and wondering if the path I took is still possible β yes, it is. The tools will change. The languages will change. The frameworks will change. But the fundamentals I've talked about in this blog β being self-driven, being competent, building relationships, communicating well β those don't have an expiry date, no matter what field you choose to work in. Double down on them.
Looking Back, Looking Forward
Four years. Same team. Same manager. A relocation from Dallas to Seattle. Projects that touched millions of customers across multiple countries. More documents than I can count. Oncall shifts that tested my patience. Colleagues who became friends. Learning of every kind β technical, professional, personal. It's been a ride.
I'm not the same engineer who logged into that first virtual standup from his Dallas apartment in February 2022. I'm more confident, more deliberate, and honestly, more aware of how much I still don't know. The world is changing fast β AI is reshaping what it means to be an engineer, and I'd be lying if I said I have it all figured out. But I'm leaning into it, not running from it. The next chapter is unwritten, and I don't know exactly what it looks like. But I know that whatever comes next β whether it's a new team, a new company, a new challenge, or an entirely new era of building software alongside AI β these four lessons will come with me.
Sometimes I sit back and think about how far this journey has come β from a modest town in Pakistan to building software at one of the world's biggest tech companies. It feels nothing less than a dream. But it wasn't luck. It was hard work, parents' prayers and support, and the stubborn refusal to give up β even when giving up felt like the easier option.
To anyone starting this journey β from Pakistan, from South Asia, from anywhere β know that it's possible. The path is not linear. My bachelor's degree was in Electrical Engineering, not Computer Science. I didn't go to Stanford or MIT. I came from NUST and UTD. I worked hard, I showed up consistently, and I learned from every failure. That's all it takes. That, and the refusal to stop.
"Khudi ko kar buland itna ke har taqdeer se pehle,
Khuda bande se khud pooche bata teri raza kya hai."
(Elevate yourself so high that before every destiny is written,
God Himself asks you: tell me, what is your will?)
β Allama Iqbal
Here's to four years. And to whatever comes next. After all, it's always Day 1.
Comments