Notion

Notion Software Engineer Interview

Focus areas and question themes aggregated from 11 current openings — pick any opening below and practice a voice mock calibrated to it.

Notion Software Engineer mock interview

A live voice mock calibrated to this role — real questions, the real follow-up rhythm, and a score at the end. Free to start.

Start the mock interview

Notion's Software Engineer family spans New Grad through Staff, but an unusually large share of postings - AI Workflows, Data Product Platform, both Developer Experience roles, Security, Trust, and even the AI-focused New Grad track - reference building or hardening LLM-powered features directly, even when the team isn't formally an 'AI team.' The other constant is ambiguity: nearly every posting explicitly asks how you scope an underspecified problem into a concrete, shippable plan, whether that's a database permission model, a security RFC, or a first AI agent feature.

What this interview tests

Productionizing AI and LLM features, not just prototyping them — AI Workflows, Data Product Platform, both Developer Experience postings, Security, Trust, and the AI-focused New Grad track all ask about taking an LLM or embeddings-based feature past the demo stage - adding guardrails, monitoring, evals, and handling real failure modes.
Scoping ambiguity into a shipped plan — Collections Experience, Data Product Platform, Infrastructure, Trust, and both New Grad postings all explicitly test how a candidate breaks down a genuinely underspecified problem, rather than assuming requirements are handed to them cleanly.
Long-term data model and architecture judgment — Collections Experience (the database block's schema and permissions) and the Go platform lead role both weigh decisions with multi-year consequences - schema choices, authorization architecture, platform trade-offs - over any single language or framework trivia.
Full-stack TypeScript ownership from UI to data layer — AI Workflows, Collections Experience, Data Product Platform, Web Infrastructure, and the general New Grad track all expect candidates to reason across the React/TypeScript frontend and the backend/data model (Postgres/MySQL) for the same feature, not just one layer.
Security, trust, and AI-safety guardrails as a distinct practice — Security and Trust are dedicated postings covering authentication migrations, fraud/abuse detection, and AI agent guardrails against prompt injection - but AI-safety thinking also bleeds into AI Workflows and Developer Experience, suggesting it's a company-wide concern, not siloed to one team.
Developer platform and tooling adoption — Both Developer Experience postings, Infrastructure, Web Infrastructure, and Data Product Platform all center on building internal tools, APIs, or platforms (CI, Go services, async task runners, ergonomic APIs) that other Notion engineers actually adopt, with adoption itself treated as a success metric.

Common question themes

Walk through an AI feature you built end-to-end - from an LLM or embeddings prototype to a production system with guardrails and monitoring.

Grounded in the AI Workflows, Developer Experience, and New Grad (AI) postings, all of which frame productionization, not just prototyping, as the real skill being tested.

Describe scoping a genuinely ambiguous, underspecified problem into a concrete plan you could actually ship.

This exact framing recurs across Collections Experience, Data Product Platform, Infrastructure, Trust, and both New Grad postings.

Tell me about a data model, schema, or architecture decision you made that had long-term consequences - what would you change in hindsight?

Directly asked in the Collections Experience posting and echoed in the Go platform lead posting's questions about platform trade-offs.

How would you build an evaluation set (evals) to know whether an AI feature or model change actually improved things?

Comes from the Collections Experience, Developer Experience, and New Grad (AI) postings, all of which treat evals as a first-class engineering deliverable, not an afterthought.

How would you design guardrails for an AI agent that has access to sensitive data or workflows?

Reflects the Security and Trust postings directly, with a matching theme in the Developer Experience posting's AI harness work.

How do you decide which reliability or observability guardrails are must-have versus something you add later?

Named in the Go platform lead and Infrastructure postings, both of which frame this as a real prioritization call under time pressure.

Frequently asked questions

Does every Notion Software Engineer role involve AI or LLM work?

Not literally every posting, but a striking majority reference LLMs, embeddings, or AI guardrails directly - AI Workflows, Data Product Platform, both Developer Experience roles, Security, Trust, and the AI-focused New Grad track all test this in some form, so AI product experience is a recurring differentiator even outside dedicated AI teams.

Is this role family only for senior or staff-level engineers?

No. It spans New Grad (with a general track and a dedicated AI-focused track) through Staff, represented here by the Go platform lead posting, with Mid and Senior postings filling out roles like Infrastructure, Web Infrastructure, Security, and Trust in between.

What does the Notion Software Engineer interview actually look like?

None of the postings in this family describe the loop structure, so there's nothing confirmed to report on round count or format. What is consistent is the emphasis on concrete past-project depth and ambiguity-scoping over generic technical trivia.

All Notion interviews