You got the internship. Now how the hell do you do well in them? Let's talk.

The timing of this random thought is purposeful. Happy Intern Season! 🎉

How to get them

How to do well in them

It's not as straight forward as you'd think.

In large companies, the culture and dynamics across various orgs and teams can be very different—they're fuckin huge.

In a startup, the culture and processes are still evolving, making the intern experience more centralized yet less predictable.

Naturally, there's no universal approach that fits all situations, but there's a wealth of proven advice available. I can attest to this, having experienced both environments.

The stuff people don't talk about

Be "the intern"

Ok let me clarify what I mean here.

When companies hire interns, you should know that they have and always will be looking for curious & engaged students - especially those who bring fresh perspectives and energy to the team.

Don't believe me? Well, look at this LinkedIn post from some of Microsoft's exectives:

Microsoft's Executives appreciating interns

There's a certain authenticity to being an intern that can actually work in your favor.

So honestly, embrace that intern status.

This doesn't mean you should be overly deferential or afraid to suggest improvements. Rather, I think it means leaning into the unique position you're in as someone who's there to learn and contribute, and not heavily increase shareholder value.

In practice

• Be active in team channels
  • Even if just to be a sponge and absorb as much knowledge as you can
  • Share design docs, product requests, write RFCs, trust. Champion your team's work.

Even if say Discord isn't your thing, I'd STRONGLY suggest getting comfortable with async chat in any platform. This will make it so that when you eventually join a company's Slack or Teams workspace, you'll find yourself naturally adapting to their communication style.

• Do some water coolers with people across the company whose work (or life) interests you

The whole reason this entire website exists (why I moved away from my old domain) is because of Randy Hunt.

At Notion, I met him over lunch, and we instantly hit it off. A fellow Orlando native and design nerd, we bonded over our love for the city (NYC) and product design. You should find people like this. And cherish them.

• Ask all the questions when you genuinely need help

So please, use that license while you can. Once you become a full-time employee, there's certain things on that license that you'll just be "expected to know" - not to say that you can't (ask questions) once you become a FTE.

Be self-sufficient

Let's be honest. The idea that there's "no such thing as a stupid question" isn't entirely true in non-academic/R&D professional settings. The reality is that most of the work we do as engineers is not SUPER NOVEL, and there's a good chance that someone else has either:

• Solved the same exact problem
• Solved a similar problem
• Written about the problem
• Encountered the problem

Possibly even within the same company. And if not, you're surrounded by so many talented engineers, designers, and product experts who are more than willing to help you out when the problem is not within your scope.

It's diabolical how we've collectively forgotten that "software engineers constantly Googling solutions" was a running joke in the industry for years because of AI becoming embedded in development.

Having a senior engineer spend valuable engineering time explaining something you could have discovered independently can be a productivity sink for both you and them. People often underestimate how much of a commitment it is to be an IC/non-manager trying to get things done and also explaining complex systems to a junior engineer.

Keep a personal knowledge base

A Notion or Google Doc that you treat as your own "internal documentation" is a godsend. Put:

• Previously asked questions and the answers you found
• Any relevant team documentation and links to them
• Slack channels, major team projects, and meeting notes
• Code snippets, commands, and other useful information

You'll be shocked at how much this one tip can help you during your time as an intern - please don't sleep on it. As a hourly (in most cases) employee, time is valuable, and you should always be finding ways to optimize it.

Ask good questions

This one is a no-brainer, but a lot of people don't actually know what seperates a good question from a bad question. So let's talk about it.

In practice

1error: could not find package `some-random-package` in any of the sources

1bun add some-random-package

There's a lot to call out here, but I'll just focus on the most important parts:

Be specific

Instead of saying "it's not working", try to be specific about what the issue is. Error messages, stack traces, UI screenshots, etc. Follow up questions are great, but if you get into a back and forth with someone trying to help you, it could sometimes be avoided if you're more specific.

Same example from earlier, but in this framework:

You: Hi team, I'm having trouble with my project setup. Can anyone help?

Teammate: Sure, what seems to be the issue?

You: It's just not working. I'm not sure what's wrong.

Teammate: Can you provide more details? Are you getting any error messages?

You: Oh, right. There's an error message saying "dependency not found."

Teammate: Which dependency is it referring to? And what command are you using?

You: It's some-random-package. I'm using bun add some-random-package.

Teammate: Have you checked if the package is available in the registry?

You: I haven't checked the registry. I'll do that now.

See the problem here? If you provided everything upfront, you'd avoid this back and forth dilemma between you and the person trying to help you.

Provide context

Provide context about what you're trying to accomplish. Don't just ask how to solve a specific error - explain the broader goal. This helps people give you better solutions that might address your actual needs rather than just fixing the immediate problem. Sometimes, the solution you're looking for is not actually the solution to the problem you're facing.

Show your research

Demonstrate that you've put in effort before asking. Link to documentation you've read, similar issues you've found, or approaches you've already tried. This signals respect for others' time and helps avoid suggestions you've already explored.

Format your questions for readability

Use code blocks for errors and code snippets. Break up long questions into digestible sections. Screenshots can be helpful for UI issues, but always include text versions of error messages so they're searchable for others around the company.

Make a brag doc

Slightly different from the previous tip on keeping a personal knowledge base, a "brag doc" is simply a document that you can use to track your accomplishments during your time at the company. It's very common for FTEs to have one for when performance reviews come around.

Although it's also a good idea to have one for an internship.

In this document, make sure to include all things you've done in your time at the company.

• Major optimizations you've made
• Thanks given to you by your team
• Beefy PRs you've written and merged
• Any other accomplishments you're proud of

This is also a great way to keep your mentor and or manager in the loop about your progress.

Contrary to popular belief, failing, especially in a professional setting, is not always a bad thing. Most of the time, it means you're trying new things, and you're not afraid to fall on your face.¹

For the record, I've failed a lot. But let's be real for a second. In a corporate settings, it's not the end of the world. If you can fall, get hurt, and get back up - that shows maturity, and a willingness to learn - which are all good signals to give the company/team your working with during your internship.

Let's say you take down prod.

If you just try playing the blame game, or trying to cover up your mistake, you're not going to learn anything, and people will see you as incompetent or stubborn (which is a good way to not get a return offer).

By putting it in your brag doc, you're acknowledging that you made a mistake, and you're willing to learn from it, which a WAYYYY better look than trying to seem like you're perfect and can do no wrong.

Be proactive

This section is more self-explanatory, so I'm just going to list out a things I've learned:

• If you have a mentor, make a 1x1 with them every week with a doc on your weekly progress
• If you don't have a mentor, make a 1x1 with your manager every week
• Don't wait for someone to tell you what to do if you have no work to do. Use the product, break things, and see if you can fix them
• Invite the other interns, FTEs, to do things with you - get to know them, and they'll remember you
• Volunteer for things the company is doing, you'd be surprised how fun they can be

Have some fun

But wait....What do I do?

No words needed

And that was just a random Friday in NYC. You can just do things ya know..

Not so fun: how to fail in them

Lone wolf

One of the biggest mistakes interns make is trying to be the "lone genius programmer". Let me explain why this mindset can hurt you.

Software engineering, especially during internships, is fundamentally collaborative. Your typical week will likely include:

• Daily standups to sync with your team
• Sprint planning to scope upcoming work
• Design reviews to get feedback on solutions
• Pair programming sessions with mentors
• Bug bashes to improve product quality
• Regular performance check-ins

The truth is that modern engineering is deeply team-oriented, despite what movies and media might portray. The myth of the solitary coding genius, working in isolation to solve complex problems, is like the last thing you want as an intern anyway.

One of the core benefits of internships in the first place is that you get to work alongside people who you can learn from and grow with as your time at the company progresses.

I think this will make more sense with an example of this in an everyday-ish roleplay:

What not to do:

You: Hey team. I saw this huge bug on prod reported by hundreds of users here, here, and here. I'm going to go ahead and fix it!

...two days later...

You: Hey team. I fixed the I mentioned a few days ago. Peace!

Ruh roh:

Your teammate: Hey Nyuma, um actually—we've already got a partially implemented solution for this in this pull request. We also agreed in this meeting that we'd be using this design for the final solution, so I'm not sure if the work (which we're glad to see you attempt) is necessary.

You: Aw, my bad—I'll go ahead and close the PR then.

Notice the tipping point here? While it's not a given that you'll not see previously implemented solutions, this is the core downfall of "being a loner". If Nyuma, our OP, had just dived a bit deeper on the problem and less of the actual implementation, he would've realized that the work he did was unnecessary.

Being yourself

Tailoring your behavior to fit the company culture - especially as an intern - is tricky. While the advice to "be yourself" is often given in social settings:

Your friend: Good luck on your first date, bro! Just be yourself, and they will love you!

You: Thanks!

Alright, so the "just be yourself" advice is great - in a dating context - but, when you're stepping into a professional setting, especially as an intern, it's a bit more nuanced. You want to fit in with the company culture while still being true to yourself. It's all about finding that balance.

Some places are super chill when it comes to this sort of thing, but most will expect you to maintain some level of professionalism, especially in how you communicate.

So, while you're being your awesome self is dope, please, be mindful of how you come across to your coworkers. And honestly, it's a skill that will serve you well beyond your internship.

This tweet below, (albeit a bit of a hyperbolic example), is exactly what I'm talking about:

With your friends in school, it may be okay to joke around, share deeply personal stories, and be a bit more casual. However, with your full-time coworkers, they will likely not be able to relate to you - and that's okay! So yeah — "don't be yourself" is kinda hyperbolic, but the idea is extremely important. I had to "code-switch" pretty much every day for my first few internships. Before we move on, let's look at one example of this in-play:

In practice

If you don't appreciate the direction of the company, don't vocalize it to anyone working at the company.

If you work at a artistic company pivoting to an "AI-first" ideology but you're anti-AI art, keep those thoughts locked up. Instead:

• Save broader critiques for your own reflections, (eg., blog like mine, or with your friends & family)
• Discuss it with other fellow interns in private, or talk about it in non-work channels.

Yes, it does sorta sound bootlicking, but this is the unfortunate game of corporate we play.

Anyone who knows me knows that I'm generally an esoteric, more reclusive kinda guy. Having something like this prior to my first internship would've been nice, especially given the background I come from.

Still, even I had to suck up—because at the end of the day, having a job that you slightly alter your personality for is better than not having a job.

Last → A reality check

Let me be straight up. It's true. Oftentimes, company hiring budgets change unexpectedly, layoffs happen, damn—maybe even a hiring freeze. This could mean that you do everything right and still don't get a return offer.

You can't control how your company acts.

But you can control how you react.

This. Is. Not. Your. Fault. Remember that.

If you made it to this exact point in the post, you're awesome. But hey, that's why I'm sharing it with you all on the world wide web, for free - to make everyone, awesome.