Interning at Amazon! Pt. 1

Matthew Chen
Sep 3, 2018 · 6 min read

I’d thought I’d take some time to document my most recent internship: working in Seattle at Amazon (Summer ’18). I couldn’t have been more lucky to have this opportunity to grow so much under the guidance of such talented coworkers and I hope whoever’s reading this can get something useful out of this (or at least some mild entertainment).


Applying

Something along the lines of this showed up in my inbox around January after I applied online around November: “We’d like to invite you to a 2.5 hour on-campus test composed of coding and problem solving, an expedited process compared to the normal internship recruitment”

It was basically a three part test proctored in a random computer lab in the Duderstadt Library composed of the following portions: debugging, logic/reasoning, and technical coding questions.


Disclaimer: I’ll only talk about what I thought about these portions as I’m pretty sure I can’t discuss questions individually so these will be general tips.

Debugging was relatively easy and I’m not saying this to boast even. Tip: Just looking at the output of the bad code made it pretty easy to trace back what tiny mistake was made.

The second part honestly reminded me of a mix of SAT/ACT reasoning and discrete math. Tip: Calculate how much time per problem you have and don’t waste time on any one problem… you don’t have that much time.

The third section is where it got interesting with your typical CS technical interview questions. That last question was fairly tough. Tip: I would focus on getting solutions that simply work for all of them before optimizing for time and memory.

Thus, yours truly took the test and waited all the way until end of March to get… rejected… (yes I was rejected first) and then a very very lucky offer. Most people actually get a phone interview after that for further screening but apparently some people like me just skipped that entirely.

My Team (AWS Lambda)

Amazon took our preferences into consideration but ultimately based on availability we were assigned our team. I happened to put Amazon Web Services (AWS) as my first choice.

Thus, I interned on AWS Lambda! For those who don’t know, AWS Lambda is a server-less computing platform that lets you run code without having to worry about managing servers or scaling because Lambda takes care of that for you.

Why an Intern Project was Needed

Problem: Lambda needs to be running with at least five 9s: having a success rate executing the user’s code of 99.999% or better. Thus when the service doesn’t have five 9s, it’s imperative that mischievous components are identified easily.

However, (without breaking the NDA and spilling all of the beans on how Lambda works) this was a little difficult to do because lots of tedious log files and graphs with timing data were involved, often taking one full time developer over half a day to identify the component to be looked at.


This is where my project came in. Lambda customers already have the ability to use another public service called AWS X-Ray on their code to debug their applications. Why not use it on Lambda internally?

What is AWS X-Ray?

AWS X-Ray is a distributed tracer where users can implement entities called “segments” and “subsegments” to trace different parts of the given code which means that timing data is collected and stored in JSONs.

An example X-Ray service map (not my project)

On the X-Ray console this timing information is aggregated in a service map and via a “Traces” tab (for this project, one trace = one Lambda invocation). Thus via utilizing X-Ray’s exception handling and comparing timing information visually on a graph, one can quickly identify the mischievous component.

An example graph (not my project) in the “Traces” tab with timing information

My Project

My project involved finding the right places with IntelliJ in their huge, multi layered Java code base to place subsegments, setting up an X-Ray daemon on an Amazon EC2 instance to send these JSONs to the X-Ray console, and “feature-gating” this project with a wrapper class so that calls to AWS X-Ray’s static methods can be toggled on/off (so that segments are not automatically generated when not wanted).

I quickly found out that the design of my project changed over time and this holds true to the Agile style of software development that my team uses. Often I’d realize that certain parts of the code couldn’t be unit tested via Mockito with the current design. Thus, I even had to tweak the Lambda dependency injection configurations (in this case it was a mix of guice and spring frameworks) in order to inject a mocked object used for unit testing purposes.


One problem I ran into was getting different components that I traced to show up as different circles on the X-Ray console. Since I’m tracing within the same micro-service, there was actually no documentation on how to do this as usually circles on the X-Ray console represent downstream clients. I ended up scheduling a meeting with X-Ray developers to get a closer look on if that was possible and how it should be done (turns out it’s via remote namespaces).

Amazon’s Company Culture

A lot of people ask me about whether the horror stories about Amazon are true and I’ve got to say that I didn’t see any company wide issue that would have made my experience miserable. I do realize that they probably treat interns differently than full time employees, but I think people tend to mix up warehouse/fulfillment employees with people like me at the HQ. I got to work whatever hours I wanted, but it was hard work. I think Gayle Laakman McDowell sums it up really well in her Cracking the PM Interview Book:

At companies like Google, Microsoft, Yahoo, and Facebook, there’s a lightheartedness during the work day. These companies are proud of their excellent perks such as free food and drinks, or even free massages. And while people may work long hours, they’ll always say that the quality of their work is more important than the number of hours they put in.

On the other hand, some companies, such as Apple and Amazon, have a culture where employees are proud of how hard they work. At these companies, it is expected that employees work long hours, and frugality is valued. Employees at these companies are so inspired by the company’s mission that they’re happy to work weekends or take calls late at night. Building an amazing product isn’t meant to be easy.

Final Thoughts

All in all it was a great learning experience. A big misconception that I had going into this was that I had to know everything once I stepped foot into the office. This is totally false as I was introduced to the “onboarding” process where new hires learned about their team over a few weeks.

In fact, I’d argue that I learned more practical stuff on the job than any typical semester in school as I went from not knowing what AWS was and not having experience working with bash scripting (for example) to being able to talk comfortably about my work across both Lambda and X-Ray.


Obviously there is always room for improvement and that’s what I’m hoping to grow upon this coming school year and in next summer’s internship wherever I end up going.

Seattle was a great city fun to explore after work! A cool mix of city, lakes, and mountains. Photo Credits

I couldn’t have done this all without the guidance of my manager Phill and my two mentors Mark and Prasanth. I’m sure I’ve bugged them enough with questions and I can’t thank them enough.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade