Most people who put "SQL expert" on a CV are describing advanced skills — window functions, CTEs, clean multi-table joins. Genuine expert level is a different question: what a concurrent transaction touching the same row actually sees under a given isolation level, why an execution plan shows a full table scan despite an index existing, and what a foreign key cascade really does once it is triggered under load. Here is where the real line sits.
What "Expert" Actually Covers
A working, correct mental model of transaction isolation levels — READ UNCOMMITTED through SERIALIZABLE — and the specific read anomaly each one is designed to prevent, plus what a given engine actually defaults to (which is not the same across engines, and is worth checking rather than assuming).
Reading an actual execution plan (EXPLAIN, EXPLAIN ANALYZE, or the equivalent) to confirm whether an index is genuinely being used, rather than assuming it is because it exists on the column. Understanding locking behaviour — row-level versus table-level locks, and how MVCC lets readers avoid blocking writers in engines that implement it. Foreign key cascade behaviour (CASCADE, SET NULL, RESTRICT) and its blast radius under concurrent writes. Composite index column order and why it changes which queries an index can actually serve.
What Genuinely Still Trips Up Experts
- Assuming a query is safe under concurrency because it "looks" atomic, when in fact a read-then-update pattern without an explicit transaction and appropriate isolation level allows a lost update between two concurrent sessions
- Trusting that an index exists therefore it is used, instead of reading the execution plan and finding a full scan caused by a wrapped column, an implicit cast, or planner statistics that are simply out of date
- A CASCADE delete that looks scoped to one row in the statement but actually walks a deep foreign-key chain, taking far more locks than expected and stalling unrelated concurrent transactions
- Building a composite index in the wrong column order for the actual query patterns, so the index technically exists but cannot serve the filters being run against it
The pattern here is different from the earlier tiers: these are not wrong-row-count bugs caught by reading the query. They are correctness and performance problems that only appear under real concurrent load or real data volume — exactly why they sit at the expert tier rather than the advanced one.
What to Put on a CV at This Level
Name the specific components: "transaction isolation and concurrency reasoning, execution-plan-driven query tuning, index design, cascade/lock behaviour under load" is specific and checkable — it also tells an interviewer exactly what to probe, which is the honest version of an expert claim.
If the real experience stops at "I know CTEs and window functions" without having read an execution plan or reasoned about isolation levels, that is advanced, not expert — and the distinction matters, because the interview question at this tier is usually a scenario about two concurrent transactions, not a request to define ACID.
Where This Actually Stops
Past this point the work usually moves into database internals or platform-engineering territory proper — storage engine internals, replication topology design, query planner internals — a genuinely different job from application-facing SQL work, even expert application-facing SQL work.
The SQL Test is scenario-based across query fundamentals, joins, aggregation and correctness traps in 30 questions, which places its ceiling around the advanced tier rather than testing isolation levels or execution plans directly — a genuinely useful fundamentals check even for someone operating at expert level day to day. Pair it with the JavaScript Test for roles where the same person owns both the database layer and the application code issuing the queries.
A Note on Calling Yourself an Expert
Because "SQL expert" is such a common overstatement — often meaning "very comfortable writing queries" rather than "understands what the engine does with them" — some interviewers treat the bare claim as close to a neutral signal and reach straight for a concurrency scenario instead: what does this second transaction see while the first one is still open, why is this indexed query doing a full scan.
The upside runs the other way too. A candidate who says "solid with window functions and CTEs, still building depth on isolation levels and execution plans" reads as more credible than one who claims "SQL expert" and cannot explain what REPEATABLE READ actually guarantees when asked directly — and in a technical conversation, that kind of precision is usually what decides whether the interviewer trusts everything else the candidate said.