← Figma Interview Insights

Figma·Software Engineer·Technical Phone Screen·Senior

SeniorPrefer not to say
Jul 2026

Summary

Figma data engineering interview with two SQL-heavy questions built around their actual product data model. The problems were trickier than they looked on the surface, especially the second one where tie-breaking rules added a lot of complexity.

Questions Asked (2)

Q1

Given a files table and a file_views table, write a SQL query that returns the first time each creator ever had one of their files viewed by someone else. The creator_id is a VARCHAR and the viewer's user_id is an INTEGER, so you need to handle the type mismatch.

Data ModelingProduct Analytics & Metrics
Author's notes

The type casting thing is what got me initially.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and the exact definition of 'first time'—likely the minimum view timestamp per creator. Then, join the files and file_views tables on file_id, handle the type mismatch by casting the creator_id to INTEGER (or the viewer's user_id to VARCHAR), and use a window function or GROUP BY with MIN to get the earliest view per creator.

Pro tip: Mention that casting creator_id to INTEGER could fail if there are non-numeric values; suggest using TRY_CAST or validating the data first. Also, consider whether the view must be by a different user (viewer's user_id != creator_id) and if so, add that filter.

1. Clarify requirements and schema

Ask about the table structures, the definition of 'first time', and whether the viewer must be different from the creator. Confirm the data types and any edge cases.

2. Handle type mismatch

Decide on a casting strategy: cast creator_id to INTEGER (e.g., using CAST or TRY_CAST) or cast user_id to VARCHAR. Discuss potential pitfalls like non-numeric creator_ids.

3. Join tables and filter

Join files and file_views on file_id. If required, filter out views where the viewer is the creator (user_id != creator_id).

4. Aggregate to find first view

Use GROUP BY creator_id and MIN(view_timestamp) to get the earliest view time per creator. Alternatively, use a window function like ROW_NUMBER() partitioned by creator_id ordered by view_timestamp.

5. Write and explain the final query

Compose the SQL, ensuring correct casting and aggregation. Explain the logic and any assumptions made.

Key Points to Mention

  • Type casting: CAST(creator_id AS INTEGER) or CAST(user_id AS VARCHAR), and the risks of each.
  • Using MIN(view_timestamp) with GROUP BY creator_id for simplicity.
  • Using ROW_NUMBER() or RANK() window functions for more control (e.g., if multiple views at same timestamp).
  • Filtering out self-views if the viewer is the creator (user_id != creator_id).
  • Indexing considerations: ensuring file_id and creator_id are indexed for performance.
  • Handling NULLs or invalid data in creator_id when casting.

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

Q2

For each creator, find their closest collaborator, defined as the user who was the first non-creator viewer of the creator's files the most times. Handle ties by earliest first-share timestamp, then smallest user_id.

Data ModelingAlgorithms & Data StructuresProduct Analytics & Metrics
Author's notes

This one is a proper multi-step problem.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the definitions of 'first non-creator viewer' and 'closest collaborator', then outline a two-step process: first, for each file, identify the earliest non-creator viewer; second, for each creator, count how many times each user was that first viewer, and select the user with the highest count, breaking ties by earliest first-share timestamp and then smallest user_id. Discuss how to implement this efficiently with SQL window functions or a streaming approach, and consider edge cases like files with no non-creator viewers.

Pro tip: Mention that you would validate the logic with a small sample dataset and check for ties in the first-viewer determination (e.g., if two users viewed at the exact same timestamp) to ensure deterministic results.

1. Clarify definitions and assumptions

Confirm what 'first non-creator viewer' means (e.g., earliest view event by a user other than the creator) and how to handle ties in view timestamps. Also clarify if 'first-share timestamp' refers to the file's first share event.

2. Identify first non-creator viewer per file

For each file, find the user who viewed it first among all non-creator users. Use a window function like ROW_NUMBER() partitioned by file_id, ordered by view_timestamp, and filter out the creator.

3. Count first-viewer occurrences per creator

For each creator, count how many times each user was the first non-creator viewer across all the creator's files. This gives a frequency distribution of collaborators.

4. Select closest collaborator with tie-breaking

For each creator, pick the user with the highest count. If multiple users tie, choose the one with the earliest first-share timestamp (the timestamp when the file was first shared by the creator), and if still tied, the smallest user_id.

5. Discuss implementation and edge cases

Explain how to implement this in SQL (e.g., using CTEs and window functions) or in code, and address edge cases like files with no non-creator viewers, missing timestamps, or performance considerations for large datasets.

Key Points to Mention

  • Use of window functions (ROW_NUMBER, RANK) to identify first viewers per file
  • Handling ties in view timestamps (e.g., if two users viewed at the same time, need a deterministic rule)
  • Definition of 'first-share timestamp' and how it's used for tie-breaking
  • Efficiency considerations: partitioning, indexing, and avoiding full table scans
  • Edge cases: files with no non-creator viewers, creators with no collaborators, missing data
  • Validation: testing with sample data and checking for correctness and determinism

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