Figma QA and SDET Interview Questions (2026)

TL;DR

Strong Figma QA and SDET answers connect test technique to collaborative design risks: concurrent edits, offline recovery, permissions, visual fidelity, large-file performance, plugins, APIs, and cross-client consistency. This guide supplies 48 original practice questions, runnable examples, grading criteria, and common mistakes without presenting them as a leaked interview bank.

Key Takeaways

• Model files, nodes, permissions, versions, clients, and operations before listing test cases.
• Treat convergence, no silent data loss, and correct authorization as core collaboration invariants.
• Separate document correctness from canvas rendering, export fidelity, and local GPU behavior.
• Use deterministic model and API tests broadly, then reserve end-to-end checks for critical workflows.
• Debug real-time failures by finding the first incorrect state across client, transport, service, and storage.
• Discuss performance with workloads, percentiles, resource ceilings, and user-visible budgets.
• Confirm the actual interview format with the recruiter because public reports cannot define every team process.

Figma qa sdet interview questions should prepare you to reason about a real-time design platform, not recite generic definitions. Strong answers protect the user's document, collaboration state, permissions, visual output, and creative flow while explaining what to test at the model, service, API, browser, and exploratory layers.

This is a practice guide based on public product behavior and established testing methods, not a claim about Figma's private question bank or a fixed hiring sequence. Verify the role's product area, coding language, and interview format with your recruiter, then adapt these answers to your own evidence.

TL;DR

1. Figma QA SDET Interview Questions: Product Quality

Q: How would you test a new collaborative design editor?

Start by modeling users, files, pages, nodes, components, comments, versions, permissions, and export targets. Map create, edit, move, duplicate, share, publish, undo, restore, and delete operations to state transitions and failure modes. Prioritize silent data loss, cross-user divergence, unauthorized access, and incorrect output before cosmetic inconvenience. Cover deterministic rules below the UI, integration at service boundaries, a small set of browser journeys, and focused exploratory sessions around creative workflows.

Q: Which quality risks deserve attention before a Figma-like launch?

The first tier is document integrity, recoverability, tenant isolation, access control, and convergence because failure can destroy work or trust. The next tier includes rendering fidelity, input responsiveness, compatibility, accessibility, export accuracy, and reliable integrations. Rank each risk by impact, exposure, detectability, and reversibility rather than assigning every feature equal test time. Tie the release recommendation to evidence for the riskiest changed paths and explicitly list what remains uncertain.

Q: How do you test when the feature specification is incomplete?

Turn ambiguity into examples: who performs the action, on which object, from what state, with what permission, and what another collaborator observes. Identify invariants such as no invisible mutation, no privilege escalation, stable node identity, and recoverable user content. Use product consistency, accessibility standards, prior behavior, prototypes, and stakeholder decisions as fallible oracles. Record resolved examples as executable tests while preserving open questions instead of silently choosing behavior.

Q: What would you do in your first hour testing a new component-property feature?

Read the intended user outcome and sketch the state model for definitions, instances, overrides, reset, detach, publish, and library update. Create a compact matrix across property type, nested depth, permission, existing override, and old versus new client. Explore one normal workflow, one destructive transition, and one cross-file update while capturing network and console evidence. Finish the hour with observed risks, coverage notes, minimal reproducers, and the next highest-value experiment.

2. Real-Time Collaboration and Convergence

Q: How would you test two users editing the same property at the same time?

Control two authenticated clients and synchronize their starting document version. Issue conflicting changes within a bounded interval, vary arrival order and reconnect order, then compare the final server state and both client states. The oracle comes from the documented conflict rule, not from whichever UI updates last on one machine. Repeat with duplicated messages, delayed acknowledgments, refresh, undo, and a third observer to expose ordering assumptions.

Q: What does convergence mean, and how would you verify it?

Convergence means replicas that receive the same accepted operations eventually represent the same logical document, even if delivery order differs where the algorithm permits reordering. Compare canonical trees or semantic hashes after all messages and acknowledgments settle, excluding ephemeral cursor and selection state. Generate operation permutations involving insert, move, rename, and delete, then retain the smallest divergent sequence as a regression fixture. A UI screenshot alone is insufficient because two documents may look alike while their node identity or hierarchy differs.

The following local Node test demonstrates an order-independent last-writer-wins oracle with an explicit actor tie-break. Save it as convergence.test.mjs and run node --test convergence.test.mjs.

import test from 'node:test';
import assert from 'node:assert/strict';

function mergeOperations(operations) {
  const fields = new Map();
  for (const operation of operations) {
    const current = fields.get(operation.field);
    const newer = !current || operation.clock > current.clock ||
      (operation.clock === current.clock && operation.actor > current.actor);
    if (newer) fields.set(operation.field, operation);
  }
  return Object.fromEntries(
    [...fields.entries()].sort().map(([field, operation]) => [field, operation.value])
  );
}

test('replicas converge after receiving the same operations in different orders', () => {
  const edits = [
    { field: 'fill', value: '#ff0000', clock: 7, actor: 'amy' },
    { field: 'fill', value: '#0000ff', clock: 7, actor: 'zoe' },
    { field: 'name', value: 'Primary button', clock: 8, actor: 'amy' }
  ];
  assert.deepEqual(mergeOperations(edits), mergeOperations([...edits].reverse()));
  assert.deepEqual(mergeOperations(edits), { fill: '#0000ff', name: 'Primary button' });
});

Q: How would you test collaborator cursors and presence?

Presence is transient, so judge timeliness, identity, cleanup, and privacy rather than durable document equality. Exercise join, rapid pointer movement, tab backgrounding, temporary disconnect, duplicate sessions, rename, and sign-out across several clients. Check that stale cursors expire, reconnection does not multiply participants, and viewers never receive presence for a file they cannot access. Measure update latency under a declared network profile, but avoid treating every dropped intermediate coordinate as a defect if the latest position arrives promptly.

Q: How would you test comments, mentions, and notifications?

Build a state table for comment open, edit, resolve, reopen, delete, and reply, crossed with owner, editor, viewer, removed member, and external guest. Verify mention parsing for duplicate names, Unicode, deleted accounts, and users outside the file's access boundary. Notification assertions should cover recipient set, deep link, deduplication, ordering, and the current permission at click time. Inspect the stored thread and delivery event separately so an email failure is not misdiagnosed as comment loss.

For deeper transport practice, review Playwright WebSocket testing.

3. Offline Editing, Persistence, and History

Q: How would you test offline editing and reconnect?

Define exactly which actions are supported offline and what durable local state survives a tab or process restart. Disconnect before an edit, during an edit, after local confirmation, and during upload, then reconnect against unchanged and independently changed remote documents. Check for clear sync status, bounded retries, preserved intent, deterministic conflicts, and no silent loss. Storage exhaustion, token expiry, device clock skew, and repeated online-offline flapping reveal cases a single clean reconnect misses.

Q: What is your autosave test strategy?

Treat autosave as a pipeline from local mutation through batching, acknowledgment, persistence, and restored display. Instrument revision identifiers and timestamps, make controlled edits at debounce boundaries, close the tab at each stage, and reopen from a clean client. Verify semantic content rather than a reassuring Saved label, since the label can advance before durable storage. Add quota errors, server rejection, retry, rapid undo, and long idle sessions to validate both recovery and honest user messaging.

Q: How would you validate version history?

Create revisions with distinguishable node changes, authors, comments, and times, then compare the restored tree to the chosen historical snapshot. Restoration should create the specified current state without rewriting immutable audit facts or leaking versions to an unauthorized user. Test deletion, library references, branched work, named versions, retention boundaries, and a client that remained open during restore. A visual comparison helps, but node hierarchy, component linkage, text, and metadata require structural checks too.

Q: What edge cases matter for undo and redo in a multiplayer editor?

Clarify whether undo is local-intent based, document-global, or scoped another way. Interleave one user's grouped actions with another user's edits, then test undo after selection change, reconnect, remote deletion, and component update. The key oracle is that undo reverses the intended operation without erasing unrelated accepted work or resurrecting invalid references. Redo stacks also need coverage after a new local edit, navigation to another page, and collaborator activity.

4. Canvas Rendering, Visual Fidelity, and Export

Q: How do you test a canvas rendered with WebGL or another GPU path?

Separate model correctness from raster output and interaction hit-testing. Render a curated scene corpus covering transforms, clipping, masks, gradients, text, blend modes, deep nesting, extreme zoom, and large coordinates across supported GPU and fallback paths. Compare stable scenes with approved images while also asserting scene-graph properties and pointer-to-object mapping. Capture browser, operating system, GPU, driver, device scale factor, and render backend whenever a mismatch appears.

Q: How do you prevent visual regression tests from becoming noisy?

Stabilize fonts, browser build, viewport, device scale, color scheme, animation, test data, and rendering host before adjusting tolerance. Mask only content proven irrelevant, because broad masks can hide a real layout shift. Baseline changes require human review linked to the intended design change, and repeated unexplained diffs should trigger investigation rather than automatic approval. Keep a small high-value visual suite and use structural assertions for behavior that pixels express poorly.

Install Playwright once, save the test as canvas-visual.spec.ts, create the baseline, and rerun it. The second command is the verification run.

npm install -D @playwright/test
npx playwright install chromium
npx playwright test canvas-visual.spec.ts --update-snapshots
npx playwright test canvas-visual.spec.ts

import { test, expect } from '@playwright/test';

test('renders the stable canvas scene', async ({ page }) => {
  await page.setContent(`<canvas id='stage' width='240' height='120'></canvas>`);
  await page.evaluate(() => {
    const canvas = document.querySelector<HTMLCanvasElement>('#stage');
    if (!canvas) throw new Error('canvas missing');
    const context = canvas.getContext('2d');
    if (!context) throw new Error('2D context unavailable');
    context.fillStyle = '#ffffff';
    context.fillRect(0, 0, 240, 120);
    context.fillStyle = '#5b5bd6';
    context.fillRect(20, 20, 80, 60);
    context.strokeStyle = '#111111';
    context.lineWidth = 4;
    context.strokeRect(20, 20, 80, 60);
  });
  await expect(page.locator('#stage')).toHaveScreenshot('stable-stage.png', {
    animations: 'disabled',
    maxDiffPixels: 0
  });
});

See visual regression in CI for baseline governance and artifact handling.

Q: How would you test PNG, SVG, and PDF export?

Vary selected node, bounds, scale, format options, transparency, effects, fonts, images, and deeply nested components. Decode each result and assert dimensions, page count, vector or text semantics where promised, plus visual fidelity under a controlled renderer. Cover cancellation, invalid destination, oversized output, expired asset links, and multiple simultaneous exports. Round-trip behavior matters only where import is supported, and expected lossy conversions should be communicated rather than marked as corruption.

Q: How would you investigate a font rendering difference?

Record the exact font file, weight, feature settings, fallback chain, shaping engine context, locale, browser, operating system, and zoom. Compare glyph selection, measured bounds, line breaks, and final pixels to locate whether the first divergence is font availability, shaping, layout, or rasterization. Test missing and slow-loading fonts as separate product behaviors. Do not solve every cross-platform variation by increasing screenshot tolerance, since a changed line break can alter the design meaningfully.

5. Performance, Scale, and Reliability

Q: How would you performance-test a very large design file?

Define representative files by node count, nesting, text volume, image bytes, component instances, effects, and page distribution rather than calling one artifact large. Measure cold open, warm open, pan, zoom, selection, edit acknowledgment, search, memory, CPU, and recovery using percentile distributions. Run controlled workloads on named hardware and browsers, then compare against an agreed budget and prior build. Profile the slow path so the result identifies parsing, network, layout, rendering, or garbage collection instead of merely reporting elapsed time.

Q: How would you load-test multiplayer collaboration?

Model rooms, participants per room, operation mix, message size, think time, burst shape, and reconnect behavior from plausible usage. Track accepted operation rate, end-to-end acknowledgment latency, broadcast delay, disconnects, errors, queue depth, and convergence after the run. Include hot documents because one room with many editors stresses different resources than many two-person rooms. A realistic test preserves ordering and session semantics rather than blasting unrelated WebSocket frames as fast as possible.

Use performance testing interview questions to rehearse workload and percentile trade-offs.

Q: How do you detect a browser memory leak during a long editing session?

Automate a repeatable cycle such as create, duplicate, delete, undo, change page, and return to an idle state. Sample heap, DOM nodes, GPU resources where observable, and process memory after allowing comparable garbage-collection opportunities. Growth alone is not proof, so compare retained object classes and dominator paths across cycles and against a control build. The defect report should include the workload, slope, eventual user impact, and a trace or profile that points to retention.

Q: Which reliability metrics would you monitor after release?

Choose signals tied to user outcomes: successful file opens, edit acknowledgment latency, reconnect success, export completion, crash-free sessions, save errors, and permission-denied anomalies. Segment by build, browser, platform, file complexity, region, and feature exposure so a minority failure is not averaged away. Pair service measures with client telemetry because a healthy endpoint can still feed a broken editor state. Every alert needs an owner, threshold rationale, diagnostic context, and a response action.

6. Figma REST API, Webhooks, Permissions, and Plugins

Q: How would you test the Figma REST API file endpoint?

Authenticate with the intended token type and least required scope, then test accessible, missing, inaccessible, malformed, and branch file keys. Validate status, schema, document root, requested depth, selected node behavior, metadata, and conditional expectations for large or unsupported content. Exercise throttling and transient failure without assuming a fixed universal quota, since applicable limits can depend on endpoint and account context. Never print the token or store production document payloads as public CI artifacts.

This current Playwright API test uses Figma's documented endpoint and personal or plan token header. Save it as figma-file-api.spec.ts, set FIGMA_TOKEN and FIGMA_FILE_KEY, then verify with npx playwright test figma-file-api.spec.ts.

import { test, expect } from '@playwright/test';

test('returns a document root for an accessible Figma file', async ({ request }) => {
  const token = process.env.FIGMA_TOKEN;
  const fileKey = process.env.FIGMA_FILE_KEY;
  test.skip(!token || !fileKey, 'Set FIGMA_TOKEN and FIGMA_FILE_KEY');

  const response = await request.get(
    `https://api.figma.com/v1/files/${encodeURIComponent(fileKey!)}?depth=1`,
    { headers: { 'X-Figma-Token': token! } }
  );
  expect(response.status()).toBe(200);
  const file = await response.json();
  expect(file.document.type).toBe('DOCUMENT');
  expect(file.version).toEqual(expect.any(String));
});

Q: How would you test webhook delivery?

Create a subscription in an isolated context and first verify the documented ping callback and passcode. For each event, assert authentication data, context, payload contract, retry handling, and an idempotent consumer keyed by a stable delivery or business identity available to the integration. Simulate duplicates, delays, out-of-order arrival, endpoint timeout, invalid passcode, deletion, and subscription pause. The receiver should acknowledge safely and move expensive work behind a durable boundary rather than risk repeated side effects.

Q: How would you test sharing permissions?

Construct a role and resource matrix for owner, editor, viewer, guest, removed member, link user, team member, and administrator across files, folders, branches, comments, and exports. Attempt both UI and direct API actions because a hidden control does not prove server authorization. Test permission changes during an open session, cached links, copied node URLs, embeds, search, notifications, and previously issued download URLs. Audit evidence should identify the actor and action without exposing document content unnecessarily.

Contract skills transfer directly here, so practice with API contract testing using Pact.

Q: How would you test a third-party plugin?

Assess manifest permissions, editor modes, selection assumptions, dynamic page loading, network access, UI messaging, cancellation, and document mutations. Use disposable files to compare the tree before and after plugin execution, including partial failure and repeated invocation. Malformed plugin data, huge selections, missing fonts, locked nodes, and unavailable external services deserve explicit cases. Security review should verify the plugin cannot read or transmit more than its declared function requires, while compatibility tests cover supported editor contexts.

7. Automation Architecture and CI

Q: What test architecture would you propose for a Figma-like web product?

Place document algebra, permission rules, and merge invariants in fast deterministic model tests. Exercise storage, messaging, API contracts, export services, and renderer boundaries with component and integration suites, then keep a focused end-to-end layer for critical user outcomes. Add visual, accessibility, performance, security, migration, and exploratory work according to their distinct risks. The architecture should optimize trustworthy feedback and diagnosis, not maximize the number of browser scripts.

Q: How would you automate a canvas workflow when DOM locators are limited?

Drive accessible controls and stable product commands through role, label, or supported test hooks, then assert both the underlying document state and visible canvas result. Convert known document coordinates through the application's public interaction model only when the workflow truly requires pointer input. Keep coordinate helpers aware of viewport, zoom, pan, and device scale, and fail with those values attached. Avoid reaching into private production internals unless the team deliberately exposes a versioned test seam.

Q: How do you reduce flakiness in real-time end-to-end tests?

Give every worker isolated users and files, expose correlation identifiers, and wait for observable domain states such as an acknowledged revision rather than sleeping. Control network faults explicitly and reset them in teardown, even after failure. When multiple clients participate, log their operation sequence and server revision so ordering bugs remain diagnosable. Quarantine is temporary containment with an owner and deadline, not a way to keep the dashboard green.

Q: How would you organize CI for this risk profile?

Run static checks and model tests on each change, then targeted integration and browser tests based on affected ownership boundaries. Shard only suites whose data and infrastructure are independent, while serializing scenarios that intentionally share a document. Pin rendering environments for visual baselines and retain traces, screenshots, console logs, and service correlation IDs on failure. Scheduled jobs can cover broad browser, GPU, longevity, and load matrices that would make pull-request feedback impractical.

8. Accessibility, Input, Compatibility, and Localization

Q: How would you test accessibility in a canvas-heavy editor?

Begin with complete tasks: open a file, navigate layers, select an object, change a property, comment, share, and recover from an error without a pointer. Inspect names, roles, states, focus order, announcements, modal trapping, zoom, contrast, and shortcuts, including dynamic collaboration updates. A canvas may require an alternative semantic representation, so verify that the accessibility tree communicates meaningful objects and current selection rather than thousands of decorative primitives. Combine automation with keyboard and assistive-technology sessions because static rules cannot prove task completion.

See accessibility testing with Playwright for practical browser checks.

Q: How would you test keyboard shortcuts safely?

Create a command matrix by operating system, keyboard layout, editor context, focused control, selection type, and modifier state. Confirm that typing into text fields does not trigger canvas commands and that browser or assistive-technology conventions are not captured unexpectedly. Test repeated keydown, keyup loss, key remapping, menus, discoverability, and undo grouping. Assertions should cover the resulting document command, not merely receipt of a keyboard event.

Q: How would you prioritize browser and GPU coverage?

Start with supported browsers and usage evidence, then add recently changed engines, graphics paths, strategic enterprise environments, and historically unstable combinations. Use a stable scene corpus to compare accelerated and fallback rendering, while functional suites isolate engine-independent behavior. Pairwise selection can reduce ordinary combinations, but a rewritten renderer or new GPU backend deserves direct depth. Record exact browser build, operating system, GPU, driver, feature flags, and display scale in every rendering failure.

Q: What localization risks are specific to a design tool?

Beyond translated chrome, test Unicode layer names, bidirectional text, shaping, line breaking, locale fonts, numeric fields, decimal separators, sorting, and localized shortcuts. Mixed-direction text inside rotated or constrained frames can expose both layout and editing defects. Sharing, search, comments, export, and plugin data must preserve grapheme clusters rather than split code units. Pseudolocalization catches expansion and hard-coded strings, while native review evaluates meaning and culturally appropriate terminology.

9. Debugging, Incidents, and Release Decisions

Q: One collaborator cannot see an update that others see. How do you debug it?

Capture file, user, client revision, operation ID, server revision, timestamps, build, and connection state without collecting unnecessary design content. Trace the update through local dispatch, transport send, authorization, persistence, publication, subscription, client apply, and render to find the first missing or incorrect state. Compare the failing client with a passing observer and test refresh only as a discriminating experiment. A refresh fix narrows the possibilities toward subscription or local cache, but it does not by itself prove either cause.

Q: An export fails once in fifty runs. What evidence do you collect?

Preserve the source file key or sanitized fixture, selected node IDs, export options, request ID, response, worker logs, timing, memory pressure, and resulting artifact if any. Compare successful and failed executions by backend instance, queue delay, asset dependency, and input complexity. Repetition with one controlled variable can reveal races, expiring URLs, resource ceilings, or a particular node type. Report the measured frequency and conditions instead of labeling the issue random.

Q: How would you respond to a production incident involving possible lost edits?

Protect user work first by stopping risky rollout or mutation paths when authorized, preserving logs and durable state, and enabling a tested recovery route. Establish affected versions, time window, accounts, and document operations while security and privacy rules govern artifact access. Communicate confirmed facts, uncertainty, mitigations, and the next update time to the incident group. After recovery, add the missing invariant, detector, rollback check, and test at the layer where the failure first became observable.

Q: Would you release with a known visual defect?

The decision depends on affected workflow, customer reach, accessibility impact, brand or content fidelity, workaround, regression risk, and reversibility. Compare the defect against the value and timing of the release, then offer options such as scope removal, feature control, staged exposure, or a verified follow-up. A one-pixel decorative shift and exported text clipping do not belong in the same category. State a recommendation and the evidence behind it while keeping final product ownership explicit.

10. Coding, Data Structures, and Testability

Q: How would you test a function that applies node operations?

Partition operations into create, update, move, and delete, then cover valid transitions, missing nodes, duplicate IDs, cycles, stale versions, and repeated application. Assert document invariants after every operation rather than checking only the final example output. Generate short operation sequences and shrink any failure to a minimal reproducer. Determinism, immutability promises, and error semantics matter as much as the happy path.

Q: Where would property-based testing help?

Document trees and edit sequences have far more combinations than handcrafted examples can cover. Generate valid trees and operations, then assert invariants such as unique IDs, acyclic ancestry, stable serialization, undo round trips where defined, and convergence under permitted reorderings. Bias generators toward deep nesting, boundary sizes, and operations near deleted or moved nodes. Keep named regression examples for production failures because random generation complements, rather than replaces, readable cases.

Q: Write an algorithm to find duplicate node IDs. What would you discuss?

Traverse the tree once, store seen IDs in a set, and collect any ID encountered again. The expected time is O(n), with O(n) auxiliary space for n nodes, while recursion depth may overflow on adversarially deep documents. An iterative stack avoids that call-stack risk and can carry the node path for a diagnostic message. Clarify whether shared references are legal, because a graph requires visited-object handling separate from duplicate logical IDs.

import test from 'node:test';
import assert from 'node:assert/strict';

function duplicateNodeIds(root) {
  const seen = new Set();
  const duplicates = new Set();
  const stack = [root];
  while (stack.length > 0) {
    const node = stack.pop();
    if (seen.has(node.id)) duplicates.add(node.id);
    seen.add(node.id);
    for (const child of node.children ?? []) stack.push(child);
  }
  return [...duplicates].sort();
}

test('reports each duplicate logical ID once', () => {
  const tree = {
    id: 'document',
    children: [{ id: 'button' }, { id: 'frame', children: [{ id: 'button' }] }]
  };
  assert.deepEqual(duplicateNodeIds(tree), ['button']);
});

Save this as duplicate-node-ids.test.mjs and verify it with node --test duplicate-node-ids.test.mjs.

Q: How would SQL help investigate collaboration failures?

Query immutable operation records by document, actor, revision, and bounded time window, then order them by the server's sequencing field rather than client clock alone. Join authorization decisions and delivery acknowledgments carefully to locate a missing transition without multiplying rows. Use a replica or approved diagnostic path, parameterize identifiers, and avoid selecting raw user content unless essential and authorized. Explain transaction isolation and retention limits before treating query output as a complete history.

Refresh core query reasoning with SQL interview questions for testers.

11. Behavioral and Cross-Functional Judgment

Q: Tell me about disagreeing with a developer about a defect.

Choose a real example where the disagreement concerned evidence or impact, not personality. Explain the shared user outcome, the experiment or telemetry used to resolve uncertainty, and any product or engineering constraint that changed your view. Make your own action visible, including how you listened and what trade-off was accepted. Close with the mechanism improved, such as a clearer requirement, monitor, test oracle, or rollout guard.

Q: How do you discuss a defect that escaped your testing?

State the customer impact and your responsibility without exaggerating personal blame or hiding behind the team. Reconstruct why the existing strategy missed it, whether the gap involved risk modeling, environment, data, oracle, observability, or a conscious trade-off. Describe containment and the durable change at the most effective layer. A credible answer also acknowledges residual limits instead of promising that the category can never recur.

Q: How have you influenced requirements before implementation?

Describe a concrete ambiguity, such as what happens to an offline editor when access is revoked. Show the examples, state transition, or failure modes you brought to design and engineering, then identify the decision made before code hardened around an assumption. Quantify the result only if the measurement is defensible. The quality signal is earlier risk reduction and shared clarity, not ownership of another discipline's work.

Q: What does a healthy quality culture look like?

Teams expose uncertainty early, make systems testable, review production evidence, and treat quality as a product and engineering responsibility. QA contributes specialized exploration, risk modeling, tooling, and independent evidence without becoming a final inspection queue. Failures lead to better controls and learning rather than hidden flaky tests or individual blame. Leaders protect time for reliability work and evaluate outcomes, not automation counts.

12. Interview Questions and Answers: Figma QA SDET Interview Questions

Q: What is the difference between severity and priority?

Severity describes the magnitude of harm to users, data, security, or system behavior. Priority describes when the organization should act given reach, timing, workaround, commitments, and fix risk. Silent document corruption may be severe even with limited reports, while a visible launch-page typo can become urgent without being technically severe. Both labels need evidence and may change as exposure becomes clearer.

Q: When would you use an exploratory charter instead of a scripted case?

Use a charter when the risk is important but the behavior space or oracle still benefits from learning, such as conflict handling across unstable networks. The charter defines target, risk, timebox, and useful evidence while allowing observations to guide the next experiment. Scripted cases are stronger for stable, repeatable checks with known expected results. Mature strategies turn important discoveries into durable regression coverage without eliminating future exploration.

Q: What is the difference between a mock, a contract test, and an end-to-end test?

A mock gives controlled local responses and fault cases, but it can drift from the provider. A contract test checks that consumer expectations and provider behavior remain compatible at their boundary. An end-to-end test proves a selected user outcome across deployed components but is slower and harder to diagnose. Use all three selectively, with contract verification limiting mock drift and a small end-to-end set checking wiring and critical journeys.

Q: What would your first 90 days in a QA or SDET role focus on?

First learn customers, architecture boundaries, current quality signals, release flow, and the team's most expensive failure patterns. Pair with design, engineering, support, security, and data partners while contributing useful testing to an active change. Next, improve one evidence gap with a scoped test seam, diagnostic field, risk model, or reliable suite rather than proposing a framework rewrite immediately. By day 90, share measured learning, remaining risks, and a jointly owned next investment.

How Interviewers Grade Your Answers

Interviewers usually score the reasoning behind your coverage more than the length of your test list. A strong response clarifies the user and promise, identifies the object and state model, prioritizes credible failures, chooses appropriate layers, defines oracles, and explains what evidence would change a decision.

Use this answer frame when a scenario feels broad:

1. Clarify the user, operation, supported clients, and consistency or recovery promise.
2. Name two or three high-impact risks before listing ordinary cases.
3. Model relevant states, permissions, data dimensions, and concurrency.
4. Assign checks to model, API, integration, UI, visual, performance, security, or exploratory layers.
5. Define observable results, diagnostics, and exit evidence.

Coding answers are graded for correctness, boundaries, complexity, naming, tests, and communication. Behavioral answers need personal decisions and honest outcomes. Product answers should show curiosity about public behavior without inventing internal Figma architecture, metrics, or interview rounds. You can rehearse scenario delivery in the QAJobFit practice interview and tailor stories from your resume in the resume workspace.

Common Mistakes

• Presenting these practice questions as leaked or guaranteed Figma interview content.
• Listing generic login and button cases before document loss, convergence, permissions, or export fidelity.
• Saying real time without defining ordering, acknowledgment, conflict, and convergence expectations.
• Treating a visual screenshot as proof that the stored document tree is correct.
• Hiding restricted UI while never testing direct API authorization.
• Raising screenshot tolerance until meaningful font or layout defects disappear.
• Load-testing raw messages without realistic rooms, operation mixes, or reconnect behavior.
• Waiting with arbitrary sleeps instead of observable revisions and acknowledgments.
• Quoting universal automation percentages, performance thresholds, or rate limits.
• Giving an incident story that ends with another person fixing the bug.
• Inventing internal architecture when a clear assumption would be more credible.
• Using confidential employer artifacts or customer files in an interview example.

Conclusion

Figma QA and SDET interview preparation is strongest when it combines product judgment with engineering depth. Practice protecting document integrity, collaboration convergence, offline recovery, visual and export fidelity, permission enforcement, performance, accessibility, APIs, and diagnosable automation.

Pick four questions from different sections, answer each aloud in under three minutes, then accept one deeper follow-up. Replace the model answer with your own verified project evidence so the interviewer hears how you actually make quality decisions.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Canva QA and SDET Interview Questions (2026)
• Notion QA and SDET Interview Questions (2026)
• 500+ QA and Manual Testing Interview Questions and Answers (2026)
• Adyen QA and SDET Interview Questions (2026)
• Airtable QA and SDET Interview Questions (2026)
• Airwallex QA and SDET Interview Questions (2026)