What SQL level should you claim on a data resume?

SQL appears on almost every resume from data analysts, data engineers and data scientists, and almost always with a qualifier: "good command", "advanced level", "expert". These labels mean nothing without reference points, and they can work against you: a recruiter who reads "advanced SQL" prepares a test to match the claim. It is better to know precisely where you stand, write it in a verifiable way and prove it in an experience. This article offers a concrete grid of levels, details what each data job expects, shows how to describe SQL in an experience and what recruitment SQL tests contain.

Why "advanced SQL" worries as much as it reassures

For a recruiter, the mention of a SQL level has two contradictory effects.

On the one hand, it reassures: SQL is a prerequisite for most data roles, and seeing it in the skills section lets you get through the first screening.

On the other, it worries, because "advanced" covers very different realities. For an analyst used to spreadsheets, being able to write a join is already advanced; for a data engineer, advanced starts with reading execution plans and optimising queries on tables of several hundred million rows. The recruiter does not know which scale you are using.

That is why many data recruitment processes include a SQL test, often in the first stages. The level stated on the resume then serves as a starting point: an ambitious claim invites difficult questions. Stating an accurate level, with precise reference points, is both more honest and more effective.

A concrete grid of levels

Rather than "beginner, intermediate, advanced", use technical reference points. Here is a four-level grid that matches what is seen in recruitment tests.

Level 1: the basics

SELECT, WHERE, ORDER BY, LIMIT;
simple aggregations: COUNT, SUM, AVG with GROUP BY and HAVING;
inner joins between two tables;
understanding NULL values and their effect on calculations.

Level 2: an analyst’s everyday use

outer joins (LEFT JOIN) and joins across several tables;
subqueries and common table expressions (WITH 🔗) to structure a long query;
CASE WHEN to build categories;
date handling: extraction, truncation by month or week, differences;
deduplication and data consistency checks.

Level 3: advanced analysis

window functions 🔗: ROW_NUMBER, RANK, LAG, LEAD, running sums and averages with OVER (PARTITION BY … ORDER BY …);
cohort, retention and event sequence analyses;
recursive queries for hierarchies;
writing readable, maintainable queries, split into named steps.

Level 4: performance and modelling

reading an execution plan (EXPLAIN 🔗) and diagnosing a slow query;
choosing indexes 🔗, partitioning, clustering depending on the engine;
modelling: star schema, fact and dimension tables, history tracking;
specifics of cloud warehouses (BigQuery, Snowflake, Redshift): query cost, columnar storage, partitioned tables;
transactions and isolation levels, for profiles close to production databases.

Place yourself honestly: the highest level whose essentials you master, unaided, is your level.

What data analyst, data engineer and data scientist roles expect

Expectations differ by job, as do their tasks, compared in our article on the difference between a data analyst and a data scientist.

Data analyst: level 2 is the minimum, level 3 makes the difference. Window functions come up very often in tests, to calculate changes, rankings or cohorts. Query readability also matters, because queries are reviewed and reused.
Data engineer: level 3 is expected, level 4 is at the heart of the job. Optimisation, modelling, costs and data tests are part of daily work, as described in our article on the data engineer job.
Data scientist: level 2 to 3 is generally expected. SQL is mainly used to extract and prepare training data; window functions are valuable for building time-based features.

SQL is not reserved for data teams, either. Auditors increasingly use it to analyse entire sets of accounting entries rather than samples: the data skills expected in financial audit 🔗 give an overview from the firms’ side.

Describing it in an experience

On the resume, the skills section is not enough. The level is proven in an experience or a project, by what you did with SQL.

For the skills section, specify the use rather than an adjective:

Before: "SQL (advanced)".

After: "SQL: window functions, cohort analyses, query optimisation (PostgreSQL, BigQuery)".

Then, in the experience section:

Before: "SQL queries for reporting."

After: "Rewrote the sales dashboard queries using window functions and intermediate tables: refresh time cut from forty minutes to five, and cohort retention indicators added at management’s request."

For a data engineer:

"Optimised the transformation models on BigQuery (date partitioning, clustering, removal of redundant joins): volume of data read by the daily pipeline divided by three."

These wordings say which SQL you write, on which engine, for what result. The data engineer resume template shows how SQL fits into a pipeline description, and our article on training for a data analyst job explains how to build projects that prove this level when you are starting out.

SQL tests in recruitment

SQL tests take several forms, which it is better to know in advance.

The timed online test: a few exercises on a given database, with queries to write within a time limit. They often cover joins, aggregations and window functions.
The whiteboard or screen-share exercise: a table schema and a business question ("monthly revenue by category and its change from the previous month"), to be solved while explaining your reasoning.
The take-home exercise: a dataset and a series of questions, sometimes with an oral debrief.
Comprehension questions: the difference between WHERE and HAVING, the effect of NULL in a join, the difference between RANK and ROW_NUMBER, possible reasons for a slow query.

A few tips:

clarify the question before writing: expected granularity, period, handling of missing values;
build the query step by step, with named WITH expressions, and check each step;
test your assumptions on edge cases (duplicates, null values, empty periods);
explain your choices out loud in the interview: the method counts as much as the result.

To practise, take public datasets and ask yourself realistic business questions: monthly change, rankings, cohorts, user sessions.

Stating an accurate level, then proving it, starts with a readable resume. The TechCV editor lays out your skills and experience on a page that recruitment software extracts without errors, so that the mention of SQL and your engines actually reaches the recruiter. You can update your resume before your next test.

Frequently asked questions

Should I specify the database engine?

Yes, when you know one in depth or the ad mentions one: PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, Snowflake. The basics of the language are shared, but functions, performance and costs vary from one engine to another.

Can I write "SQL expert"?

Rarely wisely. The word invites the most pointed questions (execution plans, transaction isolation, optimisation on large volumes). Describe instead what you can do, with technical reference points and results.

Do no-code tools replace SQL?

Visualisation and data preparation tools reduce the need to write SQL for some tasks, but employers still require it. It remains the most direct way to understand and control the data being used.

How do I progress from level 2 to level 3?

By practising window functions on real cases: changes from one period to the next, rankings within groups, cohorts. Take queries you already write at work and rewrite them more simply using these functions.