How Product Companies Test CS Fundamentals

Aarav walked into his first on-site feeling great. He'd ground through hundreds of coding problems and could reverse a linked list in his sleep. Then the interviewer leaned back and asked, "What's the difference between a process and a thread, and when would you pick one over the other?" Silence. He knew the words but had never been asked to explain them out loud. He'd prepared for one kind of question and walked into another.

That gap is exactly what this lesson closes. Product companies don't only test whether you can code — they test whether you understand the machinery underneath: the operating system, the database, the network, and the design principles that hold real software together. This lesson maps out how that testing happens so nothing surprises you.

Freshers vs. experienced: two different exams

The single biggest factor shaping your interview is how much experience you have. The same company will interview a final-year student and a five-year engineer in noticeably different ways, even for the "same" topic.

For freshers and new grads, interviews lean heavily on definitions and theory. Because you have little production experience to draw on, interviewers check whether the foundations are solid. Expect questions like:

• "What is normalization in a database? Walk me through 1NF, 2NF, 3NF."
• "Explain deadlock and the four conditions required for it."
• "What happens, step by step, when you type a URL into a browser?"
• "Write a SQL query to find the second-highest salary."

Notice the pattern: these have knowable, teachable answers. That's good news. A fresher round rewards the candidate who studied the fundamentals carefully, and that is squarely what this course trains.

For experienced engineers, the emphasis shifts from "do you know it?" to "why did you choose it?" Interviewers assume you know the definitions and instead probe applied trade-offs:

• "You used a NoSQL store here — what did you give up by not using a relational database?"
• "This endpoint is slow. How would you decide between adding an index, a cache, or a read replica?"
• "You said you'd use threads — what concurrency bugs are you now responsible for?"

The fundamentals are still being tested; they're just wearing a costume. You can't reason about whether to add a database index unless you understand what an index is and how B-trees make lookups fast. So even the experienced-level "trade-off" questions sit on the same foundation freshers are quizzed on directly.

Where fundamentals sit vs. system design

Students often blur "CS fundamentals" and "system design" into one scary blob. They're related but distinct, and knowing the difference tells you what to study and when.

CS fundamentals is the vocabulary and mechanics of how computers and data work: processes vs. threads, how an index speeds a query, what a transaction guarantees, how TCP differs from UDP, the four pillars of OOP. These are mostly settled, well-defined concepts with correct answers.

System design is the open-ended craft of assembling those pieces into a working system: "Design a URL shortener," "Design Instagram's feed." There's rarely one right answer — it's about reasonable choices and clear reasoning.

The crucial insight: system design is fundamentals applied at scale. When you say "I'll put a cache in front of the database to reduce read load," every noun in that sentence — cache, database, read load — is a fundamentals concept. Weak fundamentals make system design impossible; strong fundamentals make it almost conversational.

The dedicated rounds you'll meet

Here's something many candidates don't realize until they're sitting in the chair: CS fundamentals frequently get their own entire round, separate from coding and design. Let's walk through where they show up.

The SQL round

Many companies — especially those built around data — run a separate SQL round where you write live queries against sample tables. You'll be asked to join tables, group and aggregate, filter with subqueries, and reason about results. A classic warm-up looks like this:

-- Find each department's average salary,
-- but only for departments with more than 5 people.
SELECT d.name AS department,
       AVG(e.salary) AS avg_salary,
       COUNT(*)      AS headcount
FROM employees AS e
JOIN departments AS d ON d.id = e.department_id
GROUP BY d.name
HAVING COUNT(*) > 5
ORDER BY avg_salary DESC;

If you've never practiced the difference between WHERE and HAVING, or when a JOIN drops rows, this round can quietly sink you. That's why we treat SQL as exam-worthy, not optional.

OS / DBMS rapid-fire

Some rounds fire short, factual questions in quick succession to gauge breadth: "What's a page fault?" "ACID — what does each letter mean?" "Difference between clustered and non-clustered indexes?" The goal isn't depth on any single item; it's confirming you have a working map of the territory. Crisp, confident one-liners win here.

"Explain this concept" screens

Increasingly common is the round where you explain a concept as if teaching it: "Explain how a hash map works to a junior developer." This tests genuine understanding — you can't bluff a clear explanation. If you can teach it simply, you truly know it.

Anatomy of a fundamentals question

Here's the secret that makes you look calm under pressure: most fundamentals questions follow the same four-beat rhythm. Once you recognize the rhythm, you can pace your own answer to match it.

1. Definition — "What is X?" The interviewer wants a crisp, correct one- or two-sentence answer.
2. Example — "Can you give an example?" Now you ground the definition in something concrete and real.
3. Trade-off — "When would you not use it?" This separates memorizers from understanders. Every real tool has costs.
4. Follow-up — "How does that interact with Y?" The interviewer pushes one layer deeper to find your edge.

Let's run the rhythm on a real question: "What is an index in a database?"

• Definition: "An index is a separate data structure — usually a B-tree — that lets the database find rows by a column's value without scanning the whole table."
• Example: "If I index the email column, then WHERE email = '[email protected]' jumps almost straight to the row instead of reading every row."
• Trade-off: "Indexes cost storage and slow down writes, because every INSERT, UPDATE, and DELETE must also update the index. So I wouldn't index a column that's rarely searched but constantly written."
• Follow-up: "A composite index on (last_name, first_name) helps queries that filter by last_name first, but not ones that filter by first_name alone — because of the left-to-right ordering rule."

See how the same knowledge powers all four beats? If you only memorized the definition, you'd stall at the trade-off. This course deliberately teaches every concept along this exact arc — definition, example, trade-off, follow-up — so your answers naturally land all four beats.

Further reading

• GeeksforGeeks — DBMS last-minute notes (quick fundamentals refresher)
• The System Design Primer — see how fundamentals scale up