What to Expect in a Technology Internship

A realistic week-by-week picture of a mentored technology internship: the work you will do, how you will be reviewed, and what separates interns who get offers.

Book a Consultation
Min read
2
Category
Internship Guide
In short: A well-run technology internship is mostly small, scoped, reviewed work: reproducing bugs, making supervised changes and writing documentation. Interns who succeed ask clarifying questions early, communicate blockers within a day, and treat review feedback as information rather than criticism.

Interns often arrive expecting to build something impressive from scratch. Almost no internship works that way, and the ones that do generally teach less.

What the work actually looks like

  • Small, clearly scoped tasks that someone has already thought about
  • Reading far more existing code, configuration or documentation than you write
  • Reproducing a reported problem before attempting to fix it
  • Submitting work for review and revising it, often more than once
  • Writing down what you changed so the next person is not confused

A typical arc

WeeksFocusWhat good looks like
1-2Environment setup and orientationYou can run the system locally and explain what it does
3-5First supervised tasksYou finish small tickets and ask questions before guessing
6-9Independent scoped workYou are trusted with a feature or investigation end to end
10-12Ownership and handoverYou document your work so someone else can maintain it

How you will be evaluated

Technical output matters less than most interns expect. Mentors are largely assessing whether you would be safe and pleasant to work with as a junior hire.

  1. Do you communicate a blocker within a day, or disappear for a week?
  2. Do you ask a clarifying question before building the wrong thing?
  3. Do you respond to review feedback without defensiveness?
  4. Do you leave the system better documented than you found it?
  5. Do you finish what you start, including the unglamorous last ten percent?

Common mistakes

  • Staying silent when stuck, because asking feels like admitting weakness
  • Rewriting existing code because you would have done it differently
  • Optimizing for volume of commits rather than completed, reviewed work
  • Skipping documentation because the task felt finished without it
  • Treating review comments as a verdict on you rather than on the change

How to get the most out of it

Keep a running log of what you did each week, in plain language. It makes your weekly update trivial to write, it makes your completion report accurate, and it becomes the source of your interview answers for the next two years.

Where to go next

Turn the reading into something you can show

Courses end in graded projects and internships end in documented deliverables, both give you something concrete to talk about.