What CS Programs Stopped Teaching

Pull up the course catalog for any top-25 CS program. Compare the 2000 edition to the 2025 edition. Count the required systems courses. Count the required applications courses. The shift is dramatic and it happened gradually enough that nobody raised an alarm.

This section isn’t about nostalgia for some golden age of CS education. There wasn’t one. The 2000 curriculum had its own gaps — distributed systems were undertaught, security was barely mentioned, software engineering practices were often outdated. But the 2000 curriculum forced every graduate through a set of courses that built a mental model of how computers actually work. The 2025 curriculum makes that mental model optional.

The Shift in Requirements

Here’s a composite view based on published requirements from several major CS programs. This isn’t any single university — it’s the aggregate pattern.

Typical Required CS Courses, circa 2000:

Course	Status	Systems Knowledge
Intro to Programming (2 courses)	Required	Minimal
Data Structures & Algorithms (2 courses)	Required	Minimal
Computer Architecture/Organization	Required	Deep
Operating Systems	Required	Deep
Compilers / Language Theory	Required	Deep
Computer Networks	Required	Deep
Software Engineering	Required	Minimal
Discrete Math / Theory of Computation	Required	Moderate
Database Systems	Required	Moderate

Typical Required CS Courses, circa 2025:

Course	Status	Systems Knowledge
Intro to Programming (2 courses)	Required	Minimal
Data Structures & Algorithms (2 courses)	Required	Minimal
Computer Systems (survey)	Required	Moderate
Machine Learning / AI	Required	Minimal
Software Development / Engineering	Required	Minimal
Ethics in Computing	Required	None
Discrete Math / Theory of Computation	Required	Moderate
Capstone Project	Required	Varies

Moved to Elective:

Course	2000	2025
Operating Systems (deep)	Required	Elective
Compilers	Required	Elective
Computer Networks	Required	Elective
Computer Architecture (deep)	Required	Elective
Database Internals	Required	Elective

The deep systems courses didn’t disappear. They became optional. And when a demanding course is optional and competes with an ML elective that aligns with industry hiring trends, the enrollment numbers tell the story.

At one large state university, Operating Systems enrollment dropped 40% between 2015 and 2023 while Machine Learning enrollment tripled. The courses didn’t change — the students’ choices did, responding rationally to market signals.

What Was Added

The additions to the curriculum are defensible individually:

Machine Learning and AI — the industry’s most active research and employment area. Every company wants ML engineers. Every student wants ML skills. Universities that don’t require ML coursework look outdated.

Mobile and Web Development — practical skills with immediate employability value. Students can build portfolio projects. Employers can hire graduates who contribute on day one.

Cloud Computing — understanding AWS, containerization, and distributed deployment. Practical and relevant to modern engineering roles.

Ethics in Computing — genuinely important in an era where software systems affect billions of people. This is not a frivolous addition.

Human-Computer Interaction — design thinking and user-centered development. Important for building software that people actually use.

Each of these courses fills a real need. The problem isn’t what was added. The problem is what was removed to make room, because a four-year degree has a fixed number of credit hours and students have a finite appetite for coursework.

The “Career-Ready” Pressure

Universities operate in a competitive market. They compete for students, and students choose programs based on outcomes — primarily job placement rates and starting salaries. Accreditation bodies like ABET set minimum standards, but those standards have loosened around systems requirements over the past two decades, reflecting industry input.

The feedback loop is direct. Companies tell career services offices what skills they want. Career services tells the department. The department adjusts its curriculum to improve placement metrics. Companies hire the graduates and report back that they want more of the same.

What companies ask for: React, Python, cloud, ML, agile methodology, soft skills.

What companies don’t ask for in entry-level job descriptions: virtual memory management, network protocol implementation, compiler construction, hardware-software interface design.

The curriculum follows the job descriptions. The job descriptions reflect what companies think they need today. Nobody in this chain is asking what companies will need when their systems fail in ways that React knowledge can’t diagnose.

This is a classic principal-agent problem. The entity optimizing the curriculum (the university) is optimizing for a measurable proxy (job placement) rather than the actual goal (engineering competence across the full abstraction stack). The proxy and the goal overlap significantly for the first five years of an engineer’s career. They diverge dramatically thereafter.

What Systems Courses Teach That Nothing Else Does

The specific concepts that live exclusively in systems courses — Operating Systems, Computer Architecture, Compilers, Networks — don’t appear anywhere else in a typical curriculum. When these courses become elective, the concepts become optional. And some of these concepts are load-bearing in production.

Memory Models

Operating Systems teaches how virtual memory works: page tables, TLB caches, demand paging, copy-on-write, memory-mapped files. This is the foundation for understanding:

• Why a Python process that allocates 8GB of RAM doesn’t crash on a machine with 4GB of physical memory (until it touches all the pages)
• Why forking a process doesn’t double memory usage (copy-on-write)
• Why container memory limits trigger OOM kills that application code can’t catch
• Why mmap can make file reads faster than read() for certain access patterns

Without this course, an engineer’s mental model of memory is “the computer has RAM, my program uses some of it.” That model works until it doesn’t, and when it doesn’t, the failure mode is invisible to anyone who thinks memory is just a big array.

Concurrency at the Hardware Level

Computer Architecture teaches what happens when two CPU cores access the same memory location. Cache coherence protocols (MESI, MOESI), memory barriers, store buffers, and instruction reordering. This is why:

• A volatile variable in Java has performance implications — it forces memory visibility across cores
• Lock-free data structures are hard — they require understanding the CPU’s memory ordering guarantees
• Race conditions can produce results that no sequential execution of the code could produce — because the hardware reorders operations in ways the source code doesn’t reveal

Without this knowledge, concurrency bugs are black magic. With it, they’re predictable consequences of a specific hardware architecture.

Protocol Design

Networking courses teach how protocols are designed, layered, and negotiated. TCP’s three-way handshake, congestion control algorithms, flow control with sliding windows, the DNS resolution chain, TLS negotiation. This is why:

• Connection establishment has latency — three round trips for TCP + TLS before the first byte of data
• “The network is slow” can mean a dozen different things: congestion, packet loss, retransmission, DNS delay, TLS renegotiation, small TCP windows
• HTTP/2 multiplexing solves head-of-line blocking at the HTTP layer but not at the TCP layer — which is why HTTP/3 uses QUIC over UDP
• Load balancers that terminate TLS on behalf of your application aren’t just a “deployment thing” — they change the security and performance characteristics of every connection

Compilation and Interpretation

Compiler courses teach parsing, type checking, optimization, and code generation. This is why:

• Regular expressions have performance characteristics that depend on the regex engine’s implementation (backtracking vs. DFA)
• JIT compilation makes “interpreted languages are slow” a misleading statement — the JVM and V8 compile hot paths to native code
• “Undefined behavior” in C isn’t just a theoretical concern — the compiler assumes it doesn’t happen and optimizes based on that assumption, producing binaries that do unexpected things when it does happen

The Concepts Working Engineers Lack

Survey any team of engineers with 2-5 years of experience. Ask them to explain the following:

Virtual memory: How does the OS present more memory than physically exists? What’s a page fault? When does the OOM killer activate? Most will know the term. Few can trace the mechanism from page table miss to disk read to page fault handler.

Process scheduling: How does the OS decide which process runs next? What’s the difference between preemptive and cooperative multitasking? Why does a CPU-bound process affect the responsiveness of an I/O-bound process on a single-core machine? Most will say “the OS handles it.” The details have been abstracted away.

Network protocol internals: What happens between “the browser sends a request” and “the server receives it”? DNS resolution, TCP handshake, TLS negotiation, HTTP framing, potential proxy traversal. Most can name DNS and TCP. Few can explain congestion control, why retransmission happens, or how flow control works.

File system internals: What happens when you call write()? The data goes to a kernel buffer, may or may not be written to disk depending on the filesystem’s journaling mode, and the fsync() call is needed to guarantee durability. This matters for databases, for log files, for any application that claims to have “saved” data.

These aren’t academic trivia questions. They’re the knowledge that separates an engineer who can build software from an engineer who can diagnose software. The former is a requirement. The latter is what production systems demand when things go wrong.

The Paradox

The skills most critical in production — understanding memory management, networking internals, process lifecycles, file system behavior — are the skills most commonly categorized as “elective” in the curriculum that produces the engineers who staff production systems.

The university’s goal is to prepare graduates for their first job. The industry needs engineers who can handle their fifth year. The curriculum optimizes for the one-year horizon. The gaps appear on the five-year horizon. And by then, the engineer has absorbed the culture’s attitude that systems knowledge is specialized, optional, someone else’s problem.

This isn’t an unsolvable problem. It’s a misaligned incentive problem. Universities, employers, and engineers each need to adjust. Universities need to make at least one deep systems course required — not as nostalgia, but because the knowledge is load-bearing. Employers need to signal that systems knowledge matters in hiring, not just in incident response. Engineers need to pursue the knowledge that their formal education didn’t provide, not because anyone requires it, but because the systems they build on demand it.

The curriculum will adapt when the signals change. Right now, the signals say “ship fast.” They need to also say “understand deeply.”