SQL interview questions: the 10 that keep appearing.
SQL is the quiet constant of developer interviews: frameworks churn yearly, but the database round has asked roughly the same things for a decade - because the data layer is where mistakes cost real money. Here are the ten that dominate junior and early-mid rounds, the live exercises behind them, and the AI-verification question that now joins them.
Plenty of interview topics died when AI made their content cheap. SQL did the opposite, for a reason worth internalising before the questions: the database is where software mistakes become permanent. A bad component re-renders; a bad query deletes the wrong rows. As AI began generating most day-to-day queries, employers discovered they needed people who could verifydata code more than people who could type it - and verification demands exactly the relational fundamentals below. So the SQL round quietly became a judgement screen wearing a syntax screen’s clothes, the same shift running through every 2026 round (the full interview guide maps it). Answer accordingly: definitions fast, reasoning aloud, and the verification mindset visible throughout.
The ten questions
1. What is the difference between SQL and NoSQL databases, and when would you choose each?
SQL (relational) databases store structured data in tables with enforced relationships and support powerful querying across them; NoSQL covers several families (document, key-value, graph) that trade some of that structure for flexibility or scale in specific shapes. The 2026 answer interviewers want is unfashionably boring: default to a relational database (Postgres is the market standard) because most business data IS relational - users have orders, orders have items - and reach for NoSQL when you have a specific reason (flexible document shapes, extreme write scale, caching). "MongoDB because the tutorial used it" is the answer this question exists to catch.
2. Explain the different types of JOIN.
INNER JOIN returns only rows with matches in both tables; LEFT JOIN returns all rows from the left table with NULLs where the right has no match; RIGHT JOIN mirrors that; FULL OUTER returns everything from both sides. The live follow-up is almost guaranteed: "customers and orders - show me customers who have never ordered" (LEFT JOIN orders, WHERE orders.id IS NULL). Interviewers use joins as the core SQL screen because they test whether you think in relationships - and because AI-generated queries with subtly wrong join types are a real production bug class someone has to catch.
3. What is a primary key vs a foreign key?
A primary key uniquely identifies each row in a table (users.id); a foreign key is a column referencing another table’s primary key (orders.user_id → users.id), creating the relationship and letting the database enforce it - you cannot create an order for a user who does not exist. The depth signal: mention referential integrity and what enforcement buys you (the database refuses orphaned data even when application code has bugs). This question is fast, fundamental, and revealing: candidates who have only ever used an ORM sometimes cannot answer it, which tells the interviewer exactly what it sounds like.
4. Write a query with GROUP BY and explain when you need HAVING.
GROUP BY collapses rows sharing a value so aggregates run per group: SELECT customer_id, SUM(total) FROM orders GROUP BY customer_id. WHERE filters rows BEFORE grouping; HAVING filters groups AFTER aggregation - "customers who spent over RM 1,000" needs HAVING SUM(total) > 1000, because the sum does not exist until after grouping. This distinction is the single most common live SQL exercise in junior interviews: expect to type a variant of exactly this query, and narrate the WHERE-vs-HAVING reasoning as you do, because the reasoning is what is being graded.
classics.sql - the two live exercises to have ready
An index is a lookup structure the database maintains so it can find rows without scanning the whole table - like a book index versus reading every page. Queries filtering or joining on indexed columns get dramatically faster. The half candidates forget is the cost: every write must also update the indexes, and they consume storage - so you index the columns your queries actually filter/join on, not everything. Strong answer includes the diagnostic habit: "when a query is slow, I check whether it is using an index" - naming EXPLAIN earns immediate credit as evidence you have debugged real slowness.
6. What is a transaction, and why does it matter?
A transaction groups operations so they succeed or fail as one unit - the classic example is a transfer: debit one account, credit another; a crash between the two must not lose money, so both commit together or both roll back. Knowing the term ACID helps, but interviewers care more that you can name when YOU would need one: any multi-step write where partial completion corrupts data (bookings + payments, order + inventory decrement). It matters in the AI era for a specific reason worth saying aloud: AI-generated data code frequently omits transactions, and the person reviewing needs to know they are missing.
7. What is SQL injection, and how do you prevent it?
The classic attack: user input concatenated into a query string becomes part of the SQL itself ("...WHERE name = '" + input + "'" plus a malicious input equals a query you never wrote - reading or deleting anything). Prevention is parameterised queries/prepared statements - input travels as data, never as SQL text - which every modern library and ORM does by default. This is a hard-floor screening question: security-basics failures are instant red flags, so answer crisply and add the modern coda: "and I check AI-generated queries for it too, because concatenation still shows up in generated code."
8. Design the tables for a simple e-commerce app - walk me through it.
The most common junior schema-design exercise, and it is testing process as much as output. The expected shape: users, products, orders, and - the step that separates candidates - order_items joining orders to products with quantity and price-at-purchase, because an order contains many products and prices change over time. Narrate your reasoning: what is a table, what is a relationship, where do keys live, why store price on the order item (historical accuracy). Perfect normalisation is not the bar; visible relational thinking is. Practising this on your own project’s schema is the best preparation - and gives you a war story when asked.
9. Why is SELECT * discouraged in production code?
Three reasons that show working maturity: it fetches columns you do not need (wasted bandwidth and memory, and it can bypass index-only query plans), it makes code fragile to schema changes (a new large column silently fattens every response), and it hides intent - explicit columns document what the code actually uses. A small question, but interviewers like it because it separates people who have written queries in tutorials from people who have maintained them in systems. The one-line answer with all three reasons takes fifteen seconds and quietly scores.
10. The AI-era question: an AI wrote this query for you - how do you verify it before running it on production data?
The database version of the review round - and the highest-stakes one, because a wrong query can damage real data. The checklist to narrate: read it and explain what it does in plain words FIRST (especially any UPDATE/DELETE - check the WHERE clause twice; a missing WHERE is the classic catastrophe); run it against non-production data or wrap it in a transaction you can roll back; for SELECTs, sanity-check counts against expectations ("this should return roughly 200 rows, not 2 million"); and check join types and GROUP BY logic, where AI errors are subtle rather than loud. Close with the principle: "generated SQL is a draft - production data gets my review, not the model’s confidence."
Two weeks of preparation that covers all ten
SQL rewards short daily reps over cramming. Week one - query fluency:fifteen minutes daily against your own project’s database (that context beats abstract puzzles): day-by-day, run the never-ordered-customers join, the big-spenders aggregate, an index experiment (time a query, add an index, time it again - the before/after becomes an interview story), and one deliberate transaction. Week two - design and judgement:the ten-minute schema-sketch drill on apps you use daily, plus the AI-review drill from question 10 - generate queries, verify them aloud with the checklist. By the end you have covered every question on this page as practice rather than reading, and collected the personal war stories that make answers land. If the drills expose that the foundation itself is missing - you’ve never actually had a database of your own to practise against - that is the real gap, and it is exactly what building fixes: the free trial’s projects put a real database under your hands in week one, and the full data layer - Postgres via Supabase, auth, real schemas - is core curriculum in the AI-native developer path.
FAQ
How much SQL do I need for a junior developer interview?
The ten topics on this page are the working syllabus: SQL-vs-NoSQL judgement, joins (deeply - they are the core screen), keys and relationships, GROUP BY/HAVING, indexes and their cost, transactions, injection prevention, basic schema design, query hygiene, and AI-query review. What is generally NOT junior material: window functions, query-planner internals, replication, and exotic optimisation - nice bonuses, wrong priorities. If you can design a small schema aloud and type a join-plus-aggregate query while narrating, you clear the bar at most Malaysian and remote junior rounds.
Do I still need SQL if I use an ORM or Supabase?
Yes - arguably more. ORMs and platforms like Supabase generate SQL for you, which moves your job up one level: knowing whether what they generate is right, and dropping to raw SQL when the abstraction runs out (complex reports, performance debugging). Interviewers ask ORM users exactly these questions to check the foundation exists under the convenience. It is the same pattern as AI assistance everywhere: the tool produces, you verify - and verification requires understanding the layer below. A candidate who says "the ORM handles it" to a join question has answered a different question than the one asked.
How do I practise SQL for interviews without a job?
Use your own project’s database as the gym - it beats abstract puzzle sites because the data means something to you. Drill the canonical patterns against it: customers who never ordered (LEFT JOIN + NULL), top spenders (GROUP BY + HAVING), monthly totals (aggregates + date functions). Then do the schema-design drill: pick any app you use (Grab, Shopee, a clinic) and sketch its tables aloud in ten minutes. Finally, practise the AI-review drill: have an assistant generate queries against your schema and verify them with question 10’s checklist. Fifteen minutes daily for two weeks covers this entire page.
Which database should I learn first?
PostgreSQL - the answer has become boring because the market decided. It is the default of the modern stack (and of platforms like Supabase built on it), it is what most Malaysian and remote job listings mean when they say SQL, and everything you learn transfers to MySQL and others with minor dialect differences. Our own curriculum teaches Postgres via Supabase for exactly this reason: one database, deeply, with real projects on top - which happens to be the same preparation this page’s questions assume.
The database round is a judgement screen. Judgement comes from having a database of your own.
Real schemas, real queries, real mistakes safely made - the free trial puts a database under your hands in week one, with a live instructor session. One signup, no card.
