Rapid-Fire

The last ten minutes of an interview are usually short, sharp questions. No whiteboard, no thinking time.

Almost all of them come from six pairs of concepts that sound similar and aren't.

Why & what

Interviewers use pairs because a candidate who memorised definitions can recite both — but can't say what one word separates them.

Every pair below differs by a single idea. Learn that idea, and both halves come free.

How it works

Read each as difference first, then the pair.

1. Super key vs candidate key → the word is minimal. Both are unique; a candidate key has nothing spare. (roll_no, name) is a super key only.
2. 2NF vs 3NF → the word is what it depends on. 2NF: depends on part of the key. 3NF: depends on a non-key column.
3. DELETE vs TRUNCATE → the word is rollback. DELETE picks rows and can be rolled back; TRUNCATE removes all rows and is DDL.
4. WHERE vs HAVING → the word is when. WHERE runs before grouping, HAVING after.
5. Non-repeatable vs phantom read → the word is changed vs appeared. A row you read changed, versus a new row showing up.
6. Clustered vs non-clustered → the word is physical. Clustered sets the actual row order, so one per table.

Cover the right-hand side of the diagram and say the missing half of all six pairs out loud. If any one takes more than five seconds, that's the topic to reread tonight.

Notice: each pair differs by exactly one word — learn the word, not the pair.

Common confusion

The trap here isn't a concept — it's overconfidence in recognition. Reading "ah yes, WHERE and HAVING" feels like knowing it. Saying the difference out loud, cold, in eight seconds, is a different skill.

Test yourself by producing the answer, not recognising it.

Interview angle

Ten questions that cross module boundaries. If you can answer these, the course has done its job.

1. "What's the difference between a primary key and a unique constraint?" — Both enforce uniqueness; a primary key also forbids NULL, and there's only one per table.
2. "Why is a foreign key allowed to be NULL?" — It means "not linked to anything yet," which is a legitimate state. A primary key can never be NULL, because a row must be identifiable.
3. "Your query got slow after the table grew. What do you check?" — Whether it's doing a full scan, whether a useful index exists, and whether a function on the column is disabling one.
4. "Is a table in 3NF always in BCNF?" — No. Give the (student, subject, teacher) case where a non-key column decides another.
5. "How would you find rows in A with no match in B?" — LEFT JOIN, then WHERE b.column IS NULL.
6. "What happens if two users update the same row at the same time?" — Locking makes one wait. Without adequate isolation you get a lost update.
7. "Why does an interviewer care whether you'd denormalize?" — Because it tests whether you measure before optimising, rather than following rules blindly.
8. "What's the cost of adding an index?" — Slower writes and extra disk space, since every insert and update must maintain it.
9. "What does a view actually store?" — Nothing. It's a saved query that re-runs each time. A materialized view stores results and can go stale.
10. "Explain a database you've worked with." — Have one real example ready — even a college project. Say what the tables were, one design decision you made, and one thing you'd change now.

That last one is asked more often than any technical question in this list, and it's the one candidates prepare least.

Recap

Six pairs cover most rapid-fire questions, each separated by a single word — minimal, what-it-depends-on, rollback, when, changed-vs-appeared, and physical.