\
\
Its been a couple of months since I left my engineering role at [Amazon](https://hackernoon.com/company/amazon), one of the biggest tech companies in the world. Working at a big tech company was one of my top goals while pursuing my bachelor’s and both [Samsung](https://hackernoon.com/company/samsung) and Amazon helped me fulfill it.

\
In this article, I want to talk about my experience at Amazon and what I learned about software development.

\
Amazon has many organizations, some of them large enough to be independent companies (Amazon Prime, Amazon Alexa, Amazon Web Services, and many more). Some of these organizations have a different culture from others, but all of them follow the famous Leadership principles that Amazon’s culture is based on. 

\
I have observed the following things based on my experiences and that of my friends from different organizations:

\
## An Engineer plays many roles

Depending on the project and deadlines, an engineer plays a lot of roles at Amazon. Following principles like [Bias for Action](https://en.wikipedia.org/wiki/Action_bias) and Customer Obsession, an engineer developing a feature is supposed to work with TPM, EM, PM, and engineers from their own and other teams to get their project to completion. This is very different from other companies where only the senior engineers/ tech leads interact with the product, and business teams and new grads are supposed to do only the coding work. 

\
Not at Amazon, here you are the feature lead just 6-8 months into the job. Of course, there are other mid-level and senior engineers providing you guidance and support but you are yourself responsible for talking to different teams, identifying blockers early on, and reporting them to your manager / sorting them out.

\
This is one of the many reasons Amazon is a good company for people early in their careers. Getting so much ownership and varied experience early on helps engineer develop both their technical and people skills.

\
This brings me to my next point below:

\
## Soft skills are as important as technical skills

Well, soft skills are not *soft.* Most often than not, engineers focus so much time on honing our tech skills that we hardly focus any time at all on developing our people skills. We develop software for our customers. These customers can be our end users, other internal teams, or other business partners. 

\
It’s important that we understand the business context, understand our customer’s needs and work with our teammates to give our best output. All of these things require a lot of communication, empathy, teamwork, and emotional intelligence. It’s very important that we focus on developing these early in our career and at Amazon, I got a lot of opportunities to do so. Working on large projects and closely with product and business teams, helped me develop strong communication skills and product sense.

\
> *The technical skills are important and describe the HOW of the software development process, the soft skills help us understand the WHY.*

\
## Impact and Visibility > Longer and harder hours

Some teams at Amazon are notorious for long working hours. Creating and managing a Tier 0 / 1 service with millions of customers and an SLA to stay up and running 99.99% of the time, sometimes bringing long hours and too many SEV 2s.

\
I am not saying this is always the case, but I won’t deny that some teams it have worse than others. Although, from my limited experience at the company, I have seen that working on high-impact projects is more important than pulling long hours. These projects usually have visibility which might mean tighter deadlines and high ROI. Usually, these are projects one should aim for as they result in deeper learning and puts you out of your comfort zone.

\
> Side note: In some cases, the engineers themselves have to prioritize these projects and bring it up to leadership and product teams. 

\
Too many SEV 2s? The root cause might become a project which should be worked upon. Bringing attention to the stability and performance of a product is also an important job of an engineer.

\
Remember, high-impact and high-visibility projects are what get us *promotions*. Whether it’s a new product feature addressing a dire customer need or a refactoring project to improve the stability and scalability of the system, these projects push us to learn more about different parts of the code base, frameworks, and sometimes even languages!

\
Not to mention, the system design, documentation, communication, and project management work that comes along with development. These situations push you to perform at the next level as well as improve as an engineer… landing you a promotion.

\
## Your manager is very important

A good manager is a force multiplier. As a developer one of the best things you can do for your career is to find a manager who *cares*. Cares for the product you’re building, the team’s overall health, your career, and ambitions as well as the team’s overall impact.

\
Of course, this is hard to gauge and you can only check these qualities after working with someone for some time, but do keep an open eye. Observe how they handle tough situations, failed deadlines, career growth conversations, inter-team communication, and so on. Do they just manage down or also manage up? Are they technical enough to understand the project and architecture deeply? Can they help you make tradeoffs between short-term project features and long-term product health? How do they handle your 1:1s? 

\
The right manager is friendly enough that you can open up to them but professional enough to give you constructive criticism from time to time. A manager’s job is a hard one for sure so it’s important to give them feedback from time to time too. Though, if you feel your manager is lacking in some key aspects and there is little to no improvement over time, change teams.

You should keep looking for the right manager till you find one.

\
## Invest in developer tooling and improving processes

Usually, developers at big tech companies don’t pay heed to the vast number of resources at their disposal. You write your code on a code editor, build it with a build system and use a code management workflow to build and run it on production machines sitting on some far away server. These are just some of the products a developer interacts with daily. Good developer tooling is very important. What will happen if running your unit tests takes twenty long minutes or you have to patch your test environments with security updates once a month? It’ll terribly slow you and your team down. Thank god there are teams that take care of all this. Thank god there are tools and software that take care of this. Good software development tooling and processes save you so much time by speeding up development cycles. It’s important to invest in them.

\
As I mentioned, not only tooling, but *processes* play an important role too. Everybody thinks a 10x engineer is someone who generates 10x code. Wrong! A 10x engineer is someone who develops the product and processes that increases productivity for 10 developers. **Be that engineer**. Setting up the right engineering process and investing in developer tooling for your team is important. Focus on improving your code building time, testing and review process, improve your oncall processes, and invest in applications that help you write secure and stable applications. Keep optimizing processes that save developers time and energy.

\
## Keep Learning

\
> This one is cliche advice but important to mention. Keep learning!

\
No matter how much you know about your service and product, there are always ways to make it better, to make yourself better. No matter how busy you get with your work, take some time out to learn about a new technology or language. If you think it’s a huge time commitment, just read the code from your sister team’s services. Read different design documents and understand why they are written that way. Read the source code of the daily tools you use. The purpose is not to know everything, it’s to keep an open mind and always be in *learning* mode. As you grow in your career, being curious will keep you interested in the game and save you from burnout.

\
## Network with people

People you work with today will move to other teams, and companies or may even start their own ventures. Making long-lasting relationships with your peers will not only help you in your current role but also you’ll also reap its benefits many years down the line. I found mentors at Amazon who were very open to giving me honest feedback and valuable advice. Some of them moved on to different companies and I still get to interact with them every now and then. 

\
Networking with people at your current company who are from different teams or even different roles is always a great way to learn about different parts of the business you’re in. I can go on and on about this but you get the point.


***

There are many other things that I have observed and learned but for now, that’s it, folks. Hope you find this article helpful.

\
Also published [here.](https://adityarohilla.com/2022/09/23/what-2-years-at-amazon-taught-me-about-engineering/)

\
 ![](https://cdn.hackernoon.com/images/0A8k3h4w6EZszSpha5fxK46lMoC2-2022-09-24T01:18:04.967Z-cl8f838a000050as6aoawhd9a)

Amazon

Samsung

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

What Working at Amazon Taught Me About Growth and Engineering

Too Long; Didn't Read

Companies Mentioned

@aditya.rohilla94

RELATED STORIES