Congrats, you got an offer! Whether this is your first internship or your last, this guide aims to help lead you towards thinking about success in your next step, whether it be building up rapport and getting that return offer or expanding your perspective by pivoting to experience another field.
If this is your first tech experience, there's a lot to consider - what you've done to prepare to pass the interviews wouldn't necessarily translate to useful skills on the job. Or, if you've already got a few internships under your belt, this article may bring you some interesting thoughts from a mentor of a few interns (and full-timers) at Amazon.
Preparing for the job
TLDR:
- Don't cram technical knowledge before your start date.
- Learn high-level domain knowledge.
- Do your people research!
- Take it easy.
"How do I prepare for an internship?" is the most common question I get asked - an incoming intern, excited to make an impact on their first day. To hit the ground running, to show the team what they've got. I've prepared some pragmatic tips to kick this off.
Don't cram technical knowledge
People often ask me about the best ways to prepare a few weeks before their internship starts. Truth is, you're not going to learn anything technically useful in a couple weeks. Best you'd hope for is completing a toy project or a general perusing of the documentation and best practices.
More generally, it's important to understand the role and expectations for you, going in. For example, if it's a big tech company, you're not actually expected to know company-specific tooling, or even generic tooling at the level they operate at in such a company. You may have used git for your projects, but may have never dealt with a gnarly merge conflict in a monorepo. This is not a leveraged area for you to prepare for.
I know some folks really can't help but cram tech knowledge 32 hours a day. If you're one of these people who has to study something technical, focus on basics and fundamentals. A good rule of thumb to follow is to learn topics instead of technologies. Instead of learning the ins and outs of Guice or Dagger, learn about dependency inversion and injection as a concept. It would be reasonable to gain familiarity at the depth where you could describe what it means, why people use it, the common downsides, and alternatives to consider.
You're an interesting person
Some of the interns whom I have the strongest impressions of approached me on day 1 with an interesting introduction. Some talked about themselves, some found interesting connections between us, and others just had a really great pitch about their goals and how this internship was going to help them get there. First impressions are important, and this may not be a bad area to prepare ahead of time.
Meet your mentor and team, social onboarding
TLDR:
- First impressions matter.
- Make time to speak with everyone on the team.
- Identify the stakeholders in your success.
- Who are the other interns?
Welcome to Day 1. If you're at Amazon, every day is Day 1, but especially today. This ties nicely into the previous subsection about introductions, so let's continue that here.
First impressions matter
There was one particular student who shared a niche background in modding Minecraft - they found some old contributions I've made to a modpack (to this day, I still have no idea how they found them, as this now defunct mod has not seen the light of day in a decade) and we struck up a great conversation about how the scene has changed and all the exciting new developments. The sort of impression I've gained from interacting with them was more dictated by personalities and backgrounds, than more superficial attributes like technical competency.
Say hello to everyone
One of the most important things to identify early on are the roles and dynamics of each member on your team. Who is your assigned mentor? What do other people think their strengths are? What about your manager? What role do they play on your team? As you experience a variety of teams at a variety of companies, compare and contrast this learning to see if you find correlations. For example, you may find that managers who oversee more junior teams drive more meetings, while managers who oversee a senior team drive fewer meetings.
If there are individuals who aren't interested in speaking with you, figure out why. Are they using busyness as an excuse? Is it "always" crunch time? Throughout the course of your internship, these are the really important social dynamics to note and figure out, as it's something which exclusively exists in a work environment and cannot be replicated in school. Leverage your manager, other interns, or whoever you trust to discuss.
There's a variety of interesting topics to bring up during your initial 1:1. I'll leave some ideas for you here, but please adapt them to your personality, background, skills, and goals. They're roughly ordered in increasing complexity and difficulty:
- Favourite XKCD comic? Does it tie into any personal experience?
- Favourite technology/app/tool? What did you do before you found it?
- What is the hardest problem you've solved? Why did you solve it?
- What is a problem you wish you didn't have to solve? Why did you solve it?
- How is this current team similar/different to team X?
- This is an especially interesting question to ask different people on the same team. Your manager will likely give a different answer/reasoning than a junior engineer.
- How are the team's goals and projects contributing to the company's goals? What are goals this team has which don't directly contribute to the company, and vice versa?
- What's your opinion on the current staffing of the team? What are the gaps and strengths at the team level?
I also feel like I have to say this because seeing it first-hand was too painful: be empathetic and sensitive. If the other party is uncomfortable answering certain questions or talking about a certain item, don't push them on that. Change the topic and stay lighthearted; you can follow up with your manager later about the specifics of that situation.
Yes, "everyone" includes the other interns too
This more so applies at mid-sized and bigger companies, with intern communities. Get involved! Go to every single event, at work and outside (if possible, obviously I know people have other responsibilities). If there aren't events, get buy-in from leadership and organize some.
One of my fondest memories during my second internship at AWS was organizing an intern hike for our Vancouver office. We had about 50 interns that season, and I was able to convince a few of my buddies + their friends to come along, totalling about 20 people. We met downtown one weekend, took the bus down to the North Shore Mountains, and did a ~10km hike, ending with dinner at a Korean restaurant. I can confidently say I don't remember a single technical contribution from any of those interns, but even after all these years, I still remember that we had a great time despite H.L. twisting an ankle and us having to carry him out to hail a cab halfway. Go out of your way to make friends, it can definitely pay off.
Pragmatic onboarding
TLDR:
- Understand how to communicate.
- Ask until you understand.
- Be clear about timelines.
- Make a knowledge database.
The overarching goal of onboarding, technical or not, is to understand how the company operates and thus, how you should operate. Note that while some examples focus specifically on technical aspects, the rules and ideas similarly apply to non-technical areas.
Ask stupid questions
The first thing to familiarize yourself with is how to ask questions. Different teams at different companies have different systems in place, so pay attention during your first day and ask your manager explicitly if it's not abundantly clear by the second. A common direction is for you to filter every question through an onboarding buddy or your mentor before reaching out to the broader team (though to be clear, your primary point of contact is likely not a replacement for your search bar). This is usually a rule implemented to shelter everyone else from distraction.
On the topic of questions, this is a good place to emphasize that you need to ask questions. Sometimes, it's as simple as asking them to explain again. It's the responsibility of the responder to ensure you understand, but it's your responsibility to communicate whether you do or not. Perhaps they need to try a different format or explanation. Maybe it's time to pull out a white board. If you don't understand, you won't be effective. And trust me, it's far better to give off the impression that you're "slow" and need more upfront help, than for others to think that you're slow, meandering, unproductive, and still incorrect at the end of it all.
This is as good of a place as any to give a personal tip for clarifying difficult ideas or concepts. Sometimes, there's a lack of connection and it's difficult for the answerer to see where your reasoning is flawed. In these cases, it can help to flip the script. Instead, offer to explain the idea from your perspective, and ask them to stop you when you're wrong. This is a really effective method for understanding systems which you already know the fundamentals of but are unsure of the specific details of the technology's implementation.
Know your goals
Finally, get a grasp of what the company's goal for you is. This may start small at the beginning, such as knowing how long it should take you to finish onboarding, whatever that may mean. Hopefully you'll soon also learn what their vision of a successful internship is, and how that translates to tasks you have to do. For example, is it that by the end of the internship, you would have shipped ZYX feature? Or that you've completed n tickets? Understanding how your success is measured is critical for forming goals and milestones during your internship.
Build a knowledge database
Onboarding is the perfect time to start building a system of knowledge which you will add and refer to throughout your internship. This is an abstract idea - the concrete implementation of which you should decide, based on your preferences, skills, and what the company already provides.
A basic approach is to start from a blank sheet (either a document, or pen and paper). Add tidbits of information you find yourself referring to frequently to the page, building it up until you can find trends and categories. If you find yourself using a lot of the same terminal command frequently, add them as aliases (search this up on google if you don't know how). If your team uses Alfred or Raycast, ask them for their config. Gain knowledge on your mentor and teammates' mechanical processes and adopt the ones that are useful to you.
Allocate your time efficiently
TLDR:
- Understand your project and goals.
- Engage with other interns.
- Attend all the events you can.
This is a section and topic which I find myself speaking about surprisingly often when onboarding new interns and during my general mentorship programs. The advice won't apply to everyone on every internship, especially at smaller companies, but I think it's still worth knowing.
Going for a return offer?
If you're given a solid, reasonable, and invested project which people really want to see succeed (whatever that means in your context), that should be your sole technical focus. Typically, this may mean that you're given a project that is relatively binary in nature - did it succeed or not? - and is within your technical and social skill set. Delivering this project well will do more than most other actions to help you push for that return offer.
To add, delivery isn't simply that the code is merged. It also includes how the team felt about the process. Did they have confidence in your proposals? Were there many revisions to the design? Technically insane interns who shipped their projects perfectly, although likely received a return offer, were less memorable than those who were human, struggled through it all with their mentor, and showed true grit and adaptability when things didn't go their way.
However, if you're being thrown into a bugs or features backlog project, recognize that your technical achievement is not being chased here. Realistically, you're being used as cheap(er) labour and thus, recognize that your return offer will be based purely on market conditions and upcoming product opportunities for the company and team.
Regardless of the shape of the project, there's a few common ideas to note. I'll start it off with my favourite: you're going to be wrong, and everyone will know it too. The difference is whether you can recognize it (good intern) and course correct (great intern). Be proactive in identifying where you might have gaps in knowledge, and if those gaps might cause issues for you or the team down the road. Having foresight in this manner is a really great quality to demonstrate, though I recognize it is not easy.
Stay aligned with your stakeholders (likely just your manager) throughout your entire internship. In other words, the outcome of your internship should never be a surprise. Typically, this means a weekly 1 on 1 meeting with your manager where you'll talk through concerns, achievements, and if you need help. Often, these conversations can feel uncomfortable, and forcing yourself to be uncomfortable is never fun, but it's better to do it while you can still do something to influence the outcome of your internship. Bring up hard topics during these 1 on 1 meetings so they don't resurface later as a surprise.
Oh, and be fun, don't be a downer, and add funny emojis to the company Slack. That never hurts your chances.
Spending time outside of project work
If the second project shape resembles your situation more closely, then try to spend as much time as possible outside of technical work. This may include hanging out at intern events to get "boots on the ground" knowledge about current hiring practices, rumours about other companies, build connections to leverage in a future term, interview tips and prep, and to learn about other backgrounds.
In the same vein, go to every single event you're invited to. This includes lunches, show and tells, demos, other intern presentations, celebrations, etc. These are a great, low stakes setting to meet senior employees and get to know their work and background. Acknowledge that this is a unique opportunity for speaking to highly experienced technical and product experts about internal projects that you wouldn't get elsewhere.
While it's expected that most interactions are just for your learning purposes, you may identify one or two individuals whose backgrounds and achievements are highly aligned to your future goals. For these, study up on their achievements and projects, and leverage your background in the topic, albeit shallower, to strike up a more engaging conversation. If it goes well, ask to schedule a 1:1 meeting in a couple weeks to discuss the topic further.
Another idea is to join all the team meetings you're allowed in. Managers may discourage you from joining the team meetings in which interns aren't expected to contribute, but joining these when you don't have an impending project deadline could be a unique way to gain more perspective on the work of a full time engineer. Good examples of such meetings include design review and sprint retro. All the interns I've had come back full-time were the ones who were highly engaged, even in areas they didn't need to be.
Sidenote: connecting with remote team members
What used to be an uncommon team structure is now common. Team members, leads, managers, and various people within the professional circle you work with might be located in a different office, or even an entirely different city from yours. While the same advice above applies regardless if you're in-person or remote, you'll likely feel less connected if you never get to meet someone in the flesh.
One tip I share with people is to establish a social ritual, surrounding some form of casual fun time. For example, do a board game (virtual ones work great for this) session every sprint! Social guessing games like wavelength do great for ice-breaking and are easy to understand. I've also had a good time doing impromptu (non-formal) presentations on topics that are interesting. For example, presenting some pictures of you pursuing a hobby is great, especially if it's a more esoteric one. This sort of thing works especially great if you give the first presentation, purposely without any preparation to establish the vibes and casualness. Then in the future, encourage team members who always bring up fun topics to present their interests as well.
Leading your slice of the product universe
This section is directly applicable to those who have the opportunity to lead their own project.
I've decided to stuff this in as the last topic, as some interns have a say in the project they take on. It's generated a ton of discussion in the past, so I thought I'd add a little context here for people to build more nuanced discussions upon.
What do project stakeholders actually care about? Do they actually want this feature to launch, or are they just using it as a tool to gauge your technical or leadership merits? At companies that hand out return offers conservatively, this is an important meta question to ask yourself, and maybe your manager, before talking about projects. This ties into goal-setting, introduced in the onboarding section.
Identify and align on the shape of your project
Most projects given to software interns can be broken up into the three stages of development: scoping and planning, design, and execution. Each of these corresponds to a unique shape, allowing the intern to highlight and develop specific skills.
If you're trying to demonstrate project or product management skills, try to get a project with lots of ambiguity and cross functional collaboration (e.g., needing collaboration from data scientists, engineers from UI/UX, framework, infrastructure, product, etc). These projects are great for those who want to develop (or to demonstrate) strengths in product management. These projects will usually be under-scoped or even unscoped, with the intention of allowing the intern to navigate processes and to propose a path forward.
Experienced interns may try to seek a project about systems design. These projects are usually well defined from a customer's perspective, but do not prescribe a way to achieve that outcome. The high-level goal is usually to produce a design doc, subject to a design review from senior engineers on the team. The scope and difficulty can vary drastically based on the project and the intern's background, and often the goal is not to produce an acceptable design from the start, but to be able to receive and iterate on feedback from the team.
Lastly, there are the projects focusing on technical execution. Often, projects which don't fall into the design category will fall into this - a customer request is triaged by a product manager, and an experienced engineer drafts a design in passing. Of the three types of projects outlined, these are the most common type because they're a small project, or start off as a small piece of a larger project(which was de-prioritized later on). These are great for new interns to cut their teeth, as success is usually dependent solely on their own skills (which include asking for help). These projects typically involve the intern studying the problem, understanding the solution being proposed, optionally breaking down the proposal into milestones (may or may not already be done), and moving towards the goals by creating PRs. If you're lucky, you may even see the feature reach production before you leave. Otherwise, make sure to set up the next responsible individual for success by leaving good documentation for next steps.
How to say goodbye
I've seen my fair share of intern departures (both ones whom I directly mentored, and ones who were just on my team), and I've found that it's harder for interns to say goodbye than it is for the team. The saying, "For us, dogs are only a small piece of our life. For them, we are their whole world." feels appropriately adapted to "For us, interns are only a small piece of our career. For them, we are their whole professional career (thus far)."
This section is for those who find goodbyes difficult. Of which I'm one of them.
Hopefully you've added your teammates to linkedin/preferred social media during your internship, but if by the end you haven't already, definitely do so. Also, think back to your time interacting with other interns and full timers from other teams. Did any stand out? Be sure to send them an invite too (when you send the invite, also include a short message about where you met and why you appreciate their time and connection).
For those that really made a strong impact on you, find the time to schedule an exit 1:1 meeting. Your manager will almost certainly have one scheduled with you, but also consider meeting with your mentor and any other people on the team who made a strong impression on you. And definitely tell them that! Ask the people you respect most to give you their closing thoughts, words of encouragement, tips and tricks about navigating school, the market, whatever you're curious about. Definitely ask about external opportunities for engagement after you leave. Asking them directly puts the ball in their court, allowing them to commit to something they're comfortable with. The truth is, some people are simply not interested in interns, so it's helpful to go into these conversations without expectations. That being said, most will be cordial - even if they're not willing to chat with you after, they'll usually be able to point you towards potentially helpful resources. A student asked me about where we could stay in touch, and I introduced them to some mentorship Discord servers I was active in.
Lastly, take your notes and learnings with you. Don't take anything confidential and proprietary obviously, but high level notes such tips and tricks working with React, git aliases, and the like are fair game. As you take and internalize these learnings, you'll build up an ever increasing head start in your future work.
Assorted FAQs
In case you haven't noticed, I'm not a writer. There were many questions and comments early reviewers and students have asked since I started the outline of this document, and I was too lazy (read: incapable) to incorporate them into the main piece so I'm adding them here. If you have questions that aren't answered either in the main doc nor in the FAQs, write to me in the TCN discord and I'm happy to discuss and add to this doc.
How do I write good documentation?
Good documentation is in the eye of the beholder. Who is going to read the docs? For example, if you're reading a piece of documentation as part of your onboarding, improving that doc will likely help future interns who are onboarding to the same project, so you'd avoid using jargon and other complicated concepts to maximize the effectiveness of your writing.
These days, a lot of documentation is scraped, aggregated, amalgamated, and regurgitated by AI. If you're writing docs for AI's eyes, then maybe you would choose to focus more on conciseness and preciseness to the point where a human may consider it pedantic.
Similarly, each PR you submit also includes a mini-documentation in the description (I hope). The goal of that piece of documentation is to provide the reviewer with the necessary context to approve or reject your code change.
This would be a great question to ask your mentor, as it's simply impossible to give both specific and widely-applicable advice on this topic.