Technical Interview Preparation for Freshers: Complete Campus Placement Guide

By FreePare Team · Tue Jun 23 2026 · 37 min read

The technical interview is one of the most important rounds in campus placements.

This is where the interviewer checks whether you actually understand what you have written in your resume. They may ask questions from your programming language, projects, database, core subjects, coding logic, internship work, or technical skills.

For freshers, the technical interview is not about knowing everything. It is about being clear with your basics and honest about your experience.

This guide will help you prepare for technical interviews in a structured way. Every core subject below comes with the questions that are actually asked and a model answer you could say out loud in the room, along with the SQL, the schema and the scheduling arithmetic behind them. Read an answer, close the page, and say it in your own words before you move on.

What is a Technical Interview?

A technical interview checks your subject knowledge, problem-solving ability, and practical understanding.

For freshers, questions usually come from:

1. Programming language
2. OOPs concepts
3. DBMS
4. SQL
5. Data structures
6. Operating systems
7. Computer networks
8. Projects
9. Internship or training
10. Resume skills
11. Coding logic

The difficulty level depends on the company and role.

The shape of the conversation is fairly predictable. An interviewer picks a line from your resume, asks a definition question to check that the word means something to you, then asks a "why" or "what happens if" question to check that you did not simply memorise the definition. A candidate who can define encapsulation but cannot say why a field is made private is exactly the candidate that second question is designed to find. Every model answer below is written to survive the follow-up.

Why Technical Interviews Matter

Aptitude and coding rounds may help you reach the interview, but the technical interview helps the company decide whether you are ready for the role.

A good technical interview shows that you:

• Understand your basics
• Can explain your projects
• Can solve problems logically
• Are honest about your skills
• Can learn and improve
• Have role-relevant knowledge

You do not need to answer every question perfectly. But you should be able to explain what you know clearly.

Start with Your Resume

Before preparing random interview questions, read your own resume carefully.

Ask yourself:

1. Can I explain every skill?
2. Can I explain every project?
3. Can I answer questions on every technology mentioned?
4. Can I justify my certifications?
5. Can I explain my internship work?

If you cannot explain something, either learn it properly or remove it from your resume.

Your resume controls many interview questions.

A useful exercise is to sit with your resume and write down the question each line invites. The table below shows how directly a resume line converts into an interview question.

If a line cannot survive its own question, rewrite the line. If you are still assembling the document itself, the structure and phrasing rules are in Resume Guide for Freshers: How to Make a Job-Ready Resume for Campus Placements.

Programming Language Preparation

Choose the language you know best and revise it deeply.

If you mention Java, prepare:

• Data types
• Loops
• Functions
• Arrays
• Strings
• Classes and objects
• OOPs concepts
• Exception handling
• Collections basics
• Access modifiers

If you mention Python, prepare:

• Data types
• Lists
• Tuples
• Dictionaries
• Functions
• Loops
• String operations
• File handling basics
• OOPs basics

If you mention C++, prepare:

• Pointers basics
• Arrays
• Strings
• Functions
• OOPs
• STL basics
• Constructors
• Inheritance

Do not mention a language if you cannot answer basic questions from it.

Here is the question from each language that freshers are asked most often, with the answer that gets full marks.

Q1. In Java, what is the difference between == and .equals() for Strings?

For objects, == compares references, meaning it asks whether two variables point to the same object in memory. .equals() compares content, and the String class overrides it to compare characters. String literals are stored in the string pool and reused, so two identical literals are the same object and == happens to return true. But a String created with new is a fresh object, so == returns false even when the characters are identical. That is why strings are always compared with .equals().

String a = "hello";
String b = "hello";
String c = new String("hello");

System.out.println(a == b);        // true  - same pooled literal
System.out.println(a == c);        // false - c is a separate object
System.out.println(a.equals(c));   // true  - same characters

Q2. In Python, what is the difference between a list and a tuple?

A list is mutable, so I can append, remove or reassign elements after creating it. A tuple is immutable, so once created its elements cannot be replaced. Because a tuple is immutable it is also hashable, provided everything inside it is hashable, which means a tuple can be used as a dictionary key or placed in a set while a list cannot. I use a tuple when the group of values is a fixed record, such as a coordinate pair, and a list when the collection is going to grow or change.

The natural follow-up is why immutability matters here. Say it in one line: a mutable object could change after it was used as a key, and the dictionary would then look for it in the wrong bucket, so Python refuses to allow it in the first place.

Q3. In C++, what is the difference between a pointer and a reference?

A pointer is a variable that stores an address. It can be null, it can be reassigned to point somewhere else, and it has to be dereferenced to reach the value. A reference is an alias for an existing variable. It must be initialised when it is declared, it cannot be made to refer to a different variable afterwards, and it is used with the same syntax as the original variable. I pass large objects by const reference to avoid copying them, and I use a pointer when the value is genuinely optional or when I need to change what I am pointing at.

OOPs Concepts for Technical Interviews

OOPs is one of the most common technical interview topics.

Prepare:

• Class
• Object
• Inheritance
• Polymorphism
• Encapsulation
• Abstraction
• Constructor
• Method overloading
• Method overriding
• Interface
• Abstract class

Be ready to explain concepts with examples.

Example:

Encapsulation means wrapping data and methods together inside a class and controlling access using access modifiers.

Do not only memorize definitions. Try to explain in simple words.

These five questions cover most of what freshers are actually asked about OOP.

Q4. What is the difference between a class and an object?

A class is a blueprint. It declares what fields an object will have and what methods it can perform, but it does not by itself hold any instance data. An object is an instance created from that blueprint at runtime, and each object gets its own copy of the instance fields. If Student is the class, then two students created from it are two objects, each with its own roll number and name, while both share the same method definitions.

Q5. What is encapsulation, and why do we make fields private?

Encapsulation means keeping data and the methods that operate on that data inside one unit, and restricting direct access to the data from outside. In practice I make the fields private and expose behaviour through methods. The reason is that a private field can only be changed through code I control, so the rules can be enforced in one place. If the balance field of an account were public, any code could set it to a negative number. When it is private and changed only through a deposit method, the validation lives in exactly one place.

public class BankAccount {
    private double balance;          // no outside code can touch this directly

    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        balance += amount;
    }

    public double getBalance() {
        return balance;
    }
}

Q6. What is the difference between abstraction and encapsulation?

Abstraction is about what is exposed. It means showing only the essential behaviour and hiding how it is done, so somebody using my class sees a send() method and not the connection handling inside it. Encapsulation is about how the data is protected. It is the mechanism of bundling the data with its methods and restricting direct access to it. Abstraction is a design decision about the interface; encapsulation is the implementation technique that keeps the internals safe.

Q7. What is the difference between method overloading and method overriding?

Overloading means two or more methods in the same class share a name but differ in their parameter list, by number of parameters, by type, or by order. The compiler decides which one to call from the arguments, so it is resolved at compile time. A different return type alone is not enough to overload a method. Overriding means a subclass replaces an inherited method with its own version using the same signature. The decision happens at runtime based on the actual object rather than the reference type, which is what gives us runtime polymorphism. In Java, static, final and private methods cannot be overridden.

class Animal {
    void speak() { System.out.println("Some sound"); }
}

class Dog extends Animal {
    @Override
    void speak() { System.out.println("Bark"); }   // overriding
}

class Printer {
    void print(int x) { }                          // overloading:
    void print(String s) { }                       // same name,
    void print(int x, int y) { }                   // different parameter lists
}

Animal a = new Dog();
a.speak();     // prints "Bark" - chosen at runtime from the real object

Q8. When would you use an abstract class and when an interface?

I use an abstract class when several related classes share both state and partly implemented behaviour, because an abstract class can hold instance fields and a constructor. I use an interface when I only want to declare a capability that unrelated classes can promise to provide. The practical constraint in Java is that a class can extend only one class but implement many interfaces, so a capability that has to be mixed into different hierarchies must be an interface. Since Java 8 an interface can also carry default and static methods, so the gap is narrower than it used to be, but an interface still cannot hold instance state.

One nuance that impresses interviewers: only instance methods are dispatched dynamically in Java. Fields and static methods are resolved from the reference type at compile time, so a subclass that declares a field with the same name hides the parent field rather than overriding it.

DBMS and SQL Preparation

DBMS is another common technical interview area.

Important DBMS topics:

• Database
• Table
• Primary key
• Foreign key
• Candidate key
• Normalization
• Joins
• Indexing
• Transactions
• ACID properties
• SQL queries

Important SQL statements to be fluent in: SELECT, WHERE, GROUP BY, ORDER BY, JOIN, COUNT, MAX, MIN, AVG, INSERT, UPDATE and DELETE.

Freshers should practice writing basic SQL queries.

Every question in this section uses the same two small tables, so you can follow the rows all the way through.

-- students
student_id | name
-----------+--------
1          | Aditi
2          | Rahul
3          | Meera
4          | Sameer

-- marks
mark_id | student_id | subject | score
--------+------------+---------+------
101     | 1          | DBMS    | 78
102     | 1          | OS      | 65
103     | 2          | DBMS    | 91
104     | 4          | DBMS    | 55

Q9. What is the difference between a primary key, a candidate key, a unique key and a foreign key?

A candidate key is any minimal set of columns that uniquely identifies a row, and a table can have several of them. One candidate key is chosen as the primary key, which must be unique and cannot be null, and there is exactly one per table. The remaining candidate keys are usually enforced with unique constraints, which also guarantee uniqueness but do allow nulls, because the SQL standard treats two nulls as distinct rather than equal. A foreign key is a column in one table that references the primary or unique key of another, and the database rejects any value that does not exist in the parent table, which is what enforces referential integrity.

Q10. What is the difference between an INNER JOIN and a LEFT JOIN? Show me the rows.

SELECT s.name, m.subject, m.score
FROM students s
INNER JOIN marks m ON m.student_id = s.student_id
ORDER BY s.name;

Four rows. Aditi appears twice because she has two mark rows, and Meera does not appear at all because an inner join keeps only rows that matched on both sides. Change one word and the result changes:

SELECT s.name, m.subject, m.score
FROM students s
LEFT JOIN marks m ON m.student_id = s.student_id
ORDER BY s.name;

An inner join returns only the rows where the join condition matched on both sides. A left join returns every row from the left table, and fills the right table's columns with nulls where there was no match. So the inner join gives four rows and drops Meera, while the left join gives five rows and shows Meera with null marks. To list students who have no marks at all, I keep the left join and add WHERE m.student_id IS NULL.

The trap interviewers set here: putting a filter on the right-hand table in the WHERE clause silently turns a left join back into an inner join. Writing LEFT JOIN marks m ON m.student_id = s.student_id WHERE m.subject = 'DBMS' drops Meera, because her m.subject is null and NULL = 'DBMS' evaluates to unknown rather than true, so the row is filtered out. If you want to keep every student and join only their DBMS marks, that condition belongs in the ON clause, where it is applied before the outer join fills in the nulls.

Q11. What is the difference between WHERE and HAVING?

SELECT subject,
       COUNT(*)   AS students_appeared,
       AVG(score) AS average_score
FROM marks
WHERE score IS NOT NULL
GROUP BY subject
HAVING COUNT(*) >= 2;

-- subject | students_appeared | average_score
-- --------+-------------------+--------------
-- DBMS    | 3                 | 74.67
--
-- OS forms a group too, but HAVING removes it: it has only one row.

WHERE filters individual rows before grouping, so it cannot use an aggregate function. HAVING filters the groups after GROUP BY has aggregated them, so it can. In this query WHERE first removes rows with a null score, then the rows are grouped by subject, and finally HAVING discards the OS group because it contains only one row.

Two details worth carrying into the room. COUNT(*) counts rows including those with nulls, while COUNT(score) skips rows where score is null, and that difference is a favourite follow-up. Also, in SQL Server AVG over an integer column returns an integer, so 74.67 comes back as 74 unless the column is cast to a decimal first.

Q12. What is normalization? Explain 1NF, 2NF and 3NF on a real table.

Start with a table that breaks all three. It stores courses as a comma-separated string, which is already illegal.

First normal form requires every column to hold a single atomic value, with no repeating groups. Split the multi-valued column into one row per course. The key is now the composite (roll_no, course_code).

Second normal form requires every non-key column to depend on the whole composite key, not on part of it. Here student_name depends only on roll_no, and course_name depends only on course_code. Both are partial dependencies, so those columns move out into their own tables.

Third normal form then requires that no non-key column depends on another non-key column. In the students table that remains, dept_hod depends on dept_code, which is not a key, so it is a transitive dependency and the department details move to a third table. The finished design:

departments(dept_code PK, dept_name, dept_hod)

students(roll_no PK, student_name, dept_code FK -> departments)

courses(course_code PK, course_name)

enrollments(roll_no FK, course_code FK, score,
            PRIMARY KEY (roll_no, course_code))

Normalization is the process of organising columns into tables so that each fact is stored in exactly one place. First normal form removes multi-valued columns. Second normal form removes partial dependencies on part of a composite key. Third normal form removes transitive dependencies, where a non-key column depends on another non-key column. The short version I remember is that every non-key column must depend on the key, the whole key, and nothing but the key. The payoff is that changing the head of department becomes one update to one row instead of an update to every enrollment row, and there is no way for two rows to disagree.

Q13. What are the ACID properties of a transaction?

Atomicity means a transaction is all or nothing. If a fund transfer debits one account and the credit then fails, the debit is rolled back using the undo log. Consistency means a transaction moves the database from one valid state to another, so constraints such as foreign keys and check constraints still hold when it commits. Isolation means concurrent transactions do not see each other's uncommitted work, and at the strictest level the outcome is the same as if they had run one after another. Durability means that once a transaction commits, its effect survives a crash, because the change is written to the write-ahead log on disk before the commit is acknowledged.

Expect a follow-up on why isolation has levels at all. The honest fresher answer is that full serializability is expensive, so databases offer weaker levels such as read committed and repeatable read, and each weaker level permits one specific anomaly, such as a non-repeatable read or a phantom row.

Q14. What is an index, and when does it make things worse?

An index is a separate structure, usually a B-tree, that keeps the indexed column values in sorted order along with pointers back to the rows. It lets the database find matching rows by descending the tree instead of scanning the whole table, which turns a full scan into a few page reads. The cost is that every insert, update and delete has to update the index as well, and the index occupies disk space, so a heavily indexed table writes more slowly. An index also will not help when the column has very few distinct values, or when the query wraps the column in a function, because then the sorted values stored in the index no longer match what is being compared.

Data Structures Preparation

Prepare basic data structures:

• Array
• String
• Stack
• Queue
• Linked list
• Hash map
• Tree basics
• Graph basics

Common interview questions:

1. Difference between array and linked list
2. What is stack?
3. What is queue?
4. What is hashing?
5. What is time complexity?
6. When would you use a linked list?

Do not only memorize definitions. Understand real use cases.

Q15. What is the difference between an array and a linked list?

An array stores elements in one contiguous block of memory, so the address of element i can be computed directly and access by index is constant time. Inserting or deleting in the middle is linear, because the remaining elements have to shift. A linked list stores each element in its own node with a pointer to the next node, so inserting or deleting is constant time once I already hold the previous node, but reaching element i takes linear time because I have to walk the chain from the head. Arrays also read faster in practice because contiguous memory is cache friendly, and a linked list spends extra memory on the pointers.

The natural follow-up is when you would actually choose a linked list. A good answer: when the collection changes constantly at a position you already hold a reference to, such as an LRU cache moving a node to the front, or the buckets of a hash map that resolve collisions by chaining.

Q16. What is the difference between a stack and a queue, and where is each used?

A stack is last in, first out, so the last item pushed is the first one popped. A queue is first in, first out, so items leave in the order they arrived. Both support their operations in constant time. Stacks are used for the function call stack, for undo history, for checking balanced brackets, and for depth first search. Queues are used for breadth first search, for print and task scheduling, and for buffering between a producer and a consumer.

Q17. What is hashing, and what is the time complexity of a hash map?

Hashing applies a hash function to a key to produce an index into an array of buckets, so a lookup goes straight to the bucket instead of searching. Insertion, lookup and deletion are constant time on average. The worst case is linear, when every key hashes to the same bucket and the structure degrades into one long chain. Collisions are handled either by chaining, where each bucket holds a list, or by open addressing, where the entry goes into the next free slot. When the load factor grows too high the table is resized and every key is rehashed.

If you name Java, be ready for the equals and hashCode contract: two objects that are equal must return the same hash code, otherwise a key stored in a map can never be found again. Mutating an object after using it as a key causes exactly the same bug.

Q18. What is time complexity?

Time complexity describes how the number of operations grows as the input grows, ignoring constant factors and lower order terms, and Big O notation states an upper bound on that growth. It matters because it predicts what will happen at a size I cannot check by hand. A nested loop over a hundred thousand elements is ten billion operations and will time out, while a single pass over the same data is a hundred thousand operations and finishes instantly.

If any row of that table is unfamiliar, work through Time Complexity for Beginners: Understanding Big O Without the Confusion, and for the coding round that usually precedes this interview, the worked problems are in Coding Round Preparation for Freshers.

Operating System Basics

Prepare these operating system topics:

• Process
• Thread
• CPU scheduling
• Deadlock
• Memory management
• Paging
• Segmentation
• Virtual memory
• File system basics

Freshers usually get basic OS questions, not very advanced ones.

Q19. What is the difference between a process and a thread?

A process is a program in execution with its own address space, and the operating system tracks it with a process control block. A thread is a unit of execution inside a process. Threads of the same process share the code, the heap and the open file descriptors, but each thread has its own stack, its own registers and its own program counter. Switching between threads of one process is cheaper than switching between processes, because the memory mappings do not have to change. The trade-off is isolation: since threads share memory they need synchronisation to avoid race conditions, and a fatal error in one thread takes the whole process down.

Q20. What is a deadlock, and what conditions cause it?

This is the OS question freshers are asked most, and the full-marks answer names the four Coffman conditions. A deadlock needs all four to hold at the same time.

Here is a deadlock in a few lines. Both blocks take the same two locks, in opposite orders.

final Object lockA = new Object();
final Object lockB = new Object();

// Thread 1
synchronized (lockA) {
    synchronized (lockB) { transfer(); }
}

// Thread 2
synchronized (lockB) {
    synchronized (lockA) { transfer(); }
}

// The interleaving that hangs forever:
//   Thread 1 acquires lockA
//   Thread 2 acquires lockB
//   Thread 1 waits for lockB   (held by Thread 2)
//   Thread 2 waits for lockA   (held by Thread 1)

A deadlock is a state in which a set of threads are each waiting for a resource held by another thread in the same set, so none of them can ever proceed. It requires four conditions to hold simultaneously: mutual exclusion, hold and wait, no preemption, and circular wait. Because all four are necessary, breaking any one of them prevents the deadlock, and the practical fix in code is to break circular wait by always acquiring locks in the same global order. Beyond prevention, an operating system can avoid deadlock by granting only requests that leave the system in a safe state, which is the Banker's algorithm, or it can allow deadlocks to happen, detect the cycle, and recover by killing or rolling back one of the threads.

Q21. Explain FCFS, SJF and Round Robin with an example.

Take three processes that all arrive at time zero, with burst times P1 = 6, P2 = 2 and P3 = 4.

First come first served runs processes in arrival order. It is simple, but it suffers from the convoy effect, where one long process makes every short process behind it wait. Shortest job first picks the smallest burst next, and for a fixed set of processes that are all ready at the same time it provably gives the lowest average waiting time. Its problems are that burst times are not actually known in advance and that long processes can starve. Round Robin gives each process a fixed time quantum in turn, which makes response time predictable and is why interactive systems use it. A very small quantum means good responsiveness but more context-switch overhead, and a quantum larger than every burst degenerates into FCFS.

In this particular example Round Robin ends up with the same average waiting time as FCFS, but P2 finishes at time 4 instead of time 8, and that responsiveness is exactly what Round Robin is bought for.

Q22. What is virtual memory, and what is a page fault?

Virtual memory lets each process work with its own address space that can be larger than the physical RAM available. Memory is divided into fixed-size pages and physical memory into frames of the same size, the page table maps one to the other, and the hardware memory management unit performs the translation. Only the pages currently needed have to be resident. When a process touches a page that is not in memory, the hardware raises a page fault, and the operating system loads that page from disk, evicts another page if no frame is free, updates the page table and restarts the instruction. If processes have so little memory that the system spends most of its time servicing page faults instead of executing instructions, that is thrashing.

Q23. What is the difference between paging and segmentation?

Paging divides memory into fixed-size blocks, so a process can be scattered across whichever frames are free. Because the size is fixed there is no external fragmentation, but the last page of a process is usually only partly used, which is internal fragmentation. Segmentation divides a program into variable-size logical units such as code, stack and data, which matches how a programmer thinks about the program and makes per-segment protection natural, but variable sizes leave unusable gaps between allocations, which is external fragmentation. Real systems commonly combine the two by paging each segment.

Computer Networks Basics

Prepare:

• IP address
• DNS
• HTTP and HTTPS
• TCP and UDP
• Client-server model
• OSI model
• LAN and WAN
• Port number
• Request and response

If you have web development projects, HTTP, APIs, frontend-backend communication, and databases become more important.

Q24. What is the difference between TCP and UDP?

TCP is connection-oriented. It sets up a connection with a three-way handshake of SYN, SYN-ACK and ACK, numbers the bytes it sends, acknowledges what it receives, retransmits what is lost, delivers data in order, and applies flow control and congestion control. That reliability costs latency and a larger header. UDP is connectionless. It simply sends datagrams, with no handshake, no acknowledgements, no retransmission and no ordering guarantee, and its header is only eight bytes. So TCP is used where every byte must arrive, such as web pages, file transfer and email, and UDP where being late is worse than being lost, such as live video, voice calls, gaming and DNS queries.

Q25. What happens when you type a URL in the browser and press Enter?

The browser first checks its own cache and the operating system cache for that domain. If the address is not there, DNS resolution happens: the resolver asks a root server, then the server for the top-level domain, then the authoritative server for the domain, and gets back an IP address. The browser then opens a TCP connection to that address, on port 443 for HTTPS, using the three-way handshake, and performs a TLS handshake to verify the server's certificate and agree on encryption keys. It sends an HTTP GET request with its headers, the server responds with a status code and the HTML body, and the browser parses that HTML, requests the CSS, JavaScript and images it references, and renders the page.

Q26. What is the difference between HTTP and HTTPS, and what do the status codes mean?

HTTPS is HTTP carried over TLS. It gives three things plain HTTP does not: the traffic is encrypted so it cannot be read in transit, the server proves its identity with a certificate signed by a certificate authority, and any tampering with the data is detected. HTTP uses port 80 by default and HTTPS uses port 443.

Have the common status codes ready, because this question almost always turns into that one: 200 OK, 201 Created, 301 permanent redirect, 302 temporary redirect, 400 bad request, 401 unauthorised meaning you are not authenticated, 403 forbidden meaning you are authenticated but not permitted, 404 not found, 429 too many requests, 500 internal server error and 502 bad gateway. The pairs that get confused are 401 against 403, and 301 against 302.

Q27. What is the OSI model, and where do TCP, IP and HTTP sit in it?

The OSI model has seven layers: physical, data link, network, transport, session, presentation and application. Each layer uses the service of the layer below it and adds its own header. IP is the network layer and handles addressing and routing between networks. TCP and UDP are the transport layer and handle delivery between processes, which is what port numbers identify. HTTP is an application layer protocol. In practice the four-layer TCP/IP model is what the internet actually implements, and it folds the top three OSI layers into a single application layer.

Project Explanation in Interview

Your project is often the most important part of the technical interview.

Prepare answers for:

1. What is your project about?
2. Why did you build it?
3. What problem does it solve?
4. What technologies did you use?
5. What was your role?
6. What features did you build?
7. What challenges did you face?
8. How does the database work?
9. How can you improve the project?

Use simple language. Do not make your project sound more complicated than it is.

The model answers below use one imaginary college project, a library management system, so you can see the level of detail that is expected. Replace the specifics with your own, but keep the shape.

Q28. Tell me about your project.

It is a library management system for our department library, which was tracking issues and returns in a paper register. It has three roles: a student can search the catalogue and see what they have borrowed, a librarian can issue and return books, and an admin can add titles and view overdue reports. I built it with Java and Spring Boot on the backend and MySQL for the data, and another team member built the React frontend. The part I would call the core is the issue flow, because it has to check that the copy is available, that the student is under the borrowing limit, and that they have nothing overdue, and all three checks have to happen in one transaction so that two librarians cannot issue the same copy at the same moment.

That answer takes under a minute, names the users, names your specific contribution, and hands the interviewer an obvious next question about transactions, which is a question you want to be asked.

Q29. How does your database work? Walk me through the schema.

There are four main tables. Books holds one row per title, with the ISBN as a natural key. Copies holds one row per physical copy with a foreign key to books, because the library owns several copies of the same title and each copy has its own condition and status. Members holds the students. Loans joins a copy to a member with an issue date, a due date and a nullable return date, where null means the book is still out, and it has foreign keys to both copies and members. I added an index on the member column of loans, because the most frequent query is listing everything a given member currently has out, and without the index that query was scanning the whole loans table.

Notice what makes that answer credible: it explains why copies are separate from books instead of just listing tables, and it justifies one specific index rather than claiming that indexes make things faster.

Q30. What was the hardest bug or challenge you faced?

The overdue report was showing books as overdue that had already been returned. The query filtered on the due date being in the past but never checked the return date, so any loan that had ever been returned late kept appearing forever. I found it by taking one wrong row from the report and running the query by hand for that single loan, which showed the return date was populated. The fix was to add the condition that the return date is null, and I also wrote a test with one returned-late loan and one genuinely overdue loan so the same mistake cannot come back.

A small, specific bug, honestly described together with how you diagnosed it, is worth far more than a vague claim about a difficult integration. The interviewer is checking whether you debug by reasoning or by guessing.

Q31. How would you improve this project?

Three things. The catalogue search returns every matching row at once, so it needs pagination before the number of titles grows. Passwords are hashed, but there is no rate limiting on the login endpoint, so it is open to repeated guessing. And the overdue reminder runs as a scheduled job inside the application, which means it fires once per running instance, so if the app were ever run on two servers students would get duplicate emails. If I rebuilt it, I would move that job out or guard it with a database lock.

Naming real weaknesses in your own work is one of the strongest signals a fresher can send. It shows you understand the system well enough to see its edges, and it is received far better than claiming the project has no limitations.

How to Answer Unknown Questions

Do not fake answers.

If you do not know something, you can say:

"I am not fully sure about that concept, but I understand the basic idea. May I explain what I know?"

This is better than giving a wrong confident answer.

Interviewers usually respect honesty when the candidate is willing to learn.

There is a middle path between a confident wrong answer and silence, and it earns real marks. State the boundary of what you know, then reason forward out loud from something you do know. If you are asked about database isolation levels and you have only studied ACID, you can say that you know isolation means concurrent transactions should not see each other's uncommitted changes, that you have not used the specific levels, and that you would expect a weaker level to run faster and to permit some anomaly in exchange. That answer is honest, it is correct as far as it goes, and it shows the interviewer how you think once you are past the edge of what you memorised, which is the thing actually being tested.

Two habits help here. Ask a clarifying question when the question is genuinely ambiguous, because a candidate who asks whether the array is already sorted is behaving like an engineer. And do not argue when you are corrected: note it down, say thank you, and move on.

7-Day Technical Interview Revision Plan

Day 1

Resume and project revision. Go line by line through your resume and write the question each line invites, using the table earlier in this guide. Then write out your one-minute project answer, your schema walkthrough, and one real bug you fixed, and say all three out loud.

Day 2

Programming language basics. Revise the language you named first on your resume: data types, strings, collections or containers, and error handling. Answer the three language questions above from memory, then check yourself against the code.

Day 3

OOPs concepts. Do not re-read definitions. Write a small class that demonstrates encapsulation, then a parent and child class that demonstrate overriding, and be able to say what each will print and why.

Day 4

DBMS and SQL. Copy the two small tables from this guide onto paper, then write the inner join, the left join, the group by with having, and a query for the second highest score. Then normalize one messy table up to third normal form from scratch.

Day 5

Data structures basics. Array against linked list, stack, queue, hashing, and complexity. For each structure, be able to name one place it is genuinely used rather than only defining it.

Day 6

Operating system and networks basics. Process against thread, the four Coffman conditions, one scheduling example worked out with real numbers, virtual memory, TCP against UDP, and what happens when a URL is typed.

Day 7

Mock interview and final revision. Have a friend ask you fifteen of the questions in this guide in random order, out loud, with no notes in front of you. Every answer you stumble on is your revision list for the evening.

This plan is useful when your technical interview is close.

Common Mistakes to Avoid

Freshers should avoid these mistakes:

1. Writing fake skills
2. Not knowing your own project
3. Memorizing without understanding
4. Giving very long answers
5. Arguing with interviewer
6. Guessing confidently
7. Ignoring basics
8. Not revising resume
9. Not practicing SQL queries
10. Not preparing project explanation

Technical interviews are mostly about clarity and honesty.

Two of these deserve a sharper warning. Guessing confidently is worse than saying you do not know, because an interviewer who catches one invented answer starts doubting the answers you got right. And giving very long answers is usually a symptom of not knowing which part matters: if you cannot answer a definition question in three sentences, you have not finished revising it.

Conclusion

Technical interview preparation for freshers is mainly about understanding the basics.

You do not need to know every advanced topic. But you should know your resume, your projects, your programming language, and your core subjects.

Prepare honestly. Practice explaining your answers. Revise important topics. Keep your project explanation ready.

A clear and confident fresher often performs better than someone who tries to fake advanced knowledge.

The most useful way to finish this guide is to close it and test yourself. Say the deadlock answer without looking. Write the left join and predict its rows before you run it. Then browse the practice tests by subject and topic and take one on the subject you have just revised, because a topic you can pass under a clock is the only kind you can rely on in an interview room. Once the technical round is over the questions change shape completely, and those are covered in HR Interview Questions and Answers for Freshers.

FAQs

1. What should freshers prepare for technical interviews?

Freshers should prepare programming basics, OOPs, DBMS, SQL, data structures, projects, and resume-based questions. The highest-return items are overloading against overriding in OOP, joins and group by in SQL, process against thread and deadlock in operating systems, and a rehearsed project explanation, because those come up in almost every fresher interview.

2. Are projects important in technical interviews?

Yes. Interviewers often ask detailed questions from projects mentioned in the resume. Expect the questioning to go one level deeper than your description, into the schema, the reason you chose a particular technology, and one specific bug, so prepare those three answers rather than a summary.

3. What if I cannot answer a technical question?

Be honest. Explain what you know instead of giving a fake answer. State the boundary of what you are sure about, then reason out loud from a related concept you do know, because the interviewer is watching how you handle an unknown as closely as what you have memorised.

4. Is DBMS important for technical interviews?

Yes. DBMS and SQL are commonly asked in fresher technical interviews. The reliable core is keys, the difference between an inner and a left join, WHERE against HAVING, normalization up to third normal form, the ACID properties, and what an index costs.

5. How should I explain my project?

Explain the problem, technologies used, your role, main features, challenges, and possible improvements. Keep the first version under a minute, name the part you personally built, and end on a real limitation, which invites the follow-up question you are best prepared for.

Tags: campus-placement, freshers-placement-guide, technical-interview