Learning beyond the classroom
How I succeed at Amazon with skills I gained outside the classroom
Having recently started work full time as a SDE at Amazon, I reflected on the skills I use in my everyday job with the ones I learned at college. I found myself using an even split of using skills that I learned in the classroom and those that I had to go out of my way to learn. Here, I hope to share with you the most valuable “outside the classroom” skills that continue to help me succeed as an engineer.
My name is Harsha Srikara and I graduated with an undergraduate degree in Computer Science from the University of Texas at Dallas. I believe that the curriculum I was exposed to was really useful in developing strong software engineering foundations. Through our core classes I learned about numerous topics like data structures, algorithms, operating systems, networking, discrete mathematics and more which are all used regularly in my software development role. Furthermore, through electives I was able to explore specialization topics like cryptography, working with big data, machine learning, low-level forensic analysis and more. Concepts from these classes tangentially prove to be useful in connecting the dots when working on vast projects. At Amazon, I’m an engineer in the Alexa Organization helping develop the next generation of Echo products and services used by millions of customers worldwide. Many of the underlying concepts and knowledge from my classes are used by hundreds of teams including ours to build everything from the operating system to the voice assistant. The knowledge from a Computer Science curriculum is indispensable towards a career in software engineering.
All of this is to say that I am here to advocate for the skills that you need to learn outside of class without ignoring the opportunities you are given inside the classroom. It’s the combination of the two that can accelerate your developer journey at your internship or job.
Let’s take a look at the top 3 skills I learned outside the classroom.
Skill 1: Working with people
Developers do not work in isolation. Software development is a collaborative activity involving working with many people across many teams. A full-time role requires developers to work with QA, product owners, managers, and several other stakeholders. Communication, understanding project planning, working with deadlines and dependencies, and documentation are some of the many skills that need to be grown in the process of working alongside other people.
University courses try to give students the experience in collaborating with others through group projects. However, these are short-lived projects / assignments that never extend beyond the scope of a single semester. Group projects are also relatively small (4 people max?). In a corporate setting, its very likely that you’ll work with multiple people from multiple teams over the course of a single week. Expand that out to a year and you might have had to interact with over a 100 people.
Now, how can we get that same experience before joining your first internship or job? I highly recommend working on software development projects with student organizations. By associating your work with an entity that has a larger impact and long term scope, you’ll find many situations where you need to collaborate with several people. These include fellow developers, other stakeholders in the organization as well as your end-user (typically students across your university for a student organization). It’s also an easy way to make a large impact with your project work and a nice way to learn about the entire software development lifecycle. Check out this article I wrote about one of the projects I created for the ACM student organization at UT Dallas that helped me learn a lot about working with many stakeholders.
Skill 2: Working with “full stack” projects & problems
Software development in most courses at university tends to happen within walled environments. Your course on databases focuses only on databases. Your course of data structures focuses only on data structures. This means that many of the course projects also deal with one area of software engineering at a time. There are very few cross-domain project opportunities in a typical Computer Science curriculum. An important facet of real-world software engineering is working on complex systems that interface with all the domains together. This includes working with data, writing scriptable code, building web or app interfaces, dealing with various algorithms, debugging networking issues, using pipelines, including testing, and so much more all at once. Finding opportunities to work on these types of projects is critical to being able to understand and not be overwhelmed by the systems you’ll encounter in a workplace. You might be wondering what kind of projects a student could try to get exposure to everything at once.
Let’s choose a simple project and slowly start adding in layers of complexity. Let’s say given a piece of text you need to identify the frequency at which various characters occur (the # of a’s, the # of b’s and so on). Fairly trivial to compute, you might create a simple script in the language of your choosing and pick an appropriate algorithm to calculate the requested metric. If we were to add an additional layer of complexity we might ask for calculating this metric for all the text in the “Harry Potter” books. Now its left as an exercise to the solver to figure out where to fetch the data from, how to store it, how to efficiently read it, and finally extract all the relevant information. Still fairly straightforward we can now add the requirement that the data should be presented to the user on a web interface and to allow the user to select which book series they want analyzed. This requires the developer to compute these metrics for various different sources and store it in a database. Then they’ll need to build a website, read in from a database and render it to the user. As a final challenge, we ask that instead of displaying metrics for a static resource like books, we want to see character frequency for a streaming resource like twitter tweets. At this point you’ll need to likely setup a server or lambda to be computing these statistics continuously and update them in a cloud database. You may have also reached a level of complexity for the codebase where you’ve setup version control, checks to make sure that everything builds successfully, pipelines for automatically deploying new revisions to your code, and more!
Although you may never have to build the example I demonstrated above as-is, its not a far throw away from how a project in your first job likely will be architected. When it comes to analytics and dashboards, check out this article about an event checkin system I designed that has much of the same complexity described earlier.
Skill 3: Working with ambiguity
Thinking about all the projects and homework assignments I had during my undergrad there’s one thing that’s common with most of them. They all have little to no ambiguity. They are designed keeping in mind a very specific learning outcome. This can be as simple as “writing an if statement” in your intro CS course or writing a program to classify Iris flowers using machine learning. Well defined outcomes are important in the initial learning process since it clarifies the steps needed to be taken to achieve a goal. However, to ascend to the next level of problem solving, developers need to gain the skill to deal with ambiguity. Addressing ambiguous situations with resolution will help developers navigate the novelty of problems encountered in the real world.
Let’s take a quick look again at the example project from the previous skill. Now imagine instead of gradually building up complexity, you were immediately tasked with the final outcome. Now there’s an incredible amount of ambiguity for how to build the project. Where do you host the project? Which databases do you use? Will your code run on-demand or asynchronously on a schedule? What types of trade-offs will you need to make? There’s so many questions that need to be answered and there’s multiple “right” answers. Tackling these situations will help you deal with navigating from your current state to a goal state without having all the in-between steps laid out clearly. Dealing with ambiguity is a core skill that every software engineer should gain. Unlike problems presented in a classroom, real-world challenges often have no clear pathway laid out from start to finish. It is the responsibility of the engineer to determine how best to navigate various challenges, to break them up into smaller parts (like we did with our example) and make a call on whether a given solution is acceptable or not.
Working on getting better at dealing with ambiguous problems means getting better at asking good questions.
Sometimes the ambiguity can exist about what the correct solution should be as well. Instead of being presented with an end goal you may be presented with a broad problem statement & it falls on you to figure out what an appropriate solution even is. Here you may need to address ambiguity around the existing workflow to determine a solution. Is the best course of action to always build a new product / service? Is the best solution to change the environment to make the problem irrelevant? Is the best solution to to create a short term fix quickly or invest into a long term solution? Working on getting better at dealing with ambiguous problems means getting better at asking good questions. Knowing what the right questions are can help clarify the situation and help you navigate your way towards an effective solution. Check out this article that describes how I dealt with many ambiguous problems when implementing an internal Amazon recognition service from scratch for use by students at UT Dallas.
A few final thoughts 💭
The three topics I listed were the most important skills I learned outside the classroom which helped me successfully transition into my role at Amazon. However, they are by no means an exhaustive list. Here’s a few others shared by my fellow engineers working at companies like Meta, Capital One & IBM.
- Reading other people’s code to understand how it works
- Getting into software testing and automation
- Understanding how different tools and technologies work with each other
- Learning languages and frameworks not taught in the classroom
- Exploring concepts like containerization, the cloud & more modern innovations
- Communicating about technical projects with people who may not have a technical background
The key takeaway from reading this should be that learning from the classroom lays the foundation but its upon you, the reader, to build upwards from there by continuing to learn outside the classroom as well.
