The four levels are read uncommitted, read committed, repeatable read and serializable, and they trade concurrency for the anomalies they allow: dirty reads, non repeatable reads, phantom reads and write skew. PostgreSQL defaults to read committed, where every statement sees a fresh snapshot; MySQL with InnoDB defaults to repeatable read, where the whole transaction sees one snapshot. Serializable is the only level that guarantees the result matches some serial order.
Why interviewers ask this
Concurrency bugs in backend systems are usually isolation bugs, and they only appear under load, which makes them expensive. The interviewer wants to know whether you understand what your database actually guarantees rather than assuming a transaction makes everything safe. Naming the default for your engine and describing a real anomaly, such as a balance check that passes twice, shows you have debugged this rather than memorized a table.
How to structure your answer
- List the levels alongside the anomaly each one removes.
- State the default for the database you actually use.
- Describe one concrete anomaly you have hit.
- Say how you would fix it: higher isolation or explicit locking.
Example answer
They go from read uncommitted up to serializable, and each step removes an anomaly at some cost in concurrency. Read committed stops dirty reads but every statement gets its own snapshot, so the same query twice in one transaction can return different rows. Repeatable read pins one snapshot for the whole transaction. Serializable additionally guarantees the outcome is equivalent to running transactions one after another, which in Postgres is done with predicate tracking, so instead of blocking it can abort a transaction and you have to be ready to retry. Defaults matter: Postgres is read committed, InnoDB is repeatable read, which surprises people moving between them. The bug I actually hit was write skew on a booking table, where two requests each checked that no overlapping reservation existed, both saw a clean snapshot, and both inserted. Repeatable read did not help because they wrote different rows. We fixed it with serializable plus a retry, and later with an exclusion constraint, which is cheaper.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What is write skew, and why does repeatable read allow it?
- How do you handle serialization failures in application code?
- When would you use select for update instead of raising the isolation level?
Related backend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions