Snap SWE Interview: Technical Screen Coding and Craft Guide

Estimated read time: 8-10 minutes

Summary: Snap software engineer (SWE) technical screens evaluate coding and Craft. Examples include graph-style conversion ratios, powers of two, breadth-first search/depth-first search (BFS/DFS) themes, and role-specific mobile questions. The exact screen depends heavily on whether the role is backend, mobile, augmented reality (AR), ads, infrastructure, machine learning (ML), or platform.

TL;DR + FAQ

• Prepare for a structured technical screen with coding and craft signals.
• Practice 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 examples 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.

How should I practice?
Practice the known task shapes and the role-adjacent themes for your target team.

Can iOS candidates avoid algorithm-style coding tasks?
Do not assume that. Mobile paths can diverge from generic expectations, but they are still 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. 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 user interface (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, infrastructure, and platform paths can differ.

Not testing code. Weak testing is a common risk in this round.

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

Assuming role-specific examples are universal. Treat mobile/iOS and machine learning examples as specific to those paths.

---

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, infrastructure, or platform roles, prepare domain-specific data-flow follow-ups.
• Use a rhythm: clarify, solve, test, complexity, adapt.

---