The Pinternship: A Retrospective

This past summer, I had the pleasure of working as a software engineering intern at Pinterest in San Francisco. Before diving in, some background on me:

1. I started coding in fifth grade with… Visual Basic 😰.
2. After enjoying The Social Network a bit too much, I spent my free time in high school coding random projects, thinking that the skills could come in handy down the line.
3. I spent my entire freshman and part of my sophomore year in college coding for a 5-person YC startup that made an accidental $23 in revenue my first year there.

With this background in mind, in the spirit of the Pinterest’s “Win or Learn” motto, let me lay out the “winnings” and “learnings” of my first ever internship at a big tech company.

I don’t exactly know how the entire intern team matching process happens. I just filled out some form and kinda overestimated the technical skills I was capable of performing at a real company.

Am I an expert in PyTorch? Yeah sure why not 🤷‍♂️

The main points I wanted to hammer home in my survey were:

1. I work super fast but sometimes end up breaking things.
2. I’ve never worked in a company that cares about SRE.
3. I want to do something that isn’t front-end.

Initially, when I found out I was stuck on an internal tools team on my first day, I could feel a bit of my soul leave my body. Previously, I was the 19-year-old in charge of ~all~ the front-end of the company’s main product. I loved the ownership. I thrived under the pressure. Internal tools is not that.

My two predefined intern projects were back-end centric as I had asked for. One involved writing an API to manage some files in an S3 bucket. This task was quite similar to work I had done prior, so the two-week estimate they gave me turned into one day of implementation, one day of writing unit tests, and four days of waiting for an infrastructure team to create the S3 bucket for me (there were a few hours waiting for my code reviewer to critique my variable naming in there as well). Gotta love big companies.

Learning: Big companies are scared to mess up, so they intentionally move slowly.

If I think Pinterest’s this way, then it sure is a good thing I didn’t work at Google or Microsoft!

Remember how I said I didn’t want to do front-end? Well, my team was mainly back-end engineers, writing whatever Javascript they need to in order to get by. The only two front-end engineers on my team were one contractor, and one apprentice. Turns out I, a 20 year-old rising Junior in college, had the most industry experience in front-end development on the team. You know what that means…? Front-end all summer 😢. Now, that being said, my manager did give me the choice to do what I wanted to, front-end or not. Me being me, though, software engineering will never be enjoyable unless I feel needed and important, so I just stuck to my guns.

I did not have any exposure to internal tools at this point, so I had no clue what was in store. It was a relatively small front-end code base, so that means it should be well written and organized, right? Unfortunately for me, the code was 4 year old React code written hastily to work with the back-end they had, and no one bothered to touch it because it got the job done. Me being the young whippersnapper front-end guy, I couldn’t simply settle to write React.createClass style components. No, no, no… My OCD simply wouldn’t let me. So, I volunteered to upgrade the code base to React 16. As a result, my manager pushed off the next predefined project I was supposed to do because this migration was needed for so long. I rolled up my sleeves and got linting.

Learning: Tech companies, no matter whether they’re worth billions of dollars, carry debt from their startup origins.

For another example, see here about how Facebook wrote a new programming language instead of migrating their old PHP code base to a modern framework.

We had a “focus week” coming up for the tool, so I had a hard deadline to finish this migration, the first and only time I had a deadline this internship (and I volunteered for it). As a college student used to staying up until 3am a few nights a week to finish seemingly impossible problem sets, this one week time span to migrate a 30 thousand-ish line code base should feel like a piece of cake. Sure enough, after changing over all the syntax, a lot of it by hand, and fixing what seemed like hundreds of linter errors, the rest of my team could work with this shiny new code base. Of course, though, the project wasn’t truly finished until my team and I closed some 30–40 reported bugs in the new web app.

Yes, this sucked to do, but simply knowing that the team needed this migration and that these changes would stick in the code base for many many years, made it all worth while. I even won a growth team award for sacrificing myself to the cause of modernization! Ultimately, though, this success was not a function of the work done but on the task management and, more than anything, trust. I do not know of any other manager who would trust a 20-year-old, hired as a back-end focused engineer, who started two weeks prior, to refactor an entire 4-year-old code base.

Winning: Interns want to work and drive impact, so trust their ingenuity and ambition. If they fail, let them learn from their mistakes and just take another project.

This project capped off my first month on the team. From here, I moved to making more front-end UI improvements that our PM had in the pipeline for a while. At this point, the work seemed to fly by. Because this tool hadn’t gotten any love for so long, we had so much low-hanging-fruit to pick and ship. Again, this period solidified why this team ended up perfectly for me, coming from a small startup. My manager and PM believed in my scrappy, git-er-done mentality at this point, so I could just keep picking up tasks and shipping them. A re-layout here, performance improvements there, etc… As a result, the team shifted from chugging along like a steam locomotive to shooting down the track like a Japanese bullet train.

Winning: Generally internal tools teams don’t need to be as steady and meticulous as Core Product teams are, so don’t be, and own the startup-level velocity.

My last full project was one I was supposed to do at the beginning of the summer before, ya know, they found out I know React. The project was adding reply-to and sender name support to outgoing campaign emails, which sounds useful and easy on the surface, at least to me. That is, until I looked at the 5 year old email code they tasked me to edit. This project served as an entirely new experience for me because the bulk of the work involved carefully reading and understanding existing code written by engineers long-since departed from the company. Naturally, I had to wait a few days for an infrastructure engineer to add a column to a database table. Interestingly enough, the final product of this project was only a few lines of code, passing some fields of data down the execution tree. It took me a day to write, and after testing it a bit, the code was landed.

A few days later, another engineer asked me to help him fix a bug in the email sending UI. He said it was urgent because of a bug in master that caused sent emails to have a sender name of “null,” and he wanted to fix it forward (rather than roll back the change after the bug was reported and deploying an old version, instead fixing the bug and deploying all of the other new code changes at once). Of course, after reading his message, my stomach dropped, and I mouthed out a bad word to myself. Interestingly enough, this bug was reported the morning of, but the engineer on my team never told me because he thought he should fix it when I obviously wrote the offending code. I told him to go home — it was 5pm on a Friday — and I sat at my desk debugging for a few hours.

Learning: Fixing and learning from your mistakes is one of the most valuable experiences as an intern, so please let them know when they’ve effed up, and let them fix it.

After bug testing for a few minutes, I realized a crucial misstep on my part: I only tested my sender name code when a user send an email WITH one and never when someone sent an email WITHOUT one.

Learnings:

1. Don’t be stupid
2. Don’t be stupid
3. Realize when you’re changing code that actually effects millions of users and try to be at least a little more careful than you usually are. (Also, you can’t unsend sent emails 🙂)

The entire incident post-mortem meeting was out of the show Silicon Valley. The managers were trying to figure out ways act more carefully, have better unit tests, etc… when they really just needed to tell me to not be an idiot. I guess fortunately for me, a PM was supposed to look over the emails before they sent but did so hastily, so I wasn’t the only one to blame 🎉🙌.

Besides the technical aspects of this internship, the whole experience was worth it simply because of the super fun and kind interns (sans Jonathan) who shared in my exploits after work and on the weekends. The University Recruiting team did an amazing job in scheduling events for all of us to attend and bond, making the weekends of this job just as rewarding as the weekdays.

All that said, I found it profound how the size of the company nonetheless made me feel swallowed by all of the other people, teams, internal tools, etc… While I did have a great time working with my team, and I would never imagine myself on any other one right now (thanks intern matching team!), our tool was only used by ~50 people inside the company. No matter what progress I made, this number puts it into perspective. Moreover, if I wanted to touch more users, I couldn’t work on as many different things or would have one project, covering a small piece of functionality, and spend the entire summer coding it perfectly.

In this sense, I definitely miss my old company in the camaraderie and chemistry we shared, in the freedom I had in coding a bunch of different equally-consequential things, and the feeling of urgency, how if I just stopped working for a day, then the entire company would feel injured. That said, I will remember these winnings and learnings of my Pinternship for the rest of my career, and at the end of the day, I can’t think of a 1,000+ person company I would rather work for.

One thing’s for sure, it’s definitely going be annoying during the school year when I don’t have an unlimited supply of iced green tea, La Croix, and coconut water to coax me to work 😔.