← Amazon Interview Insights

Amazon·Data Scientist·Technical Phone Screen·Senior

Senior
May 2026Remote

Summary

Amazon Data Scientist technical screen, heavy pandas and data engineering focus. The main problem was a subscription-revenue attribution question that looked like a pandas exercise but quickly turned into a system design conversation about scaling to 100M events.

Questions Asked (4)

Q1

Given an events table and a subscriptions table, compute per-user active subscription days and purchase revenue attributed only to periods when the user had an active subscription, for a specific month. Also flag purchases that fall outside any active subscription window.

Data ModelingProduct Analytics & MetricsAlgorithms & Data Structures
Author's notes

This was the core of the whole interview.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and definitions: what constitutes an active subscription (start/end dates, status), how events relate to purchases, and the target month. Then outline a SQL-based solution using date ranges and joins to compute active days and attribute revenue, with a flag for out-of-window purchases. Finally, discuss edge cases and validation.

Pro tip: Mention that you would validate the results by cross-checking with a sample of users and ensuring that the sum of active days matches the subscription duration. Also, consider performance implications for large datasets and suggest indexing strategies.

1. Clarify requirements and schema

Ask about the table structures, definitions of active subscription, and the specific month. Confirm whether subscriptions can overlap or have gaps, and how purchases are recorded.

2. Compute active subscription days per user

For each user, calculate the number of days in the target month during which they had an active subscription. This may involve generating a date series and joining with subscription periods.

3. Attribute purchase revenue to active periods

Join purchases with subscription periods to sum revenue only for purchases that occurred within an active subscription window. Use date comparisons to filter.

4. Flag purchases outside active windows

Identify purchases that do not fall within any active subscription period for that user and flag them, possibly as a separate output or a boolean column.

5. Validate and discuss edge cases

Check for edge cases like subscriptions starting/ending mid-month, time zones, and data quality issues. Validate results with sanity checks.

Key Points to Mention

  • Use of date functions and interval arithmetic to compute active days.
  • Handling of overlapping subscriptions and gaps between subscriptions.
  • Definition of 'active' (e.g., status = 'active', or based on start/end dates).
  • Attribution logic: only include purchases with timestamps within active periods.
  • Flagging mechanism: left join and check for nulls or use NOT EXISTS.
  • Performance considerations: indexing on user_id and date columns, partitioning by month.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you merge overlapping or back-to-back subscription intervals into minimal disjoint half-open intervals before attributing revenue?

Algorithms & Data StructuresData Modeling
Author's notes

Classic interval merge problem but applied to a pandas DataFrame context.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data model and business context, then outline a sweep-line algorithm that sorts intervals by start time and merges overlapping or adjacent ones. Emphasize the use of half-open intervals [start, end) to avoid double-counting at boundaries, and discuss how to attribute revenue to the merged intervals.

Pro tip: Mention that back-to-back intervals (where one ends exactly when the next begins) should be merged because half-open intervals treat the end as exclusive, preventing gaps or overlaps. Also, highlight the importance of handling edge cases like zero-length intervals and timezone consistency.

1. Clarify requirements and data

Confirm the definition of overlapping and back-to-back intervals, the time granularity, and how revenue is attributed (e.g., prorated daily). Ensure intervals are half-open [start, end).

2. Sort intervals

Sort all subscription intervals by start time. This is the foundation for an efficient O(n log n) merge algorithm.

3. Merge intervals using sweep-line

Iterate through sorted intervals, maintaining a current merged interval. If the next interval's start is less than or equal to the current end, extend the current end to the maximum of the two ends; otherwise, output the current interval and start a new one.

4. Attribute revenue to merged intervals

For each merged interval, calculate the total revenue by summing the revenue from all original intervals that contributed, ensuring no double-counting at boundaries. If revenue is prorated, compute based on the merged interval's duration.

5. Validate and handle edge cases

Check for zero-length intervals, intervals with null end dates (ongoing subscriptions), and timezone consistency. Validate that the merged intervals are disjoint and cover the original intervals exactly.

Key Points to Mention

  • Half-open intervals [start, end) to avoid double-counting at boundaries.
  • Sorting by start time for O(n log n) efficiency.
  • Merging condition: next.start <= current.end (including equality for back-to-back).
  • Revenue attribution: sum or prorate based on merged interval duration.
  • Handling edge cases: zero-length intervals, ongoing subscriptions, timezones.
  • Scalability: discuss how to handle large datasets (e.g., using distributed sorting or streaming).

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

How would you scale this subscription-revenue attribution pipeline to handle 100 million events with limited RAM? What specific techniques would you use?

System DesignTechnical Trade-offs
Author's notes

Talked about chunking with pandas read_csv chunksize, switching to int32/float32 dtypes, and doing predicate pushdown with parquet column scans.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data characteristics and constraints, then propose a streaming architecture that processes events in chunks or real-time, using memory-efficient data structures and algorithms. Emphasize trade-offs between accuracy, latency, and resource usage, and mention specific techniques like sketching, partitioning, and incremental aggregation.

Pro tip: Demonstrate awareness of Amazon's leadership principles by discussing how you would measure success (e.g., cost per event, accuracy) and iterate, and mention that you'd validate the approach with a small-scale prototype before full deployment.

1. Clarify Requirements and Constraints

Ask about event volume, velocity, variety, required accuracy, latency, and available resources (RAM, CPU, storage). Confirm whether exact counts are needed or approximations suffice.

2. Design a Streaming Architecture

Propose processing events in a streaming fashion (e.g., using Apache Kafka, Kinesis, or Spark Streaming) to avoid loading all data into memory. Use windowing and incremental aggregation.

3. Apply Memory-Efficient Techniques

Use probabilistic data structures (Count-Min Sketch, HyperLogLog) for approximate counts, partitioning by key to process subsets independently, and compression or columnar formats for storage.

4. Optimize for Attribution Logic

Implement incremental attribution using session windows and last-touch or multi-touch models, updating aggregates as events arrive. Use efficient joins or lookups with caching.

5. Validate and Iterate

Test with a scaled-down dataset, measure memory usage and accuracy, and tune parameters (e.g., sketch size, window length). Plan for monitoring and scaling out horizontally.

Key Points to Mention

  • Streaming processing (e.g., Kafka, Kinesis, Spark Streaming) to handle events in real-time or micro-batches
  • Probabilistic data structures (Count-Min Sketch, HyperLogLog) for approximate counting with low memory
  • Partitioning and sharding by user or subscription ID to distribute load and enable parallel processing
  • Incremental aggregation and windowing to compute attribution metrics without storing all raw events
  • Trade-offs between accuracy, latency, and resource consumption; when to use approximate vs exact methods
  • Horizontal scaling and cloud services (e.g., AWS Lambda, EMR) to handle large volumes with limited per-node RAM

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

Output two separate DataFrames: one with user-month aggregates (active days, subscribed revenue, out-of-window purchase count) and one anomaly log with a reason column indicating whether a purchase was outside a subscription window or flagged due to a fixed overlap. How do you structure and populate both?

Data ModelingProduct Analytics & Metrics
Author's notes

Straightforward once the interval merging was done.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the definitions of 'active days', 'subscribed revenue', and 'out-of-window purchase', then outline a two-step process: first compute user-month aggregates from the transaction and activity logs, then generate an anomaly log by comparing each purchase against subscription windows and checking for fixed overlaps. Emphasize the use of window functions and conditional aggregation to efficiently produce both DataFrames.

Pro tip: Mention that you would validate the anomaly detection logic with a small, manually crafted dataset to ensure edge cases (e.g., purchases exactly at window boundaries) are handled correctly, and that you would document the assumptions about time zones and subscription definitions.

1. Clarify definitions and assumptions

Confirm what constitutes an 'active day' (e.g., any activity or a specific action), how 'subscribed revenue' is defined (e.g., revenue from subscription purchases), and what 'out-of-window' means (purchase date outside the subscription period). Also clarify the 'fixed overlap' condition (e.g., overlapping subscription periods).

2. Prepare and join data sources

Gather activity logs, purchase transactions, and subscription records. Join them appropriately, ensuring each purchase is linked to the user's subscription status at the time of purchase.

3. Compute user-month aggregates

Group data by user and month. Calculate active days (count distinct dates with activity), subscribed revenue (sum of revenue from purchases within subscription windows), and out-of-window purchase count (count of purchases outside any subscription window).

4. Generate anomaly log

For each purchase, determine if it falls outside the subscription window or if it is flagged due to a fixed overlap (e.g., overlapping subscription periods). Create a reason column indicating the specific anomaly type.

5. Validate and output DataFrames

Check for consistency (e.g., out-of-window count in aggregates matches anomaly log entries) and output the two DataFrames with clear schemas.

Key Points to Mention

  • Use of window functions (e.g., SUM OVER, COUNT DISTINCT) for efficient aggregation
  • Handling time zones and date boundaries consistently
  • Definition of 'active day' and how it impacts aggregation
  • Logic for determining subscription windows and overlaps
  • Validation steps to ensure data quality and correctness
  • Scalability considerations for large datasets (e.g., partitioning by user/month)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.