CrackingTheSQLInterview: a single-file SQL interview guide organised as 115 question banks

One README, ten sections, and a numbering scheme that lets you jump

CrackingTheSQLInterview is unusually simple in shape. The repository's top level holds a LICENSE and a README.md, and nothing else. There is no code, no schema, no test harness and no build configuration. The whole artefact is the document.

The document is titled The Absolute SQL Interview Guide, and its stated ambition is to be the only SQL resource you need, whether you are preparing for a first data analyst role or for a senior backend engineering position at a FAANG company. It says it goes beyond surface-level definitions and that you will find ASCII diagrams, real-world analogies, production-grade best practices, and 115 battle-tested Q&As.

The organisation is what makes it usable rather than merely long. Ten sections run from SQL fundamentals through to database design and normalisation, and each section that carries questions ends with a numbered bank: Section 1 covers questions 1 to 10, Section 2 covers 11 to 42, Section 3 covers 43 to 54, Section 4 covers 55 to 60, Section 5 covers 61 to 91, Section 6 covers 92 to 96 together with 115, Section 7 covers 97 to 104, and Section 8 covers 105 to 114.

That numbering is the interesting design decision. Because every question has a stable number, a candidate can be told 'question 47' in an interview and go straight to it, and a reader who wants only the advanced parts can skip the banks. It also lets the section 6 bank hold question 115 alongside 92 to 96, since that section covers indexes, privileges and security together.

Two sections carry no question bank at all: Section 9 on query optimization and execution plans, and Section 10 on database design and normalisation. Those two are structured as reference sections, with reading EXPLAIN output and the ten query performance killers, and the normal forms from 1NF through BCNF with examples plus a section on when to denormalise.

ASCII diagrams and analogies as the teaching method

The guide's stated method is visual learning with analogies, and the README is explicit about the difference from a conventional reference. Every JOIN, index and transaction is explained with ASCII art, and complex concepts are explained using everyday things such as libraries, bank transfers and Venn diagrams.

The restaurant analogy for declarative SQL is the clearest example. The guide describes SQL as a declarative language where you describe what you want and the engine works out how, then contrasts it with an imperative loop, the point being that you do not say go to the fridge, take out the meat and heat the pan, you say what you want. That analogy does a lot of work in one paragraph because it explains the entire impedance mismatch between SQL and the imperative languages most people arrive from.

The diagrams are drawn as boxed ASCII art with a header row, and the SQL command families get the same treatment: a table with one row per family, the DDL row listing CREATE, ALTER, DROP, TRUNCATE and RENAME, DML listing INSERT, UPDATE and DELETE, DQL listing SELECT, DCL listing GRANT and REVOKE, and a plain-language gloss for each. The office analogy carries the same load, with people who build the office, people who work in it, people who ask questions, security guards and managers who approve or cancel decisions.

Why this matters for an interview guide is a question about how people actually revise. Most SQL reference writing is organised by feature, so a candidate preparing for a specific question has to reconstruct the topic from a chapter. Diagrams and analogies give you a retrievable image instead: when someone asks about isolation levels in the interview, you can picture the bank transfer, and when they ask about indexes, you can picture the library catalogue.

The trade-off is that it is a reading format, not a practice format. Diagrams are excellent for building a mental model and useless for checking whether you can write the query, and the repository offers nothing to run.

MySQL and PostgreSQL as the baseline, with the other vendors tabulated

The guide makes a dialect assumption up front, and it is a good one for the stated audience. Examples use MySQL and PostgreSQL syntax unless noted, and differences between MySQL, PostgreSQL, SQL Server and Oracle are highlighted where relevant.

The comparison table it opens with is the kind of detail that saves an interview. It lines up four features across the four major engines. For limiting rows it shows LIMIT 10 for MySQL and PostgreSQL, TOP 10 for SQL Server, and FETCH FIRST 10 for Oracle. For booleans it shows TINYINT(1), BOOLEAN, BIT and NUMBER(1). For the current date it shows CURDATE(), CURRENT_DATE, GETDATE() and SYSDATE. For string concatenation it shows CONCAT(), the || operator for PostgreSQL and Oracle, and + for SQL Server.

Those four rows are where most interview candidates get caught, and they are all dialect questions rather than conceptual ones. A candidate who knows exactly what an inner join is and then writes LIMIT for a SQL Server interview has still lost the point.

The stated structure also tells you the level the guide aims at. The advanced topics it names are window functions, CTEs, execution plans, query optimization and isolation levels with dirty-read examples, and the advanced list is placed alongside the visual learning and analogy approaches rather than replacing them. That combination is unusual: most writing that goes deep on execution plans stops drawing boxes, and most writing that draws boxes stays shallow.

The other dimension of the guide is breadth of topic rather than depth of any one. The table of contents runs from data types, filtering, pattern matching, sorting and pagination, aggregation and the GROUP BY engine, through subqueries, CTEs and window functions, into DDL and DML, constraints and integrity, then indexes and privileges, then transactions and ACID with the three read phenomena and locks and deadlocks, then views, stored procedures, triggers and cursors, and finally optimization and normalisation.

So the scope is the full breadth of a general relational database interview, not a speciality. The questions that actually distinguish candidates, the ones on isolation levels and query plans, are in the same guide as the ones on data types.

The three read phenomena and the bank transfer, which is where interviews turn

Two sections carry the weight that distinguishes a database interview from a SQL syntax interview, and they are adjacent by design.

Section 7 is transactions, ACID and concurrency. It opens with the bank transfer analogy, which is the standard way of making ACID concrete, then covers the ACID properties, the isolation levels with the three read phenomena, and locks and deadlocks. The section's question bank runs from 97 to 104, which is eight questions on concurrency in a 115-question document, and question 115 sits back in the security section, which suggests the numbering is arranged so that the most contested topics are spread rather than concentrated at the end.

The three read phenomena named in the table of contents are dirty reads, non-repeatable reads and phantom reads, and the guide pairs the isolation levels with concrete examples of each rather than listing the levels abstractly. That is the right way round for an interview, because the question is rarely what is READ COMMITTED, it is what a session running at READ COMMITTED can observe about another session's uncommitted write, and an example settles that faster than a definition.

Locks and deadlocks are named separately from the isolation levels, which is the right split, because deadlock avoidance and detection is a separate mechanism from the isolation setting. A candidate who can describe lock granularity, the wait-for graph and the victim's rollback is showing they understand what happens when two sessions want the same rows in opposite orders, which is a systems question rather than a syntax one.

Section 9, the one without a question bank, is where the practical half of that knowledge lands. It covers reading EXPLAIN output and the ten query performance killers. An interview asking why a query is slow is really asking whether you can read a plan, so the pairing of the execution plan section with the concurrency section in the same guide is deliberate.

The audience claim in the README is that every question is something that has actually been asked in real interviews. That is a claim about the selection rather than about the answers, and it is the part worth testing against your own preparation. A guide of 115 questions is a good revision set; it is not a syllabus for the specific role you are applying to.

What you cannot do with it, and what to use it alongside

The honest limitations are structural, and they follow from the repository containing exactly two files.

There is no runnable code. Not one of the 115 answers comes with a schema to run it against, a seed script, or an expected output you can diff. A candidate preparing for a technical screen that involves writing SQL will find that this guide teaches the shape of the answer and not the mechanics of the keystroke, and no amount of reading substitutes for running queries against a real engine until the syntax is automatic.

There is also no engine to point it at. The guide is dialect-aware in the way described above, but it is not a substitute for a specific engine's documentation when you need to know precisely what a given database does. The README is upfront about the assumption, which is honest, but it also means the guide's answers are the intersection of several engines rather than the behaviour of yours.

The alternative worth naming is the vendor's own reference documentation, and the difference in approach is instructive. Vendor documentation is authoritative for its own engine, it is updated with the engine, and it is organised by feature and by version, which is exactly what makes it hard to revise from. An interview guide is organised by question, it is written to be read once through, and it is a snapshot that will age. Use the two for different jobs: the guide to establish the shape of each topic, the documentation to check the details you are about to assert out loud.

The usual third resource is practice against a real database, and the gap in this repository is exactly that. If you are preparing, the sequence that works is to read a section here, then type the queries yourself against whatever engine you will be interviewed on, because the dialect table in the guide is a list of differences to check, not a substitute for having the fingers on the keyboard.

The database design section in Section 10 is the part that ages best, incidentally, because normal forms and denormalisation trade-offs do not change between engine versions.

A document project, with a licence and a last commit date

On maintenance, the repository is not archived and the last push was on 2026-05-15, on the master branch. There are no GitHub releases, and the repository has no version tags to speak of, which is what you would expect from a single document rather than a package.

The licence is MIT, and the repository holds a LICENSE file beside the README. This review does not interpret licence terms, and for a document the practical point is simply that the text is reusable and attributable, so you can adapt it into your own preparation notes without asking.

The absence of a release history is a genuine limitation for a guide that is meant to be current. Because there are no tags, you cannot tell from the repository whether a given copy of the text reflects a later revision of the answer to question 40, and the fact that the last commit is from May 2026 means the content has not been reviewed against anything more recent than that.

The topics attached to the repository list database, interview, interview-preparation, interview-questions, mysql and sql, which tells you the intended use precisely: this is a candidate's revision set rather than a teaching resource for a course, and it assumes you already know enough SQL to have a career to prepare for.

The primary language is listed as unknown, which is a fair description of a README with ASCII diagrams and SQL fragments. There is no build, no test and no linting, so nothing in the repository can tell you that an example query is syntactically valid. That is a limitation of the format rather than a defect, but it is the reason to treat the queries as illustrations to be rewritten and verified rather than as code to be trusted.

My judgement is that this is a well-organised revision document with a real structural idea in it, the numbered question banks, and a teaching method that suits a reader who has to remember things under pressure. Used as a map of the territory, with a real database open beside it, it does the job its description claims. Used as the territory itself, it stops at the point where the interview starts asking you to write.

Editorial conclusion

CrackingTheSQLInterview fits a candidate who wants one self-contained document to revise SQL from, because the question banks are numbered and cross-referenced so a topic can be read in one sitting and the diagrams make the shape of a join or an isolation level visible without a database. It is the wrong choice if you want answers you can execute, since the repository holds prose and no query files, a schema, or a test harness, and it is the wrong choice if you need the authoritative behaviour of one engine, since the guide explicitly assumes MySQL and PostgreSQL syntax and only notes where the other vendors differ. Before you rely on it, check the numbering in the table of contents against the questions you are asked, and read the section on locking and deadlocks in full, since that is the part most likely to be tested as a systems question rather than a syntax one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. xoraus/CrackingTheSQLInterview on GitHub