← Robinhood Interview Insights

Robinhood·Software Engineer·Technical Phone Screen·Senior

Senior
Jun 2026

Summary

SQL-heavy technical screen for a Data Engineer role at Robinhood. Three questions all built on the same two tables, each one adding a layer of complexity around temporal state tracking. Felt manageable at first but the edge cases crept up on me.

Questions Asked (3)

Q1

Given a user info table and an edit log table, write a SQL query to find users who were always in CA as of 2021-01-01, meaning their state was CA at that point and there is no prior record of them ever being in a non-CA state.

Data ModelingTechnical Trade-offs
Author's notes

My first instinct was to just filter the current snapshot for state = 'CA' and call it a day.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the table schemas and the definition of 'always in CA' as of 2021-01-01. Then, use a window function or subquery to find the latest state before or on that date for each user, and filter for users whose state is CA and who have no prior non-CA state.

Pro tip: Mention that you would validate the query with edge cases, such as users with no edit logs or multiple edits on the same day, to ensure correctness.

1. Understand the data model

Identify the user info table (e.g., user_id, state) and edit log table (e.g., user_id, state, edit_date). Clarify how state changes are recorded and whether the user info table reflects current state or initial state.

2. Define the target condition

A user is 'always in CA as of 2021-01-01' if their state on that date is CA and they have never been in a non-CA state before that date. This means the earliest state change (if any) must be to CA, and no non-CA state appears before 2021-01-01.

3. Determine state as of the date

For each user, find the most recent state change on or before 2021-01-01. If no change exists, use the initial state from the user info table. This can be done with a correlated subquery or window function.

4. Check for prior non-CA states

Filter out users who have any record in the edit log with a non-CA state and an edit_date before 2021-01-01. Also consider the initial state from the user info table if it is non-CA.

5. Combine conditions and write query

Select users whose state as of 2021-01-01 is CA and who have no prior non-CA state. Use CTEs or subqueries for clarity, and consider performance implications.

Key Points to Mention

  • Handling users with no edit log entries (use initial state from user info table).
  • Using window functions like ROW_NUMBER() or LAST_VALUE to get the latest state before a date.
  • Considering the initial state from the user info table as a potential prior state.
  • Edge cases: multiple edits on the same day, edits exactly on 2021-01-01, and timezone considerations.
  • Performance: indexing on (user_id, edit_date) and avoiding full table scans.
  • Clarifying whether 'always in CA' means from the beginning of time or from account creation.

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

Q2

Using the same two tables, write a SQL query to find users who moved to CA strictly before 2021-01-01 and were still in CA as of that date.

Data ModelingTechnical Trade-offs
Author's notes

This one felt cleaner than the first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the schema of the two tables (likely a users table and a location history table). Then, use a self-join or window functions to find users who have a record of moving to CA before 2021-01-01 and no subsequent move out of CA before or on that date, ensuring they were still in CA as of that date.

Pro tip: Explicitly state your assumptions about the table schemas and date semantics (e.g., whether the date represents the start of residence). This shows you think about data modeling and edge cases, which is crucial for a fintech company like Robinhood.

1. Clarify table schemas and assumptions

Ask or state the columns of the two tables, such as users(user_id, ...) and user_locations(user_id, state, move_date). Assume move_date is the date the user started living in that state.

2. Identify users who moved to CA before 2021-01-01

Filter the location history for records where state = 'CA' and move_date < '2021-01-01'. This gives a set of users who moved to CA before the cutoff.

3. Ensure they were still in CA as of 2021-01-01

For each such user, check that there is no subsequent move to a different state with a move_date <= '2021-01-01'. This can be done with a NOT EXISTS subquery or by finding the latest state before the date.

4. Combine conditions and select distinct users

Use a query that joins or filters to return distinct user_ids that satisfy both conditions. Consider using window functions like ROW_NUMBER to get the latest state per user before the date.

5. Test with edge cases

Mention testing scenarios like users who moved to CA exactly on 2021-01-01 (should be excluded), users who moved to CA then left before the date, and users with multiple moves.

Key Points to Mention

  • Use of date comparison strictly before 2021-01-01 (exclusive).
  • Handling of multiple location records per user and determining the latest state before the cutoff date.
  • Use of NOT EXISTS or LEFT JOIN with NULL check to ensure no move out of CA before or on the date.
  • Consideration of window functions (e.g., ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY move_date DESC)) to get the most recent state.
  • Importance of indexing on (user_id, move_date) for performance.
  • Clarifying whether the date represents the start or end of residence, and how that affects the query.

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

Q3

Write a SQL query to find users who might have moved out of CA after 2021-01-01, meaning they were in CA as of that date and there is a subsequent log entry showing a change from CA to a different state.

Data ModelingProduct Analytics & Metrics
Author's notes

Easiest of the three structurally.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Use a self-join on the user activity log table to find users who had a 'CA' entry on or before 2021-01-01 and a later entry with a different state. Ensure the later entry is the first state change after that date to avoid false positives from multiple moves.

Pro tip: Clarify the table schema and whether 'as of 2021-01-01' means the most recent state before that date or any state on that date. Also, consider using window functions for efficiency and to handle multiple moves correctly.

1. Understand the data and requirements

Identify the table containing user state logs, with columns like user_id, state, and timestamp. Clarify that 'in CA as of 2021-01-01' means the user's state was CA on that date, and 'subsequent log entry' means a later record showing a different state.

2. Filter users in CA on the given date

Select users who have a log entry with state = 'CA' and timestamp <= '2021-01-01', ensuring it's the latest entry before or on that date. Use a subquery or window function to get the most recent state per user up to that date.

3. Find subsequent state changes

For those users, find log entries after 2021-01-01 where the state is not 'CA'. Ensure that the change is from CA to another state, not just any non-CA entry.

4. Combine conditions and output

Join the results to return distinct user_ids that satisfy both conditions. Optionally, include the new state and the date of change for context.

Key Points to Mention

  • Use of window functions (e.g., ROW_NUMBER) to get the latest state before a date
  • Handling of multiple state changes and ensuring the first change after the date is considered
  • Importance of indexing on user_id and timestamp for performance
  • Clarifying ambiguous requirements like 'as of' and 'subsequent'
  • Considering edge cases such as users with no prior state or multiple moves
  • Writing a clear, readable query with comments

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