Skip to main content

8.1.3. How to Maximize Your Day-To-Day

When you start your internship, it’s natural to want to make a good impression. You want to show that you’re capable, eager to learn, and ready to contribute. But how do you do that in a way that stands out?

Don't Ask Bad Questions​

When you join a team, you might hear the phrase, “there are no bad questions.”

While the intent behind this sentiment is to encourage curiosity, it’s not entirely accurate. The way you ask questions can leave a lasting impression, and asking poorly thought-out or vague questions can reflect negatively on you.

Good questions demonstrate that you’ve put effort into understanding the problem before seeking help. They show that you’re thoughtful, resourceful, and respectful of others’ time.

For example, instead of asking, “Why isn’t this working?” try asking, “I’m getting this specific error when I run my code, and here’s what I’ve tried to resolve so far. Could you help me understand what I might be missing?”

As a rule of thumb, write every question you ask like a Stack Overflow question forum post. This means including screenshots, error logs, links to relevant code or documentation, and a clear description of what you’ve already tried.

Before asking a question, try…

  • Searching for the issue within your company’s documentation platform
  • Searching for the issue within your company’s message app (Slack, MS Teams)

By showing that you’ve taken the initiative to research, test, or troubleshoot, you signal to your team that you’re proactive and committed to learning.

Consistently asking questions without context or preparation suggests a lack of independence or effort, which can erode trust over time.

Start With Good First Issues & Pairing​

Starting in a new codebase can feel overwhelming, but there are ways to ease the transition and make a strong impression on your team.

When starting out in a new codebase, I recommend asking to pair program with one of the full-time developers on your team while working on “good first issue” tickets when they are busy.

Pair Programming​

Pair programming involves collaborating with a teammate to work through a piece of code together.

Ask to pair program with one of the full-time developers on your team. This is a great way to get an applied understanding of your team’s immediate work as opposed to reading through documentation or getting an oral overview of the codebase.

Good First Issues​

“Good first issues” are curated tasks designed to be approachable for new contributors. These tickets are typically non-urgent, low-risk, and great opportunities to get familiar with the codebase while contributing something meaningful.

Once your development environment is set up, proactively ask your mentor or engineering manager for good first issues to work on. Emphasize that you’re looking for tasks that won’t block your team or have tight deadlines, as these are ideal for ramping up.

Not every team has a list of curated tasks ready for new members. If that’s the case, bring up the idea early. By asking for good first issues, you encourage your manager or mentor to prepare tasks that will help you contribute sooner.

Advocate for Breadth of Work​

If you’re new to a codebase, it’s easy to get pigeonholed into working on similar tasks or focusing on a specific area, especially as an intern who hasn’t yet built trust with your team members.

During most software engineering internships, you’ll likely have time to complete only a handful of tasks, making it crucial to advocate for opportunities that allow you to work on diverse tasks and interact with different technologies across your team’s system.

For example, if your team is building an app with both frontend and backend components, try not to limit yourself to just backend work.

Throughout your internship, think about how your experiences will shape your resume. Are there skills or technologies that would make you more employable in the future if you gained experience with them now?

Also consider what you’ve done in previous internships. If you already have experience with a given technology or area of the stack, make sure you’re learning something different during your current internship.

If your workplace doesn’t naturally offer opportunities to explore different areas, consider raising this with your manager or mentor during a 1:1 meeting.

Take Ownership and Clarify Details Early​

One of the most common pitfalls for interns, junior developers—and even seasoned programmers—is diving into implementation before fully understanding the requirements or assumptions behind a task. Instead, you should take ownership and work to fully understand a ticket’s scope and ensure that all requirements are met when it’s delivered.

You do not want to tell your team your ticket is almost done, only for your entire approach to be questioned once you submit your first draft of the code for review. You also don’t want to mark a ticket complete while missing a part of an acceptance critiria and potentially derail future dependant tickets in your team’s backlog.

If a ticket has ambigious requirements, hop in a call with the developer, designer, or product manager who wrote the ticket to clarify when you have a question.

For design or product driven tasks, share screenshots and video updates to confirm you’re meeting their vision before completing the task. This iterative approach avoids spending hours building something that doesn’t meet their needs.

By seeking clarification early and staying aligned with your team, you’ll build trust with your colleagues and have more time to take on a greater breadth of tickets.

Pair on Tickets Outside Your Depth​

As an intern, you’re going to see tickets that you just don’t feel you have the experience to take on.

It’s tempting to avoid these tickets to avoid slowing down the team or making mistakes. However, these tickets often provide the most valuable learning opportunities and can accelerate your growth as a developer.

Instead of shying away, consider taking a proactive approach: while continuing to work on tickets within your comfort zone, ask your teammates if it’s possible to pair program on the more challenging tickets.

Especially for tickets like research tasks or spikes, it’s great to pair with someone so you can observe how they break down ambiguous problems, structure their research, and prioritize key insights.

Don't Have Too Many Tickets in Flight​

Aim to keep no more than two tickets in progress at a time.

The final 5–10% of a ticket can often be the most challenging, requiring extra effort to address edge cases, resolve loose ends, or finalize documentation. Additionally, once a ticket reaches the code review stage, it may go through several iterations of feedback, potentially adding days of additional work.

Start by focusing on one ticket. Only take on a second if:

  • Your first ticket has reached the code review stage.
  • Your current ticket is blocked and will likely remain so for more than a few days.

Some valid reasons for taking on a second ticket might include waiting for:

  • Alignment from another team on the ticket’s direction.
  • Input or clarification from stakeholders.

If you know a ticket is going to be blocked for an extended period (e.g., over a week) and it’s unclear when it will be unblocked, let your manager know and ask to be unassigned and explain the situation and the uncertainty around resolution timelines.

Participate in Code Reviews​

As an intern, you might not feel comfortable or ready to contribute to code reviews. It’s natural to worry about saying the wrong thing or not understanding enough to provide valuable feedback. But remember, no one expects you to be an expert as a newcomer. Code reviews are not just about spotting issues—they’re also an excellent learning opportunity for you.

A great way to get involved in code reviews is simply by asking thoughtful questions. If you’re unsure about why something was implemented a certain way, ask for clarification.

Another way you can get involved is by QA-ing the change. Leaving a comment like, “I’ve tested this change in my local environment and it works as expected, but don't have context on (x,y,z) parts of the codebase. Can someone else confirm ...” is a great way to contribute without needing deep knowledge of the codebase.

At the very least, just read code reviews. Pay attention to how other team members provide feedback during reviews. Notice the types of comments they leave and over time, you’ll gain confidence and start contributing more meaningfully.

Every Meeting is a Presentation​

Come to every meeting prepared.

Treat every meeting you need to speak in like a presentation.

If you’re expected to speak—even for a brief update—take the time to organize your thoughts beforehand. Be concise, clear, and confident in your delivery.

If you’re organizing a meeting—even a brief one—make sure you’ve created an agenda with clearly identified questions or outcomes you need from the meeting.

Meetings aren’t just about exchanging information; they’re moments to leave a positive impression, establish yourself as a valuable team member, and build trust with your team.