Ace Your SQL Interview, Part 1: The Foundations Every Developer Must Know
This is Part 1 of a 4-part SQL interview prep series. Whether you’re prepping for your first tech interview or brushing up before a senior role, this series breaks down the most commonly asked SQL questions with clear, practical answers.
System Design Refresher
Designing a Robust Distributed Logging System for Modern Applications
20 System Design Concepts Every Developer Should Know - Part - I
You’re sitting across from the interviewer. They smile and say, “So, tell me about SQL.”
This is where it all starts. The foundational questions might seem basic, but they trip up more candidates than you’d think. Getting these right with confidence sets the tone for the rest of your interview. Let’s make sure you nail them.
What Is SQL, Really?
SQL stands for Structured Query Language. It’s the standard language for talking to relational databases - asking them to store data, fetch it, update it, or remove it. If a database is a library, SQL is how you talk to the librarian.
The interviewer isn’t looking for a textbook recitation here. They want to know you understand that SQL is declarative - you tell the database what you want, not how to get it. That distinction matters, and mentioning it shows depth.
Follow-up they might ask: “What’s a database, then?”
A database is an organized collection of data stored and accessed electronically. Think of it as a structured filing cabinet that can hold millions of records and let you find exactly what you need in milliseconds.
The key word is organized - that’s what separates a database from a random pile of CSV files on someone’s desktop.
Keys: The Backbone of Relational Databases
If there’s one topic that comes up in every single SQL interview, it’s keys. Interviewers love them because they reveal whether you actually understand how relational databases maintain order and integrity.
Primary Keys
A primary key is a column (or combination of columns) that uniquely identifies each row in a table. No two rows can share the same primary key value, and it can never be NULL.
Think of it like a social security number for your data. Every row gets its own identity. If you try to insert a duplicate, the database will reject it outright.
The interview trap: Candidates sometimes confuse primary keys with unique keys. Here’s the distinction - a primary key must be unique and cannot be NULL. A table can only have one primary key. A unique key also enforces uniqueness, but it can allow a single NULL value, and a table can have multiple unique keys.
Foreign Keys
A foreign key is a column in one table that references the primary key of another table. It’s the mechanism that creates relationships between tables and enforces referential integrity.
Picture two tables: an Employees table and a Departments table. The Employees table has a DeptNo column that points to the DeptNo primary key in Departments. This foreign key ensures you can’t assign an employee to a department that doesn’t exist.
Why interviewers care: Foreign keys reveal whether you understand relational design. If you can explain how they prevent orphaned records and maintain data consistency, you’re demonstrating real-world understanding.
Candidate Keys vs. Primary Keys
A candidate key is any column (or set of columns) that could serve as the primary key - it uniquely identifies rows and contains no NULLs. The primary key is simply the candidate key you chose to use.
For example, in a Users table, both email and user_id might uniquely identify each row. Both are candidate keys. You pick one (usually user_id) as the primary key. The other remains a candidate key, often enforced with a unique constraint.
Normalization: Why Your Table Design Matters
Normalization questions are a favorite because they separate people who just write queries from people who understand design.
Normalization is the process of organizing data to minimize redundancy and dependency. You break a large table into smaller, related tables and define relationships between them. The goal is eliminating duplicate data and ensuring that updates, inserts, and deletes don’t create inconsistencies.
The Normal Forms (What You Need to Know)
There are several levels, and interviewers typically expect you to know the first three fluently:
First Normal Form (1NF) requires that each column contains only atomic (indivisible) values and each row is unique. No repeating groups, no comma-separated lists stuffed into a single cell.
Second Normal Form (2NF) builds on 1NF by requiring that every non-key column depends on the entire primary key, not just part of it. This matters most with composite keys.
Third Normal Form (3NF) goes further: every non-key column must depend only on the primary key, not on other non-key columns. This eliminates transitive dependencies.
Beyond 3NF, there’s Boyce-Codd Normal Form (BCNF), Fourth Normal Form (4NF), and Fifth Normal Form (5NF/PJNF). Most real-world databases aim for 3NF. Mentioning that you know the higher forms exist - and that denormalization is sometimes the right call for performance - shows maturity.
Database vs. Schema: A Subtle but Important Distinction
This question catches people off guard because the terms are sometimes used loosely in conversation.
A database is the top-level container that holds everything - tables, views, indexes, stored procedures. It represents a complete, logical grouping of related data.
A schema is a container within a database. It’s a namespace that organizes objects and defines ownership. In SQL Server, for instance, dbo.Users and hr.Users could be two completely different tables in the same database, separated by schema.
Think of a database as a building, and schemas as different floors within that building. Each floor has its own rooms (tables), but they’re all under the same roof.
What to Remember
The foundation questions aren’t about memorizing definitions. They’re about demonstrating that you understand why these concepts exist and how they work together. A primary key isn’t just “a unique identifier” - it’s the mechanism that makes relational integrity possible. Normalization isn’t just “reducing redundancy” - it’s a design discipline that prevents data anomalies.
In Part 2, we’ll tackle the questions interviewers love most: joins, subqueries, and the clauses that make SQL powerful.
Next up: Part 2 - Querying Like a Pro: Joins, Subqueries, and the Clauses That Matter
