Reviewed by Aditya Kumar · Last reviewed 2026-08-08
These are two different window operations, and the question is really checking that you know the difference. LAG looks back a fixed number of rows; a cumulative total sums everything from the start of…
This easy-level SQL question appears frequently in data engineering interviews at companies like Deolite. While less common, it tests deeper understanding that distinguishes strong candidates.
Start by clearly defining the core concept being asked about. Interviewers want to see that you understand the fundamentals before diving into implementation details. Structure your answer with a definition, then explain the practical application with a concise example. The expert answer includes a code example that demonstrates the implementation pattern.
These are two different window operations, and the question is really checking that you know the difference. LAG looks back a fixed number of rows; a cumulative total sums everything from the start of the partition to the current row.
SELECT id,
surface_area,
LAG(surface_area, 1, 0) OVER (ORDER BY id) AS previous_area,
SUM(surface_area) OVER (
ORDER BY id
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS cumulative_area
FROM surfaces
ORDER BY id;
LAG(column, offset, default) returns the value from offset rows earlier in the ordered partition. The third argument is what makes this robust: without it, the first row's LAG is NULL, and any arithmetic on NULL yields NULL. Supplying 0 means surface_area + LAG(surface_area, 1, 0) gives a real number on row one instead of a hole. LEAD is the same function looking forward.
Strictly, LAG alone cannot produce a cumulative total — it only reaches back one row. A true running total needs SUM with a frame, which is why both appear above.
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW states explicitly that the frame is row-based. The default when you write only ORDER BY id is RANGE, which is value-based: rows sharing the same id collapse into one frame and all receive the same total. With a unique id the results are identical, but if the ordering column ever contains duplicates the two diverge. Being explicit removes the ambiguity.
Add PARTITION BY to restart the accumulation for each group, for example PARTITION BY material_type ORDER BY id.
A cumulative total is only meaningful over a deterministic order. If id is not unique, add a tiebreaker, otherwise the same query can return different numbers on different runs.
In the interview, also mention that LAG is the standard way to compute period-over-period change: surface_area - LAG(surface_area) OVER (ORDER BY id).
Red Flag: LAG for running total (use SUM). Pro-Move: 'LAG for diff from prev; SUM for cumulative—right tool per need.'
Some links below are affiliate links. If you buy through them we may earn a small commission at no extra cost to you — it helps keep DataEngPrep free.
According to DataEngPrep.tech, this is one of the most frequently asked SQL interview questions, reported at 1 company. DataEngPrep.tech maintains an editor-reviewed database of 1,863 data engineering interview questions across 7 categories.