DBMS interview questions — the ones that separate "memorized the definition" from "used it"

DBMS is one of the most reliably asked subjects in an Indian campus placement or fresher technical round, and also one of the most reliably over-memorized. Candidates can recite normal forms and ACID properties in their sleep. What actually decides the round is whether they can apply either concept to a scenario they haven't seen written down before.

Normalization

What gets recited: 1NF, 2NF, 3NF, BCNF, each with a textbook definition about eliminating redundancy and dependency.

The follow-up that actually tests understanding: "Here's a table with student, course, and instructor columns, and an instructor teaches only one course. What normal form is this in, and what breaks if you don't normalize further?"

The honest answer isn't the definition — it's the consequence. Un-normalized data means if an instructor's name is misspelled in one row and correct in nine others, you now have a data integrity problem with no single source of truth. Interviewers ask this because "normalize your database" is advice every fresher has heard and very few can justify in a specific case.

ACID properties

What gets recited: Atomicity, Consistency, Isolation, Durability — one sentence each.

The follow-up: "A bank transfer debits one account and credits another. Walk me through what Atomicity actually guarantees here, and what happens if the system crashes between the two operations."

This is the question that separates people who read the definition from people who understand why it exists. The real answer: atomicity guarantees the whole transaction happens or none of it does — if the system crashes after the debit but before the credit, the database rolls back to before the debit, not left in a half-completed state where money vanished.

Indexing

What gets recited: an index speeds up lookups, like an index in a book.

The follow-up: "If indexes make reads faster, why not index every column?"

The definition-only answer misses the trade-off entirely. Every index has to be updated on every insert and update, so more indexes mean slower writes and more storage — the real skill is deciding which columns are worth that cost, usually ones that show up in WHERE clauses often, not just any column that exists.

Joins

What gets recited: INNER JOIN returns matching rows, LEFT JOIN returns all rows from the left table plus matches, and so on.

The follow-up: "Given these two tables, write the query that finds customers who have never placed an order."

This is where memorized join syntax either turns into a working query or doesn't. The answer needs a LEFT JOIN from customers to orders, then a WHERE order_id IS NULL — a combination that isn't in the standard join definitions and has to be reasoned out, which is exactly why it's asked.

Transactions and concurrency

What gets recited: a transaction is a unit of work; concurrency control prevents conflicts between simultaneous transactions.

The follow-up: "Two users try to book the last seat on a flight at the same time. What stops both bookings from succeeding?"

The real answer touches locking or isolation levels — a row-level lock on the seat count, or a transaction isolation level that prevents a second read from seeing a stale count. Most freshers can name isolation levels; fewer can explain which one actually solves this specific race condition and why a lower one wouldn't.

The pattern across all five

Every one of these follow-ups takes a definition the candidate already knows and asks them to use it on a case they haven't memorized an answer for. That's not a harder version of the same question — it's testing a genuinely different skill, and it's the one that separates candidates who studied DBMS from candidates who understand it.

---

Prepair asks DBMS questions scoped to your actual level — fresher through experienced — and scores whether your answer used the concept or just defined it. Try a free interview — 3 a month, no signup required to start.