Most software engineering freshers prepare for technical interviews by reading about data structures and doing LeetCode problems. Some of them prepare well. Most don't — not because they lack the knowledge, but because they prepare in the wrong format.
A technical interview is not a quiz. It's a conversation about how you think. The interviewer is watching how you approach a problem, not just whether you get the right answer. This guide covers how to actually prepare — and what to do differently from the standard advice.
What a technical interview for a fresher actually looks like
Most fresher technical rounds in India follow a similar structure:
- Project discussion (15–20 min): Questions about your resume projects — what you built, why you chose certain technologies, what went wrong, what you'd change
- DSA / problem solving (20–30 min): One or two coding problems, usually asked verbally or on a shared screen
- Fundamentals (10–15 min): Core CS concepts — OOP, databases, OS basics, networking basics
- Role-specific (optional): System design lite for product companies; SQL or Python for data roles
The ratio varies by company. Product companies (Flipkart, Google, Swiggy, startups) emphasise DSA. Service companies (TCS, Infosys, Wipro) emphasise fundamentals and project discussion. Know which type you're interviewing for before you prepare.
The part freshers underestimate: project discussion
Your project is often the deepest part of the technical round. Interviewers ask about it because it's the only area where you can't bluff — you either built it or you didn't. They will ask:
- Walk me through what your project does and how it works
- Why did you choose [this technology/framework/database]?
- What was the hardest part to build?
- What would you do differently if you had to rebuild it?
- How does [specific component] work internally?
Prepare for these before any DSA practice. Write out the architecture of your project on paper. Know every technology choice you made and why. Be honest if you used a tutorial — interviewers can tell, and honesty paired with understanding is far better than confident bluffing.
DSA: what to focus on as a fresher
You don't need to solve 500 LeetCode problems. You need to solve 60–80 problems well across the high-frequency topics:
| Topic | Priority | What to practise |
|---|---|---|
| Arrays & strings | High | Two pointers, sliding window, in-place manipulation |
| Linked lists | High | Reversal, cycle detection, merge two lists |
| Trees & BST | High | Traversals, height, LCA, validate BST |
| Hashing | High | Frequency count, two-sum patterns, anagram checks |
| Sorting & searching | Medium | Binary search variations, merge sort logic |
| Dynamic programming | Medium | Fibonacci variants, 0/1 knapsack, LCS — just the classics |
| Graphs | Low–Medium | BFS, DFS, cycle detection — basic only for most fresher rounds |
Solve each problem by hand first — without looking at hints. Then look at the solution, understand the pattern, and solve a similar one without help. The goal is pattern recognition, not memorisation.
How to practice: think out loud
The biggest mistake freshers make in technical interviews is going silent. They receive a problem, stare at it, and try to come up with the perfect solution before saying anything. Interviewers hate this — they can't give hints, they can't guide you, and they assume you're stuck.
Practice narrating your thought process:
- "My first instinct is to use a brute force O(n²) approach — let me think about whether there's a better way."
- "I'm thinking about using a hashmap here to bring this down to O(n)."
- "I notice the array is sorted — that suggests binary search might apply."
This is a skill that requires explicit practice. Do it while solving problems at home. Speak the thinking, don't just think it.
Core CS fundamentals to know cold
For most fresher technical rounds, you need a solid answer for:
- OOP: The four principles with a real-world example each. Be able to write a small code snippet demonstrating polymorphism or inheritance.
- Databases: Difference between SQL and NoSQL, what an index does, what a JOIN is, write a basic SELECT query with WHERE and GROUP BY.
- OS basics: Process vs thread, what a deadlock is and when it occurs, virtual memory in one sentence.
- Networking basics: What happens when you type a URL (DNS → TCP → HTTP), difference between TCP and UDP.
Don't read textbooks — read short explanations and then try to explain it to yourself out loud without notes. If you can't explain it simply, you don't know it well enough yet.
The day before: what to actually do
Don't practice new problems the day before. You're not going to learn something new in 24 hours, but you can undermine your confidence by hitting a problem you can't solve. Instead: review your project notes, re-read your core fundamentals, and sleep properly. Your brain consolidates memory during sleep — late-night cramming is actively counterproductive.
The technical interview is a conversation, not an exam
Ask clarifying questions before you start coding. "Can the array have negative numbers?" "Should I optimise for time or space?" This signals engineering maturity — the ability to gather requirements before building. It also gives you time to think.
If you get stuck, say so directly: "I'm not immediately seeing the optimal solution — let me think through the brute force first." This is honest, professional, and gives the interviewer something to work with.
Practice all of this in a realistic setting before the real interview. Sanviora's AI mock interview gives you voice-based technical questions with structured feedback — so you can build the habit of thinking out loud, not just solving on paper. Your first session is free.