Build a SQL Portfolio That Proves You Can Answer Business Questions

Build around questions, not query tricks

A useful SQL portfolio demonstrates how you translate a business question into a defensible result. Pick a question with a clear unit of analysis: for example, how weekly repeat purchasing differs across customer cohorts. Define what counts as a customer, a purchase, a week, and a repeat event before writing the query.

Interviewers can learn more from a transparent, modest analysis than from a complicated query with unexplained assumptions. State the question, data source, time range, and intended audience. If the dataset is synthetic or educational, say so plainly; never imply that practice data represents a real employer or market.

Design a compact relational dataset

Use a dataset that naturally needs joins: orders and order lines, events and users, or products and categories. Document table grain and keys. A row in an order-line table is not the same thing as a row in an orders table, and joining them can multiply amounts if the analyst aggregates at the wrong level.

Add a small schema diagram or a markdown table describing columns and relationships. Record known limitations, such as missing dates or inconsistent category labels. This context lets a reviewer distinguish an analytical decision from an accidental artifact of the source data.

Show core SQL with readable stages

Include filtering, joins, aggregation, conditional logic, and at least one window-function example where it genuinely helps. A window calculation can compare a row with a prior period while preserving row-level detail; a grouped aggregate instead collapses rows. Explain why you chose one rather than inserting advanced syntax for decoration.

Use common table expressions to name meaningful stages, consistent aliases, and explicit column lists. Avoid SELECT * in final analytical outputs because schema changes can silently alter results. Keep formatting consistent enough that someone can follow the logic without mentally re-parsing every line.

Make correctness inspectable

For each headline measure, write a plain-language definition and a check. Compare record counts before and after joins, identify duplicate keys, test null behavior, and reconcile a sample total against a second calculation. A plausible-looking output is not proof: incorrect joins often produce believable numbers.

Include edge cases such as customers with no qualifying activity, events on boundaries, or refunds if the source includes them. Explain how these cases are treated. If the dataset cannot answer a question, say what extra fields or collection process would be needed rather than silently inventing a proxy.

Explain findings without overclaiming

Present a small result table and one restrained visualization if useful. Distinguish descriptive patterns from causes: a difference between cohorts does not show that cohort membership caused the difference. Note the timeframe, denominator, and any data quality concerns near the conclusion, not hidden in a technical appendix.

Add a short “what I would do next” section. This might propose checking seasonality, validating with an operational owner, or testing a hypothesis with a suitable design. A good portfolio shows judgment about the next question as well as competence producing the current result.

Package it for review and practice

Provide a README with setup instructions, database assumptions, how to run the queries, and a map of the repository. Include sample outputs that can be inspected without installing a database, while keeping the source query authoritative. Never commit credentials, private data, or a large raw extract that violates source terms.

Practice narrating one query in three minutes: explain the grain, join path, definition, validation, and interpretation. Then prepare to modify it when an interviewer changes a requirement. That adaptability is a stronger signal than memorizing isolated syntax patterns.

• State the assumptions and limitations plainly.
• Link to the official documentation or data source used.
• Give the reader one concrete action they can complete next.