figma Data Engineer Interview: Questions, Experience & Prep (2026)

Figma is a collaborative design platform and one of the most recognizable product-led companies actively hiring data talent in 2026. Knok's jobradar tracked 542 Data Engineer openings across India as of July 2026, with Bangalore leading at 92 roles and Delhi at 66. Figma alone has 179 open roles posted, signalling sustained hiring across functions.

Candidates report that Figma's interview process typically includes a recruiter screen, one or two technical rounds covering SQL and data modelling, a system design discussion, and a final behavioural panel. Round structures and names vary by team and level, so treat this as a general framework, not a guaranteed sequence.

Figma's core product is a browser-based design tool used by millions of teams globally. Their data problems reflect that scale: collaborative session events, version history, billing signals, plugin activity, and growth analytics all generate high-volume event streams. As a Data Engineer, you are expected to build reliable pipelines from raw events to clean, documented datasets that analysts and product managers can act on.

The questions below are drawn from publicly shared Figma interview experiences and general patterns for product-analytics companies. Treat them as preparation topics, not a guaranteed question list.

1. Write a SQL query to find the top 10 most active organisations in the past week, ranked by the number of distinct active users.
2. Design a pipeline that ingests Figma's real-time collaboration events and makes them queryable by the analytics team within a few minutes of each event occurring.
3. How would you model a 'document version history' fact table? Walk through your grain, dimensions, and slowly changing dimension strategy.
4. A dbt incremental model is running slower than expected after a schema change upstream. How do you diagnose and fix it?
5. We have two event tables, one from the web client and one from the desktop client, that track the same user actions with slightly different schemas. How do you unify them into a single canonical table?
6. Explain how you would use partitioning and clustering in BigQuery to reduce query costs on a large events table.
7. A dashboard used by the growth team has been showing incorrect retention numbers for a week. Walk me through how you would find and fix the root cause.
8. How do you ensure data quality in a pipeline that has no formal SLA but feeds a critical business report?
9. Tell me about a time you had to deprecate or replace a pipeline that was already in production and actively used by downstream teams.
10. How would you design a metrics layer so that 'monthly active users' means exactly the same thing across every team and every tool in the company?
11. Figma recently acquired a smaller company. How would you approach integrating their data into our existing warehouse without disrupting current pipelines?
12. What is your approach to documenting data pipelines so that a new hire can understand, debug, and extend them without asking you?

Q: Design a pipeline that ingests Figma's real-time collaboration events and makes them available for product analytics within a few minutes.

*Situation:* At my previous company, we had a similar challenge with a collaborative SaaS product. Design events were being written to flat files and batch-loaded once a day, making real-time product decisions impossible.

*Task:* I was asked to redesign the ingestion layer so analysts could query session-level data within a few minutes of an event occurring.

*Action:* I proposed a streaming architecture: events published to Kafka topics by the application layer, consumed by a Flink job that validated schema and enriched records with user and org metadata from a side-input, then written to an Iceberg table in object storage. A dbt incremental layer on top produced clean, analytics-ready tables on a frequent schedule. I added a dead-letter queue for malformed events and set up alerts on consumer lag so the team could catch issues early.

*Result:* End-to-end latency dropped from hours to a few minutes. The analytics team moved from daily batch dashboards to near-real-time product reports, and the dead-letter queue caught a schema drift issue from a mobile client release before it could corrupt production tables.

---

Q: A dashboard used by the growth team has been showing incorrect retention numbers for a week. Walk me through how you would find and fix the root cause.

*Situation:* At a previous role, our weekly retention metric dropped sharply over several days and the growth team flagged it as a possible product regression. Leadership was concerned it reflected a real change in user behaviour.

*Task:* I needed to determine quickly whether the drop was a real product signal or a data quality issue, and fix it either way.

*Action:* I started by comparing raw event counts before and after the anomaly date against the aggregated retention table, looking for row count drops or unexpected nulls. I traced the data lineage back through dbt to the source event table and found that an upstream team had renamed a key event without updating the downstream pipeline. I wrote a patch model to backfill the affected date range using the corrected event name, then added a dbt test to alert if that event count fell below a historically consistent threshold.

*Result:* We confirmed within a few hours that the drop was a tracking gap, not a product problem. The backfill restored accurate numbers, and I shared a root-cause write-up with the growth team so they understood exactly what had changed and how to prevent similar gaps in future.

---

Q: Tell me about a time you had to deprecate or replace a pipeline that was already in production and actively used.

*Situation:* A legacy pipeline at my previous company had been built quickly to answer a one-off analyst request but had quietly become the source of truth for several dashboards and a weekly executive report.

*Task:* I needed to replace it with a properly modelled, tested version without causing any data outage for downstream consumers.

*Action:* I first audited all downstream dependencies by searching our BI tool and dbt DAG for references to the old table. I built a new pipeline in parallel using proper incremental logic and dbt tests, then ran both versions side by side for a full billing cycle, comparing outputs daily. I published a migration guide for each downstream team and set a clear cutover date. On cutover day, I renamed the old table with a '_deprecated' suffix and added a view alias pointing to it, so any team that missed the migration would see a clear message directing them to the new table.

*Result:* All downstream dashboards and the executive report migrated without any data outage. The new pipeline also reduced query costs noticeably, consistent with efficiency gains publicly reported by teams that have migrated from nightly batch jobs to incremental Iceberg models.

For SQL and coding questions: Think out loud before you write anything. State the grain of the expected result, identify edge cases (nulls, duplicates, users with no events in the window), then build the query in stages. Figma interviewers typically care as much about your reasoning as the final syntax.

For pipeline design questions (RADIO framework): Start with Requirements: what latency, what data volume, what consumers need. Then cover Architecture at a high level. Then Dive into the components that matter most for this specific problem. Cover Operations next: monitoring, alerting, and failure recovery. Close with the trade-offs you consciously accepted and why.

For data quality and debugging questions: Follow a structured trace. Define the symptom precisely. Isolate the layer where data breaks (source, ingestion, transformation, serving). Form a hypothesis, verify it with evidence, then fix and prevent recurrence. Avoid jumping straight to 'I would rewrite the pipeline', as interviewers want to see methodical diagnosis first.

For behavioural questions (STAR): Keep Situation to one or two sentences. Spend the most time on Action, specifically what you personally did versus what the broader team did. Close with a concrete Result and, if relevant, what you would do differently in hindsight.

For metrics definition questions: Align on business intent first (what decision will this number drive?), then define the population, the event or action being measured, the time window, and any exclusion rules. This approach mirrors how mature data teams handle metrics standardisation.

Figma's data teams, based on candidates' publicly reported experiences, value a few qualities above raw technical knowledge.

Ownership mindset. Interviewers want to hear that you treat a broken pipeline as your problem even if you did not build it. Stories where you waited for someone else to act on a data issue tend to land poorly.

Clear communication about trade-offs. Figma is a product-led company where data engineers work closely with analysts and product managers. Interviewers want to see you explain technical decisions in plain terms, not just defend a choice with jargon.

Precision with data modelling. Questions about grain, SCD types, and metrics definitions come up frequently. Vague answers like 'I would normalise the table' without specifying what and why signal shallow experience.

Comfort with ambiguity. Real pipeline problems at a product company rarely have a single correct answer. Interviewers reward candidates who ask clarifying questions, state their assumptions explicitly, and adapt when the interviewer adds a new constraint mid-question.

Collaboration signals. Even in technical rounds, interviewers notice whether you acknowledge that a good data model requires input from analysts, engineers, and product managers, not just a solo engineering decision.

Week 1: SQL and data modelling depth

Practise window functions, recursive CTEs, and query optimisation on platforms like LeetCode or StrataScratch. Separately, revise star schema design: understand slowly changing dimensions, bridge tables, and aggregate tables. Practise sketching a schema for Figma's core product (documents, users, organisations, events) from scratch, thinking carefully about what grain each fact table should carry.

Week 2: Pipeline architecture and tooling

Review streaming concepts: Kafka topics, consumer groups, and at-least-once versus exactly-once delivery guarantees. Understand how dbt incremental strategies differ and when to use each. Search for Figma's engineering blog and read any posts about their data infrastructure. Candidates report Figma uses BigQuery and dbt, so hands-on familiarity with both helps.

Week 3: Behavioural prep and system design

Prepare four to six STAR stories covering: a pipeline you built from scratch, a data quality incident you resolved, a time you worked across teams, and a technical decision you had to justify to a non-technical stakeholder. Practise the RADIO framework for system design questions out loud, ideally with a peer who can push back on your assumptions.

Week 4: Mock interviews and company research

Do at least two full mock interviews with a peer or on a structured practice platform. Research Figma's recent product launches and think about what data problems those features would create. Prepare two or three genuine questions for each interviewer about their team's data stack and current challenges. While your focus is on interview prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you do not miss a Figma opening during this period.

Skipping clarifying questions. Candidates who jump straight into a pipeline design without asking about latency requirements, expected data volume, or downstream consumers often solve the wrong problem. Figma interviewers expect you to define the scope before you design the solution.

Over-indexing on tools instead of principles. Saying 'I would use Spark' is not an answer. Saying 'I would use a distributed processing framework because the dataset exceeds single-node capacity and we need fault-tolerant transformations' is. Interviewers care about the reasoning, not just the tool name.

Vague STAR answers. Answers like 'we improved performance significantly' or 'the team was happy' are weak. Be specific about what you personally did and what the outcome was. If you do not have an exact number, say so directly and describe the qualitative impact instead.

Ignoring lineage and documentation. Many candidates forget to mention how they would document a pipeline or communicate schema changes to downstream teams. At a company where analysts depend on data engineers to maintain trust in the data, this is a meaningful gap in your answer.

Treating every pipeline as a batch problem. Figma's product generates real-time collaborative events. If your default answer to every ingestion question is a nightly batch job, you signal unfamiliarity with the kinds of data problems the company actually solves.