Welcome to the Course

Two candidates sit down for the same interview. Both can recite that ACID stands for Atomicity, Consistency, Isolation, Durability. The interviewer nods, then asks a follow-up: "A user transfers $100 from savings to checking, but the server crashes halfway through. What protects them from losing the money?"

The first candidate repeats the definition again. The second one says: "That's atomicity — the transfer is one transaction, so either both the debit and the credit happen, or neither does. On crash, the database rolls the half-done work back as if it never started." Same four letters memorized. Completely different outcome. The second candidate reasoned about a real failure, and that is exactly what this course trains you to do.

The big promise of this course

Here is the promise in one sentence: by the end, you'll be able to explain core CS concepts like an engineer, not like a textbook. That distinction is the whole game, so let's make it concrete.

A textbook answer is a definition recited from memory. It's accurate, it's flat, and it's forgettable. An engineer's answer starts from a situation — a slow query, a deadlocked process, a dropped network packet — and walks through why the concept matters there. Interviewers can tell the difference in about ten seconds, because the engineer's answer comes with examples and trade-offs attached.

Consider a single concept, an index in a database, explained two ways:

• Textbook: "An index is a data structure that improves the speed of data retrieval operations on a database table."
• Engineer: "Think of the index at the back of a book. Without it, finding 'recursion' means flipping every page — that's a full table scan. With it, you jump straight to page 212. A database index does the same for a column you search often, like email. The trade-off is that every write has to update the index too, so you don't index everything blindly."

Both are correct. Only the second one shows the interviewer that you'd make a good engineering decision. Every lesson in this course is built to push you toward that second style — example first, then the concept, then the trade-off.

The five pillars

This course is organized around five pillars of computer science that product companies test again and again. They aren't random topics — each one answers a different question an engineer faces every day.

Let's walk through each pillar and the everyday question it answers:

• OOP (Object-Oriented Programming) — How do I structure code so a team can grow it without it collapsing? Classes, objects, encapsulation, inheritance, and polymorphism are the grammar of large codebases. Interviewers ask you to model a parking lot, a deck of cards, or a ride-share app.
• DBMS (Database Management Systems) — How do I store data so it stays correct even when things go wrong? Transactions, ACID, normalization, indexing, and concurrency live here. This is where the bank-transfer story comes from.
• SQL — How do I ask the database precise questions and get fast answers? Joins, aggregations, subqueries, and window functions. Many companies run an entire dedicated SQL round, so we treat it as exam-worthy.
• OS (Operating Systems) — What is my program actually doing on the machine? Processes vs. threads, memory, scheduling, deadlocks, and concurrency. This explains why your code is slow or why two threads corrupt the same variable.
• Networks — How do two computers talk? TCP vs. UDP, HTTP, DNS, and what really happens when you type a URL. Every web request you've ever made rides on these ideas.

Notice the shape of the diagram: the pillars hold up the offer, and the roof falls if any single pillar is missing. You don't need to be world-class in all five on day one — but you can't have a hole where one should be. We'll fill each one in, in order.

Theory vs. practice

The single biggest upgrade you can make to your prep is to stop collecting definitions and start collecting scenarios. A definition is something you recite; a scenario is something you reason through. Interviews are almost entirely the second kind.

Let's see the gap with the ACID example from the intro, made fully concrete. Here is the kind of database operation the theory is really about:

-- A money transfer is a single transaction: both steps, or neither.
BEGIN TRANSACTION;

UPDATE accounts
SET    balance = balance - 100
WHERE  id = 'savings';

UPDATE accounts
SET    balance = balance + 100
WHERE  id = 'checking';

COMMIT;   -- if the server crashes before this line, the database
          -- ROLLs BACK the first UPDATE — the $100 is never lost.

A theoretical answer stops at "A stands for atomicity." A practical answer points at the COMMIT line and explains that everything between BEGIN and COMMIT is all-or-nothing. The same applies in code. Here's a tiny Python sketch of the same idea — a transaction that must not leave the system half-updated:

def transfer(db, from_id, to_id, amount):
    try:
        db.begin()
        db.debit(from_id, amount)     # step 1
        db.credit(to_id, amount)      # step 2
        db.commit()                   # both steps land together
    except Exception:
        db.rollback()                 # crash here? undo step 1
        raise

When you can show where a concept lives in real code or a real query, you've crossed from theory into practice. That's the level every lesson here aims to leave you at. We'll keep definitions short and spend our time on the "why" and the "what happens when it breaks."

Where these get tested

It helps to see when in the hiring process your fundamentals actually come under the microscope. Most product-company pipelines look like a funnel: a wide top of applicants narrowing down to a single offer, with a clearly defined stage where CS fundamentals decide who advances.

Your résumé and the recruiter screen get you in the door, but it's the technical rounds — highlighted above — where OOP, DBMS, SQL, OS, and Networks separate the offers from the rejections. Some companies even break these out into dedicated rounds: a stand-alone SQL round, an OS/DBMS rapid-fire, or an "explain this concept" screen. The next lesson digs into exactly how those rounds are structured, but for now the takeaway is simple: the fundamentals you build here are the gate you must pass to get an offer.

How to use this course

Good intentions don't finish courses; a good system does. Here's how to get the most out of this one.

• Go in order, at least the first time. The recommended path is OOP → DBMS → SQL → OS → Networks, then a crash-course revision. OOP comes first because it's the gentlest on-ramp and later examples lean on it.
• Study the diagrams — then redraw them. Each lesson ships hand-built visuals like the two above. Re-drawing a diagram from memory beats re-reading the text three times, because it forces you to reconstruct the logic.
• Don't skip the "boring" foundations. Normalization, processes vs. threads, and joins feel dry until they're the exact question between you and an offer. Boring is often where the fastest wins hide.
• Use the quizzes and mark lessons complete. The button at the bottom of each lesson tracks your progress in the sidebar, and the quizzes catch gaps before they cost you in a real interview.

Further reading

• Teach Yourself CS — a respected guide to the core CS subjects and the best books for each.
• Coding Interview University — a popular open study plan covering the same fundamentals.