Click any module to expand. OS interview questions come in two forms: conceptual ("What is a deadlock?") and numerical ("Calculate average waiting time for this schedule"). This module trains both — every concept includes worked numerical examples and interview-style practice problems.
What an OS does, how it's structured, and the hardware-software boundary
Resource manager (CPU, memory, disk, I/O). Abstraction layer between hardware and applications. Convenience (easy to use) vs efficiency (maximum utilisation). Why every program you write depends on the OS — from printf to malloc to file open.
Batch → multiprogramming → time-sharing → real-time → distributed → mobile. What each type optimises for. Why time-sharing (Linux, Windows) dominates desktops. Real-time OS (RTOS) in embedded systems (cars, pacemakers). Mobile OS (Android kernel = Linux).
Privilege levels: user applications run in user mode (restricted), OS kernel runs in kernel mode (full hardware access). Mode bit switching. Why the separation exists — one buggy app shouldn't crash the entire system. System calls as the controlled gateway between modes.
The API between user programs and the OS. Categories: process control (fork, exec, wait, exit), file management (open, read, write, close), device management (ioctl), information (getpid, time), communication (pipe, shmget, socket). How printf eventually calls write(). The syscall mechanism: trap → mode switch → handle → return.
Monolithic (Linux): all OS services in kernel space — fast but large. Microkernel (Minix, QNX): minimal kernel, services in user space — modular but IPC overhead. Hybrid (Windows NT, macOS): mix of both. Modular monolithic (Linux modules). Which companies ask about this: systems companies, Google, Microsoft.
Hardware interrupts (I/O device signals CPU), software interrupts (system calls, exceptions). Interrupt handling: save state → identify source → run handler → restore state. DMA (Direct Memory Access): device transfers data to memory without CPU involvement. Why DMA matters for performance.
The core of OS — how programs execute, how threads work, and how processes communicate
What a process IS (program in execution). Process states: New → Ready → Running → Waiting → Terminated. Process Control Block (PCB): PID, state, program counter, registers, memory limits, open files. Context: everything the OS needs to pause and resume a process.
fork() — creates a child process (copy of parent). exec() — replaces process image with new program. wait() — parent waits for child to finish. exit() — terminates process. The fork-exec pattern used by every shell command. "How many processes does fork() create?" — the classic interview question with n forks creating 2ⁿ processes.
What happens when the OS switches from one process to another: save PCB of current → load PCB of next → resume. Context switch overhead: time spent switching is "wasted" CPU time. What triggers a switch: timer interrupt, I/O request, higher-priority process. Why too many switches = poor performance.
Thread = lightweight process (shares code, data, files with other threads of same process; has own registers, stack, PC). "Difference between process and thread" — THE most asked OS interview question. Why threads are faster to create/switch than processes. Shared memory advantage and race condition risk.
User-level threads (managed by thread library, OS sees one thread) vs kernel-level threads (OS manages each thread). Threading models: many-to-one, one-to-one (Linux pthreads), many-to-many. Multithreading benefits: responsiveness, resource sharing, economy, scalability on multi-core. Java threads use one-to-one model.
Shared memory: fastest, processes access same memory region (shmget, shmat). Message passing: send/receive messages (pipes, message queues). Pipes: unnamed (parent-child) and named (FIFO — any two processes). Sockets: communication across machines. Signals: asynchronous notifications (SIGKILL, SIGTERM). When to use which IPC mechanism.
How the OS decides which process runs next — the most numerical OS topic
CPU utilisation, throughput, turnaround time (completion - arrival), waiting time (turnaround - burst), response time (first response - arrival). How to calculate each from a Gantt chart. Trade-offs: minimising waiting time vs maximising throughput vs fairness. Preemptive vs non-preemptive scheduling.
FCFS (First Come First Served): simple, convoy effect (short jobs wait behind long ones). SJF (Shortest Job First): optimal for average waiting time (non-preemptive). SRTF (Shortest Remaining Time First): preemptive SJF. Worked numerical examples with Gantt charts for each. Starvation in SJF/SRTF.
Each process gets a fixed time slice (quantum). After quantum expires, process goes to end of ready queue. Effect of quantum size: too large → degrades to FCFS, too small → too many context switches. Optimal quantum: 10–100ms typically. Numerical: calculate WT, TAT for given quantum. The fairest scheduling algorithm.
Each process has a priority. Higher priority runs first. Preemptive vs non-preemptive priority. Starvation problem: low-priority processes never run. Solution: aging (gradually increase priority of waiting processes). Priority inversion: low-priority process holds a lock needed by high-priority process. Mars Pathfinder bug — the real-world priority inversion case.
Multilevel Queue: separate queues for different process types (foreground/background), each with its own algorithm. Multilevel Feedback Queue (MLFQ): processes can move between queues based on behaviour — interactive processes stay in high-priority queue, CPU-bound processes move down. How Linux CFS (Completely Fair Scheduler) works conceptually.
Given arrival times and burst times, draw Gantt chart, calculate waiting time, turnaround time, and average for: FCFS, SJF, SRTF, Round Robin, Priority. Compare algorithms on the same input. "Which algorithm gives minimum average waiting time?" — the standard exam/interview numerical question.
Race conditions, critical sections, and the tools that prevent concurrent access bugs
What a race condition IS: two processes/threads access shared data simultaneously, and the result depends on execution order. Critical section: code segment accessing shared resources. Requirements for a solution: mutual exclusion, progress, bounded waiting. Peterson's solution for 2 processes. Why software-only solutions are insufficient for modern multi-core systems.
Atomic hardware instructions that enable synchronisation. Test-and-Set (TAS): atomically read and write a lock variable. Compare-and-Swap (CAS): atomically compare and conditionally update. Spinlocks using TAS — busy waiting problem. Why hardware support is necessary for correct synchronisation on modern CPUs.
Semaphore = integer variable + wait(P) + signal(V) atomic operations. Binary semaphore (mutex): 0 or 1, for mutual exclusion. Counting semaphore: for managing N identical resources. Using semaphores to solve producer-consumer, readers-writers. Implementation: without busy waiting (block/wakeup).
Mutex: binary lock, only owner can unlock. Semaphore: signalling mechanism, any thread can signal. Monitor: high-level construct — mutual exclusion + condition variables (wait/signal/broadcast). Java synchronized = monitor. pthread_mutex = mutex. The distinctions interviewers test: "When do you use semaphore vs mutex?"
Producer-Consumer (bounded buffer): producer adds, consumer removes, buffer has finite size. Readers-Writers: multiple readers allowed simultaneously, writer needs exclusive access. Dining Philosophers: 5 philosophers, 5 chopsticks, avoid deadlock and starvation. Solutions using semaphores and monitors for each. These are the 3 problems every interviewer knows.
Spinlock: busy-wait for short critical sections (used in OS kernel code). Read-write lock: allows concurrent reads, exclusive writes. Lock-free programming concepts (CAS-based data structures). Barriers and condition variables. Why choosing the right synchronisation primitive matters for performance — and what Linux kernel uses internally.
When processes wait for each other forever — detection, prevention, avoidance, and recovery
Four necessary conditions: Mutual Exclusion (resource held exclusively), Hold and Wait (holding one, waiting for another), No Preemption (can't forcibly take), Circular Wait (cycle of waiting). ALL four must hold simultaneously for deadlock. Removing any one prevents deadlock. The foundation of every deadlock question.
Directed graph: processes (circles), resources (rectangles with dots), request edges (P → R), assignment edges (R → P). Cycle in RAG with single-instance resources = deadlock. Cycle with multi-instance resources = may or may not be deadlock. Drawing and analysing RAGs — a standard interview exercise.
Eliminate one of the four conditions: break mutual exclusion (not always possible), break hold-and-wait (request all resources upfront), allow preemption (forcibly take resources), break circular wait (impose ordering on resource requests). Trade-offs: prevention is conservative — may reduce resource utilisation.
Banker's algorithm: before granting a resource request, check if the system remains in a safe state. Safe state: there exists a sequence in which all processes can complete. Safety algorithm: step-by-step check using Available, Max, Allocation, Need matrices. Worked numerical example. "Is this state safe? If yes, find the safe sequence." — the classic OS numerical.
Detection: periodically run a detection algorithm (similar to safety algorithm). Wait-for graph for single-instance resources. Recovery options: kill processes (one by one or all), preempt resources (rollback). Which process to kill? Criteria: priority, time consumed, resources held. Real-world: databases use timeout-based detection.
How the OS allocates, tracks, and protects memory — the most conceptually rich OS topic
Fixed partitioning (equal/unequal sizes) and dynamic partitioning. Allocation strategies: First Fit (first block that fits), Best Fit (smallest sufficient block), Worst Fit (largest block). Internal fragmentation (wasted space inside allocated block) vs external fragmentation (wasted space between blocks). Compaction to reduce external fragmentation.
Divide physical memory into fixed-size frames, logical memory into same-size pages. Page table: maps page number → frame number. Address translation: logical address = page number + offset → physical address = frame number + offset. No external fragmentation. Internal fragmentation only on last page. Page table entry: frame number, valid bit, dirty bit, reference bit.
Problem: page table itself can be huge (4GB address space, 4KB pages = 1M entries). Solution: multi-level (hierarchical) page tables — page the page table. Two-level paging: outer page table → inner page table → frame. Inverted page table: one entry per frame (not per page) — saves space, used in PowerPC, IA-64.
TLB = fast hardware cache for page table entries. TLB hit: address translated in 1 cycle. TLB miss: walk the page table (10-100 cycles). Effective memory access time = hit_ratio × (TLB_time + memory_time) + miss_ratio × (TLB_time + 2 × memory_time). TLB flush on context switch (ASID tag avoids flush). Numerical problems on effective access time.
Segmentation: divide memory into variable-size segments (code, data, stack, heap) — matches programmer's view. Segment table: base + limit. Address translation: segment number + offset → base + offset (with limit check). Segmentation with paging: segment each segment into pages (used in x86 protected mode). Segment fault vs page fault.
Virtual memory: process address space larger than physical memory. Demand paging: load pages into memory only when accessed (lazy loading). Page fault: page not in memory → OS loads from disk → update page table → restart instruction. Copy-on-Write (COW): fork() shares pages until one process writes — then copy. Why COW makes fork() fast.
FIFO: replace oldest page. Belady's anomaly: more frames can cause MORE page faults with FIFO. Optimal (OPT): replace page not used for longest time (theoretical — requires future knowledge). LRU: replace least recently used (good approximation of OPT). LRU approximation: clock algorithm (second-chance), enhanced clock. Numerical: given a reference string and N frames, calculate page faults for each algorithm.
Thrashing: process spends more time page-faulting than executing. Cause: too many processes, not enough frames per process. Working set model: keep the set of pages a process is actively using in memory. If working set size > available frames → thrashing. Solution: suspend processes to free frames. Degree of multiprogramming vs CPU utilisation curve.
How data is stored persistently — files, directories, allocation, and disk scheduling
File = named collection of related data. Attributes: name, type, size, location, owner, permissions, timestamps. File operations: create, open, read, write, seek, close, delete. File descriptors in Unix/Linux. Access methods: sequential access, direct (random) access, indexed access.
Single-level (flat), two-level (per-user), tree-structured (hierarchical — what we use), acyclic graph (shared files via links), general graph. Path names: absolute (/home/user/file) vs relative (./file). Hard links vs soft links (symbolic links). Inode structure in Unix/Linux.
Contiguous allocation: fast sequential + random access, but external fragmentation and file growth problems. Linked allocation: each block points to next — no fragmentation, but slow random access (FAT). Indexed allocation: index block stores all block pointers — fast random access, no fragmentation (Unix inode). Multi-level indexed (direct + indirect + double-indirect pointers).
Bit vector (bitmap): one bit per block (1 = free, 0 = allocated). Linked list of free blocks. Grouping and counting approaches. Trade-offs: bitmap is fast for contiguous allocation, linked list is space-efficient for fragmented disks.
FCFS: simple, high seek time. SSTF (Shortest Seek Time First): greedy, starvation possible. SCAN (elevator): move in one direction, service all requests, reverse. C-SCAN (circular SCAN): uniform wait time. LOOK / C-LOOK: like SCAN/C-SCAN but only go as far as last request. Numerical: calculate total head movement for each algorithm given a request sequence.
RAID 0 (striping — speed, no redundancy), RAID 1 (mirroring — redundancy, 50% capacity), RAID 5 (distributed parity — speed + redundancy), RAID 6 (double parity), RAID 10 (stripe of mirrors). When to use each level. How RAID handles disk failure. Why enterprise servers use RAID and which levels they choose.
Input/output management, practical Linux, and containerisation/virtualisation
I/O hardware: controllers, ports, buses. Polling vs interrupt-driven I/O vs DMA — trade-offs. Device drivers: OS module that communicates with specific hardware. Kernel I/O subsystem: scheduling, buffering, caching, spooling. Why printing uses spooling and disk uses buffering.
Single buffering, double buffering, circular buffering. Buffer cache: keep recently accessed disk blocks in memory. Write-back vs write-through caching. Page cache in Linux: unifying file I/O and memory management. Why "everything is a file" in Unix simplifies I/O.
ps, top, htop for viewing processes. kill, nice, renice for managing processes. Background processes (&), jobs, fg, bg. cron for scheduled tasks. Process priority and scheduling in Linux. /proc filesystem — virtual filesystem exposing kernel data. Practical skills every developer needs.
Read (r=4), write (w=2), execute (x=1) for owner, group, others. chmod, chown, chgrp. The permission string: -rwxr-xr-x. Setuid, setgid, sticky bit. sudo and root access. Why permissions matter for security — and what happens when they're misconfigured.
Virtual machines: running one OS inside another. Type 1 hypervisor (bare-metal: VMware ESXi, Xen) vs Type 2 (hosted: VirtualBox, VMware Workstation). Hardware virtualisation support (Intel VT-x). Why cloud computing relies entirely on virtualisation — AWS EC2 = virtual machines on Type 1 hypervisors.
Containers (Docker): OS-level virtualisation — share the host kernel, isolated userspace. Containers vs VMs: faster startup, less overhead, less isolation. Namespaces (process, network, mount isolation) and cgroups (resource limiting) — the Linux kernel features that make containers possible. Kubernetes for container orchestration. Why understanding containers matters for every modern software role.
50+ Gantt chart problems: FCFS, SJF, SRTF, RR, Priority. Calculate WT, TAT, avg for each. Compare algorithms on same input.
30+ reference string problems: FIFO, LRU, OPT with varying frame counts. Identify Belady's anomaly cases.
20+ safety check problems: determine if a state is safe, find safe sequences, decide if resource requests can be granted.
15+ head movement problems: FCFS, SSTF, SCAN, C-SCAN, LOOK. Compare total seek distances.
Hands-on Linux practice: process management (ps, kill, nice), file permissions (chmod), shell scripting basics, cron jobs.
Write C programs using fork(), pipe(), and shared memory. Count processes created by nested forks. Classic OS programming exercises.
Trainers explain concepts with diagrams, real-world examples, and worked numericals. Every concept connects to interview questions — not textbook theory.
OS is the most numerical CS subject. Every topic includes worked examples and practice problems: scheduling Gantt charts, page faults, Banker's algorithm, disk head movement.
Hands-on practice on Linux terminal: process commands, file permissions, shell scripting. Understanding the OS through direct interaction — not just slides.
MCQs on OS concepts + numerical problems. Auto-evaluated with topic-wise analytics. Timed to simulate placement test conditions.
TCS NQT, Infosys SP, Wipro NLTH, Cognizant GenC — every service company's technical section includes OS questions. Process vs thread, scheduling calculations, page faults, deadlock conditions. Students who skip OS lose 5–10 marks that aptitude prep can't recover.
Google, Amazon, Microsoft, Flipkart ask OS in system design context: "How does virtual memory work?" "What happens when you type a URL?" "How does fork() work internally?" These aren't textbook recitations — they test whether you understand the mechanisms behind daily programming.
Every tech company runs on Linux. Server deployment, Docker containers, CI/CD pipelines, cloud infrastructure — all Linux. Students who can't navigate a Linux terminal, manage processes, or set file permissions are unprepared for any backend or DevOps role.
Why is my program slow? (thrashing or excessive context switching). Why does my multi-threaded code produce wrong results? (race condition). Why did my server crash? (memory leak, fork bomb). OS knowledge is the debugging superpower that separates junior developers from senior developers.
E-305, Industrial Area, Sahibzada Ajit Singh Nagar, Punjab 160055, IN
