Computer Science Interview Question Bank: Project Deep-Dive Chains and Core-Course Follow-Ups

What this page helps you do first

• Follow-up depth expectations for data structures, OS, networks, and databases
• Project deep-dive chains: how interviewers unpack your project layer by layer
• CS-specific signals: coding ability, system reasoning, and verified enthusiasm

What makes CS interviews different: everything is verifiable

The defining property of CS interviews is **verifiability**: course questions have canonical answers, the project code actually exists, and algorithms can be written live. Two consequences: first, preparation has unusually high ROI — the knowledge is convergent and the question bank is stable; second, inflation carries unusual risk — any overstated layer collapses at the next question.

The strategy is therefore **convergent**: revise the four core courses by follow-up depth, re-walk your projects against the standard “every layer must survive drilling”, and leave the rest to delivery.

The four core courses: entry questions and expected depth

| Course | Frequent entry question | Expected depth | Drill directions | | :--- | :--- | :--- | :--- | | **Data structures** | Walk me through quicksort and its complexity. | Write-level: best/worst cases, why O(n log n) | Hash collision handling, B+ vs B trees, heap vs stack use cases | | **Operating systems** | Process vs thread? | Scenario-level: context-switch cost, when to prefer which | Deadlock conditions, virtual memory, page replacement, IO multiplexing | | **Networks** | What happens from typing a URL to rendering? | Full-chain: DNS→TCP→HTTP→rendering, any link can be probed | Why three-way and not two, TLS handshake, HTTP version deltas | | **Databases** | ACID? How do indexes work? | Engineering-level: which columns to index, when indexes fail | Isolation levels and phantom reads, MVCC, slow-query tuning |

> [!NOTE] > Revise by “entry question → follow-up tree”, not by textbook table of contents. Draw the follow-up tree for each entry question; the leaves you cannot answer are exactly your blind spots.

Project deep-dive chain: the interviewer’s unpacking path

The killer move of CS interviews is project drilling. The standard unpacking path has five layers:

1. **What**: what the project does and what problem it solves — many candidates fail to distinguish background from value at this layer; 2. **Why**: why this stack/architecture, which alternatives were rejected; 3. **How**: which parts you personally owned, key implementation details, the hardest technical problem; 4. **How deep**: what QPS? what data volume? why no other optimization at that scale? 5. **Boundaries**: what breaks first at 10× traffic? what would you redesign if starting over?

**Preparation**: write a five-layer answer sheet per project, investing mainly in layers three and four — their details are hard evidence of real involvement. If you cannot state your numbers (users, data volume, latency), the interviewer will assume the involvement is questionable.

Extra follow-ups for machine-learning projects

Candidates targeting AI/ML should expect drilling concentrated on experimental design:

1. **Data**: dataset size, train/validation/test split, leakage risks; 2. **Baselines**: compared against what, why that baseline, how much gain is significant; 3. **Ablations**: how much performance drops when a module is removed — failing the ablation question equals announcing the experiments were not yours; 4. **Deployment**: is it live? what latency? if not, how do you estimate the offline-to-production gap.

The shared logic: **separating “someone who ran a model” from “someone who designed an experiment”**. Advisors want the latter.

Coding verification beyond the machine test

Some interviews include live coding or oral algorithms. Oral algorithm questions test not recall but **narrating while writing**: state approach and complexity first, then edge cases, then start writing. Training: take 20 medium LeetCode problems and drill “3-minute explanation + whiteboard writing” — more effective than 200 problems without review.

Your GitHub may also come up. Be able to describe any public repo in one sentence; consider making stale experimental repos private to avoid wasted questioning.

Sprint checklist

• **Follow-up trees for the four courses**: five trees per course, all unanswerable leaves patched;
• **Five-layer answer sheets**: every project filled to layer five, with concrete numbers;
• **One closely read paper**: for AI tracks, a paper related to the target advisor — motivation, method, weaknesses;
• **Whiteboard practice**: 20 medium problems in “explain + write” mode;
• **English terms**: skim English terminology for core courses — the English round often tests term explanation.

Frequently asked questions

Which matters more, the machine test or the interview?

Weights vary by school, but the trend is rising interview weight, especially for academic master’s and direct-PhD slots. The machine test sets the floor (can you code); the interview sets the ceiling (does the advisor want you). For research-track slots the advisor’s interview verdict is often decisive. Strategy: drill machine-test problems to secure the floor, and prepare follow-up chains from this page to raise the ceiling.

What if my projects are only course-project level?

Course projects are not the sin — inflation is. Retell the course project in the grammar of a full project: how requirements drove the technical choices, the pitfalls hit, what would change at larger scale. Interviewers expect “course-level projects plus research potential” from undergraduates; an honest course project with clear reflection scores better than a vague “big project”.

How do I handle a course question I cannot answer?

CS questions reward reasoning. “I am not sure of the canonical answer, but based on principle X I would infer …” shows a reasoning path and beats silence. For genuinely unfamiliar territory, say “I have not systematically studied this”, then immediately demonstrate learning ability: “to pick it up quickly, I would start from X”. Avoid long silence or wild guessing.

Do recommendation interviews differ from re-examination interviews for CS?

The core question bank overlaps heavily; the emphasis differs. Recommendation interviews (summer camps, pre-announcement) weight research potential more — paper reading and research interest get more airtime. Re-examination interviews weight fundamentals more — deeper drilling on the four courses. The project deep-dive chain is identical for both; the five-layer unpacking in this page applies universally.

Where to go after this question bank

Question banks rehearse the follow-up chains; your own materials decide whether the answers hold. Use the thesis workflow to strengthen the draft behind your answers.