The Operating Systems Questions Freshers Actually Get Asked

14 Jul 2026 6 min read

Operating systems is the subject freshers skip, and then get caught by. It’s not because OS is hard — it’s because it feels like theory you memorise for a semester exam and forget. Then an interviewer asks “what’s the difference between a process and a thread?” and the answer comes out as a definition rather than an explanation, and everyone in the room can hear the difference.

Here’s what actually gets asked, and what a good answer sounds like.

Process vs thread

The most asked question in the subject. The definition-shaped answer — “a process is a program in execution, a thread is a lightweight process” — is technically true and tells the interviewer nothing.

The answer that lands is about what’s shared:

A process has its own memory space. Threads live inside a process and share its memory — the heap, the globals, open files — but each has its own stack and registers.

Everything else follows from that one fact, and saying so is what makes it an explanation:

Threads are cheaper to create and switch between, because there’s no address-space switch.
Communication between threads is easy (shared memory), between processes it needs IPC.
One thread crashing can take down the whole process; one process crashing doesn’t touch another.
And shared memory is exactly why threads need synchronisation — which is where the follow-up is going.

If you can say “because they share memory” and then derive the rest, you’ve answered the next three questions before they’re asked.

Deadlock

Expect: what is it, what are the four conditions, how do you handle it.

Deadlock is when a set of processes are each waiting for a resource another one holds, so none can proceed. The four Coffman conditions must hold simultaneously:

Mutual exclusion — a resource can’t be shared.
Hold and wait — a process holds one resource while waiting for another.
No preemption — a resource can’t be forcibly taken away.
Circular wait — a cycle of processes each waiting on the next.

The useful part — and the follow-up you should be ready for — is that all four must hold, so breaking any one prevents deadlock. That’s what turns the list into something other than trivia:

Break hold-and-wait: require processes to request everything up front.
Break no-preemption: allow the system to take resources back.
Break circular wait: impose a global ordering on resources and require requests in that order. (This is the one used in practice, because it’s cheap.)

If asked about handling deadlock generally: you can prevent it (break a condition), avoid it (Banker’s algorithm — grant a request only if the system stays in a safe state), detect and recover (let it happen, find the cycle, kill something), or ignore it. Worth knowing that most general-purpose operating systems mostly choose the last one, because prevention is expensive and deadlocks are rare — that’s the ostrich algorithm, and knowing the name of it is a nice touch.

Paging and virtual memory

Expect: why paging, what’s a page fault, what’s thrashing, TLB.

Paging exists to solve external fragmentation and to let a process use more memory than physically exists. Memory is split into fixed-size pages; physical memory into frames of the same size. A page table maps one to the other. Because the pages don’t need to be contiguous in physical memory, you can’t get stranded by fragmentation the way you can with variable-sized segments.

A page fault is a reference to a page that isn’t currently in physical memory. The OS traps, fetches the page from disk, updates the page table, and restarts the instruction. It’s not an error — it’s the mechanism working.
The TLB is a small cache of recent page-table entries, because otherwise every memory access would need an extra memory access to read the page table first.
Thrashing is when the system spends more time servicing page faults than doing work, because processes don’t have enough frames to hold their working set. The counterintuitive detail worth mentioning: adding more processes makes it worse, not better.

Know at least two page-replacement policies (FIFO, LRU, Optimal) and know that Optimal is unimplementable — it needs the future — and exists as a benchmark to compare the others against. Belady’s anomaly (more frames can mean more faults, in FIFO) is a favourite follow-up.

Scheduling

Expect: the algorithms, and their trade-offs.

FCFS, SJF, Priority, Round Robin, Multilevel Queue. Don’t just list them — know what each one is bad at, because that’s the question:

FCFS — simple, but one long job delays everyone behind it (the convoy effect).
SJF — optimal for average waiting time, but you can’t know job lengths in advance, and long jobs can starve.
Round Robin — fair and responsive, but performance hinges on the time quantum. Too large and it degenerates into FCFS; too small and you drown in context-switch overhead.
Priority — starvation risk, solved with aging (gradually raise the priority of waiting processes).

The pattern in all four: every scheduler trades throughput against fairness and response time. If you can name the trade-off, you don’t need to memorise a table.

Synchronisation

Expect: race condition, critical section, mutex vs semaphore.

A race condition is when the result depends on the timing of threads. The critical section is the code touching shared data, and it needs mutual exclusion, progress, and bounded waiting.

Mutex vs semaphore trips people up, so be precise:

A mutex is a lock with an owner — whoever locks it must unlock it. It’s for mutual exclusion, full stop.
A semaphore is a counter with wait and signal, no ownership, and any thread can signal it. A binary semaphore looks like a mutex but isn’t one, because of that ownership difference — semaphores are for signalling between threads, not just locking.

Producer-consumer is the standard problem here, and being able to sketch it with semaphores is a reasonable thing to have ready.

How to prepare this

Don’t read a textbook cover to cover. The examinable surface of OS for placements is genuinely about twenty concepts, and they’re all above.

The way to get them into long-term memory is retrieval, not re-reading: get asked the question, try to answer, find out immediately whether you were right. Our OS interview bank does exactly that — questions with explanations on every one, so a wrong answer teaches you something instead of just marking you wrong.

Then do the same for DBMS and computer networks. The three together are the bulk of the CS-fundamentals round, and they’re the part of the syllabus where a few focused hours move you further than anywhere else — because most candidates skip them.