Free lesson · Operating Systems
What An Operating System Actually Does
The Simplest Way to Think About an Operating System
Imagine you are running a restaurant. You have a kitchen with limited counter space, a few ovens, a walk-in fridge, and a small team of cooks. Customers are placing orders constantly. Some orders are simple - a salad. Some are complex - a five-course meal. Some customers are impatient. Some are willing to wait.
You need someone to manage all of this. Someone who decides which cook works on which order. Someone who makes sure two cooks do not try to use the same oven at the same time. Someone who allocates counter space so one cook's ingredients do not spill into another's. Someone who handles the walk-in fridge so cooks can store and retrieve ingredients efficiently.
That manager is the operating system.
Your computer has a CPU (the cooks), RAM (the counter space), a disk (the walk-in fridge), and devices like the network card and keyboard (the dining room where orders come in). Programs are the orders. The operating system is the manager that coordinates everything so that all the orders get filled, nothing gets lost, and the kitchen does not descend into chaos.
Without an operating system, every program would need to know how to talk directly to the hardware. Every program would need its own code for reading from disk, drawing on the screen, and managing memory. Programs would step on each other. One buggy program could overwrite another program's data or crash the entire machine.
The operating system exists to solve this problem. It sits between your programs and the hardware, providing a clean, safe, and organized interface. Your programs ask the OS for what they need - memory, disk access, network connections - and the OS handles the messy details of making it happen.
The Five Core Jobs of an Operating System
Every operating system, from the Linux kernel running on Google's servers to the Windows installation on a laptop, performs five core jobs. Each one manages a different hardware resource and solves a specific coordination problem.
graph TD
OS[Operating System] --> PM[Process Management]
OS --> MM[Memory Management]
OS --> FS[File System Management]
OS --> IO[I/O Management]
OS --> SEC[Security & Protection]
PM --> PM1[Create, schedule, and<br/>terminate processes]
PM --> PM2[Manage threads within<br/>processes]
PM --> PM3[Handle inter-process<br/>communication]
MM --> MM1[Allocate and free<br/>memory for programs]
MM --> MM2[Provide virtual memory<br/>so every program thinks<br/>it has unlimited RAM]
MM --> MM3[Decide what stays in<br/>RAM and what goes<br/>to disk]
FS --> FS1[Organize data into<br/>files and directories]
FS --> FS2[Handle read and write<br/>operations]
FS --> FS3[Manage disk space<br/>allocation]
IO --> IO1[Communicate with<br/>hardware devices]
IO --> IO2[Buffer and schedule<br/>I/O operations]
IO --> IO3[Provide a uniform<br/>interface to diverse<br/>hardware]
SEC --> SEC1[Isolate processes<br/>from each other]
SEC --> SEC2[Enforce file and<br/>resource permissions]
SEC --> SEC3[Protect kernel from<br/>user programs]
This diagram shows the operating system at the top, branching into its five core responsibilities: process management, memory management, file system management, I/O management, and security and protection. Each responsibility branches further into three specific tasks the OS performs for that area.
Job 1: Process Management
Interactive animation: One core runs one thing at a time, so the OS switches between processes thousands of times a second.
A process is a program that is currently running. When you open a web browser, the OS creates a process for it. When you start a music player, that is another process. When you run a Python script, that is yet another process. Your computer might have hundreds of processes running at the same time - but it probably has only 4 to 16 CPU cores.
The operating system's process management job is to create new processes when programs start, decide which process gets to use the CPU and for how long, pause processes that are waiting for something (like data from the disk) so the CPU can do other work, let processes communicate with each other when they need to share data, and clean up processes when they finish or crash.
This is the single most important OS concept for interviews. Processes and threads (which are lightweight processes) come up in system design, concurrency, and fundamentals rounds. Module 01 and Module 02 of this course cover them in depth.
The key idea to hold onto is that your CPU can only run one thing at a time per core. The OS creates the illusion of many programs running simultaneously by switching between them very quickly - thousands of times per second. This switching is called a context switch, and it is one of the most frequently asked-about OS concepts in interviews.
Job 2: Memory Management
Interactive animation: Virtual memory: each process sees a private, continuous space from address 0, while the OS maps it to physical RAM.
Your computer has a limited amount of RAM - maybe 8 GB, 16 GB, or 32 GB. Every running process needs some of that RAM to store its code, its data, and its working state. The OS needs to decide how much memory each process gets, make sure one process cannot read or overwrite another process's memory, and handle the situation when there is not enough RAM for everything.
The clever solution that modern operating systems use is called virtual memory. Here is the core idea: every process thinks it has its own private, continuous chunk of memory, starting at address 0 and going up to some large number. But this is an illusion. The OS translates the process's "virtual" addresses into "physical" addresses - the actual locations in RAM where the data lives.
This illusion provides two critical benefits. First, it gives each process isolation - one process cannot accidentally (or deliberately) touch another process's memory. Second, it allows the OS to use more memory than physically exists by storing some data on disk and swapping it into RAM when needed.
Virtual memory is one of the most elegant concepts in computer science, and it comes up frequently in interviews. Module 07 and Module 08 of this course give you the complete picture - from how memory is laid out inside a process to how paging works to what happens during a page fault.
Job 3: File System Management
Interactive animation: From raw disk blocks to a path you can type: inodes, the directory tree, and journaling for crashes mid-write.
When you save a file, where does it go? You think of files as living in folders on your computer. But the disk does not know about files or folders. The disk is just a long sequence of storage blocks - millions or billions of them - with no inherent organization.
The file system is the OS component that creates the abstraction of files and directories on top of raw disk blocks. It decides where on the disk to store each file's data, keeps track of which blocks belong to which file using data structures (on Linux, these are called inodes), organizes files into a directory tree so you can find them by path (/home/user/documents/resume.pdf), and handles operations like creating, reading, writing, renaming, and deleting files.
The file system also has to deal with a hard problem: what happens if the power goes out in the middle of writing a file? Without protection, this can corrupt the file or even the entire file system. Modern file systems solve this with journaling - they write a log of what they are about to do before they do it, so they can recover if something goes wrong mid-write. This is conceptually identical to write-ahead logging in databases, which means understanding file system journaling helps you in system design interviews when discussing database reliability.
Module 09 covers file systems in detail, including inodes, allocation methods, journaling, and the Unix philosophy that "everything is a file."
Job 4: I/O Management
Interactive animation: The speed gap the OS has to hide: CPU operations against disk reads and cross-country network round trips.
I/O stands for Input/Output - any communication between your program and the outside world. Reading from a disk, sending data over the network, receiving keyboard input, displaying something on screen - all of these are I/O operations.
I/O is fundamentally slow compared to computation. A CPU can perform billions of operations per second. A disk read takes milliseconds - a million times slower. A network round-trip across the country takes tens of milliseconds. The OS needs to manage this speed mismatch so that the CPU does not waste time waiting for slow I/O operations to complete.
The OS handles I/O management by providing a uniform interface to diverse hardware (your program calls read() the same way whether it is reading from a hard drive, an SSD, or a network socket), buffering data to smooth out speed differences between the CPU and the device, scheduling I/O operations to maximize throughput and minimize latency, and supporting different I/O models - blocking (wait for the operation to finish), non-blocking (check back later), and multiplexed (watch many operations at once).
The I/O model you choose has enormous consequences for system performance. A blocking model is simple but limits concurrency. A non-blocking model with I/O multiplexing is complex but can handle tens of thousands of concurrent connections on a single thread. This is the foundation of how Nginx, Redis, and Node.js achieve high performance, and it comes up regularly in system design interviews.
Module 10 covers I/O in depth, including the difference between blocking and non-blocking I/O, I/O multiplexing with epoll, DMA (Direct Memory Access), and zero-copy I/O.
Job 5: Security and Protection
Interactive animation: A system call carries your program from user mode into kernel mode and back, with the kernel doing the work.
The OS is the enforcer. It makes sure that no process can access memory that does not belong to it, users can only read, write, or execute files they have permission for, programs running in "user mode" cannot directly access hardware or kernel data structures, and one crashing program does not bring down the entire system.
Protection works at multiple levels. At the hardware level, the CPU supports two modes - user mode (where your programs run, with restricted access) and kernel mode (where the OS runs, with full hardware access). When your program needs to do something that requires hardware access - like reading a file or creating a new process - it makes a system call, which triggers a controlled switch from user mode to kernel mode. The OS performs the operation on the program's behalf and then returns to user mode.
At the memory level, virtual memory provides process isolation - each process has its own address space and cannot see or modify other processes' memory. At the file level, permissions (read, write, execute for owner, group, and others) control who can access what. At the process level, the OS can terminate any process that violates its boundaries.
This layered protection model is what makes modern computers stable. You can run untrusted code (a downloaded program, a JavaScript snippet in your browser) with reasonable confidence that it cannot take over your machine, because the OS enforces boundaries at every level.
Module 12 covers security and protection, including access control, process isolation, and how the OS defends against attacks like buffer overflows.
How These Five Jobs Work Together
The five jobs are not independent - they interact constantly. Consider what happens when you open a file in a text editor:
sequenceDiagram
participant App as Text Editor (Process)
participant OS as Operating System
participant MM as Memory Manager
participant FS as File System
participant IO as I/O Manager
participant Disk as Disk Hardware
App->>OS: open("/home/user/notes.txt")
OS->>FS: Look up file in directory tree
FS->>FS: Find inode for notes.txt
FS-->>OS: File found, inode returned
OS->>App: File descriptor (e.g., fd = 3)
App->>OS: read(fd, buffer, 4096)
OS->>FS: Which disk blocks hold this data?
FS-->>OS: Block numbers [1042, 1043]
OS->>MM: Is this data already in page cache?
alt Cache Hit
MM-->>OS: Yes, data is in RAM
OS-->>App: Data copied to buffer
else Cache Miss
MM-->>OS: No, need to read from disk
OS->>IO: Read blocks 1042-1043
IO->>Disk: Read request
Disk-->>IO: Raw data
IO-->>OS: Data received
OS->>MM: Store in page cache
MM-->>OS: Stored
OS-->>App: Data copied to buffer
end
This sequence diagram shows what happens when a text editor opens and reads a file. The text editor asks the OS to open a file. The OS uses the file system to find the file's inode. The OS returns a file descriptor. When the editor reads the file, the OS checks the file system for which disk blocks to read, then checks the memory manager's page cache. If the data is already cached in RAM, it is returned immediately. If not, the I/O manager reads from the physical disk, stores the result in the page cache, and then returns the data to the application.
In this single operation - opening and reading a file - four of the five OS jobs are involved. Process management created and scheduled the text editor process. The file system found the file and mapped it to disk blocks. Memory management checked whether the data was already cached in RAM. I/O management handled the actual disk read if the cache missed. And the entire operation happened within the security boundary of the user's permissions - the text editor could only read files the user has access to.
This interconnection is why understanding the OS as a whole system is valuable, not just knowing isolated facts about scheduling or paging. In an interview, the strongest answers connect multiple OS concepts together to explain how a real system works.
Interview: A common interview question and how OS knowledge structures the answer:
Q: "What happens when you type
lsin a terminal?"A complete answer touches all five OS jobs:
- Process Management: The shell process calls
fork()to create a child process, thenexec()to replace the child's code with thelsprogram.- Memory Management: The OS allocates memory for the new process - space for the
lscode, its stack, and its heap. Virtual memory maps this to physical RAM.- File System:
lsreads the current directory's contents by opening the directory file and reading its entries (name-to-inode mappings).- I/O Management: The directory data may come from the page cache (fast) or from disk (slow). The output of
lsis written to the terminal, which is another I/O operation.- Security: The OS checks that the user running
lshas read permission on the directory. If not,lsreturns "Permission denied."This kind of layered, systematic answer demonstrates depth that interviewers reward.
The OS as a Layer: Where It Sits in the Stack
One more mental model that helps: the operating system is a layer in the computing stack. Understanding where it sits relative to other layers helps you know which questions are OS questions and which are not.
graph TD
subgraph STACK["The Computing Stack"]
A["Your Application Code<br/>(Python, Java, Go)"] --> B["Libraries & Frameworks<br/>(Django, Spring, Express)"]
B --> C["System Libraries<br/>(glibc, libc)"]
C --> D["Operating System Kernel<br/>(Linux, Windows, macOS)"]
D --> E["Hardware<br/>(CPU, RAM, Disk, Network)"]
end
style D fill:#4338ca,color:#fff
This diagram shows the computing stack as five layers from top to bottom: your application code, libraries and frameworks, system libraries, the operating system kernel (highlighted), and hardware. Each layer depends on the one below it.
Your application code sits at the top. It calls libraries, which call system libraries, which make system calls to the OS kernel, which talks to the hardware. The OS is the layer that hides hardware complexity from everything above it.
When an interviewer asks "how does a hash map work?" - that is a data structures question, happening at the application layer. When they ask "how does your program allocate memory for that hash map?" - that is an OS question, because memory allocation is managed by the OS. When they ask "what happens when your hash map gets too big for RAM?" - that is also an OS question, because virtual memory and paging handle that scenario.
Knowing which layer a question targets helps you give answers at the right level of detail. If an interviewer asks an OS-level question and you answer at the application level, you have missed the point. This course gives you the vocabulary and mental models to answer at the right layer.
Exercise: Starter: Open the task manager or activity monitor on your computer. Count how many processes are running. Now think about your CPU - how many cores does it have? If you have 4 cores but 200 processes, how is the OS managing this? (Hint: the answer involves the OS's first job - process management.)
Intermediate: Pick one of the five OS jobs and think about how it applies to a web server handling HTTP requests. What role does process management play? What role does I/O management play? Write a paragraph for each.
Advanced: Consider a database like PostgreSQL. For each of the five OS jobs, identify one specific way PostgreSQL depends on or interacts with that OS component. For example, how does PostgreSQL use the file system? How does it use virtual memory?
Looking Ahead
Now that you understand what the OS does at a high level, the rest of this course teaches you how it does each of these five jobs - with the depth and specificity that interviews require.
The next topic in this module helps you plan your study. It lays out study paths based on your timeline and interview focus, so you can prioritize the modules that matter most for your specific situation.
After that, Module 01 begins with processes - the foundation that everything else builds on.