Technical Interview Guide.
What to study, in what order, and how to practice so you're ready when it counts.
The engineers who interview well are not the ones who are smarter — they're the ones who have had more reps. Start practicing early. Every practice session makes the next one easier. By the time your junior year interviews come, these should feel automatic.
What SWE Interviews Actually Test
A standard SWE interview has two components: a technical coding screen and a behavioral interview. Some companies include a systems design round.
Technical coding screen
1–2 LeetCode-style problems solved in 45–60 minutes. You explain your thinking out loud. The interviewer evaluates both correctness and communication.
Behavioral interview
Structured questions about past experience using the STAR format. Every company does this.
Systems design
Design a scalable system (e.g., design Twitter, design a URL shortener). More common at junior+ levels. Google and Meta include this even for new grads.
Data Structures & Algorithms
These are the categories that appear most often in technical interviews. Study them in roughly this order — essentials first, then high priority, then medium. Aim for 150+ medium problems by the start of junior year recruiting — this is the minimum floor, not a stretch goal.
Arrays & Strings
The most common interview category. Two pointers, sliding window, prefix sums. Know these cold.
Hash Maps & Hash Sets
Frequency counting, deduplication, lookup in O(1). Used in almost every medium-difficulty problem.
Linked Lists
Traversal, reversal, cycle detection, merge. Know the slow/fast pointer technique.
Stacks & Queues
Monotonic stack, BFS queue, parenthesis matching. Common in medium problems.
Trees & Binary Search Trees
DFS, BFS, in/pre/post order traversal, LCA, path problems. Trees appear constantly.
Graphs
DFS, BFS, topological sort, union-find. Know how to detect cycles and find shortest paths.
Binary Search
Not just searching sorted arrays — binary search on the answer. Know both variants.
Dynamic Programming
Memoization vs. tabulation. Knapsack, LCS, LIS, grid DP. Takes the most practice — start early.
Recursion & Backtracking
Permutations, combinations, subsets, N-Queens. Think in terms of decision trees.
Heaps / Priority Queues
Top K elements, merge K sorted lists, median of a stream. Know min-heap and max-heap behavior.
Tries
Prefix search, word search. Less common but appears at top companies for search-related roles.
Intervals
Merge intervals, meeting rooms, non-overlapping. Sort then scan.
How to Practice
LeetCode
The standard. Start with easy problems to build confidence, move to medium, and work through common patterns — not random problems. Focus on recognizing problem types, not memorizing solutions.
Study by pattern: sliding window, two pointers, BFS/DFS, dynamic programming, binary search on the answer. When you see a new problem, ask: what pattern does this look like? That's the skill the interview tests.
Mock Interviews
Solo LeetCode is not enough. Practice explaining your thinking out loud while solving under time pressure. Use Pramp (free peer mock interviews), interviewing.io (practice with real engineers), or sit down with a friend and take turns. Record yourself at least once — watching yourself is uncomfortable and useful.
The Interview Itself
Clarify the problem.
Ask about edge cases, input size, and constraints before writing a single line. The interviewer wants to see you think before you code.
- →'Can the input be empty?' 'Are there duplicates?' 'What's the expected input size?'
- →Restating the problem in your own words is a strong signal
Talk through your approach first.
State your plan before you start coding. The interviewer is evaluating how you think — not just what you produce.
- →Mention time and space complexity of your approach
- →If you see a brute-force solution, name it, then discuss how to improve it
Start with a working solution.
A working O(n²) solution is better than an incomplete O(n) one. Get something correct on the board, then optimize.
- →Don't freeze trying to find the perfect solution immediately
- →Correctness first — optimization second
Test your code manually.
Walk through your code with a sample input before you say you're done. Catch your own bugs.
- →Use a simple example, then test an edge case (empty input, single element, duplicates)
Talk when you're stuck.
If you get stuck, say what you know. 'I know I need to track something here — let me think about what data structure makes sense.' Silence is worse than thinking out loud.
- →Ask for a hint if you're truly stuck — it's better than sitting in silence
Systems Design
For juniors and new grads, systems design rounds test your ability to think about scale and trade-offs — not your ability to design production infrastructure. The questions are open-ended: design a URL shortener, design a messaging app, design a ride-sharing service.
Clarify requirements.
Functional (what does it do?) and non-functional (how many users? what's the latency requirement?).
Estimate scale.
How many requests per second? How much data storage? Back-of-the-envelope math matters.
High-level design.
Draw the major components — clients, load balancers, servers, databases, caches, CDNs.
Deep dive into one component.
The interviewer will push you to go deeper somewhere. Know databases (SQL vs NoSQL trade-offs), caching (Redis), and message queues (Kafka).
Discuss trade-offs.
Every design decision has trade-offs. Name them. Showing you understand trade-offs is the point.
Resources: System Design Interview by Alex Xu, Grokking the System Design Interview (Educative), and YouTube (ByteByteGo is excellent).
Behavioral Interview
Every company does behavioral interviews. Prepare with the same rigor as the technical screen. Use STAR: Situation, Task, Action, Result. Be specific — numbers and outcomes matter.
Interview question
“Tell me about yourself.”
Structure: where you're from, what you're studying, what you've built or worked on, why you're interested in this company. Keep it under 90 seconds. Practice until it sounds natural, not rehearsed.
Interview question
“Tell me about a challenging project you worked on.”
Use STAR: Situation, Task, Action, Result. Be specific about what you built, what went wrong, and what you did about it. Numbers help — impact matters more than lines of code.
Interview question
“Tell me about a time you had to learn something quickly.”
Tech changes fast. This tests intellectual curiosity and self-direction. Pick something real — a language you learned for a project, a framework you picked up mid-internship.
Interview question
“How do you handle disagreement with a teammate?”
Show that you can advocate for your position with data and reasoning, listen genuinely, and move forward once a decision is made. No stories where you were just right and they were wrong.
Interview question
“Where do you see yourself in 5 years?”
Be directional. Talk about the type of engineer you want to be, the problems you want to work on, the skills you want to build.
Interview question
“Why this company?”
This must be specific. Research the team, the products, the engineering culture. Generic answers don't land. Name a product you use, a team you want to join, a technical challenge the company is working on.
When to Start Preparing
Freshman year
Start LeetCode easy problems. Get comfortable with arrays, strings, and hash maps.
Sophomore year
Move to medium problems. Do 2–3 problems per week minimum. Start doing mock interviews with friends.
Junior year (before recruiting)
150+ problems done, patterns internalized, behavioral stories prepared. By September of junior year you should be interviewing-ready.
The people who interview well are not smarter than you. They started earlier and practiced more. That's it. Start now.