How to Prepare for a Coding Interview (Internship)

You have a live technical interview coming this fall, and "grind LeetCode" is the only advice you keep hearing, which is both vague and a little terrifying. This guide gives you a real plan instead: prep keyed to how many weeks you have left, the roughly eight patterns that cover most intern-level questions, and the talk-out-loud habit that interviewers are actually grading. One thing to settle first: the automated online assessment usually comes before this round, and the "tell me about a time" behavioral questions are a separate part of the same loop. This post is purely the coding problem you solve while a human watches.

What an internship coding interview actually is

Picture one screen: you, an interviewer on a call, and a shared editor (sometimes a plain text doc with no autocomplete). They give you a problem, and you solve it while talking. These rounds usually run about 30 to 45 minutes and cover one or two problems, not a marathon. The interviewer is not silent, either. They can hint, ask follow-ups, and nudge you when you drift.

That makes it different from the two rounds around it. The timed online assessment you take alone, with auto-graded problems and no human watching, comes first and has its own logistics like retakes and recording setup, all covered in the OA and one-way video guide. The behavioral round, where they ask "tell me about a time you handled a conflict," is separate too, and so is the opener "tell me about yourself." This guide is only the part where you write code in front of someone.

One calming truth before you start: intern interviews tend to be graded more gently than new-grad or full-time ones. Nobody expects a polished engineer. They expect a student who can think.

The honest truth: you don't need 500 LeetCode problems

The fear is that there are thousands of problems and you have to have seen the exact one they ask. You don't. Interview problems are variations on a small set of shapes, and once you can recognize the shape, you can solve a problem you've never seen before.

So the goal of prep is not volume. It's pattern recognition. "Find if two numbers in a list add up to a target" and "find if a string has a repeated character" feel like different problems, but both are solved the same way: put things in a hashmap and check as you go. Once that clicks, you stop memorizing solutions and start recognizing which tool the problem is asking for.

For intern roles specifically, you can relax about the scary end of the syllabus. Hard dynamic programming, advanced graph theory, and clever math tricks rarely show up. If you understand the patterns below and can talk through your thinking, you are prepared for most of what intern interviews throw at you.

Prep by time left: 6 weeks, 2 weeks, the night before

The right plan depends entirely on how much runway you have. This is triage, not a calendar you have to follow perfectly. Find your bucket and start there.

If you have about 6 weeks

You have room to build real fluency, so use it.

• Pick one language and learn it cold. You want to write a loop, a hashmap, and a function without thinking about syntax. Fighting the language while also solving the problem is the worst position to be in.
• Work through the eight patterns below, a few problems each. Depth over breadth. It is better to deeply understand a few problems per pattern than to half-solve fifty random ones. That is often a few dozen problems total, not hundreds.
• Do one or two mock interviews out loud. This is the step people skip and regret. Solving silently in your room is a different skill from solving while narrating to a person. Grab a friend, or talk to a rubber duck if you have to, but say the words.

If you have about 2 weeks

Drop any goal of mastery. You are optimizing for recognition and composure.

• Do two or three representative problems per pattern, not more. One classic example of each shape so you recognize it on sight. Skim solutions when you get stuck rather than grinding for an hour.
• Prioritize the common patterns first. Arrays and strings, hashmaps, two-pointer, and tree traversal earn their time before binary search or DP.
• Practice narrating from day one. Even now, solve out loud. The communication habit below moves the needle more in two weeks than three extra problems would.

The night before

Do not learn anything new. Cramming a fresh pattern at 11pm trades sleep for panic and rarely sticks.

• Re-skim your pattern notes, not full problems. Just remind yourself which shape maps to which tool.
• Prep your clarifying-questions opener (the four-step process below) so your first move is automatic when nerves hit.
• Set up your environment: the editor link tested, a quiet room, water, a charger. Remove tomorrow's friction tonight.
• Sleep. A rested brain that recognizes patterns beats an exhausted one that memorized an extra problem. This is the highest-leverage thing you can do the night before.

The 8 patterns that cover most intern questions

This is a starting set, not an exhaustive list. But learn these and you will recognize the shape of most intern-level questions you see. One line each: what it is, plus a problem type that should trigger it.

• Arrays and strings. The basics: iterate, index, build a new sequence. Example: reverse a string in place, or merge two sorted lists.
• Two-pointer. Two indices moving through a sequence, often from both ends. Example: check if a string is a palindrome, or find a pair that sums to a target in a sorted array.
• Hashmap / frequency counting. Store what you have seen for instant lookup or counts. Example: "find if two numbers sum to a target" or "find the first non-repeating character."
• Sliding window. A moving range over a sequence to track a running subarray or substring. Example: "longest substring without repeating characters."
• Binary search. Halve a sorted search space each step. Example: find a target in a sorted array, or find where a value would be inserted.
• Stack and queue. Last-in-first-out or first-in-first-out bookkeeping. Example: "are these brackets balanced," or processing items in order.
• BFS / DFS on trees and graphs. Walk a tree or graph level by level (BFS) or branch by branch (DFS). Example: tree traversals, "is this binary tree symmetric," counting connected pieces.
• Recursion and basic dynamic programming. Solve a problem by solving smaller versions, then cache repeats. Example: Fibonacci, or "how many ways to climb stairs taking one or two steps."

You do not need to master all eight before your interview. Cover the common ones first, and treat the rest as bonus recognition.

How to talk through a problem (the part they're actually grading)

Here is the thing nobody tells you clearly: the interviewer is not grading whether you produce a perfect solution in silence. They are grading how you think, and they can only see your thinking if you say it out loud. A candidate who talks through a half-finished solution often beats a silent one who finishes. Make this a repeatable four-step process.

1. Clarify the question before you touch code. Restate the problem in your own words and ask about inputs, outputs, edge cases, and constraints. Can the input be empty? Are there duplicates? How big can it get? This is not stalling. It shows you do not blindly start coding, which is exactly the habit they want in an intern.

2. State your approach and complexity out loud, before coding. Describe the plan in plain English and name the rough time and space cost. If your first idea is slow, say so and say you will start there. Getting buy-in here means you do not write thirty lines down a dead end.

3. Think out loud while you code. Narrate decisions and trade-offs as you type. "I'll use a hashmap here so lookups are constant time instead of scanning the list each pass." Silence is the enemy. When you go quiet, the interviewer cannot help you and cannot see you working.

4. Test your own code at the end. Walk a small example through your code by hand, line by line, and check the edge cases you raised in step one. Catching your own bug is a strong signal. Having the interviewer catch it for you is a weaker one.

Here is roughly what good narration sounds like:

"Okay, so I'm given an array and a target, and I want two numbers that add up to it. Can the array be empty, and can I assume exactly one answer? Got it. My first thought is checking every pair, which is O(n squared), but I think I can do better. If I store each number I've seen in a hashmap, then for each new number I just check whether its complement is already there. That's one pass, O(n) time and O(n) space. Let me code that. I'm looping through the array, and for each value I compute target minus value and look it up... let me test this with 2, 7, 11 and target 9: I see 2, store it, then 7, its complement is 2, which is in the map, so I return those indices. Works."

That is the whole skill. Not magic, just out loud.

What to do when you blank

You will probably hit a moment where your mind goes empty. It happens to almost everyone, and it is not the failure you think it is. Interviewers expect it. What they are watching is how you get unstuck. Here is a recovery script.

• Say it out loud. "I'm a bit stuck, let me think through this." This is allowed and normal. It buys you a moment and signals composure instead of a freeze.
• Walk a tiny example by hand. Take the smallest possible input and solve it manually on the shared screen. The pattern often reveals itself once you see concrete numbers.
• Solve the brute-force version first. A slow solution that works beats a fast one that does not exist. Get something correct, then say "now let me see if I can make this faster."
• Write pseudocode before real code. Sketch the steps in plain English, then translate. It is much easier to debug a plan than a pile of half-written syntax.

None of these are cheating. They are exactly the problem-solving moves a real engineer makes, which is the whole point.

Frequently asked questions

How many LeetCode problems should I do for an internship interview?

There is no magic number, and anyone who gives you a precise one is guessing. Aim for a few solid problems per pattern that you understand deeply, which often lands around a few dozen total, not hundreds. Recognizing the pattern behind a problem matters far more than the raw count you have grinded.

Are internship coding interviews easier than full-time ones?

Generally, yes. Interns tend to be graded more leniently, and the hardest dynamic programming or graph problems rarely appear. That said, "usually" is not "always," and communication still matters at every level. Prepare seriously and treat the leniency as a cushion, not a guarantee.

What language should I use for a coding interview?

The one you know best. Many people use Python because it is short and quick to write, but the company almost always lets you choose, so play to your strengths. Do not learn a new language just for the interview; fighting unfamiliar syntax under pressure is the last thing you want.

What do interviewers actually look for in an intern?

A clear thought process, good clarifying questions, the willingness to get unstuck, and signs you are teachable. They are not hunting for a flawless memorized solution. An intern who reasons well and takes hints is more hireable than one who silently recites an answer.

What if I can't finish the problem in time?

Partial, well-communicated progress with a stated approach often still passes. A silent candidate who happens to finish is not the bar. If you explained your plan, made real progress, and stayed unstuck, you have shown the thing they care about. No guarantees, but unfinished is rarely an automatic fail.

Three things to do today. Pick the one language you will use and commit to it. Save the eight-pattern list above somewhere you will actually re-read it, or skim a free pattern-based guide like the Tech Interview Handbook to go deeper. And book one mock interview out loud this week, because narrating to a person is the rep that separates calm from frozen. If a round does not go your way, it is one data point, not a verdict, and there is a way forward from a rejection. Meanwhile, keep your pipeline full and browse internships so you have more shots at the rounds you are now ready for.