← Citi Interview Insights

Citi·Data Scientist·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
Jun 2026

Summary

Interviewed for a Data Scientist role at Citi, heavy SQL focus around crypto trading metrics. Two tasks back to back, both required getting the join logic and date math exactly right under pressure.

Questions Asked (2)

Q1

Given a trades table and a users table, compute the share of active traders in the last 30 days who made at least 3 trades in that same window. Return the count of active traders, count of power traders, and the ratio as a decimal.

Product Analytics & MetricsData Modeling
Author's notes

I got the denominator wrong at first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the definitions of 'active trader' and 'power trader' and the time window. Then, write a SQL query that filters trades to the last 30 days, aggregates by user to count trades, and joins with the users table to identify active traders. Finally, compute the counts and ratio, ensuring correct handling of users with zero trades.

Pro tip: Always confirm whether 'active traders' are defined as users who made at least one trade in the last 30 days or users who were active on the platform (e.g., logged in) regardless of trades. This distinction drastically changes the result and shows attention to detail.

1. Clarify definitions and assumptions

Define 'active trader' (e.g., users with at least one trade in the last 30 days) and 'power trader' (e.g., users with at least 3 trades in the last 30 days). Confirm the time window and whether to include all users or only those with trades.

2. Filter trades to last 30 days

Use a WHERE clause to select trades within the last 30 days from the current date. Ensure the date column is correctly identified and that the time zone is consistent.

3. Aggregate trades per user

Group by user_id and count the number of trades. This gives the trade count per user in the window.

4. Join with users and compute metrics

Join the aggregated trade counts with the users table to get all users (or only those with trades). Compute the count of active traders (those with >=1 trade) and power traders (those with >=3 trades).

5. Calculate ratio and present results

Compute the ratio as power_traders / active_traders (as a decimal). Handle division by zero if there are no active traders. Present the three values clearly.

Key Points to Mention

  • Definition of active trader: typically a user with at least one trade in the last 30 days.
  • Definition of power trader: a user with at least 3 trades in the last 30 days.
  • Use of date filtering with a dynamic date function (e.g., CURRENT_DATE - INTERVAL '30 days') to ensure the window is relative to today.
  • Aggregation using GROUP BY and COUNT, and the need to handle users with zero trades (e.g., using LEFT JOIN or filtering).
  • Calculation of the ratio as a decimal, with attention to division by zero.
  • Potential edge cases: users with multiple accounts, trades outside the window, and time zone considerations.

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

Q2

For each signup cohort, compute 7-day retention defined as a user making at least one trade on exactly the 7th calendar day after their signup date. Include users who never traded.

Product Analytics & MetricsData ModelingTechnical Trade-offs
Author's notes

The 'include users who never traded' part is where people probably drop the ball and I almost did.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the definition of a signup cohort (e.g., by signup date) and the retention metric (trade on exactly day 7 after signup). Then outline a SQL-based approach: generate a cohort table of all users with signup dates, left join to trade activity filtered to day 7, and aggregate to compute the percentage of users who traded on day 7, including those with no trades.

Pro tip: Emphasize that retention is calculated on a per-cohort basis and that users who never traded are included in the denominator, which is crucial for accurate retention rates. Also, mention the importance of handling time zones consistently to avoid off-by-one errors in day calculations.

1. Clarify definitions and requirements

Confirm what defines a signup cohort (e.g., daily, weekly) and the exact retention window (day 7 after signup). Ensure understanding that 'exactly the 7th calendar day' means the trade must occur on that specific date, not within a range.

2. Identify data sources and schema

Locate the users table (with signup dates) and trades table (with user IDs and trade timestamps). Determine how to join them and filter trades to the 7th day after signup.

3. Construct cohort and retention calculation

Create a cohort of all users by signup date. For each user, check if they have at least one trade on the 7th day after signup. Use a LEFT JOIN to include users with no trades, and flag retention as 1 if they traded on day 7, else 0.

4. Aggregate and compute retention rate

Group by cohort (signup date) and calculate the retention rate as the sum of retained users divided by the total number of users in the cohort. Ensure the denominator includes all users, even those who never traded.

5. Validate and present results

Sanity-check the results (e.g., retention rates between 0 and 1). Consider edge cases like users who signed up less than 7 days ago (they should be excluded or handled appropriately). Present findings with clear labels and possibly a visualization.

Key Points to Mention

  • Definition of signup cohort (e.g., grouped by signup date)
  • Retention metric: trade on exactly day 7 after signup
  • Inclusion of users who never traded in the denominator
  • Use of LEFT JOIN to ensure all users are considered
  • Handling of time zones and date boundaries to avoid off-by-one errors
  • Exclusion of users who haven't reached day 7 yet (if analyzing recent cohorts)

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