DBMS interview questions test whether you can store, query, and protect data under concurrency, not whether you memorized a glossary. Simplilearn-style banks, DataCamp guides, and course platforms keep ranking because candidates need layered difficulty: basics, SQL, transactions, indexing, and scenario debugging. This page gives concise answers you can say aloud, then covers OOPS interview questions and operating systems interview questions as separate H2 sections that often appear in the same screening loop for software roles.
This page was reviewed on September 30, 2026.
TL;DR
- Know definitions cold: DBMS vs database, keys, normalization, ACID, indexes, isolation.
- Practice explaining tradeoffs: normalization vs denormalization, SQL vs NoSQL, locking vs MVCC.
- Be ready to debug slow queries with indexes and join strategy, not buzzwords.
- OOPS and OS questions often share the same early technical screen; prep them together.
- Pair this bank with system design interview questions for senior rounds.
Basic DBMS interview questions
What is a DBMS?
A database management system is software that stores data, enforces structure and constraints, and provides safe concurrent access. A database is the organized data; the DBMS is the system managing it.
How is a DBMS different from a file system?
A DBMS adds schemas, query languages, transactions, indexing, access control, and recovery. A raw file system stores files but does not give you ACID transactions or declarative queries.
What is a schema?
A schema defines the structure of data: tables, columns, types, relationships, and constraints. Logical schema is what applications see; physical schema is how storage is laid out.
What are primary keys and foreign keys?
A primary key uniquely identifies a row. A foreign key references a primary key (or unique key) in another table to enforce relationships and referential integrity.
What is normalization? Name normal forms.
Normalization reduces redundancy and update anomalies by organizing attributes into related tables. Common forms:
| Form | Idea |
|---|---|
| 1NF | Atomic values, no repeating groups |
| 2NF | 1NF + no partial dependency on a composite key |
| 3NF | 2NF + no transitive dependency of non-key on non-key |
| BCNF | Stronger 3NF variant around determinants |
Denormalization can be valid for read performance when you accept controlled redundancy.
Explain ACID.
| Letter | Meaning |
|---|---|
| Atomicity | All-or-nothing transaction |
| Consistency | Constraints preserved after commit |
| Isolation | Concurrent transactions do not corrupt each other’s view beyond the isolation level |
| Durability | Committed data survives crashes |
SQL and query questions
INNER JOIN vs LEFT JOIN
INNER JOIN returns matching rows only. LEFT JOIN returns all left rows plus matches from the right, with NULLs where unmatched.
WHERE vs HAVING
WHERE filters rows before aggregation. HAVING filters groups after GROUP BY.
DELETE vs TRUNCATE vs DROP
DELETE removes rows and can be transactional with WHERE. TRUNCATE empties a table quickly (semantics vary by engine). DROP removes the table object itself.
What is an index?
An index is a data structure that speeds lookups at the cost of storage and slower writes. B-tree indexes are common for range queries; hash indexes suit equality in some engines.
Clustered vs non-clustered index
A clustered index defines the physical order of rows (one per table in many systems). Non-clustered indexes store keys pointing to row locations.
How would you speed up a slow join?
Check the plan, ensure join keys are indexed, reduce scanned rows early, avoid SELECT *, watch implicit conversions, and confirm statistics are fresh. Measure before and after.
Transactions, concurrency, and advanced DBMS topics
Isolation levels (conceptual)
Read uncommitted, read committed, repeatable read, and serializable trade consistency for throughput differently. Name the anomalies each level allows or prevents (dirty read, non-repeatable read, phantom).
What is a deadlock?
Two or more transactions wait on locks the others hold. Engines detect deadlocks and abort a victim. Prevention includes consistent lock ordering and shorter transactions.
What is MVCC?
Multi-version concurrency control keeps row versions so readers and writers overlap with less blocking. Used by systems such as PostgreSQL.
Sharding vs replication
Replication copies data for availability and read scale. Sharding partitions data across nodes for write/storage scale, with cross-shard complexity.
SQL vs NoSQL (when to choose)
Use relational systems when strong constraints, complex joins, and transactions dominate. Consider document/key-value/wide-column stores when access patterns are simple, horizontal scale is primary, or schemaless iteration matters. Many products use both.
Scenario prompts to rehearse
- Users report timeouts on a report query joining four tables. What do you inspect first?
- A payment update must not partially apply. How do transactions help?
- You need historical prices. Would you redesign schema or use slowly changing dimensions?
- Reads are fine; writes stall after adding five indexes. What is happening?
- You must enforce “each email unique.” Constraint or application check only?
OOPS interview questions
Object-oriented programming questions often appear beside DBMS screens for backend roles.
What are the four pillars?
Encapsulation, abstraction, inheritance, polymorphism. Define each with a one-line example from code you wrote.
Encapsulation vs abstraction
Encapsulation bundles state with methods and restricts direct access. Abstraction hides complexity behind a simpler interface. Related, not identical.
Inheritance vs composition
Inheritance models “is-a” and shares behavior via hierarchy. Composition models “has-a” and often yields more flexible designs. Prefer composition when reuse does not need subtype polymorphism.
Method overloading vs overriding
Overloading: same name, different parameters, resolved by signature (language rules vary). Overriding: subclass replaces superclass method for polymorphic dispatch.
Interface vs abstract class (typical distinction)
Interfaces define contracts; abstract classes can mix abstract and concrete behavior and state. Exact rules depend on the language (Java, C#, TypeScript differ).
SOLID in one breath each
- Single responsibility: one reason to change
- Open/closed: extend without rewriting core
- Liskov: subtypes must be usable where base types are
- Interface segregation: small focused interfaces
- Dependency inversion: depend on abstractions
Quick OOPS drills
| Prompt | Aim |
|---|---|
| Design a notification system | Polymorphism for channels |
| Why avoid deep inheritance trees | Fragility and coupling |
| Mutable vs immutable objects | Concurrency and reasoning |
| Equals/hash contract | Collections correctness |
Operating systems interview questions
OS questions check whether you understand processes, memory, and concurrency beneath your database and services.
Process vs thread
A process is an isolated execution environment with its own address space (typically). Threads share process memory and are lighter to create, which makes synchronization critical.
What is a context switch?
The OS saves one thread/process state and restores another so multiple tasks share a CPU. Too many switches waste time.
User space vs kernel space
User space runs applications with restricted privileges. Kernel space runs privileged OS code. System calls bridge them.
Virtual memory and paging
Virtual memory maps process addresses to physical frames, enabling isolation and larger address spaces. Paging faults occur when a needed page is not resident.
Mutex vs semaphore
A mutex is typically a lock owned by one thread for mutual exclusion. Semaphores can signal resource counts and more general waiting patterns. Misuse causes deadlocks or races.
CPU scheduling (high level)
Schedulers decide which ready thread runs. Goals include fairness, throughput, and latency. Know that priorities and I/O wait change behavior.
How does this connect to DBMS?
Databases rely on OS files, threads/processes, memory mapping, and disk I/O. Understanding locking and caches helps explain database performance beyond SQL text.
OS drills
- What happens when two threads increment a counter without synchronization?
- Why can too much paging destroy database performance?
- Difference between concurrency and parallelism?
- What is thrashing?
How to prep this bank in a week
| Day | Focus |
|---|---|
| 1 | Keys, normalization, ER basics |
| 2 | SQL joins, GROUP BY, indexes |
| 3 | Transactions and isolation |
| 4 | OOPS pillars + SOLID examples from your code |
| 5 | OS process/thread/memory |
| 6 | Mixed mock: 20 minutes DBMS + 20 OOPS/OS |
| 7 | Restate weak answers aloud in 60–90 seconds |
Also rehearse behavioral stories with behavioral interview questions so technical screens do not collapse when the panel asks about an outage you owned. Broader Q&A patterns sit in interview questions and answers.
Spoken answer length
Aim for 45–90 seconds per definition question. Start with the one-sentence definition, add one example, then stop. Interviewers will probe. Over-answering on “What is a primary key?” signals anxiety more than mastery.
For scenario questions, structure with: symptom → hypotheses → checks → fix → prevention. That pattern mirrors how senior engineers debug production databases.
Linking OOPS and OS answers to database work
Interviewers like connective tissue. Examples:
- Encapsulation maps to hiding storage details behind repository interfaces.
- Inheritance mistakes map to fragile schema hierarchies.
- Threads and locks map to connection pools and transaction isolation.
- Virtual memory pressure maps to buffer pool and OS cache behavior.
One bridging sentence after a definition shows you build systems, not flashcards.
Practice set: 15 rapid-fire prompts
- Surrogate vs natural keys
- Covering index
- Write skew (conceptually)
- Hot partition in sharding
- ORM N+1 problem
- Idempotent writes
- Soft delete tradeoffs
- Read replica lag
- Checkpointing / WAL at a high level
- CAP in plain language
- Polymorphism example in API design
- Composition over inheritance example
- Race condition bug you fixed
- Page fault impact on latency
- Mutex misuse symptom
Answer each in under a minute, then expand only when asked.
Run it on Parlel
Map DBMS, OOPS, and OS prep to live backend or data roles so practice stays concrete.
target_roles: backend, data platform, fullstack
prep_blocks: dbms_30m, oops_20m, os_20m
artifacts: one_schema_design, one_incident_story
digest: new_roles_needing_sql_or_storage_depth
Digest shape: { role, company, sql_depth, systems_depth }. Find openings on /jobs and keep your profile searchable after /signup.
Keep reading
Frequently asked questions
How many DBMS interview questions should I memorize?
Memorize core definitions, then practice explaining tradeoffs and debugging scenarios. Pure memorization fails when the interviewer changes the schema mid-question.
Do startups ask DBMS theory?
Many ask practical SQL, indexing, and transaction safety. Theory still helps when they ask why a choice is safe under concurrency.
Are OOPS interview questions still relevant?
Yes for most object-oriented codebases. Even in multi-paradigm stacks, interviewers use OOPS prompts to test design clarity.
What OS topics appear most often for application engineers?
Processes vs threads, synchronization, virtual memory basics, and how blocking I/O affects latency. Deep kernel internals are rarer outside specialized roles.
Should I learn a specific database engine?
Pick one relational engine deeply (PostgreSQL or MySQL are common) and know how its indexes and transactions behave. Mention others only if you have used them.
How do DBMS questions differ from system design questions?
DBMS questions go deep on storage, queries, and transactions. System design questions zoom out to components, APIs, and scale. You need both for many mid/senior loops.