This guide was originally written for Ada interns at Amazon. Rebecca Zuick helped generalize it for a wider audience.
This document was last updated on 21 MARCH 2023
Yes, every single day. And, yes, it’s really hard to be on your most professional behavior every single day for five months. But you have to. Here are some ways that you can demonstrate professional behavior all day every day:
Has your manager not assigned you an on-team mentor and it’s past week one? Do you not have a project by the end of week four? Does your manager consistently cancel your weekly 1:1s at the last minute? Did your manager move you to report to an peer SDE as a “trial run” for that person to see if they want to become a manager? Did your manager and skip both quit and now you’re reporting to a VP?
Every single one of these things is a problem, and literally no one will know about these things except you. Yes, even if your manager quits. Ada is not omnipotent; they do not have visibility into this.
You own your internship. You have to escalate your concerns. You cannot hope that someone will magically intervene on your behalf.
Assertiveness is rewarded in this industry, particularly at Amazon. When something is broken and no one is working to fix it, Amazon rewards taking that problem up your leadership chain until someone pays it the right attention. I’ll give you an example:
When I was an intern, I was supposed to do some integration work with some other team. Their service didn’t work correctly and they were giving me the runaround and refusing to fix it. My own manager basically shrugged and told me I would just have to deal with the broken thing in the broken way. Instead of listening to him, I took the problem up the chain until I got to my Principal Engineer, Adam Bradley. I explained the situation to him and told him that it just didn’t seem right, and he literally walked over to the other team and made their manager promise to fix the problem within the week, which they did. I’m pretty sure that story is what clinched my hiring decision — my own manager said “do something stupid” and I said no and went over his head.
If your manager is telling you to do something stupid and you have good reason to disagree, take it to your skip! If your manager is not meeting your expectations and you’ve made your expectations clear in writing, take it to your skip! There is nothing I relish more than having my manager’s manager tell my manager to change their ways on my behalf.
In order for an escalation to be successful, though, you have to make a paper trail. If you can’t demonstrate in writing that you asked for X on Y date, then you didn’t ask for X on Y date. Let’s look at the examples of the problems listed in the previous section and talk about how to create the right paper trail.
‹name, alias›, an SDE with less than one year of experience acting as a manager. My understanding is that this does not meet the requirements for managers of Ada interns. My expectation is that I will report to a manager who meets all Ada internship manager requirements, be that ‹original manager›, or if ‹original manager› does not have adequate bandwidth to supervise me, then another eligible manager who meets the requirements to manage an Ada intern.”‹name, alias› will be leaving my team on ‹date›. As an intern, I’m concerned that this may negatively impact my success and my chance of receiving an offer. I’m writing today to ask for three things:If you come from a culture that isn’t assertive, this might be a culture shock for you! Channel your inner tyrant. Demand the thing you need in no uncertain terms. No apologies, no requests. “This is the thing I expect to have happen. How will you ensure that this expectation is met?”
We cannot be afraid of asking questions. Do you know who is out there asking questions without fear? The white cis men! They are publicly asking questions without fear all the live-long day. You have to channel that energy.
Here are some places you can ask questions at Amazon (in no particular order):
#adies-looking-for-help Slack channelHow you ask questions matters! Read the Guide to Asking High-Quality Technical Questions.
When you ask questions and get answers, take detailed notes. There is honestly nothing more frustrating to me than getting asked the exact same question twice as though I haven’t answered it before. If I help you resolve a build failure and then you come back tomorrow asking for help resolving that same or a similar build failure, please do not let the answer to the question, “Have you tried the steps that we went through yesterday?” be, “No,” or “I can’t remember what we did yesterday.”
It’s absolutely okay to ask for clarification! It’s okay to say “I’m looking at my notes from yesterday, and I’m not sure that I understand this part of what we did. Can you explain that step to me again?” But show me that you respect my time and energy by taking notes, cleaning up your notes so that they’ll still make sense when they aren’t fresh in your mind, and reviewing and attempting to understand those notes before asking a question I’ve already answered once.
And your notes have to be detailed and they have to be organized! You are going to run into the same set of problems over and over and over. Don’t waste your own time by making yourself rediscover the answer to a problem you have already seen.
In mountaineering, we say, “Slow down to speed up.” Set aside time throughout your day (at minimum at the end of each day) to review what you did; synthesize that work into notes; ensure that those notes will make sense to you once the context isn’t fresh; round up the links to all of the documentation you referenced, all the Stack Overflow answers, Google searches you used; record the error messages you encountered and the solution you found to get past those error message.
Put those notes somewhere robust! I store my notes under version control in a private repo — a separate commit for every “I got stuck trying to do X, but eventually I figured it out and the solution was this Stack Overflow answer.”
Yes, it’s a lot of personal overhead to record my work at this level! But it pays for itself twice: once by forcing me to really think through the problem and its solution so that I’m confident that my notes will make sense to me later, and then again later when I run into the same problem and don’t have to reinvent the wheel to solve it.
Not being able to get around comfortably in your IDE is akin to moving into a new house, not unpacking your boxes, and then tripping on those boxes every day for months on end. Knock it off. Invest in your tools! If you’re writing Java, taking two or three days to really deeply get to know IntelliJ is one of the best investments you can make.
When I was trying to learn my IDE, I wrote down 10 important key commands on a post-it note and pasted them to my monitor. Then I hid my mouse in my desk drawer until I had committed those commands to memory. When I got through those 10, I picked a new 10. It was painful! It’s also the single most fruitful thing I’ve done for myself as an engineer.
You cannot be afraid of git. Git is not some “other” over on the side of our work, something that comes up only in the moment that we think to “save” our work; git is the water we swim in all day every day. I made you a nearly 5 hour tutorial, (https://youtu.be/o0WWf83JI78) and I need you to watch the entire thing. You will hear my voice saying “command K to clear the screen” in your dreams for the rest of your life; you can thank me later.
Not investing in your tools is like tying the shoelaces of both of your shoes together and then trying to run a marathon. Technically possible! Extraordinarily painful and unnecessarily difficult. Knock. It. Off.
There’s a whole other doc for that: Strategies for Staying Focused and Not Panicking
Does stand-up make you panic? That’s because you aren’t prepared. There is nothing stopping you from reading from your notes during stand-up; in fact, I strongly encourage it. Reading from notes means that you can listen during the updates your peers give, rather than using that time to try to think about what you’re going to say for your own update. If you’re trying to think on your feet while delivering your stand-up, you’re probably bullshitting, and your teammates can tell when you’re bullshitting.
If you’re keeping an in-depth daily worklog (which you absolutely should be), you can read from your daily worklog. Here’s an entry from my daily worklog from 29 DEC 2021 (lightly redacted):
I will literally just read this out loud during stand-up.
I’m not expecting your daily worklog to be as long or as complex as mine (I’ve been doing this job for five years). I am expecting it to be detailed and to include links to all relevant artifacts/code reviews/google searches/Stack Overflow answers that you touched or relied on throughout the day.
Often, interns say, “I don’t know what to talk to my manager about in a 1:1.” Your 1:1 time with your manager is a time to perform inception — to show up and say “I am so smart! I am so capable! I am so successful! I am so engaged in this internship! I want and will get an offer!"
Here some ways that you can show how smart and capable and engaged you are:
‹reason›.” Tell them what you need them to do to get you unblocked. Escalating when you are blocked serves you in two ways: 1) It makes you look confident, capable, and communicative, and 2) it gets you unblocked. My personal threshold for saying “I am blocked” is 24 hours without response from whoever I need help from.It’s also a time to stoke your manager’s ego. Tell your manager they are smart! Say thank you! “I just wanted to say thank you for the documentation you sent to me about ‹some technical thing›, I found it really useful.” Ask them for their advice (which is one way of telling them that you think they are smart): “I’m looking for some advice about this piece of work that I’m working on. Is that something you could look at with me? I value your input.” When our managers feel good they think we are good.
If your manager has a habit of canceling or rescheduling your 1:1, manage up. Send them an invite for a new time and/or send them a message on Slack saying “Hey! I saw you had to cancel. I wanted to give you a status update on my project, but I can do that async. Here’s what I’m working on: ‹fill in the blank›. I did have a question I wanted to ask: ‹fill in the blank›. Thanks!”
We call this behavior “finding an opportunity to demonstrate our leadership principles and the LP here is probably Ownership. Sure, it’s “not your job” to reschedule your own 1:1s, but leaders never say “that’s not my job” 😉
Do NOT. The only thing that saying this sentence does is make you feel like a failure when you don’t have a CR out by the end of the day. We have no way of knowing when our work will be done, because we have no idea what kinds of problems we’ll run into while we’re doing it. Sometimes work that I thought would take 10 minutes takes two days; sometimes vice versa. The work will be done when it’s done.
On my team, we call each other out for this in stand up — if you say “code review out by end of day” on my team I will interrupt you and tell you to take it back.
Your work doesn’t exist if you don’t have public work artifacts. Here are things that count as work artifacts:
Amazon internship end with a "Bar Raiser meeting," where your manager, technical mentor, and an Amazon Bar Raiser meet to discuss your work. Amazon interns are given the opportunity to represent themselves in that meeting with a self-review document.
The Amazon self-review template is honestly pretty dumb. If you're at Amazon, use Internal Search to find the "Intern Self-Review Template"
I encourage you to take that dumb template and turn it into the opportunity you want it to be to write about your work. Treat it like politicians treat questions from reporters — answer the question(s) you wish you had been asked.
What your finished self-review needs to not be is something like “Areas of Strength: Learn and Be Curious. I had to learn and be curious during my internship and so I showed that strength.” This is not middle school. If you fill out your self-review like that, you might as well not bother filling it out.
When I was an intern, I just made my own document. I focused on telling STAR-style (“Situation, Task, Action, Result”) stories that I felt “showed” rather than just “told” about my leadership behavior. Is it “technically” too long? Yes. If someone stopped reading after the first two pages, would they hire me? Also yes.
In the first page of the document, I quote a Principal Engineer who said that my work “raises the bar for ownership.” It’s a slam dunk. Make your self-review a slam dunk.
Every cohort, I get a few interns who come to me the week of their hiring decision meetings saying, “I was set up for failure, can’t you help me?” Very honestly, no I cannot. You need proof. Proof that you were set up to fail and proof that you tried to do something about it. You need a paper trail. And you need to have started escalating much, much earlier. There is almost nothing we can do in week 17 to change the outcome of your hiring decision meeting.
Internships are hard. When I was an intern, I did not see a way to survive internship and prep for interviews. An Ada Cohort 2 alum (and now good friend) counseled me to put all my eggs in the internship basket and save interviewing practice for after internship. I was in a financial position where I knew that I would be okay if I didn’t have a job lined up by the last day of internship, so I heeded that advice. If you’re in that same position, consider picking one — internship or interview practice — and use this time to focus on that one thing.
Even if you know you don’t want to be at your internship company long-term, focusing on getting an offer at your internship company and then staying there for a year or so while you practice interviewing elsewhere might be a good approach! (And maybe you’ll learn that you like your internship company — I never thought that I would be at Amazon as long as I have been, but it has turned out to be a good place for me.)
We are only as successful as the person around us who is struggling the most. When you learn something, find someone else and teach them what you know. We do this together or not at all.