Technical Interview Questions for Freshers: 16 Answers & Prep Plan

Last updated: September 2026

Quick Answer

A fresher technical interview tests four things: computer science fundamentals (object-oriented programming, databases, operating systems, networking), one or two data structures and algorithms problems, one project you can defend line by line, and whether you can explain any of it clearly to someone who already knows the answer. Interviewers are not checking whether you have industry experience. They are checking whether your fundamentals are real rather than memorised. Practise saying these answers out loud in OphyAI Interview Practice, because recognising a definition and explaining one are different skills.

#	Question	What it really tests
1	The four pillars of OOP, with examples	Whether you learned concepts or slogans
2	Overloading versus overriding	Precision about compile time and runtime
3	Abstraction versus encapsulation	Whether you can separate two things that sound alike
4	Process versus thread	Memory model understanding
5	What a deadlock is	Whether you know the four conditions
6	What happens when you type a URL	Breadth across the whole stack
7	TCP versus UDP	Trade-off reasoning, not definitions
8	The TCP three-way handshake	Detail retention under questioning
9	Normalisation and when to stop	Judgement, not recitation
10	Primary, unique and foreign keys	Precision on constraints
11	SQL join types	Practical database fluency
12	ACID properties	Whether you understand why they exist
13	Database indexes and their cost	Whether you think about trade-offs
14	Array versus linked list	Complexity reasoning applied to a choice
15	Time complexity of your own solution	Whether you can analyse, not just recall
16	Your final-year project	Ownership, honesty and depth

The Questions, With Sample Answers

1. “What are the four pillars of object-oriented programming?”

Why they ask it: It is the cheapest way to find out whether you learned OOP from a textbook summary or from writing code. Almost every candidate can list four words. Very few can give a real example of each.

Sample answer: “Encapsulation, abstraction, inheritance and polymorphism. Encapsulation means bundling data with the methods that operate on it and controlling access, so in my project the account balance was private and only changed through a deposit method that validated the amount. Abstraction means exposing what something does and hiding how, like an interface that declares a save method without saying whether it writes to a file or a database. Inheritance lets a class reuse another’s behaviour, which I used for a base user class with student and admin subclasses. Polymorphism means one call behaves differently depending on the actual object, so calling save on a list of storage objects runs whichever implementation each one has.”

What weak answers look like: Listing the four words and stopping. Confusing abstraction with encapsulation. Giving the classic animal or shape example when you have your own code to talk about instead.

2. “What is the difference between method overloading and method overriding?”

Why they ask it: It separates candidates who understand when things are decided, at compile time or at run time, from candidates who pattern-match on the similar words.

Sample answer: “Overloading is several methods in the same class with the same name but different parameter lists. The compiler picks which one to call based on the arguments, so it is resolved at compile time. Overriding is a subclass replacing a method it inherited, with the same signature. Which version runs is decided at run time based on the actual object type, which is what makes runtime polymorphism work. A quick way to keep them apart: overloading is about the same class doing several similar jobs, overriding is about a subclass doing an inherited job differently.”

What weak answers look like: Saying overloading is “same name, different work” without mentioning parameter lists or compile time. Claiming you can overload by changing only the return type.

3. “What is the difference between abstraction and encapsulation?”

Why they ask it: Both are about hiding something, so it exposes whether you understand what each one hides and why.

Sample answer: “Abstraction hides complexity: it shows the caller what an object can do and not how it does it. Encapsulation hides data: it keeps state private and forces changes through controlled methods. Abstraction is mostly a design decision, expressed with interfaces or abstract classes. Encapsulation is mostly an implementation decision, expressed with access modifiers and getters or setters. Concretely, an interface called PaymentProcessor with a pay method is abstraction. Making the balance field private so nobody can set it to a negative number from outside is encapsulation. They usually appear together, which is why they get confused.”

What weak answers look like: “Both are hiding” with no distinction. Describing getters and setters as abstraction.

4. “What is the difference between a process and a thread?”

Why they ask it: It is the entry point to everything else about concurrency, and the answer reveals whether you understand memory.

Sample answer: “A process is an independent program in execution with its own memory space. A thread is a unit of execution inside a process, and threads within one process share the same heap and code, though each has its own stack and registers. That sharing is why threads are cheaper to create and switch between than processes, and also why they are dangerous: two threads writing the same variable can corrupt it, so shared state needs synchronisation. Processes are isolated, so a crash in one does not usually take another down, but they have to communicate through mechanisms like pipes or sockets instead of just reading the same memory.”

What weak answers look like: “A thread is a lightweight process” and nothing more. Not mentioning shared memory, which is the whole point.

5. “What is a deadlock and what conditions cause it?”

Why they ask it: There is a precise answer, the four Coffman conditions, and knowing it signals you studied operating systems properly rather than skimming.

Sample answer: “A deadlock is a state where two or more processes are each waiting for a resource the other holds, so none of them can proceed. It needs four conditions to hold at the same time: mutual exclusion, meaning a resource cannot be shared; hold and wait, meaning a process holds one resource while waiting for another; no preemption, meaning a resource cannot be forcibly taken back; and circular wait, meaning there is a cycle of processes each waiting on the next. Because all four are required, you can prevent deadlock by breaking any one of them. The most practical in real code is breaking circular wait, usually by making every thread acquire locks in the same global order.”

What weak answers look like: Describing the situation but not naming the conditions. Confusing deadlock with starvation or with an infinite loop.

6. “What happens when you type a URL into a browser and press enter?”

Why they ask it: It is one question that samples the entire stack, so the interviewer can find the layer you are weakest at and go deeper there.

Sample answer: “The browser checks its cache, then the operating system resolves the domain through DNS, going to the resolver and up the hierarchy if it is not cached, and gets back an IP address. The browser opens a TCP connection to that address on port 443, and because it is HTTPS there is a TLS handshake where the server presents a certificate and both sides agree on keys. Then the browser sends an HTTP GET request with headers including the host and any cookies. The server responds, often through a load balancer and application server, with a status code and HTML. The browser parses the HTML, builds the DOM, requests the CSS, JavaScript and images it references, and renders progressively.”

What weak answers look like: Stopping at “it sends a request and gets a page”. Skipping DNS. Not knowing where TLS fits.

7. “What is the difference between TCP and UDP, and when would you use each?”

Why they ask it: The definitions are easy. The “when” is what distinguishes a candidate who has thought about systems.

Sample answer: “TCP is connection-oriented and reliable: it establishes a connection with a handshake, numbers segments, acknowledges them, retransmits what is lost, and delivers bytes to the application in order. UDP just sends datagrams with no connection, no acknowledgement and no ordering guarantee, so it is faster and has less overhead. You want TCP where correctness matters more than latency: web pages, file transfer, database connections, anything where a missing byte breaks the meaning. You want UDP where a late packet is worse than a lost one: live video and voice, online games, DNS queries. In a call, retransmitting audio from two seconds ago is useless, so dropping it is the better behaviour.”

What weak answers look like: “TCP is reliable, UDP is fast” with no examples. Claiming UDP is used because it is newer or better.

8. “Explain the TCP three-way handshake.”

Why they ask it: It is a specific, checkable detail. Candidates who have genuinely revised networking get it exactly right.

Sample answer: “The client sends a SYN segment with its initial sequence number. The server replies with a SYN-ACK: it acknowledges the client’s sequence number and sends its own. The client sends an ACK acknowledging the server’s sequence number, and the connection is established. Three messages, because both sides need to agree on sequence numbers and both need to know the other received theirs. Connection teardown is different: it usually takes four messages, a FIN and an ACK in each direction, because each side closes its half independently and one side can keep sending after the other has finished.”

What weak answers look like: Getting the order or the number of messages wrong. Saying the handshake is for authentication, which it is not.

9. “What is normalisation, and how far would you normalise?”

Why they ask it: Freshers usually recite normal forms. Interviewers want to hear judgement about when to stop.

Sample answer: “Normalisation is organising tables to reduce redundancy and avoid update anomalies. First normal form means atomic values and no repeating groups. Second normal form removes partial dependencies on part of a composite key. Third normal form removes transitive dependencies, so non-key columns depend only on the key. In practice most designs stop at third normal form, because further forms rarely change much and the extra joins cost read performance. If a table is read constantly and written rarely, like a reporting table, denormalising deliberately can be the right call, as long as you know which redundancy you are accepting and how you will keep it consistent.”

What weak answers look like: Reciting all normal forms up to fifth with no examples. Claiming normalisation always improves performance, which is untrue for reads.

10. “What is the difference between a primary key, a unique key and a foreign key?”

Why they ask it: Constraints are where careless answers show up quickly, especially around nulls.

Sample answer: “A primary key uniquely identifies a row, cannot be null, and there is only one per table. A unique key also enforces uniqueness but can usually allow a null, and a table can have several. A foreign key is a column that references the primary key of another table and enforces referential integrity, so you cannot insert a row pointing at a parent that does not exist, and you have to decide what happens on delete: cascade, restrict, or set null. In practice I would use a primary key for the identity of the row, a unique constraint for something like an email address that must not repeat, and foreign keys wherever the relationship must not be allowed to break.”

What weak answers look like: Saying a unique key cannot be null. Not knowing what happens to child rows on delete.

11. “Explain the different types of SQL joins.”

Why they ask it: Almost every technical role touches a database, and this is the fastest check of practical fluency.

Sample answer: “An inner join returns rows that match in both tables. A left outer join returns every row from the left table plus matches from the right, with nulls where there is no match, and a right outer join is the mirror image. A full outer join returns unmatched rows from both sides. A cross join produces the Cartesian product of every combination, which is occasionally useful and usually a bug. A self join is just a table joined to itself with an alias, which I used to match employees to their managers in the same table. The one to be careful with is a left join followed by a WHERE clause on the right table’s column, because that silently turns it back into an inner join.”

What weak answers look like: Listing join names with no notion of what nulls do. Not being able to say why a left join returned fewer rows than expected.

12. “What are the ACID properties of a transaction?”

Why they ask it: It is the vocabulary of every data-handling job, and it shows whether you understand why databases are built this way.

Sample answer: “Atomicity means a transaction happens completely or not at all, so a transfer that debits one account and credits another cannot leave money missing. Consistency means the database moves from one valid state to another, respecting constraints. Isolation means concurrent transactions do not interfere in ways that produce results impossible in a serial order, which is what isolation levels tune, trading strictness against throughput. Durability means once a transaction commits, it survives a crash, usually because the write-ahead log was flushed to disk before the commit was acknowledged. Isolation is the one with real choices in it: read committed and repeatable read behave differently under concurrent updates.”

What weak answers look like: Expanding the acronym with no meaning attached. Confusing consistency here with the consistency in the CAP theorem, which is a different thing.

13. “What is a database index, and what does it cost?”

Why they ask it: Freshers know indexes make queries faster. The follow-up about cost is the actual question.

Sample answer: “An index is a separate data structure, usually a B-tree, that lets the database find rows matching a column value without scanning the whole table, turning a linear scan into a logarithmic lookup. The cost is on writes and storage: every insert, update or delete has to maintain every affected index, so a table with six indexes writes far more slowly than the same table with one. Indexes also only help if the query can use them, so a function applied to the indexed column or a leading wildcard in a LIKE pattern will usually cause the planner to ignore the index. My rule is to index the columns I filter and join on, and to check the query plan rather than assume.”

What weak answers look like: “Indexes make queries faster” and nothing about write cost. Not knowing what structure an index uses.

14. “When would you use an array and when a linked list?”

Why they ask it: It converts complexity theory into a decision, which is what the job actually requires.

Sample answer: “An array gives constant time access by index because elements are contiguous in memory, and that contiguity also makes it cache-friendly, but inserting or deleting in the middle is linear because everything after has to shift. A linked list makes insertion or deletion constant time once you already hold the node, but access by position is linear and every node costs an extra pointer plus poor locality. So I use an array or dynamic array by default, especially when I read by index or iterate a lot, and a linked list when I am constantly inserting and removing at known positions, for example an LRU cache where I move nodes to the front. In practice, arrays win more often than the complexity table suggests because of cache behaviour.”

What weak answers look like: Quoting the complexity table with no mention of memory locality. Recommending linked lists for general use because “insertion is O(1)“.

15. “What is the time complexity of your solution?”

Why they ask it: Every coding round ends here. It tests whether you can analyse code you just wrote rather than recall a memorised answer.

Sample answer: “The outer loop runs n times and the inner loop runs over the remaining elements, so it is roughly n squared over two comparisons, which is O(n squared). Space is O(1) because I am sorting in place and only using a few variables. If I used a hash set to track what I have seen, it would drop to O(n) time and O(n) space, which is the trade-off I would take if memory is not tight. I would also mention that the worst case and the average case differ here: with early termination, an already-sorted input runs in linear time.”

What weak answers look like: Guessing. Saying O(n) for a nested loop. Ignoring space complexity until asked.

16. “Walk me through your final-year project.”

Why they ask it: For a fresher this is the closest thing to work experience, and it is the round where interviewers find out whether you built the thing or watched someone build it.

Sample answer: “It was a bus-tracking application for our campus. The problem was that students waited without knowing where the bus was. I built the backend: a Node service that ingested location pings from a driver app every fifteen seconds, stored them in PostgreSQL, and served the latest position over a REST endpoint the frontend polled. The main decision I got wrong was polling every second from every client, which hammered the database, so I added a cache layer and increased the interval, which cut database load substantially. If I rebuilt it I would use WebSockets and push instead of poll. My teammate built the mobile client; I did the API and the deployment.”

What weak answers look like: Describing what the team built without saying what you did. No design decision you can defend and no mistake you can name. Claiming a project you cannot answer follow-up questions about, which interviewers detect within two questions.

How to Practice These

Reading these answers will not get you through the round. The failure mode for freshers is not knowing too little, it is knowing enough and explaining it badly under pressure.

Run mock rounds where something asks the follow-up question rather than accepting your first definition. OphyAI Interview Practice runs voice or text mock interviews in technical and behavioural formats, asks follow-ups, and returns a transcript with per-answer feedback so you can see exactly where your explanation lost the thread. For the coding half, OphyAI Coding Interview takes one problem end to end, from approach to code, which is the habit that makes stating complexity feel automatic.

For live rounds, Interview Copilot provides a real-time transcript and structure on Zoom, Microsoft Teams and Google Meet in 35 languages, which helps most when the difficulty is catching a fast-spoken question rather than knowing the answer. Employer policies on outside tools differ and some prohibit them outright, so ask your recruiter and keep it to mock rounds where the answer is no. Start practicing →

Frequently Asked Questions

What technical questions are asked to freshers?

Most fresher technical rounds sample four areas: object-oriented programming concepts with examples from your own code, database fundamentals such as normalisation, keys, joins and ACID properties, operating systems and networking basics such as process versus thread, deadlock, TCP versus UDP and DNS resolution, and one or two data structures and algorithms problems at easy to medium difficulty. Almost every round also includes a deep pass over one project on your resume.

How should a fresher prepare for a technical interview in one week?

Split it. Two days rebuilding fundamentals as spoken answers rather than notes, covering OOP, DBMS, operating systems and networking. Three days on coding, aiming for working solutions to medium problems inside twenty minutes rather than perfect solutions with no time limit. Two days on your project: write a one-page brief covering the problem, your specific contribution, one decision you would change, and be ready for follow-ups on every line.

Do freshers get asked data structures and algorithms questions?

Yes, in almost every technical hiring process, though the difficulty is usually easy to medium rather than the hard problems senior candidates see. Expect arrays, strings, hash maps, linked lists, stacks and queues, basic trees and simple sorting, plus a question about the time and space complexity of whatever you wrote. Service-based employers weight fundamentals more heavily; product companies weight the coding problem more heavily.

What if I do not know the answer to a technical question?

Say so, then show your reasoning. “I have not used that directly, but based on how X works I would expect it to behave like this” is a far better answer than silence or a confident guess. Interviewers are testing how you behave at the edge of your knowledge, because that is what most of the job is. Bluffing is the one response that reliably fails, since the follow-up question exposes it immediately.

How important is the project round for freshers?

It is often the deciding round, because it is the only part of the interview where you talk about something you built rather than something you studied. Interviewers use it to check ownership: what you personally did, what you chose and why, what went wrong, and what you would do differently. A modest project you can defend in depth beats an ambitious one you cannot explain.

Are technical interview questions for freshers different from experienced-hire questions?

Yes, in emphasis rather than topic. Fresher rounds weight computer science fundamentals and coding heavily because there is little work history to examine. Experienced rounds weight system design, past architectural decisions and the trade-offs you made in production. If you are a fresher, the fastest way to look stronger than your years is to be precise about the decisions in your one real project.

Which companies ask the most fundamentals questions?

Large service-based and enterprise employers tend to test computer science fundamentals hardest, often through a multiple-choice block in the online assessment. Product companies lean more towards a coding problem with follow-ups. Compare the loops in our company guides below: the difference between an assessment full of operating systems and networking questions and a single medium coding problem is significant, and it should change how you allocate your preparation week.

Related Guides

• Infosys interview guide
• TCS interview guide
• Wipro interview guide
• Cognizant interview guide
• Capgemini interview guide
• IBM interview guide
• Cisco interview guide
• Technical interview preparation for software engineers
• Coding interview examples with solutions

Sources and verification notes

Sources checked September 2026. Direct first-party fetches were blocked by this environment’s network policy, so third-party material below was consulted through search summaries. The sample answers are our own; the question selection reflects what fresher and campus-placement rounds are reported to ask.

• GeeksforGeeks, Cisco recruitment process: candidate write-ups showing fundamentals and DSA tested together in fresher assessments. Third-party.
• InterviewBit, OOPs interview questions: third-party, the object-oriented topics most commonly asked of entry-level candidates.
• FacePrep, Infosys technical interview questions 2026: third-party, reported OOP, DBMS, operating systems and DSA coverage in Indian fresher technical rounds.
• StudyBench, computer science core topics for placement interviews: third-party, the DBMS, operating systems, networking and OOP clusters that recur in campus placements.
• Glassdoor, Cisco interview questions: candidate-reported fresher and early-career question examples. Self-reported.