An 11 YoE, ex-AWS engineer’s advice for early career SWEs

Matthew Shea is a Principal Engineer at Teamworks on the Smartabase product. Before that, he was a Senior SWE at Amazon Web Services where he worked for almost 7 years. He also maintains a newsletter for software engineers that I regularly read, and highly recommend, called “Questionably Functional”.

My summer at AWS was my first experience at a real, large tech company. CS majors entering industry for the first time will know the feeling well - the realization that while a strong CS education is very helpful at a software job, the job is vastly different from college. The biggest difference being how different industry code is from college code - sprawling, interconnected, and over time, coated in layer after layer of abstraction by engineers most of whom have long left the company.

In this thick jungle, Matthew, who was a senior engineer at AWS at the time, went above and beyond to help me get comfortable with our team codebase, answering even my dumbest questions. An hour long Chime (Amazon’s internal Zoom) with Matthew was ultimately vastly more helpful than the weeks I had spent helplessly perusing AWS’s internal docs. In fact, a lot of the early inspiration for Onboard’s design was based on those interactions. An expert guide can be incredibly powerful when you’re trying to grok a complex codebase.

In this interview, I asked Matthew what advice he has for early career software engineers.

Your First SWE Job

There is often a lot of stress placed on your first SWE job. It should be at the right company and at the right location and in the right team with the right coworkers and right management. Above all, it should be on a team solving interesting problems with a modern stack.

While this is true, I would argue there is often an over-indexing on the technical details of the job. Matthew argues SWE is about people, perhaps even more than technology. In fact, his first job was not even a SWE job.

My first dev job was actually an IT Operations job, not software development. That said, I spent a lot of time writing code to automate said operations needs. The most unexpected thing I learned is that most of the job in technology isn't actually about the technology, it's about the people. Managing budgets, selling ideas, getting funding, dealing with empire building and power struggles, etc.

While this may seem counter-intuitive, dots can often only be connected looking backwards.

Doing IT Operations first really gave me a strong perspective on how to build good software even before I was officially a software engineer. Code delivered on time means absolutely nothing if it isn't running and serving traffic. If I were doing this again, I would probably do the same thing, but be more intentional about it.

Every job is different, and in your early-career pursuit of collecting and refining a variety of unique skills, it’s useful to examine and be intentional about what can you learn from your job.

That said, there are advantages to choosing software companies over other types of companies that have a software department. More impact, more resources, and generally more evolved orgs usually come as a result of software being core to the business. SWE at Stripe vs. SWE at Ford. Here’s Matthew on his time at the Tokyo office of a non-software org:

The company was a medium-sized and international, and the position was in their internal operations team. I worked at (one of, it's complicated) their Japan branches headquartered in Tokyo which was a very small team, all fitting on one floor. I liked the freedom and flexibility to just work on what needed to be done, but political maneuvering was a daily occurrence and you had to at least be aware of what was happening, if not an active player. Upper management also consistently saw IT as an expense instead of an investment, which really hampered some of our initiatives to make the company's operations better.

On Asking Good Questions

One of the reasons Onboard exists is because junior SWEs are often scared to ask questions. This is because they don’t know if the questions they are asking are dumb or smart, so they play it safe and spend 10X more time trying to figure it out themselves. Matthew believes there are two types of bad questions:

There are two main classes of bad questions: low-effort and right/wrong. I blame the frequency of both on the education system 1) driving people to think in very black-and-white terms and 2) making the right answer always available. That environment frames curiosity as "finding the right answer" instead of "finding the best answer." In practice, real-world engineering is about finding the best answer for a given set of constraints. Good questions are framed that way and include information about what you've already done. This goes for big questions, like architecture or code design, and small questions, like how something works.

At Amazon, the onboarding guide recommended that if it takes you more than 30 minutes to figure something out on your own, you should ask someone for help. Matthew has another helpful framework to help decide when to reach out to your manager.

If you need to work on DynamoDB but are unfamiliar with it, don't just ask "How do I do this?" Instead, read the docs a bit, try some things out, and then ask "Hey, I'm working on task X and I'm not sure how we can do this query. I looked into Global Secondary Indexes, but it looks like it would be too expensive. Do you have any other ideas I can look into?" In short, if you can type the question into Google and get an answer, don't bother your seniors. If you can't and need a human, ask them.

Echoing Amazon’s policy -

There's a balance to this. You want to spend a good amount of time researching and learning something on your own, but if you get truly stuck, ask. Don't spend a week grinding away at nothing just because you feel nervous asking. Recognize when your own investigation has run dry and get help.

How does one get a software job?

My first internship came from applying to over 500 internships my freshman year. This was the only offer I received. The next two came from referrals; Amazon was a referral from my roommate and now co-founder Vaishant, who had interned there the previous summer. Having now been on the hiring side too, I can attest to how valuable referrals are. If nothing else, they whittle down the pile of mass applications to a small handful of at least somewhat vetted applicants. I imagine at most organizations, applications without referrals are rarely even looked at by a human being. Here’s Matthew on building relationships being key to finding meaningful work.

My first job was sheer chance. I was working in the university media center when a local tech company came by to get a laptop for a presentation. I ran down to the info session and got into the recruiting pipeline. The one after that was a personal referral. Someone I worked with at that first company had moved to Amazon and was able to refer me for a position. I could write an entire article on the tech recruiting industry, but the thing that surprised me most is just how much referrals and personal relationships matter. Cold applications are effectively dead in the water. You need to know someone or impress a recruiter enough to reach out to you and push you through. Do not neglect your relationships.

Who should you work for?

I spent three summers interning at software companies. The first was a startup with an engineering staff of 3 (including myself). The second was Qualcomm, with a few thousand software engineers at their San Diego HQ. The last was Amazon, specifically AWS. It is hard to overstate the scale of Amazon’s engineering force. There are more software engineers at Amazon then there are employees of any kind at any other tech giant - Google, Microsoft, Apple etc.

I learned a lot about myself in how I felt in each environment. The fulfillment I got from the startup as a freshman was undeniable. Years later it would be a major factor in my decision to decline my Amazon return offer and instead move to San Francisco and pursue Onboard AI full-time. I want to qualify that I went to a well-connected tech school that took away many barriers of entry that the world of Silicon Valley venture-backed startups usually have. I was also lucky to graduate debt-free. I am 22, in good health, and have no dependents. While I grew up outside of the US, I was born here, eliminating many of the immigration struggles that heavily weigh on employer choice for many people. I am extremely fortunate to be able to work on/at early stage startups. Matthew puts it succinctly:

I've never worked at a startup myself, but my understanding is that it's a very high-demand position. Youth is the time for such things. Once you get older, get a stable relationship, real responsibilities, and so on, it becomes much less viable. You only have so much time and emotional energy to allocate to different aspects of life, and making those tradeoffs becomes a significant feature of your life.

Of course working at a large company has it’s own drawbacks. Early on it can mean lack of impact, overly specific tasks, lack of accountability, and lack of ownership. They also bring stability, usually access to extremely high-quality peers, exposure to unique scale problems, and arguably the ability to observe the systems that yielded the company’s success.

I imagine someone who has spent years at Amazon might differ, but my impression of in my time there was astonishment at how well run it was. There were systems in place to ensure employee incentives were aligned with those of the company - most notably the weight placed on mentoring new employees, something that is essential to company longevity. This is not surprising, there are only a couple of other companies that have grown to the scale and resilience of Amazon, so it is only natural that within it employees get to experience what outlier operational excellence looks like. Matthew points out more interesting aspects of working at a super-giant.

Large companies can offer you the opportunity to really make a big impact and have some degree of stability, but they also divorce you from the reality of the industry to some extent. After 6 years at Amazon, I attended a local tech conference in 2023 and was shocked at the things these other companies were struggling with. I'm really looking forward to getting back into smaller companies time at Amazon, but I don't regret my time there at all.

To read more from Matthew Shea, I highly, highly recommend his newsletter. He recently wrote specifically about his advice to SWEs starting their careers, and is always writing posts that are useful for all types of SWEs.