In February of this year, I received an internship offer from Amazon. At the time, I had no concept of what a summer internship would entail and came completely unprepared. As I write this blog post, my return offer status remains unknown, but I hope to provide an objective review of my entire internship experience.

Week 1: Onboarding

Week 1 was primarily onboarding. On the first day, I learned about my project - pure frontend! I was quite speechless when I found out, especially since the functionality seemed deceptively simple (I would regret this judgment multiple times later). The entire team was an internal platform team, which had the advantage of being very chill, but the downside was that the team’s QPS was on the order of 0.01, meaning there wasn’t particularly significant customer impact.

I set up various tools, completed training on Embark, and had coffee chats with team members. I began diving into the incredibly complex frontend codebase. At this point, I still had the leisure to arrange many social meetups with fellow Amazon interns in Seattle and meet many people.

Week 2-4: Design Document

Amazon intern project variance is quite significant - some people receive ready-made design docs, while others don’t even have a proposal. My situation included an existing tech proposal and a BRD (Business Requirement Document), which was a decent start and gave me a relatively clear understanding of what I needed to accomplish.

This was my first time writing a design document, and I still had a student mindset. A design doc should be a thorough walkthrough of the implementation. In fact, the most critical solutions in the design doc should ideally have corresponding POCs to verify complete feasibility. However, at the time, I thought like in my student days - writing a rough idea and starting working.

So the first version I submitted was, to put it mildly, terrible. It was full of very broad descriptions - the kind of thing that’s really embarrassing to show to seniors. The senior left many lengthy comments explaining his design thoughts for the project, which was extremely helpful. While going through the senior’s comments, I dove deeper into the code to think about specific implementation methods for this project and submitted the second draft.

The second draft was fine in terms of overall direction, but still lacked many specific details. For example, for a certain technology choice, I only wrote about the main solution but didn’t seriously provide other viable alternatives. Additionally, some details weren’t rigorous enough. For instance, I needed to introduce an external package to implement a feature, and I simply chose one that worked. But the senior pointed out that there were many things to consider: the package’s functionality, download count, internal Amazon usage, GitHub star count, and the date of the last GitHub commit (to see if the package was being actively maintained). Ideally, I should list 4-5 packages for comparison. Also, my mentor requested that I add a POC video, so I quickly put together a simple POC in one day, which received praise. At the time, I was still confident that implementation would be simple. After all, the POC was so quick. I’ll come back to this later…

Anyway, the third version successfully passed team review. I didn’t receive particularly critical comments since most content had been signed off by the senior frontend engineer. The main comments came from backend engineers who lacked frontend domain knowledge, making it difficult for them to understand certain parts. This reminded me that when writing docs, I need to have a clear understanding of readers’ knowledge boundaries.

Week 5-9: Implementation

I entered the most painful implementation phase. My project could be broadly divided into two stages: first, write a component, then embed that component on a page. At the beginning, my mentor told me he thought it could all be completed in one week, so my goal at the time was to basically solve it in two weeks. But as you can see from the title, I ultimately spent a full five weeks.

I first spent a week completing the component, and this step showed early signs of trouble. The cost of familiarizing myself with the team’s development environment was higher than expected. For example, when running tests, I encountered massive failures without knowing the specific factors. Additionally, TypeScript type constraints and unit test writing were more complex than anticipated. Finally, since I had no prior frontend development experience and, as an intern, had very limited familiarity with the team’s codebase, and the old code I was referencing had a lot of technical debt that needed correction (like using any type, which should be strictly prohibited), all these factors led to my CR going through 6 revisions before finally passing, accumulating 50+ comments.

After completing the component CR, I started development on the corresponding page. Various hardships aside, after submitting the CR and fixing the second revision based on comments, our team’s senior suddenly told me that my entire code design was problematic, not scalable, and needed refactoring. This was already the end of the second week, approaching the preset deadline, so my mood was understandably affected. I was very worried about not being able to deliver in the end, so I had an hour-long conversation with the senior at his desk. During this conversation, I discovered:

  1. Although he had completely gone through my design doc, my previous component CR, and my current CR, he actually misunderstood many specific details.
  2. I completely couldn’t understand what hemeant by “non-scalable” and how exactly I should modify it. My mood was overwhelmingly desperate at the time, so I immediately pulled my mentor to discuss what to do. The mentor then suggested pulling together me, the senior, him, and the manager for a meeting. So I urgently wrote a document summarizing the current situation and held a meeting. This meeting was mainly for me and the senior to exchange opinions about the design, but after the meeting, I still didn’t understand! So we pulled a second meeting, and only then did I know what the key issue was. The senior wanted me to design based on the current team’s data format, but the page I was referencing was owned by an external team that used a different data format. I had no idea there were two data formats and their differences, so I completely couldn’t understand what the senior was talking about. This really shows how important domain knowledge is.

So, after another week of diligent development (development had now taken three weeks), I finally submitted the corrected CR. This time, the team’s senior FEE had no issues. Just when I thought everything was starting to go smoothly, a senior from another team jumped out saying that a certain small part of my code, which is copied from old code and has some hard-coding, wasn’t acceptable and needed to dynamically fetch from the backend, preferably by modifying the previous backend API. My despair was imaginable - I had no contact with backend development throughout the entire project, and this small change might require a week for me to familiarize myself with and complete. Luckily, my reliable manager pulled another meeting, bringing together our team’s seniorand the other team’s senior to discuss this issue, and finally solved it by reusing an existing API.

During the process, there were several other instances where people/our team’s senior pointed out that the implementation needed modifications, and even cases where the pipeline broke preventing me from merging. Fortunately, everything was resolved one by one, and I finally successfully conducted User Acceptance Testing in the ninth week. Ultimately, this project that was initially expected to take two weeks was finally basically completed after five weeks.

For about three weeks in the middle, I worked intensively every day at the office, continued working on progress at night, and even worked on weekends, all to deliver on time. Fortunately, I completed it in time.

Week 10-11: Bugfixes and Presentation

Week 10 was mainly about fixing bugs found during UAT and making changes needed after UX review. Life was relatively relaxed, and more importantly, the major deliverable had been successfully completed. I also realized that through sufficient communication, problems can always be solved.

For example, this week when implementing a stretch goal, our team’s senior initially said there was a reusable hook. After I wrote the code using that hook and submitted the CR, another senior from a different team emerged to point out that I had misunderstood the hook (I was just following our team senior’s instructions) and shouldn’t use it that way, and questioned my goal. Again, we held a meeting to determine the direction of exploration. The difference was that this time, after my exploration, I determined that this stretch goal was much more complex than imagined, so I directly reached an agreement with the seniors and others to remove this goal from the internship project.

Throughout this process, I never panicked like before because I had realized that communication always leads to reaching agreement and solving problems.

Summary

This internship had both fortunate and unfortunate aspects. Let me list them briefly:

Unfortunate Aspects

• My mentor wasn’t actually familiar with the project and mostly relied on our team’s seniors for advice.

• The page I was working on was owned by another team and was a very old, complex page. This led me to encounter a lot of technical debt (even the senior said “sorry you have to face these debts”), and our team’s senior didn’t have deep understanding either.

• The project itself was quite boring and would be refactored in Q4, so the impact was essentially zero.

Fortunate Aspects

• The overall process was relatively standardized - no mentor/project changes occurred mid-way, and the project was fairly clear.

• The manager was protective of interns. In week 5, when they decided to refactor the entire page, they actually considered giving me a different project, but my manager prevented it, otherwise it would have been even more devastating.

• Team members were supportive, especially our team’s senior, who patiently replied to and supported me with various issues.

• The project wasn’t complex, giving me time to work on my own things

Overall, I feel that this Amazon internship honestly didn’t help much with my technical skills. However, it greatly helped me understand how to work, collaborate, and even survive in the workplace. I’d like to conclude this retrospective with three key learnings I’ve summarized from my experience:

  1. Expect the Unexpected

Never underestimate the difficulties you’ll encounter when launching a feature. You never know where problems will arise to block your progress. Always leave sufficient buffer time, maintain communication, and don’t be afraid to reach out for help.

  1. Communication Above All

Any problem can be solved through communication. When you encounter design issues, discuss them with seniors. When requirements are unclear, reach out to the PM. The entire project is built through continuous communication. Always maintain visibility - don’t work in isolation. Collaboration is key to getting things done.

  1. Maintain a Global Perspective

On one hand, always pay attention to others’ progress and what they’re working on. This prevents duplicate work and helps you know if the assumptions of your work have become outdated and need updating. On the other hand, when working on tasks, think from a long-term perspective. Don’t just consider current requirements. Always prevent the accumulation of technical debt.