First year in Big Tech

In May of 2025, I graduated from the University of Southern California with my Master’s degree. I had a growing list of worries: career goals, job applications, navigating my post-college social life, and trying to cultivate my creative hobbies amidst all the chaos. The job market was a constant churn of ups and downs, and even armed with two degrees I felt uneasy about my prospects.

But I was very fortunate, and shortly after graduation received an offer to join Amazon Web Services, where I’ve spent my time since working on the Aurora Storage team. Yesterday marked exactly 1 year since I began.

Time has moved incredibly fast for me in the last year. I’ve learned a great deal of things; about distributed systems, about people, about Amazon, about databases, about what it means to be a good engineer. And each day hasn’t just come with more opportunities to deepen my understanding, it’s come with an even broader scope.

Learning in this environment is vastly different than the learning that takes place in college; there is very much a zoom-in, zoom-out rhythm here. One day it’ll be investigating cross-service logs by the millisecond, analyzing metrics, and of course writing code. Then the next day it’ll be design reviews for months-long engineering efforts, cross-service migration plans, and organization-level initiatives. The work is endlessly diverse, fascinating, and challenging.

I’d like to talk about some of the thoughts that have stuck out to me, over my time here so far. These are personal reflections, and to some may even seem obvious, but to me they’re new. My hope is to have reflections like this throughout my career, to serve as reference points. There’s a lot that I could talk about, but I think the most impactful realizations I’ve had are related to Cost and Criticism, in the context of software engineering.

Cost

Engineering has cost. I had been taught this way before I had even entered college, but I didn’t truly understand it until I entered the workforce.

Good software can mean many things to many different people, but to anyone trying to sell software, the first question is always “what does it cost?” To an engineer, writing cost effective software often means designing for the right resource scale: software that generates more value than the cost it takes to run, and software that can scale up easily as demand increases. Writing good cost effective software is then writing software that’s easy to extend, while maintaining architectural resource efficiency.

But, as I’ve come to realize, this isn’t the full picture. Cost extends far beyond what it takes to run the software, when you factor in the time it takes to literally write it. This is the tricky part that most engineers don’t actually ever deal with, because it’s controlled by management. Engineers themselves are resources that need to be allocated in an efficient way, and utilizing their time effectively is a really hard problem because they don’t scale up/down the same way an EC2 Auto Scaling Group does.

Being a good engineer isn’t just about architecting cost efficient software, it’s also about allocating your engineering efforts in a cost-effective manner: prioritizing different projects, finding ways to automate repetitive work, constantly evaluating and re-evaluating how you spend your time to make it more efficient. These skills aren’t easy to develop, nor is there a book that can really teach them, because they are highly environment-dependent.

This is where dependency culture and AI coding really become important, because they’re both paradigms that can shift the cost model of engineering. You can save engineering hours spent building custom solutions by using open-source ones, but it comes at an upfront cost of learning the APIs & concepts of the new dependency. You can minimize the time spent coding overall by introducing agentic coding workflows, but those also come with the upfront cost of ecosystem investment and token pricing. These things also have long-term costs: more dependencies means more overhead when trying to update software, more unknowns in the final binary, more sophisticated tooling for managing builds. More agent-generated code similarly means more unknowns in the codebase, more time spent reviewing, and the continual maintenance of prompts, workflows, and tooling as capabilities evolve.

It’s often the case that there are problems that go unsolved not because they’re challenging to solve, but simply because it’s not as cost effective to solve them right now. It would be nice to have beautiful documentation for an important component with an outdated README, but it may not be cost effective to spend the time (or tokens) to set it all up in the face of pressing deadlines. There might be a backlog item to root-cause an anomalous issue from 6 months ago, but it may remain there for much longer because more pressing customer issues are constantly rising.

Writing good software, then, becomes more of a base expectation; being a good engineer means understanding not only the cost of the software, but the cost of your own efforts in improving it. Spending your time really carefully, as if it were your own cloud bill being charged, is really important.

Criticism

Part of being a good engineer is knowing how to be wrong, well.

When you write your own software, you make all the decisions. You choose when to write it, what to add, what to remove, what you like, what you don’t. As soon as anyone else enters the fold, there is now a difference of opinions. Part of what a good engineer offers is a set of reasonable opinions, and more importantly, the justification for them, delivered in a productive way.

When you’re tasked with improving a system in a collaborative setting, your design doesn’t just reflect what you’re going to do. It tells others that you’ve thought about the problem, and you’ve also thought about the possible issues that may arise with your solution. But, of course, it’s impossible to predict all the problems, nor all the opinions of your reviewers. What makes the design review most productive is not only the reviewers surfacing their feedback, but what you do with it, both in the moment, and afterwards.

Handling criticism is hard, because as an engineer, you pride yourself on having informed opinions, and making designs that are sound. Getting feedback from others can feel really dreadful, because you’re confronted with all of the details that you’ve missed, or all the ideas you wished you had when drafting the initial design. But learning to handle criticism is the most valuable skill that an engineer can have. Standing by your opinions with solid reasoning, and cleanly acknowledging the shortcomings of other aspects; these earn you respect, and they also build your confidence overall.

The truth is that there is an endless number of tradeoffs and possible design paths, even for the smallest of changes within a sufficiently large system. Each engineer will have their own opinions about which direction to go, and they might even deliver those opinions to you with differing levels of tact. At the end of the day, a good design is one that explains exactly which tradeoffs were made, and why. You’re only capable of making a good design insofar as you’re capable of handling the criticism and opinions of your reviewers.

I’ve found that it’s best to be wrong quickly. Admitting that I don’t know something, or admitting that I didn’t consider something in my design. These things feel bad at first, but they offer the most value to the end product. The sooner you’re wrong, the quicker you can realize it and do something about it. And, somewhat confusingly, the more often you’re wrong quickly, the less often you end up being wrong overall; you make all the mistakes up front. I like to think of it as like an adversarial approach to learning; you improve the most when you’re forced to challenge your understanding more often.

Being a good team member means meticulously evaluating the designs of your peers in a productive way, and presenting your opinions tactfully. Being a good engineer means learning to deal with the criticism of your peers, and learning to be comfortable being proven wrong.

Honorable mentions

Some smaller, less ‘big-picture’ observations I’ve had throughout my time so far:

Being on-call is scary, and being paged in the middle of the night is not fun. But nothing teaches you more about a system than having to debug it under pressure. One week of oncall is about as valuable as an entire month of static code analysis. There’s something really interesting that happens when a system breaks in an unexpected way; it’s almost like when you’re immersed in a book, then remember that you’re reading a page, and suddenly all you can think about is the words on the paper and not the meaning. It’s the same picture, but you’re not really seeing the same thing anymore. The same goes for oncall; you build up an understanding of your systems through the code, through your contributions, through the documentation. But then you get a page that challenges that understanding, and suddenly the way that you perceive that system is changed. It can be incredibly stressful, but it also challenges you to be creative, pushes you out of your comfort zone (hopefully while it’s still daytime).

A well-written document is infinitely more valuable than a slide deck. Amazon has an interesting culture in this regard; every single meeting I’ve ever been to follows the same structure. Instead of a slide deck, the organizer writes a document on a collaborative platform. The meeting doesn’t use slides, and participants don’t necessarily review beforehand; the meeting starts, and people silently read the document, adding comments while the organizer adds comment responses. Afterwards, the discussion happens. Before Amazon, I’d never had a meeting structured like this; it’d always been slide decks or memorized presentations. I’ve found this format not only refreshing, but incredibly productive. You can express so much more relevant detail in a document, and you can really take the time to be precise when you’re expressing your thoughts. I wish to use this format for the rest of my career, if I can.

Regular exercise is the single best habit to ever adopt. A bit more personal, but regular exercise has consistently been the most valuable habit that I’ve maintained since college. I genuinely believe that regular exercise broadens your potential as an engineer. There have been many days where I’ve come home feeling very burned out. Tons of meetings, new systems to learn about, new problems arising. Even just 30 minutes of exercise makes it disappear. In a very non-scientific way, I like to believe that the stressors and stimuli of a packed day literally accumulate in the brain, and the only way to flush it out is to force it out through the muscles. However you’d like to visualize it, the impact is very tangible. Consistent exercise has been the best thing that I’ve ever done for myself, and I have no doubt that it’s had a similar impact on my career.

Conclusion

I’m very much still learning what it means to be a good engineer. I’m incredibly grateful for all the things that I’ve been exposed to over the last year, especially the challenging things. I hope only that the next year is as exciting and challenging as the last, if not moreso.

Thank you for reading. If you think this post made you a better engineer, please go work at Microsoft and fix Windows. Please.