I’ve run hiring loops for software engineering roles across two companies before Kalvium. At Google and at HackerRank. And now I see the fresher cohort that comes out of Indian B.Tech CSE every year from the other side of the table. The pattern’s consistent enough to write down.
Most candidates arrive having prepared for the interview they expected. Not the interview that happens.
Here’s what CSE freshers say they know: C++, Python, arrays, linked lists, trees, graphs, sorting algorithms, OS basics, database queries. The branch name implies all of it.
Here’s what the hiring loop tests for: six things the branch name doesn’t mention. Candidates who’ve spent four years preparing for the exam the college gives them, not the one the market runs, arrive with a real gap.
These are the six.
Skill 1: Code that reads, not just code that runs
The bar is writing code that a stranger can understand next week without asking you questions. Variable names that mean something. Functions that do one thing each. A structure that’s obvious from the outside.
Most freshers can write code that compiles and passes test cases. Most haven’t spent time writing code that another engineer can maintain. In an interview, this shows up immediately when I read a candidate’s solution: the logic is right, but it’s written as if no one else will ever touch it.
How to actually get there. Build one project as if you’re handing it to a teammate on Friday and won’t be there on Monday to explain it. README, comments where the logic is non-obvious, function names that tell you what they return. Then put it down for two weeks and read it again. Notice where you’re confused by your own choices.
What no course teaches. Every curriculum assignment is personal. You write it, you submit it, the grade comes back. You never have to hand it to someone who’ll push back on your variable name. Real engineering is handing code to someone who will push back, every single day. The discipline of writing for a reader, not a grader, comes from deliberately choosing it.
Skill 2: Data structure trade-off reasoning, not data structure recall
The bar isn’t reciting the properties of a B-tree. It’s explaining, in a specific scenario, why a hash table serves you better than a balanced BST and what you give up for that choice. Thirty seconds, specific, no hedging.
The interview finds the limit fast. Most candidates can describe a data structure. Fewer can tell you when not to use the one they just described. The question “what’s a heap?” gets a good answer from most freshers. The question “you’ve got a stream of integers, need the median at every step: what are you reaching for?” is harder. That one separates the ones who know from the ones who’ve actually built with it.
How to actually get there. After studying each data structure, implement one real problem that uses it. Then implement the same problem with the wrong data structure and watch it break or slow down. That comparison is the intuition. Abstract properties don’t become reasoning until you’ve seen them fail in context.
What no course teaches. The “when not to” question. Every curriculum teaches you to apply the tool of the chapter. No curriculum has a chapter called “when the obvious tool is the wrong one.” The interview does.
Skill 3: System design intuition, at a fresher level
The bar is sketching how a simple product works at a systems level. Which services talk to each other. Where the database sits. What happens when one component fails. Basic, not distributed-systems depth. Just the intuition that software is components talking to each other, not a single block of code.
This isn’t the senior-engineer system design interview. For freshers, the test is simpler. Do you understand that the URL shortener you built connects to a datastore that’s separate from the logic that reads it? Do you see that there’s a choice about what happens when the writer is slow? That level of clarity separates candidates who’ve thought about architecture from those who’ve written code inside a single file.
How to actually get there. Pick three apps you use daily. Draw on paper how you think each works at a systems level. Not the product UI: the back end. Where does the data live? What happens when you send a message and the server’s busy? What does “login” actually do across multiple services? The exercise doesn’t need to be correct. It needs to build the habit of asking.
What no course teaches. The course teaches you what a relational database is. It doesn’t teach you why a ride-sharing app has a separate service for pricing, a separate service for matching, and a separate service for notifications, or why that decomposition matters when one goes down. That systems thinking is osmotic in a real engineering environment. If you haven’t been in one, it requires deliberate effort to build.
Skill 4: Git and collaborative workflow
The bar is committing with messages that tell a reader what changed and why. Creating a branch for a feature. Making a pull request that describes what it does. Resolving a merge conflict without panic.
I’ve interviewed freshers who had strong coding ability and had never made a pull request. Every commit message in their project history was “fix” or “update”. Their branching history was one main branch. That’s not what professional development looks like, and interviewers know it immediately from a GitHub link.
How to actually get there. Every personal project goes on GitHub from this point. Every meaningful change gets a commit message a stranger would understand: “add input validation for email field” rather than “fix”. Every feature gets a branch. For at least one project, find a classmate and practise the pull request and review loop. The exchange of code review is the skill.
What no course teaches. Professional development is collaborative. Most college project work is solo or loosely paired, with Git used only at submission. The practice of writing a commit message for a future reader, creating a branch per feature, and responding to code review without defensiveness is a workplace behaviour. It requires a workplace context to learn. The closest approximation in college is real collaboration with real reviewers.
Skill 5: Debugging code you didn’t write
The bar is being handed a codebase you’ve never seen, given a bug report, and finding the problem in under fifteen minutes. No panic. No rewriting from scratch. Systematic investigation, loud hypothesis, go.
This is one of the most common interview exercises at product companies for fresher hiring. It’s also one of the most commonly failed, because almost no candidate has ever practised it. Everyone practises writing code from scratch. Almost no one practises reading broken code they didn’t write and finding the fault.
How to actually get there. Use the debugger, not print statements. Find an open-source project on GitHub in a language you know. Find an issue labelled “bug”. Try to reproduce it locally, then trace through the code to find the cause. The first three times, it’ll take three hours and feel impossible. By the tenth time, the pattern of “form a hypothesis, find where to test it, test it, update the hypothesis” is automatic.
What no course teaches. The temperament. Debugging unfamiliar code is stressful. The failure mode I see in interviews isn’t wrong technique. It’s: freeze, blame the framework, ask for a hint within two minutes. That pattern comes from never having been in the situation before. The only fix is exposure.
Skill 6: Explaining your own project to a stranger
The bar is walking me through a project you built, in ten minutes, with no slides. What problem it solves. What you decided and why. What surprised you. What broke and how you fixed it. What you’d do differently. In plain language I can follow even if I haven’t read your code.
This is the most underrated skill on the list and one of the most diagnostic in interviews. Engineers who can’t explain their own work can’t get product managers, senior engineers, or hiring panels to trust them. The interview is a test of this in real time.
How to actually get there. After each project, write a one-page summary in plain language. Read it aloud. Notice where you resort to jargon or skip over why you made a choice. Rewrite that part. Practise the verbal version. The first ten times you explain a project, the explanation will be bad. By the twentieth, it’s a five-minute conversation that feels natural.
What no course teaches. The right level of detail. Most engineers either over-explain (every function call, every loop) or under-explain (hides every decision behind “it was the standard approach”). The middle path is enough depth that I can see you made real decisions, not so much that I’ve lost the thread. That calibration requires deliberate practice and almost nobody explicitly trains it in college.
What a complete fresher project looks like
If you’re building the one project that clears every part of this bar, here’s the shape it needs.
It solves a real problem, even a small one. Not “I reproduced a tutorial.” A real problem you ran into, or someone you know ran into. Small is fine. Simple is fine. The problem needs to be real enough that you made your own decisions about how to solve it.
It has readable code. You can hand the GitHub link to a stranger and they can follow what the code does without you in the room.
It has a deployment. Something hosted somewhere, reachable from outside, running on real data, not a local demo. Even a free-tier cloud deployment counts.
It has a story. You can explain in ten minutes what the project does, what you decided, and what you’d do differently. That story is what I’m asking for in an interview, because the story is what tells me how you think.
That project, built once seriously, is worth more in a hiring loop than two hundred completed algorithm exercises.
How programmes close this gap, and which ones don’t
Most B.Tech CSE programmes build knowledge. Four years of lectures, exams, and syllabus coverage. The six skills above aren’t on the syllabus anywhere. Debugging unfamiliar code isn’t a course. Collaborative Git workflow isn’t a module. Explaining your work isn’t a semester-end assessment.
The programmes that close this gap do it through structure, not lectures. Shipping working code from Year 1, not Year 4. Building with real tools in collaborative settings. Getting feedback on your code from someone who isn’t awarding you marks.
Kalvium’s B.Tech CSE is built around this premise. Students ship working software in Semester 1. The DOJO system runs daily coding practice six days a week, which builds the debugging temperament by making hard problems routine. From Semester 3, work with industry partners gives students experience of code review and collaborative workflow in settings where the feedback is real. The 2026 batch was 82.40% placed as of March 2026, with a median salary of 16.5 LPA, and companies like Morgan Stanley, PhonePe, Thoughtworks, and Yellow.ai in the recruiter list.
That’s not a coincidence. It’s what happens when the programme is designed around what the interview actually tests, not around what the syllabus requires.
The pattern
The CSE graduates who land strong roles consistently have one thing I’m looking for. Not the highest CGPA. Not the longest list of technologies on the resume. Not the most hackathon certificates.
One project, built end to end, that they can walk me through for twenty minutes starting with the problem and ending with what broke.
The branch name implies the skills. Most college programmes don’t teach the six things above explicitly. The students who go in knowing that spend the last two years of their degree building the proof. The students who don’t spend those years optimising their grade and arrive at the interview without the one thing the interview is looking for.
For the full picture of what branch choice signals to hiring managers, the guide to what engineering managers think about branch choice covers the detail. It includes the CSE versus ECE question and what AI/ML specialisations actually indicate to interviewers.
For families deciding which B.Tech programme to invest in, the framework for choosing a CSE programme applies the same filter. Does this programme build the six skills above, or does it optimise for exam performance?
For students evaluating Kalvium specifically, the complete guide to what the programme involves covers how it’s structured and what the nine partner universities for Admission Year 2026-27 look like. It also covers the selection process.
Anil is a co-founder of Kalvium and previously led engineering teams at Google and HackerRank. He runs hiring loops regularly and writes about what the Indian tech market actually rewards, from the interview side of the table. Read more from Anil or browse the Careers category.