Technical Interview Questions for Freshers: What Actually Gets Asked, from a Parul University Graduate’s Ninety-Minute Interview

Most interview preparation content is a list of questions with model answers, which is close to useless because the answers are not the point. Interviewers are checking whether you understand something, and a memorised definition is detectable within one follow-up question.

What follows is more useful: an account of a real technical interview, reconstructed from what was actually asked. Rapolu Venkatesh Satyanarayana, a B.Tech Computer Science and Engineering graduate of Parul University, expected to present his hackathon project to evaluators at Odoo. Fifteen minutes in, they closed the demonstration and started interviewing him. It ran for about ninety minutes and ended in a Software Developer offer.

The areas it covered are the areas fresher backend interviews cover generally, so it functions as a reasonable map.

The interview opened with roughly five practical database questions covering joins, aggregate functions and medium-complexity query writing. The emphasis was on reasoning through a problem rather than reciting syntax, which is typical.

Joins are something that connects data from two tables based on a related column; the join type determines whether non-matching joins are included or removed.

• INNER JOIN: returns only rows where the join condition is satisfied in both tables. Unmatched rows on either side are dropped.
• LEFT JOIN: returns all rows from the left table, with matching data from the right where it exists and nulls where it does not.
• RIGHT JOIN: the mirror image, keeping all rows from the right table.
• FULL OUTER JOIN: returns all rows from both tables, with nulls filling in wherever a match is absent.

The follow-up that catches candidates is being asked what joining a particular business question requires. That cannot be answered by memorisation, only by thinking about which rows the answer needs to include, and it is exactly what an interviewer is testing.

Aggregate functions collapse many rows into one value: COUNT, SUM, AVG, MIN and MAX. They are used with GROUP BY to produce one result per group rather than one for the whole table.

The distinction worth knowing cold is between WHERE and HAVING. WHERE filters individual rows before grouping happens; HAVING filters the groups after aggregation. Asking for departments whose average salary exceeds a threshold requires HAVING, because the average does not exist until the grouping has occurred. Candidates who confuse the two are revealing that they have memorised query shapes rather than understood the order of operations.

Every SQL interview asks about joins. The one that separates candidates asks which join the question needs, and why.

The interview moved to Java, object-orientated principles, backend architecture, software design and scalability.

Object-oriented questions almost always begin with the four principles, and the mistake is answering with definitions rather than purpose.

• Encapsulation: keeping an object’s internal state private and exposing controlled access. The purpose is that code outside the object cannot put it into an invalid state.
• Inheritance: deriving a class from another to reuse and extend behaviour. The purpose is avoiding duplication, and the useful follow-up is when composition is a better choice, which is often.
• Polymorphism: allowing different types to be treated through a common interface, so code can work with a category of things rather than one specific implementation.
• Abstraction: exposing what something does while hiding how it does it, so callers depend on behaviour rather than internals.

A candidate who answers with the purpose rather than the definition has demonstrably used these ideas rather than revised them, and the difference is obvious to an interviewer within seconds.

Because his project was containerised, evaluators asked why Docker was used, how containerisation helps deployment, and how scalable applications are managed in production.

The core answer is consistency. An application behaves differently across environments when the libraries, dependencies or configuration differ, and a container packages the application together with everything it needs so it runs identically wherever it is started. That eliminates an entire category of failure that has nothing to do with the code.

The related points worth being able to make: containers are lightweight because they share the host operating system kernel rather than running a full guest operating system, which means they start almost instantly and can be packed densely; and because a container is a defined artefact, it can be replicated to scale horizontally under load.

This section rewards candidates who used the tool and understood it over candidates who added it to a project because a tutorial did.

Version control questions covered branching strategies, collaborative development workflows, and the difference between git fetch and git pull.

This is asked constantly because it distinguishes people who use Git from people who understand it.

Fetch downloads commits, files and references from a remote repository into your local repository, updating your knowledge of what exists remotely. It changes nothing in your working directory and does not touch your current branch. Nothing you are working on can break.

Pull does the same fetch and then immediately integrates the retrieved changes into your current branch by merging or rebasing depending on configuration. It changes your working state, and it is where conflicts appear.

The practical implication, which is the answer an interviewer is hoping for: fetch when you want to see what has changed before deciding what to do about it; pull when you have decided you want those changes now. Fetch is safe by construction; pull is not.

Apart from questions related to technical background, questions related to teamwork, team bonding, and how teams organise work are also common. Teams develop features on separate branches so the main branch stays stable and releasable, merge changes through pull requests so they are reviewed before integration, and resolve conflicts when two people change the same code. The underlying subject is not Git commands but how multiple people work on one codebase without breaking it.

Both the technical and HR rounds asked what he would do on encountering an error, and this is a question about method.

His answer was a process: examine the console logs, identify the root cause rather than the symptom, implement a fix, test the solution thoroughly, and verify the application’s stability before deployment. The interviewer valued the logical structure over any textbook definition.

The reason this question appears so often is that debugging is what junior developers spend a great deal of their time doing, and the difference between a productive and unproductive one is whether they investigate systematically or change things until the symptom disappears. Any answer that moves from evidence to cause to fix to verification will land well.

The following morning brought an HR interview, which assessed judgement and temperament rather than knowledge. The questions he was asked are standard enough to prepare for.

• “Why do you want to join this company?” Tests whether you have researched what they actually build. A specific answer about their product beats a general answer about growth.
• “Why should we hire you?” Tests whether you can describe your own capability concretely and without either arrogance or apology.
• “What would you do if you found an error in your project?” The debugging question again, in a behavioural frame.
• “How would you respond if a colleague with similar experience were paid more?” Tests maturity and how you handle perceived unfairness. Interviewers are watching for resentment or entitlement.
• “How do you manage pressure?” Tests self-awareness. A specific example of a deadline handled is worth more than a claim to thrive under stress.

Venkatesh describes answering honestly and calmly despite several questions being unexpected, which is the actual skill being assessed. HR rounds test composure and judgement, and a candidate visibly constructing what they think the interviewer wants performs worse than one thinking aloud honestly.

When the unexpected questions are asked, but preparations are real, it becomes less hard to face the question. The circumstance here is worth noting: he had prepared to present a project, not to be interviewed, and was given no warning. He got through it because the preparation was real rather than rehearsed.

Three things follow from that. Build projects yourself, because every technical question in that interview was answerable from having actually built the thing under discussion. Understand the tools you use rather than adding them for appearance, since evaluators pressed him specifically on why Docker was in his stack. And when you reach the edge of your knowledge, say so.

“The interview came suddenly. I had not prepared for it, but I stayed calm and answered with whatever knowledge I had.” – Rapolu Venkatesh Satyanarayana

He encountered concepts he did not know and said as much rather than guessing. Interviewers can almost always tell, and honesty about the boundary of your knowledge reads as reliability, whereas a confident wrong answer raises a question about everything else you have said.

Also Read: Java Backend Developer Roadmap: What to Learn and in What Order, from a Parul University Graduate Who Used it