Rolling Sum vs Daily Target (Show Difference)

SQL coding challenge · Difficulty: medium · Topic: Window Functions · +200 XP

Problem

The sales floor is held to a target of 200 per day. Management reviews it

three days at a time, so next to each day they want the 3-day rolling total

and how far that total sits above or below the 600 it should have reached.

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 two extra columns:

before it**, in date order

window beat the target, negative means it fell short

Sort the result by sale_date ascending.

The target is always 600

600 is the three-day target: 200 a day for three days. It is a **fixed number on

every row**, including the first and second, where only one or two days have

been recorded yet.

That is deliberate — those early rows are genuinely behind a three-day target,

and the report says so. Do not scale the target down to match how many days

happen to be in the window: on day 1 the answer is sales - 600, not

sales - 200.

What "3-day" means here

The window is 3 rows, not 3 calendar days: the current row plus the two rows

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

back three *recorded* days however far apart they fall on the calendar. From the

fourth row onward the window slides and the oldest day drops out, which is where

a rolling total stops matching a running total that never forgets.

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_3day_sum | diff_vs_target |
| --- | --- | --- | --- |
| 2024-01-01 | 100 | 100 | -500 |
| 2024-01-02 | 200 | 300 | -300 |
| 2024-01-03 | 150 | 450 | -150 |
| 2024-01-04 | 300 | 650 | 50 |
| 2024-01-05 | 250 | 700 | 100 |
| 2024-01-06 | 180 | 730 | 130 |
| 2024-01-07 | 220 | 650 | 50 |
| 2024-01-08 | 90 | 490 | -110 |
| 2024-01-09 | 310 | 620 | 20 |

The first three rows build the window up: 100, then 100+200, then

100+200+150 = 450 — still 150 short of target.

2024-01-04 is where the window starts sliding. Its total is

200+150+300 = 650, not 750: the 1st has dropped out. That is also the first

day the three-day target is met, by 50.

Watch 2024-01-08: a weak day of 90 pulls the window down to 490, putting

the run 110 behind — even though the day before was comfortably ahead.

What this SQL challenge teaches you

“Rolling Sum vs Daily Target (Show Difference)” is a medium-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. Both new columns come from the same rolling total, so compute it once. A named WINDOW clause, a CTE, or simply repeating the expression all work.
  2. SUM(col) OVER (...) with no frame clause is a running total that never forgets. This task needs a frame that drops the oldest day.
  3. The frame is three rows counting the current one, so the offset is 2, not 3. Use ROWS, not RANGE with a day interval: calendar gaps do not shrink the window.
  4. The target is a flat 600 on every row. Do not scale it to the number of days in the window -- on day 1 the difference is sales - 600.
  5. 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.

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

Helpful resources

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 medium and covers Window Functions.

Solve this challenge free on PySpark.in