It’s not just about a paycheck: Learning
This is an article part of the It’s not just about a paycheck: Exploring the 4 important aspects of a software engineering job series.
Learning
As a college student or a new graduate, you may not know what kind of work you like. And that’s perfectly okay! Ideally, you’d try getting a taste of what you like through the sample platter of computer science electives at school, but even that isn’t always representative of what it’s like to work with those technologies on the job.
Even if you think you know what to do, try out different types of work. Your mind might be fixated on only wanting to develop mobile applications, but you might find even more satisfaction in working on a notifications pipeline using Kafka and Samza to send millions of emails a day (like we do at Redfin!). Or you might end up not liking it and that’s okay. Early on in your career, the technology that you work with doesn’t matter as much as your desire to learn.
There are varying different philosophies about what technically makes an engineer valuable. One such philosophy is that of a T-shaped engineer, an engineer that has both the breadth at the top that has a holistic view of a system works compared to depth which is the specialization in a particular area of expertise.
Internships are a great way to establish the top of the T. With this in mind, I purposefully chose not only different companies but different types of work and tried to maximize breadth over depth.
In each of my internships (in order), I worked on:
- Android mobile development
- Evaluating and benchmarking different types of big data stores, Google BigQuery vs Apache Spark vs Amazon Redshift, then integrating the chosen store with an existing data pipeline
- Full-stack work with PDF generation done with Java and React.js
- Integrating two services together, one that streams trillions of events a day and another that persists those events in a database
When it came around time to start applying to internships, each year I would purposefully try to pick companies that had work that I hadn’t done before. As a result, with every internship, the mystery around how to build software end to end started to disappear.
A concrete example of this was when I worked at Voicebox which is where I got my feet wet as an Android developer. There, I wrote client side code (code that powers what the end user sees) and had to integrate with a file service provided by Amazon, Amazon S3.
From the Android app, I would send up thousands of files up to S3 without knowing the internals about how it worked which was magical. I was amazed at the fact that my app could send tens of thousands of files and S3 could handle the load without breaking a sweat.
To satisfy my curiosity, that next summer, I decided that I wanted to try my hand at strictly backend work.
At Socrata, I was tasked to work other interns to research a suitable data store to handle datasets of up to 100 gigabytes. These datasets were processed and used to power elaborate data visualizations on browsers. After several weeks of researching and conducting benchmark tests, we decided to settle on Google BigQuery. The rest of my internship was focused on making sure the data was getting stored and retrieved correctly.
Traditionally without a database specifically designed to handle scale, it would take pages nearly 30 seconds to load the graphs as it was waiting on our server to respond. With our integration with Google BigQuery, we were able to get the visualizations to show up in less than 5 seconds.
Although I wasn’t as connected to my end customers since I wasn’t working on code that would displayed to the user, I felt a different sense of accomplishment. The circle was complete. I now had experience writing a backend service that could quickly process large amounts of data and return the information needed to power highly interactive visualizations.
Having both frontend and backend experience under my belt, that next summer, I decided that I wanted to put the two together. That fall, I aimed for an internship that have full-stack work which only helped further solidify my mental model about how client and server code connect together.
For my final internship, I was primarily doing backend work focused on integrating two systems but with a focus on performance. Since one of the systems streamed trillions of events a day, it was imperative that we benchmarked and load tested the receiving system of those events.
Reflecting on learning
Each summer, I was grateful that a company gave me a 12 week trial period to get a sense of what it was like to work in a particular area. Every internship altered the way I thought about a particular domain and opened up even more doors for me to explore. I began to develop thoughts about what I liked and didn’t like about certain types of work as well as opinions about working in each of the unique ecosystems.
Even if you don’t have the chance to intern at all these companies like I did, it’s still easy to explore different types of work. Over the course of my college career, out of sheer curiosity, I decided to implement several apps and web applications, some of which are on my website to further explore using technologies that I was curious about.
What should I focus on?
If you fall into the boat where you’re early on in your college career, either a freshman or a sophomore, consider casting even broader strokes that are above the T shape that I described with regards to being an engineer and try applying for positions that will give you a taste of what other types of work in tech are like. A great example of this would be the Microsoft Explorer program. This internship is specifically designed for exploring not only what it’s like to be a software engineer, but also to see what being a program manager is like. In short, a program manager doesn’t code but is instead in charge of deciding what to build rather than how to build it. Program managers also have responsibilities such as working with design to conduct user testing and gathering data to justify why developers should build a given product.
If that sounds interesting to you, but you’re later on in your college career, don’t fret! There are some companies that offer product manager internships, mainly the bigger ones, such as Amazon, Microsoft, Google, and Facebook. If you’re looking for something a little smaller, there are some mid-size companies that do offer PM internships like Redfin (we’re hiring!).
However, if you’re set on the software engineering route and don’t have much time left, focus on trying to find internships that have more breadth naturally in relation to the type of work you will be doing. A good example of this would be to seek out internships that offer full-stack work rather than just strictly frontend or backend work. That way, you can develop a more complete mental model about how data flows from a database all the way to what the user sees.
As a general rule, smaller companies are often better for growing out breadth. Having less engineering resources believe it or not can often present opportunity for growth. An example of this would be in mid-size to larger companies, unless you work for an operations team, you are typically not concerned with the processes used to deploy your code once it has been checked in. At a smaller company with a lack of an ops team, it is on you to have a better understanding of the deploy process (if there is one!) and perhaps even conduct deploys yourself. Although the deployment infrastructure may not be as sophisticated as a larger company like Google or Microsoft, understanding this process would give you a much better picture as how to software is shipped.
To conclude, when evaluating an offer, you want to have a clear understanding of what skills you can develop especially early on in your career. The software industry moves rather quickly as both new domains and technologies come about. It’s important to get exposure to everything sooner rather than later so that you can then later hone in and build depth in an area you really enjoy.
