← Discord Interview Insights

Discord·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

Data modeling and SQL round at Discord for a Data Engineer role. The session was 45 minutes and focused entirely on designing a schema for video call logs and then writing queries against it. Pretty heads-down technical, no behavioral stuff at all.

Questions Asked (3)

Q1

Design a data model for video call logs, capturing both client-side and server-side data. What tables and columns would you use?

Data ModelingSystem Design
Author's notes

They gave some scaffolding upfront: a video table with user_id, video_id, call_duration, number_joins, number_rejoins, and timestamp, plus a user table with user_id and country.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and scope of the video call logs, then propose a normalized schema that separates client-side and server-side data into distinct tables linked by a common call session ID. Explain how the tables support key queries like call quality analysis, troubleshooting, and user history, and discuss trade-offs between normalization and denormalization for performance.

Pro tip: Demonstrate awareness of data volume and retention policies by suggesting partitioning or time-series optimizations for the server-side logs, and mention how you'd handle privacy and compliance (e.g., GDPR) when storing client-side data.

1. Clarify Requirements and Scope

Ask questions to understand what data needs to be captured, who will query it, and what the expected scale is. This ensures your design addresses real needs rather than assumptions.

2. Identify Core Entities and Relationships

Determine the main entities such as CallSession, ClientLog, and ServerLog, and define how they relate (e.g., one call session has many client and server log entries).

3. Design Tables and Columns

Propose specific tables with columns, data types, and keys. For example, a calls table for session metadata, a client_logs table for client-side events, and a server_logs table for server-side metrics.

4. Address Scalability and Performance

Discuss how the schema handles large volumes of data, including indexing, partitioning, and potential denormalization for read-heavy workloads.

5. Consider Privacy and Retention

Explain how you would handle sensitive data, data retention policies, and compliance requirements like GDPR or CCPA.

Key Points to Mention

  • Use a unique call session ID to link client-side and server-side logs.
  • Separate tables for client logs (e.g., device info, network type, user actions) and server logs (e.g., server region, media quality metrics, errors).
  • Include timestamps with timezone awareness for all log entries.
  • Consider using a time-series database or partitioning for server logs due to high write volume.
  • Index key columns like call_id, user_id, and timestamp for efficient querying.
  • Discuss data retention and anonymization strategies for privacy compliance.

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

Q2

Write a query to find the number of video calls per country per day.

Product Analytics & Metrics
Author's notes

Straightforward join between the video and user tables, group by country and date.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema: identify the tables for calls, users, and countries, and the timestamp column. Then write a SQL query that joins these tables, groups by country and date, and counts distinct call IDs. Finally, consider edge cases like time zones and null values.

Pro tip: Mention that you'd confirm the definition of a 'video call' (e.g., duration > 0) and whether to count distinct calls or participants, as this affects the query. Also, discuss how to handle time zones to ensure daily counts align with business definitions.

1. Clarify the schema

Ask about the tables involved (e.g., calls, users, countries) and the relevant columns (call_id, user_id, country, call_timestamp). Confirm the granularity of the data.

2. Define metrics and filters

Determine what constitutes a video call (e.g., call_type = 'video', duration > 0) and whether to count distinct calls or participants. Clarify if all calls should be included or only completed ones.

3. Handle time zones and date grouping

Decide how to convert timestamps to the appropriate time zone for daily grouping. Use DATE_TRUNC or equivalent to group by day.

4. Write the SQL query

Join the necessary tables, apply filters, group by country and date, and count distinct call IDs. Use appropriate aggregation functions.

5. Validate and optimize

Check for nulls, duplicates, and performance considerations (e.g., indexing). Discuss how to handle edge cases like calls spanning midnight.

Key Points to Mention

  • Use COUNT(DISTINCT call_id) to avoid double-counting if there are multiple participants per call.
  • Join tables on appropriate keys (e.g., user_id to get country).
  • Group by country and DATE(call_timestamp) after converting to the desired time zone.
  • Consider whether to include calls with zero duration or failed calls.
  • Discuss indexing on timestamp and country columns for performance.
  • Mention potential data quality issues like missing country information.

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

Q3

Extend the previous query to show the number of video calls per country per day for rolling windows of 7, 14, and 30 days, for each date present in the database.

Product Analytics & MetricsTechnical Trade-offs
Author's notes

This is where I slowed down.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and definitions (e.g., what constitutes a video call, how to handle missing dates). Then outline a SQL solution using window functions with ROWS BETWEEN to compute rolling sums for each window size, ensuring you partition by country and order by date. Finally, discuss performance considerations and potential optimizations for large datasets.

Pro tip: Mention that you would pre-aggregate daily counts in a CTE or subquery before applying window functions to avoid redundant computation and improve performance. Also, consider using a calendar table to ensure all dates are present, even if there were no calls.

1. Clarify Requirements and Assumptions

Confirm the definition of a video call (e.g., call type, duration threshold) and whether the rolling windows should include the current day. Ask about the expected data volume and performance constraints.

2. Design the Query Structure

Outline a multi-step approach: first, aggregate daily video call counts per country; second, use window functions to compute rolling sums for 7, 14, and 30 days. Consider using a calendar table to fill missing dates.

3. Write the SQL with Window Functions

Use SUM() OVER (PARTITION BY country ORDER BY date ROWS BETWEEN N-1 PRECEDING AND CURRENT ROW) for each window size. Ensure the date range is handled correctly, especially for the first few days where the window is incomplete.

4. Address Edge Cases and Performance

Discuss handling of missing dates (e.g., left join with calendar), and performance optimizations like indexing on (country, date) and pre-aggregation. Mention potential use of materialized views for large-scale data.

5. Validate and Interpret Results

Explain how you would validate the query (e.g., check sums for a specific country/date manually) and interpret the rolling metrics to derive insights, such as trends in video call adoption.

Key Points to Mention

  • Use of window functions with ROWS BETWEEN for rolling sums
  • Partitioning by country and ordering by date
  • Handling missing dates with a calendar table or date spine
  • Pre-aggregating daily counts to improve performance
  • Indexing strategy on (country, date) for efficient window operations
  • Consideration of time zones and date boundaries

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