Here’s the thing nobody tells you before your first internship interview: the bar isn’t “can this person do the job independently?” It’s closer to “is this person coachable and will they show up?” That’s a much lower bar than it sounds, and also a completely different thing to prepare for.
What they’re actually evaluating
I’ve read a fair amount of recruiting research on this, and the pattern holds up: for internship candidates, companies weight learning speed and communication much more heavily than technical depth. A 2024 NACE research report on internship hiring found that employers rated “problem-solving” and “communication” as their top two criteria for intern selection, ahead of GPA and coursework relevance.
That doesn’t mean you can skip technical prep. It means the bar is explaining your thinking clearly, not getting every question right.
Using class projects and coursework as interview material
This is where a lot of students undersell themselves. A semester-long database project, a group capstone, a personal site you built in a web dev class: these are real projects. They involved real tradeoffs, real debugging, real collaboration. The fact that they weren’t at a company doesn’t make them less useful as interview material.
The way to talk about them: describe what you were trying to build, what broke or surprised you, and what you’d do differently. That structure works for almost any project story. It also avoids the trap of summarizing what the project was (which the interviewer can read on your resume) versus what you actually learned from doing it.
Hackathon projects work too. Even ones that didn’t finish. Especially ones that didn’t finish, honestly, because there’s usually a better story in what you cut than what you shipped.
The 30-second intro they’ll ask for
Every interviewer asks some version of “tell me about yourself.” The mistake is treating it as a biography recitation. Keep it to three things: where you are in school, what you’re interested in technically or functionally, and one specific reason you’re interested in this role or company (not “I love your company culture”).
Thirty-five to 45 seconds is the right length. Under 30 and you seem unprepared. Over 90 and you’ve lost them before the real questions start.
Example that works: “I’m a junior at UNC studying CS, focused mostly on data systems and backend stuff. I worked on a distributed logging project last semester that got me interested in observability tooling, which is why I applied to this team specifically.” That’s it. That’s the intro.
Technical questions: what to expect and how to handle blanking
For software engineering internships, the technical screen is usually fundamentals: arrays, hash maps, basic graph traversal, maybe a sorting problem. Not hard LeetCode mediums. Not system design. The interviewers know you’re a student.
What they’re watching: do you think out loud, do you ask clarifying questions before coding, do you notice edge cases, do you get defensive when given a hint. Those behaviors matter more than solving the problem in the fastest possible way.
If you blank on something, which will happen, to everyone, say what you’re thinking. “I know this should use a hash map for O(1) lookup but I’m spacing on the exact implementation, let me think through the access pattern.” That’s a real thing to say. It’s better than silence.
Questions to ask them (and why they matter)
The questions you ask at the end of the interview are not a formality. They’re the part of the interview where you get to demonstrate that you’ve actually thought about the role. Ask about the specific team, the kind of work interns actually get to do (not the idealized version), and how the feedback loop works during the internship.
Questions that work well:
- “What does a typical week look like for an intern on this team?”
- “What’s the biggest project an intern has owned in the last year or two?”
- “How do interns typically get feedback, is it structured or more informal?”
Questions to avoid: anything Google could answer for you, anything about return offer rates before you’ve even started, and “what do you like about working here?” (it’s fine but it’s what everyone asks).
One honest thing about preparation tools
Practicing answers out loud, not in your head, actually out loud, makes a bigger difference than most students expect. It’s uncomfortable, which is why most people don’t do it enough. Record yourself once if you can stand it. You’ll notice filler words and rambling you didn’t know you had.
Some students use live AI interview practice tools to simulate the question-answer loop before the real thing. I can’t say definitively whether that translates to better outcomes, but the students who practice under realistic conditions (timed, spoken aloud, with follow-ups) consistently report feeling less surprised during the actual interview. Craqly’s mock interview mode is one option for this kind of practice if you want something interactive. Whether or not you use a tool, the core habit is the same: rehearse out loud, not in your head.
The internship interview is not a test of how much you know. It’s closer to a test of whether you can be useful and honest about what you don’t know yet. That’s a much more learnable thing than most students realize.