Top Computer Science Internship Technical Interview Questions
A focused, interview-relevant guide to the questions that show up most for CS/SWE internships—and how to answer them with strong reasoning, clean communication, and correct code.
What interviewers are actually testing with intern technical questions
Intern technical interviews rarely measure how many tricks you’ve memorized. They’re checking (1) fundamentals: can you reason about data structures, complexity, and basic systems concepts, (2) problem-solving process: can you clarify requirements, choose an approach, and handle edge cases, (3) coding hygiene: can you write correct code with good variable names, boundaries, and tests, and (4) communication: can you explain tradeoffs and recover when stuck. The best answers make your thinking auditable: state assumptions, outline a plan, implement, then validate with examples and complexity.
A live-interview framework for answering technical questions
Restate the problem and confirm inputs/outputs
Repeat the task in your own words and confirm details: constraints, input size, whether input can be null/empty, and what to return. This prevents solving the wrong problem and signals engineering discipline.
Ask 2–4 targeted clarifying questions
Focus on constraints that change the approach: time/space limits, sortedness, mutability, duplicates, streaming vs batch, and whether you can use extra memory. Don’t interrogate—pick questions that affect the algorithm.
Propose an approach and justify it with complexity
Name the data structure/technique (hash map, two pointers, BFS/DFS, heap, dynamic programming) and give Big-O time/space. Mention tradeoffs and why you’re choosing this over alternatives.
Work through a small example before coding
Run your approach on a 5–10 element example and call out edge cases (empty input, one element, duplicates, negative numbers, overflow). This often exposes logic bugs early.
Write code in clean, testable units
Use helper functions, descriptive names, and clear invariants (what each pointer/index means). Prefer iterative solutions when recursion depth might be an issue unless recursion is the cleanest explanation.
Validate with tests and failure modes
Manually test typical and edge cases. If time permits, add a quick check for tricky cases (off-by-one, integer overflow, cycles, disconnected graphs). If you find a bug, narrate the fix.
Close with complexity and potential improvements
Restate final Big-O, and optionally mention an optimization (space reduction, early exits, using a different structure) or how you’d productionize (input validation, logging, benchmarks).
High-impact mistakes interns make in technical interviews
- •Jumping into coding without clarifying constraints (input size, duplicates, sortedness, mutability).
- •Not stating time and space complexity, or stating it incorrectly.
- •Using a brute-force approach when a standard pattern applies (hashing, two pointers, sliding window, BFS/DFS).
- •Missing edge cases: empty arrays/strings, single element, duplicates, negative numbers, overflow, cycles in graphs, disconnected components.
- •Writing code with unclear invariants (what pointers represent, when loops terminate), leading to off-by-one bugs.
- •Overcomplicating with premature optimizations or obscure tricks instead of a correct, explainable baseline.
- •Failing to test with a concrete example after coding, especially boundary conditions.
- •Treating system/OOP questions as trivia instead of reasoning about tradeoffs (e.g., why choose interface vs inheritance).
- •Not asking what happens on invalid input or what to return when no solution exists.
- •Getting stuck and going silent instead of narrating hypotheses, narrowing the bug, and proposing next steps.
Example: a classic internship question and what a strong answer looks like
Weak Answer
Interviewer: “Given an array of integers and a target, return indices of two numbers that add to the target.” Candidate: “I’ll just use two loops.” (Starts coding immediately.) Writes O(n^2) solution, doesn’t discuss duplicates, returns wrong indices for input [3,3], target 6, and never mentions complexity or tests.
Strong Answer
Interviewer: “Given an array of integers and a target, return indices of two numbers that add to the target.” Candidate: “To confirm: return any one pair of indices, and each element can be used at most once? Are there negatives and duplicates?” After confirmation: “I’ll use a hash map from value to index. As I scan left to right, for each value x I check if target-x exists; if yes, return (storedIndex, i). This is O(n) time and O(n) space.” Walks through [2,7,11,15], target 9, then calls out edge case [3,3], target 6 and explains why storing the first 3 then matching on the second works. Codes cleanly, tests two cases, and ends with complexity and a note: if the array were sorted, two pointers would be O(1) extra space.
Why it works
The good answer makes decisions based on constraints, communicates tradeoffs, and proves correctness with examples. The candidate also reduces interviewer risk by testing edge cases and clearly stating complexity, which demonstrates readiness to build reliable software—not just produce code.
Turn these questions into repeatable interview performance
Reading lists of questions helps you recognize patterns, but interview outcomes improve when you practice under realistic constraints: timed prompts, structured solution write-ups, and targeted feedback on communication and correctness. On CrackTheOffer, you can drill the most common intern question types (arrays/strings, hashing, recursion, graphs, SQL, and debugging) with an interview-style flow—clarify, plan, code, test, and explain—so you build habits that transfer directly to real interviews.