Snap SWE Interview: Technical Screen Coding and Craft Guide

Estimated read time: 8-10 minutes

Summary: Snap SWE technical screens evaluate coding and Craft. Public examples include graph-style conversion ratios, powers of two, BFS/DFS themes, and role-specific mobile questions. The exact screen depends heavily on whether the role is backend, mobile, AR, ads, infra, ML, or platform.

TL;DR + FAQ

• Technical screens are supported by structured and candidate-reported sources.
• Reported examples include conversion ratios, powers of two, BFS/DFS, and mobile-specific questions.
• Craft means the screen may care about implementation quality and product fit, not only final output.
• Mobile/iOS and ML reports should be treated as role-specific.
• Expect follow-ups that change constraints or domain context.

Quick FAQ

Is this a standard coding screen?
Often, but Craft and role-specific domain can matter.

Are exact tasks known?
Some examples are reported, but many are themes or role-adjacent.

Can iOS candidates avoid LeetCode-style work?
Do not assume that. A mobile report diverged from generic expectations, but it is role-specific.

What should I clarify?
Ask whether the screen is algorithmic, craft-oriented, mobile-specific, ML-specific, or product/domain-oriented.

---

1) How the technical screen works

The technical screen is usually an engineer-led gate. It may be live coding, coding plus craft discussion, or role-specific technical evaluation. Snap's official competency framing makes it useful to think in terms of Craft: clean implementation, judgment, tradeoffs, and ability to adapt.

---

2) Technical tasks you may face

• You are given conversion ratios between symbols, such as A to B and B to C. Answer conversion queries, then handle disconnected symbols and cycles.
• Write a function that determines whether a number is a power of two. Now discuss edge cases for zero, negatives, overflow, and language-specific integer behavior.
• Given a graph, use BFS or DFS to find whether two nodes are connected. Then return the shortest path or explain why the path does not exist.
• Build a small ranking or filtering helper for a Snap feature. Add a follow-up where the input updates continuously.
• For a mobile path, explain or implement a Swift/iOS state-management or UI data-flow task, then handle lifecycle or concurrency edge cases.
• For an ML or ads path, process scored candidates and return a ranked subset while handling ties, missing scores, or diversity constraints.
• After solving the base task, change one constraint: larger input, lower latency, streaming updates, or product-specific invalid cases.

---

3) What strong performance looks like

Strong candidates clarify constraints, name data structures, write clean code, test edge cases, and adapt when the interviewer changes the task. For Snap, connect technical choices to the product or platform surface when the task invites it.

---

4) Common failure modes

Ignoring domain variance. Mobile, AR, ads, ML, infra, and platform paths can differ.

Not testing code. Candidate reports repeatedly surface weak testing as a risk.

Under-explaining reasoning. Craft is visible through how you reason, not only code.

Assuming role-specific reports are universal. Treat mobile/iOS and ML examples as specific.

---

5) How to prepare

• Review graphs, BFS, DFS, maps, bit operations, arrays, sorting, and ranking helpers.
• Practice explaining edge cases before coding.
• For mobile roles, prepare Swift/iOS lifecycle, state, and concurrency examples.
• For ML, ads, infra, or platform roles, prepare domain-specific data-flow follow-ups.
• Use a rhythm: clarify, solve, test, complexity, adapt.

---