by Intern interviews are lighter on system design than full-time software engineering interviews, but they still test real coding ability: data structures, a live coding exercise, and whether you can talk through your thinking instead of just producing an answer.
Companies use internships to evaluate people for a return offer, so interviewers are also watching for coachability: how you take feedback, how you handle a bug you didn't expect, and whether you ask good questions when a task is unclear.
Most large tech employers recruit interns on a rolling basis, often opening applications for the following summer as early as the fall before, so timing your prep and applications matters as much as the technical content below.
Software developer intern at a glance
| Item | Details |
|---|---|
| BLS occupation | Software developers, quality assurance analysts, and testers |
| Median pay (full-time role) | $135,980 a year (BLS, May 2025); intern pay is hourly and varies widely by company size and location |
| Job outlook | 10% growth from 2025 to 2035, about 106,100 openings a year across the occupation group (BLS) |
| Education | Usually pursuing a bachelor's degree in computer science or a related field; most employers require a bachelor's for full-time roles (O*NET) |
| Key tools | Git and GitHub or GitLab, an IDE like VS Code, at least one of Java, Python, C++, or JavaScript (O*NET) |
| Interview format | Online coding assessment, then 1 or 2 technical interviews, sometimes plus a short behavioral conversation |
| Hiring timeline | Rolling; large employers often open summer internship applications the previous fall |
How the interview usually works
- Resume screen and online assessment. Many companies use an automated coding test (2 to 4 problems, 60 to 90 minutes) before any human interview.
- Technical phone or video screen. 30 to 45 minutes, usually 1 or 2 coding problems solved live in a shared editor, with the interviewer watching your reasoning as much as the final answer.
- Final round. Either a longer "loop" of 2 to 3 more technical interviews, or a single round combining a coding problem with behavioral questions, depending on company size.
- Offer. Because summer internship hiring is seasonal and rolling, decisions often come faster than for full-time roles, sometimes within a week or 2 of the final interview.
General and background questions
1. Why do you want to be a software developer, and why this company?
Why they ask: They want a reason beyond "I like computers," and some sign you looked at what the company actually builds.
How to answer: Connect a specific interest to something concrete about the company's product or engineering culture.
Sample answer: I got into programming building small Discord bots in high school, and what kept me in it through my CS degree was the moment a piece of code that didn't work suddenly does. I applied here specifically because your engineering blog post on migrating a service from a monolith to smaller services showed the kind of incremental, tested refactoring I want to learn to do well. I'd rather intern somewhere I can see real production code than somewhere I'd only touch a sandboxed project.
2. What programming languages and tools are you most comfortable with?
Why they ask: They want to gauge ramp-up time and whether your background fits their stack.
How to answer: Name languages with rough experience level, and mention version control and any frameworks.
Sample answer: Python is what I'm strongest in, about 2 years across coursework and personal projects, including a Flask API I built for a class project. I've used Java for a semester of data structures coursework and can read it comfortably even though I'm slower writing it. I use Git daily, mostly through the command line and VS Code's built-in Git panel, and I've used GitHub Actions to run tests automatically on a couple of my repos. I'm weaker on JavaScript, some HTML and CSS from a web dev elective, but I can pick it up.
3. Walk me through a project you've built, from idea to finished code.
Why they ask: They want to see how you scope work and make decisions, not just what the project does.
How to answer: Pick one project and go in order: the problem, your approach, one real obstacle, and the result.
Sample answer: I built a study group scheduler for my dorm because everyone was coordinating times over group texts and it was a mess. I started with a rough data model: users, availability blocks, and groups, then built a Flask backend with a SQLite database and a simple React frontend. The hard part was overlapping availability across more than 2 people; my first approach compared every pair of time ranges and got slow past about 10 users, so I switched to sorting intervals and sweeping through them once, which brought it from roughly 2 seconds to under 50 milliseconds for 30 users. About 40 people in my dorm used it last semester.
4. What do you hope to get out of this internship?
Why they ask: They want to know your goals fit what an internship can realistically offer, and whether you're thinking past this summer.
How to answer: Be specific about skills, not just "experience."
Sample answer: I want to work on code that other people depend on and see it through code review, since school projects rarely get read closely by anyone but a grader. I'd also like exposure to how a team decides what to build next, since that's invisible from the outside. Longer term, I'm hoping this turns into a return offer, but even if it doesn't, I want to leave knowing how a real engineering team runs a sprint, reviews code, and ships changes safely.
Technical questions
5. How would you explain Big O notation, and why does it matter?
Why they ask: It's a basic vocabulary check. They want to see you can reason about performance, not just recite the definition.
How to answer: Define it in plain terms and give a concrete comparison.
Sample answer: Big O describes how the time or memory a piece of code needs grows as the input grows, ignoring constant factors. Looping through a list once is O(n): double the list, double the work. A nested loop comparing every pair is O(n squared): double the list, and the work roughly quadruples. It matters because code that looks fine on a test case of 10 items can crawl at 100,000. On my scheduler project, an O(n squared) overlap check was fine for 10 users and unusable for 30, which is what pushed me to rewrite it as an O(n log n) sort-and-sweep instead.
6. How would you reverse a linked list, and what's the time complexity?
Why they ask: It's a standard check on pointer manipulation and whether you can talk through an algorithm out loud.
How to answer: Describe the iterative approach step by step, then state the complexity.
Sample answer: I'd walk through the list once, keeping 3 pointers: the previous node, the current node, and the next node saved before I overwrite anything. At each step I point the current node's next back at the previous node, then shift all 3 pointers forward by one. I'd start with previous as null, and when current becomes null, previous is the new head. That's O(n) time since I touch each node once, and O(1) extra space since I'm not allocating a new list. I'd also mention the recursive version, but I'd default to iterative to avoid stack depth issues on a very long list.
7. When would you use a hash map instead of an array?
Why they ask: They want to see you pick a data structure based on the access pattern, not habit.
How to answer: Contrast lookup time and give a concrete use case for each.
Sample answer: I'd use a hash map when I need to look something up by a key that isn't a small sequential index, since lookup, insert, and delete are all close to O(1) on average versus O(n) for scanning an array. On a project counting word frequency in a text file, a hash map mapping each word to its count made the whole pass O(n). An array makes more sense when order matters, when I need to iterate in sequence, or when the dataset is small enough that the array's lower memory overhead and cache-friendliness beat the hash map's flexibility.
8. What's your experience with Git, and how do you resolve a merge conflict?
Why they ask: Nearly every team uses Git, and interns who fight with it waste review cycles.
How to answer: Describe your normal workflow and walk through an actual conflict you resolved.
Sample answer: I branch for every feature, commit in small chunks with specific messages, and rebase onto main before opening a pull request so the diff stays clean. I hit a real conflict on a group project when 2 of us edited the same function in the same file; Git marked the conflicting lines with the usual markers in both versions. I read both changes, talked to my teammate for 2 minutes to confirm which logic was newer, kept the combined version by hand, removed the conflict markers, and ran the tests before committing the merge. I try to pull and rebase often specifically so conflicts stay small like that one instead of piling up.
9. How do you approach debugging code that isn't yours?
Why they ask: Interns spend a lot of time in unfamiliar code. They want a method, not just "I look at it."
How to answer: Describe your process: reproduce, narrow down, check assumptions.
Sample answer: First I reproduce the bug reliably, since a bug I can't trigger on demand I can't verify I've fixed. Then I read the error or stack trace closely and work backward from where it fails, adding print statements or breakpoints at a few points to see where the actual state diverges from what I expect. On a class project I inherited, a function was returning None intermittently; I added logging at each branch and found it was hitting an edge case where an input list was empty, which nobody had tested. I fix the immediate bug, then check whether the same bad assumption shows up anywhere else in the file.
10. How do you test your code before considering it done?
Why they ask: They want habits that catch problems before code review, not reliance on someone else to find them.
How to answer: Describe your actual testing habits, including edge cases.
Sample answer: I write unit tests for the main path and at least 2 or 3 edge cases: empty input, a single item, and the largest size I expect. On my scheduler project I used Python's unittest module and got into the habit of writing the test for a function right after writing the function, while the edge cases are still fresh in my head. I also run the existing test suite before pushing anything, since a change that looks isolated can break something unrelated. I know I'm not done until the tests pass and I've manually tried the one input I'm least confident about.
Behavioral questions
11. Tell me about a bug you introduced and how you found it.
Why they ask: Everyone ships bugs. They want to see ownership and a fix, not excuses.
How to answer: Name the bug plainly, how you found it, and what you changed afterward.
Sample answer: I pushed a change to my scheduler project that broke the overlap calculation for anyone in more than one group, because I'd assumed each user belonged to exactly one group when I wrote the query. A classmate testing it reported that his availability wasn't showing up correctly. I found it by adding a test with a user in 2 groups, which failed immediately and pointed straight at the query. I fixed the query and added that exact scenario as a permanent test case so it couldn't silently break again.
12. Describe a time you got difficult feedback on your code and how you responded.
Why they ask: Interns get corrected constantly. They want to see you take it in stride and apply it.
How to answer: Give the specific feedback and what you did differently afterward.
Sample answer: A TA reviewing my final project told me my functions were doing too much, one function handled input parsing, validation, and the calculation all in one block, which made it hard to test. My first reaction was that it worked fine, but I sat with the comment and realized I couldn't write a clean unit test for just the calculation without also faking the input parsing. I split it into 3 smaller functions, and testing got noticeably easier immediately. Now I check while I'm writing a function whether I can describe what it does in one sentence, and if I can't, I split it.
13. Tell me about a disagreement with another developer over how to solve a problem.
Why they ask: They want to see you argue about the work, not the person, and reach a decision.
How to answer: Describe both positions fairly and how you resolved it.
Sample answer: On a group project, a teammate wanted to store our scheduling data as nested dictionaries for flexibility, and I wanted a proper class with defined fields, since I was worried about typos in dictionary keys causing silent bugs. We didn't just argue opinions; I wrote a quick version with a class and showed him that our editor could now autocomplete field names and catch a misspelled one before running the code. He agreed the safety was worth the extra structure, and we went with classes for the rest of the project. I try to make disagreements testable when I can instead of just repeating my preference louder.
14. Describe a time you had to learn a new technology quickly for a project.
Why they ask: Interns are frequently handed a tool they've never used. They want a learning process.
How to answer: Name the technology, your approach, and the timeframe.
Sample answer: For a hackathon, my team decided to use PostgreSQL and I'd only ever used SQLite. I spent the first hour reading the official docs on data types and indexes rather than jumping straight to Stack Overflow, since I wanted to understand what was actually different, not just copy syntax. I built a tiny throwaway table to practice joins and indexes before touching our real schema. By hour 4 I was writing our actual queries, and by the end of the 24 hours I understood enough to explain the schema to a judge. I'd rather spend 30 extra minutes reading real documentation than debug guesses for hours.
Situational questions
15. You're given a task with unclear requirements and your mentor is out for the day. What do you do?
Why they ask: They want to see judgment about when to proceed and when to wait, not either extreme.
How to answer: Describe how you'd narrow the ambiguity yourself before escalating.
Sample answer: I'd start by rereading the ticket and checking if there's related code, a similar feature, or a design doc that answers most of my question already. If I can make a reasonable assumption and it's cheap to change later, I'd note the assumption in a comment or the ticket and keep moving rather than blocking a full day on it. If the ambiguity is expensive to get wrong, like a database schema change, I'd message my mentor with a specific question and 2 options I'm considering, so they can answer in 30 seconds instead of writing an essay back. I'd rather ask a sharp, specific question than a vague one.
16. You're assigned to fix a bug in a large codebase you've never seen. Where do you start?
Why they ask: They want a method for navigating unfamiliar code without freezing.
How to answer: Describe how you'd orient yourself before touching anything.
Sample answer: First I'd reproduce the bug locally so I have something concrete to check against. Then I'd search for the error message or the relevant function name to find where the behavior likely starts, rather than reading the whole codebase top to bottom. I'd check the file's test coverage, since existing tests often show what the code is supposed to do. Once I have a theory, I'd make the smallest possible change, rerun the tests, and confirm the fix before looking at whether the surrounding code needs cleanup, since expanding scope on an unfamiliar codebase is how small fixes turn into big regressions.
17. It's the day before a demo and you find a bug you introduced. What do you do?
Why they ask: They want to see you disclose problems immediately instead of hoping nobody notices.
How to answer: Describe telling your team right away and how you'd triage the fix.
Sample answer: I'd tell my mentor or team lead immediately with what I know: what's broken, how I found it, and whether I have a fix in progress, rather than quietly trying to patch it alone under time pressure. Then I'd assess whether it's fixable safely before the demo or whether the demo should route around that feature instead. On a group project, I found a bug in our login flow the night before a presentation; I flagged it right away, we agreed to demo with a pre-created test account instead of live signup, and I fixed the actual bug properly the next day without the deadline pressure.
Questions to ask the interviewer
- What would a typical week look like for an intern on this team?
- What does the code review process look like for intern pull requests?
- What's the split between working independently and pairing with a mentor?
- What separates an intern who gets a return offer from one who doesn't?
- What's the biggest technical challenge the team is working through right now?
- How is intern work usually scoped: a self-contained project, or smaller tickets alongside the team's regular work?
How to prepare
- Practice data structure problems out loud, not just silently. Interviewers grade your reasoning as much as your final answer.
- Know your Git basics cold: branching, rebasing versus merging, and resolving a conflict without panicking.
- Have 2 or 3 projects ready to walk through, including at least one obstacle you hit and how you solved it.
- Review Big O for common operations on arrays, hash maps, and linked lists.
- Prepare a short answer for "why this company" that references something specific, not just "great culture."
- Apply early. Rolling internship hiring means slots close as they fill, regardless of the posted deadline.
If you're aiming for a full-time offer after this, the cloud architect interview questions and data architect interview questions show what more senior technical interviews add on top of these basics. For a related entry-level technical track, see the uat tester interview questions, and the aws networking interview questions if you're leaning toward infrastructure work.
