What changes after the internship

Same STAR, a different room

If you went through an internship, you already built STAR stories (situation, task, action, result). They came from a solo project, a study group, or a rotation with a mentor who checked your work daily. You keep that skill for a junior interview. Every answer still takes that shape. What changes is the room hearing those stories, and the kind of story it expects. An intern interview mostly asks "can this person learn?" A junior interview, even for a first junior role, asks a harder question. Can this person be trusted with a small piece of something real, on a team, without someone checking every line before it ships? This course is about the stories that answer that second question.

What doesn't change

The mechanics stay the same. You still build answers ahead of time instead of composing them live. You still open with a specific situation instead of a vague generality. Action is still the longest and most detailed part, told in first person. If any of that feels shaky, take a quick pass back through your intern-level material first. Everything here assumes you can already build a STAR answer. This course covers which stories you reach for now, and how a team-level "action" differs from a solo one.

Ownership stops being borrowed

As an intern, you usually borrowed ownership of a task. A mentor assigned it, reviewed it closely, and carried the responsibility if it went wrong. As a junior, a ticket gets assigned to you. A senior engineer will still review your pull request, but making it work in production starts with you. Interview questions show that shift directly. Instead of "tell me about a project you built," you'll hear "tell me about a feature you shipped". You may also hear "tell me about a bug you were responsible for fixing". The word "responsible" carries weight in that sentence. Your story should show you felt that weight, beyond finishing a task.

The feedback loop reverses

During an internship, feedback mostly flows one way. A mentor reviews your code and tells you what to change. As a junior, you still receive that feedback, often a lot of it at first. You're also expected to start giving some back. You might flag something confusing in a teammate's pull request, or ask a clarifying question in a design discussion. Sometimes you push back gently when an approach seems wrong. Interviewers ask about this directly. "Tell me about a time you disagreed with a more senior engineer" is aimed at juniors. It tests whether you can hold a technical opinion without caving at once or getting defensive. Lessons 3 and 4 build this skill in depth.

Your voice starts counting in the room

An intern's opinion in a standup or planning meeting is often treated as optional. People like hearing it, but nothing rests on it. A junior's opinion starts to count, even in small ways. If you say a ticket will take two days and it takes five, that affects the sprint. If you flag a risk in a design discussion and you're right, people remember it. Interviewers probe this with questions like "tell me about a time your input changed a decision". Another common one is "tell me about a time you had to say no to a deadline". These aren't trick questions about confidence. They check whether you understand that your voice now carries weight, even at your level.

The technical bar sits behind the same question shapes

A behavioral question can sound identical in an internship interview and a junior one. "Tell me about a time you were stuck" is a good example. The bar behind it moves, though. For an intern, a good answer might be getting unstuck on a personal project after two days alone. For a junior, the interviewer listens for whether you know when to escalate. Did you spend three days silently stuck on something a five-minute Slack message could have solved? The judgment about when to ask matters more than getting unstuck alone, and lesson 5 covers it. Teams don't want a junior who never asks for help. They also don't want one who asks before trying anything. The stories in this course should show that judgment as well as persistence.

New question shapes you'll hear now

A few prompts show up at junior level and rarely in an internship interview:

"Tell me about giving feedback on a teammate's code". "Walk me through how you'd comment on a pull request you disagreed with". "Tell me about an incident or a bug that reached production". "How do you stay in sync with a team in another time zone?"

None of these has a clean intern-level equivalent. Each assumes you've been inside a team's day-to-day workflow, even briefly. That could be a class project with a shared repository, an open-source contribution, or the internship itself.

A quick self-check

Before moving on, be honest about where you stand. Do you have a disagreement story from a real team, or only an older one from a study group? Have you ever left a comment on someone else's pull request? Can you describe one mistake, calmly, in under a minute? If any honest answer is no, the next six lessons are for that. You won't invent answers. You'll find you already have more material than you think, once you know what to look for.

Where this course goes

Lesson 2 covers teamwork stories from a real team, beyond a solo project or a study group. It deals with disagreement, collaboration, and stepping up when someone else was stuck. Lesson 3 covers receiving feedback without getting defensive and giving it without being harsh, since both directions now apply to you. Lesson 4 covers the questions interviewers ask about code review culture, plus the git and pull request mechanics behind good answers. Lesson 5 handles remote communication in English: async writing, standups, and asking for help across time zones. It includes a section on interviewing from Brazil. Lesson 6 takes on mistakes and incidents, including the gap between hiding a mistake and owning it out loud. Lesson 7 runs a full behavioral round from open to close, so you walk in having heard every question shape once.

You already have material for this. If you finished an internship, you've sat in standups and had a pull request reviewed. You've probably been the one who noticed a bug nobody else caught. The stories exist. This course helps you recognize which ones answer a junior-level question, and build the two or three you still lack.