cswork / libraryOpen practice workspace

Coding questions · Netflix

Determine Maximum Consecutive Order Days Per User

Determine Maximum Consecutive Order Days Per User evaluates SQL or pandas logic, joins, grouping, window functions, null handling, edge cases, and validation in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

orders

+----+---------+------------+
| id | user_id | order_date |
+----+---------+------------+
|  1 |     101 | 2024-01-01 |
|  2 |     101 | 2024-01-02 |
|  3 |     101 | 2024-01-05 |
|  4 |     102 | 2024-01-03 |
|  5 |     102 | 2024-01-04 |
+----+---------+------------+
Scenario

The commerce team wants to know each customer’s best ordering streak for loyalty analysis.

Question

For every user, return the maximum number of consecutive calendar days on which they placed at least one order.

Hints

Generate dense date series per user; use gaps-and-islands or window functions.

Clarifying Questions to Ask

  • Clarify SQL dialect or Python library versions, date/time semantics, duplicate handling, and null handling.
  • Define the grain of each intermediate result before aggregating.
  • State expected output columns and ordering explicitly.

What a Strong Answer Covers

  • A query or pandas plan that matches the requested output grain.
  • Correct joins, filters, grouping, window functions, and treatment of NULLs or duplicates.
  • A brief explanation of why the result is correct and how it handles edge cases.
  • Performance notes, indexes/partitioning, and validation queries when relevant.

Follow-up Questions

  • How would you test the query on a tiny hand-built dataset?
  • What changes if duplicate events or late-arriving data are present?
  • Which indexes, clustering, or partitions would help at production scale?

Determine Each User's Longest Consecutive Ordering Streak

Using PostgreSQL, return every user who appears in orders and the maximum number of consecutive calendar dates on which that user placed at least one order. Multiple orders by the same user on the same date count as one ordering day. Return user_id and max_consecutive_order_days, ordered by user_id.

Table orders

columntypeconstraints
idINTEGERPRIMARY KEY
user_idINTEGERNOT NULL
order_dateDATENOT NULL

Sample data:

idorder_dateuser_id
12024-01-01101
22024-01-01101
32024-01-02101
42024-01-05101
52024-01-03102
62024-01-04102
72024-01-05102
82024-02-10103
92024-03-01104
102024-03-02104
112024-03-04104
122024-03-05104

Expected output

user_idmax_consecutive_order_days
1012
1023
1031
1042

Hints

  1. Deduplicate user/date pairs before measuring streak length.
  2. For consecutive dates, date minus a row number remains constant within each island.
  3. Count each island, then take the maximum count per user.

Solution

Solution Alignment

Use a gaps-and-islands pattern after deduplicating each user's order dates.

PostgreSQL Query

WITH user_days AS (
    SELECT DISTINCT user_id, order_date::date AS order_date
    FROM orders
), numbered AS (
    SELECT
        user_id,
        order_date,
        order_date - (ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY order_date
        )::int) AS island_key
    FROM user_days
), streaks AS (
    SELECT user_id, island_key, COUNT(*) AS streak_len
    FROM numbered
    GROUP BY user_id, island_key
)
SELECT user_id, MAX(streak_len) AS max_consecutive_order_days
FROM streaks
GROUP BY user_id
ORDER BY user_id;

Why It Works

For consecutive calendar days, subtracting the row number from the date produces the same island key for every day in the same streak. Deduplicating user_id, order_date first ensures multiple orders on one day do not inflate the streak length.

Complexity

The dominant cost is sorting within each user for the window function: O(n log n) overall in the usual implementation. Space is O(n) for intermediate rows.

Edge Cases

Users with multiple orders on the same date, one-day streaks, gaps between dates, and users with no orders if they must be included from a separate users table.