SQL Interview Warm-Up ยท Support Edition

A real database running in your browser. Refresh your SQL before a technical support / analyst interview, no signup, nothing to install.
๐ŸŽฎ built by TechLexicon
๐Ÿš€ This is already a planned game inside TechLexicon (releasing after our public launch). I built this standalone version so you can start prepping for your interview right now, the in-app version will add leveled challenges, more databases, and rewards.
๐Ÿ’ก How to use this

๐Ÿ“ฆ The sample database

โ–ถ๏ธ Query playground

๐ŸŽฏ Level 1, core challenges

๐Ÿ”ฅ Level 2, advanced (window functions, multi-table joins)

Senior-level SQL. Great if your interview goes past the basics, window functions and 3-table joins are common differentiators.

๐Ÿ› ๏ธ Level 3, changing data (CREATE, ALTER, UPDATE)

Reading data is only half the job, sometimes you shape it. These modify the practice database, so hit โ†บ Reset database in the playground to restore the original data anytime.

๐ŸŽฎ In the TechLexicon app, these levels come with a built-in AI tutor (Lex), tap-to-build queries (no typing), streaks & rewards. This page is the warm-up, grab the full game โ†’

๐Ÿ’ฌ Conceptual questions they may ask out loud

These don't need a query. Practice explaining each in one or two clear sentences, or tap ๐ŸŽด Flashcards to quiz yourself one card at a time.

๐ŸŽค Interview tips (support-role SQL)

  • Think out loud. Support/analyst interviewers care how you reason, not just the final query.
  • Clarify the schema first. "Which table has the resolution timestamp? Can an account have zero tickets?", asking is a plus.
  • Know your JOIN types. INNER vs LEFT is the most common gotcha. "Find accounts with no tickets" = LEFT JOIN + IS NULL.
  • WHERE vs HAVING. WHERE filters rows before grouping; HAVING filters groups after.
  • Handle NULLs. Open tickets have resolved_at IS NULL, use IS NULL, never = NULL.
  • Start simple, then layer. Get a SELECT working, then add filters, joins, and aggregation step by step.
  • ๐ŸŽฏ Do a live mock interview too. This tool warms up the fundamentals, but nothing beats running through questions out loud with a friend or peer. Ask around, most people are glad to help.
๐Ÿงฐ Declaring variables (cross-engine note)

A variable is just a named box that holds a value so you can reuse it instead of re-typing the same number or text. Change it in one place, and every query that uses it updates.

Good to know: this playground runs SQLite, which has no variable syntax, so you can't run the examples below here. But the database you'll use on the job (SQL Server, MySQL, or PostgreSQL) each does it a little differently, and naming that difference in an interview shows real-world depth:

-- SQL Server (T-SQL)
DECLARE @min_tickets INT = 3;
SELECT account_id, COUNT(*) AS n
FROM tickets GROUP BY account_id
HAVING COUNT(*) > @min_tickets;

-- MySQL
SET @min_tickets = 3;
SELECT account_id, COUNT(*) AS n
FROM tickets GROUP BY account_id
HAVING COUNT(*) > @min_tickets;

-- PostgreSQL (inside a function/DO block, or the psql shell)
\set min_tickets 3
SELECT ... HAVING COUNT(*) > :min_tickets;

๐Ÿ’ก Say this in the interview: "SQLite doesn't support variables, but in T-SQL I'd DECLARE @var, in MySQL I'd use a SET @var session variable, and in Postgres a variable inside a function or a psql \set."

๐Ÿš€ Want to keep leveling up? TechLexicon turns tech, cloud, DevOps, databases & security into games instead of textbooks.
Download on the App Store GET IT ON Google Play