30-Day Rolling Sales Amount

SQL coding challenge · Difficulty: easy · Topic: Window Functions · +100 XP

Problem

Finance reviews sales on a 30-day rolling total: next to each day, the sum

of that day and the 29 days of trading before it. A single day is noise; a

30-day window is what they actually steer on.

Engine: queries run on MySQL 8.0, so use MySQL-compatible syntax and functions.

Tables

daily_sales — one row per day.

| column | type | description |
| --- | --- | --- |
| sale_date | DATE | the day the sales were recorded |
| sales | INT | sales taken that day |

Return every row of daily_sales, with one extra column:

• rolling_30day_sum — the total sales over the current row and the **29

rows before it**, in date order

Sort the result by sale_date ascending.

What the window does, and when you can see it

The frame is 30 rows, not 30 calendar days: the current row plus the 29

recorded rows preceding it. If a date has no row, it is simply not there — the

window reaches back thirty *recorded* days however far apart they fall.

Two consequences worth being precise about:

• Before the 30th row, nothing has dropped out yet. For the first 29 rows

the window holds everything so far, so the running figure looks exactly like a

plain cumulative total. That is not a shortcut — it is the same window, simply

not yet full.

• From the 30th row onward the window slides, and the oldest day leaves it.

This is where a rolling total stops matching a cumulative one. A query with no

frame at all keeps adding forever and will agree with the correct answer right

up until the 31st row, then diverge from it on every row after.

The worked example below is only nine days long, so it falls entirely in the

first case. The graded tests include longer histories where the window is full

and moving.

Example input

daily_sales

| sale_date | sales |
| --- | --- |
| 2024-01-01 | 100 |
| 2024-01-02 | 200 |
| 2024-01-03 | 150 |
| 2024-01-04 | 300 |
| 2024-01-05 | 250 |
| 2024-01-06 | 180 |
| 2024-01-07 | 220 |
| 2024-01-08 | 90 |
| 2024-01-09 | 310 |

Expected output

| sale_date | sales | rolling_30day_sum |
| --- | --- | --- |
| 2024-01-01 | 100 | 100 |
| 2024-01-02 | 200 | 300 |
| 2024-01-03 | 150 | 450 |
| 2024-01-04 | 300 | 750 |
| 2024-01-05 | 250 | 1000 |
| 2024-01-06 | 180 | 1180 |
| 2024-01-07 | 220 | 1400 |
| 2024-01-08 | 90 | 1490 |
| 2024-01-09 | 310 | 1800 |

Each figure is the sum of every day up to and including that row, because nine

days is fewer than thirty and the window has not yet had to discard anything.

On a history longer than thirty rows these numbers would stop growing

indefinitely and begin to reflect only the most recent thirty.

What this SQL challenge teaches you

“30-Day Rolling Sales Amount” is a easy-level SQL challenge focused on Window Functions. Working through it gives you hands-on practice with Window Functions — the kind of transformation you are asked to write in real data engineering work and in technical interviews. You can solve it directly in the browser: the dataset is pre-loaded, so you write the query or DataFrame code, run it, and compare your output against the expected result immediately.

How to approach it

If you get stuck, work through these steps in order before looking at a full solution — each one narrows the problem down:

1. You need a total that moves with each row while keeping every row in the result. That is a window function, not a GROUP BY.
2. SUM(col) OVER (...) with no frame clause sums the whole partition up to the current row -- a cumulative total that never forgets. This task needs a frame that does forget.
3. The frame is thirty rows counting the current one, so the offset is 29, not 30. Use ROWS, not RANGE with a day interval: the window reaches back thirty recorded rows, and calendar gaps do not shrink it.
4. ORDER BY sale_date inside the OVER clause is what makes "preceding" mean earlier, rather than whatever order the rows happen to be stored in.
5. Test your query on a history longer than thirty rows. On a short table a cumulative total and a rolling one look identical -- they only diverge once the window is full and starts dropping the oldest day.

Where this comes up

Variations of this problem have been reported in interviews at Amazon. Interviewers use it to check whether you can express the logic cleanly and reason about correctness on edge cases such as ties, nulls and empty groups.

How to practise it on PySpark.in

Open the challenge, write your SQL query in the editor and press Run to execute it against the sample dataset. Submitting checks your output against every test case, including hidden ones, so you find out straight away whether your logic holds up. You can retry as often as you like, and each solved challenge adds to your XP.

Related SQL challenges

• Top 3 Products per Category
• Running Total Revenue
• Median Salary per Department
• Latest Order Per Customer
• 3-Day Rolling Sum of Sales
• 7-Day Rolling Purchase Amount by Customer

Helpful resources

• Learn this concept
• Practice this topic
• All SQL practice questions
• Open the notebook

Frequently asked questions

Do I need to install Spark or a database to solve this?

No. The SQL environment runs in your browser with the sample data already loaded, so there is nothing to install or configure.

Is this challenge free?

Yes - the problem, the sample dataset, the hints and unlimited test runs are free.

What level is it?

It is rated easy and covers Window Functions.

Solve this challenge free on PySpark.in