Forward Deployed Software Engineer

Builds full-stack prototypes with AI assistance, ships features behind flags, and turns live user feedback into working code.

Interview kit for Forward Deployed teams. Includes questions, evaluation criteria, and guides for 4 experience levels.

Buy this kit · $29.99Preview questions

Included for Forward Deployed Engineer II

Interview questions
54
Competency and attitude questions, assigned to the right round.
Evidence indicators
341
Positive and negative indicators for each question.
Role capabilities
21
Expected proficiency for each experience level.

Explore a question from the kit

Choose the experience level. The questions, criteria, and examples below update to match.

Round 2 · Feature Ownership & AI Orchestration32 competency questions

AI-Assisted Development & Tooling

AI-Assisted Development & Agentic Coding

Directs agentic coding tools autonomously across an assigned area, crafting prompts and managing sessions to produce working code fast.

Expected at Forward Deployed Engineer II

Sample competency question

Describe a time you directed an AI coding tool to do a substantial piece of work. How did you keep it moving in the right direction?

Ask once, as written, then allow silence. A helpful rephrase may hand the candidate the answer.

Positive indicators

  • Concrete direction techniques
  • Timely intervention story
  • Checkpoint verification described

Negative indicators

  • Let it run without direction
  • Could not recover from wrong turns
  • No verification of the result

Directing agentic tools autonomously across an area requires independent proficiency in prompt design and session management; orchestration at scale is senior scope.

What to look for in this role
Ryan Mahoney
What makes Engineer II genuinely hard to hire for is that the candidate must own outcomes, not just deliverables, inside an assigned product area. They decide what to build and what to cut against area-level goals, which means a polished demo proves nothing on its own. The signal that matters is a shipped feature where the data model survived real traffic, the instrumentation was actually read, and a hypothesis was killed on usage evidence. Most mid-level candidates can show you velocity; far fewer can show you the moment they chose not to ship because the data said no. I look for that decision in the artifacts and in the numbers sitting behind it.

What’s in the download

Level guides for Forward Deployed Engineer, Forward Deployed Engineer II, Senior Forward Deployed Engineer and Staff Forward Deployed Engineer.

Before you post

  • 1Ready-to-use job description
  • 3Video screening prompts
  • 8Resume screening criteria
  • 2Knockout screening questions

In the room

  • 32Competency interview questions
  • 22Attitude interview questions
  • 1Hands-on work simulations
  • 1Presentation prompts
  • 2Coding tests

At the debrief

  • Progression framework
  • Exceeds / Meets / Below anchors for every exercise
  • 4Interview plan with time per round

Interview questions for this role

Preview competency and attitude questions for the selected experience level. Each question includes criteria to help interviewers evaluate the response.

32 Competency Questions

1 of 32

  1. Discipline

    AI-Assisted Development & Tooling

  2. Job requirement

    AI-Assisted Development & Agentic Coding

    Directs agentic coding tools autonomously across an assigned area, crafting prompts and managing sessions to produce working code fast.

  3. Expected at Forward Deployed Engineer II

    Directing agentic tools autonomously across an area requires independent proficiency in prompt design and session management; orchestration at scale is senior scope.

Interview round: Feature Ownership & AI Orchestration

Describe a time you directed an AI coding tool to do a substantial piece of work. How did you keep it moving in the right direction?

Positive indicators

  • Concrete direction techniques
  • Timely intervention story
  • Checkpoint verification described

Negative indicators

  • Let it run without direction
  • Could not recover from wrong turns
  • No verification of the result

22 Attitude Questions

1 of 22

Accountability Mindset

Owns the full lifecycle of the work they touch — documentation, maintenance, decision logs, post-mortems, and honest reporting — and keeps artifacts current as the world changes, rather than letting skills, runbooks, and channels silently decay.

Interview round: Recruiter Screen

Describe how you kept the records around a feature you owned current as it reshaped. What specifically did you maintain, and when?

Positive indicators

  • Concrete artifacts and cadence
  • Records reflect the real state, including failures
  • Mentions others relying on them

Negative indicators

  • Sees records as bookkeeping done at the end
  • No decision log or equivalent in their story
  • Post-mortems sanitized of failures

Build a consistent evaluation process

Use application prompts, resume criteria, and practical exercises to gather useful evidence at each stage of hiring.

Start with application questions

Application prompts collect information before an interview. Answers to disqualifying questions determine eligibility; other responses are saved for review.

Knock-out Questions

1 of 2

Application Screen: Knock-out

Do you have professional experience building and shipping production full-stack web applications with TypeScript?

Yes
Qualifies
No
Auto-decline

Video-Response Questions

1 of 3

Application Screen: Video Response

A stakeholder sees a prototype you shipped in a day and starts treating it as production, asking when the full roadmap can be committed to it. Walk through how you would communicate what the prototype can and cannot prove, and what you would commit to next.

Candidate experience

REC
0:42 / 2:00
1Record
2Review
3Submit

Response time

2 min

Format

Recorded video

Review resumes against shared criteria

Use the same criteria to review each eligible application and decide who advances to the interview stage.

Resume Review Criteria

8 criteria
Evidence of owning a feature from problem through build and launch to measurement, including the call on what to cut, within an assigned product area.
Evidence of directing AI coding tools with independent judgment and keeping production quality while doing so.
Evidence of instrumenting shipped work, reading what users actually did, and using that data to keep or change the direction.
Evidence of running or participating in live sessions with users and reshaping the build in the moment based on what happens.

Does the resume show relevant prior work experience?

Is the resume complete, well-organized, and free from formatting, spelling, and grammar mistakes?

Does the resume indicate required academic credentials, relevant certifications, or necessary training?

Does the cover letter or personal statement convey clear relevance and familiarity with the job?

Explore how candidates approach the work

Interview rounds use the competency and attitude questions outlined above, then add tests, work simulations, and presentations that reveal deeper evidence about how the candidate thinks and works.

Coding Test

1 of 2

Live Interview · Coding Test

Without AI

60 minutes. You own this feature. Deliver a working vertical slice — schema, procedures, and a passing test — and be ready to defend the API surface decisions.

You own a small feature in an assigned area: users can group notes into collections and reorder notes within a collection. The schema and tRPC router already exist as a half-finished vertical slice. Complete it end to end: (1) finish the Drizzle schema for collections and collection membership with an integer position column; (2) implement the tRPC surface — create collection, add note (position at end), reorder note (move to position) — with Zod validation that rejects out-of-range moves; (3) the reorder operation must be atomic: either the order changes completely or not at all; (4) write one Vitest test covering the reorder validation. Do not add new dependencies.

With AI

60 minutes, same feature, AI allowed. You direct an agentic coding tool; you decide the API surface and the invariants. The assistant will happily generate plausible-looking procedures — your job is to set the contract it must honor and audit the result.

Same collections feature brief. This time you run an agentic coding session: write the plan the agent follows, including the API surface you want (which procedures exist, what each accepts, what invariants they enforce) and the constraint that reorder is atomic and out-of-range moves are rejected. Two decisions are yours, and the agent's plausible defaults will get both wrong: (1) extensibility — collections will later support shared multi-user access, so position semantics and owner checks must not assume single-owner code paths that would have to be rewritten; (2) the reorder contract — the agent will likely implement a swap-positions behavior, which corrupts order when a note moves across collections; decide the position model that survives that case. After the agent finishes, audit the diff against your plan, fix what it got wrong, and be ready to explain what you rejected and why.

Response time

60 min

Positive indicators

  • Treats the feature as owned: schema, API, and test hang together as one slice
  • Rejects invalid reorder moves with structured errors and keeps the operation atomic
  • Makes deliberate API surface calls (what the procedures accept and return) and can defend them
  • Orders rows in SQL so ordering stays correct as collections grow
  • Wrote a plan that encoded the invariants the agent would otherwise get wrong, then audited against it
  • Chose a position model that survives cross-collection moves and explained the tradeoff
  • Named specific generated choices they rejected and the reason
  • API surface is defensible against the future shared-access requirement

Negative indicators

  • Ships the API without owning the schema or the ordering invariant
  • Lets reordering corrupt positions or apply partially
  • Duplicates validation ad hoc inside procedures instead of enforcing it at the boundary
  • Let the agent's swap-based reorder ship; order corrupts across collections
  • Plan was generic; the audit found nothing because expectations were never written down
  • Accepts generated code whose invariants they cannot restate

Presentation Prompt

Walk us through a feature you owned end to end. Show the problem, the hypothesis you formed, what you shipped, the usage evidence you read afterward, and the call you made — keep, cut, or reshape. Focus on your reasoning at each decision point rather than on the code itself.

Format

deck-and-walkthrough · 20 min · ~2 hr prep

Audience

Hiring manager and a product or analytics partner — the same audience as the 'Experiment Retrospective' round already scheduled for this level.

What to prepare

  • A short deck of 3-5 slides built from your own work on one feature you owned
  • Optional: a dashboard view or event data you can talk through
  • The decision log for that feature: what was tried, kept, and killed

Deliverables

  • 3-5 slides
  • A verbal walkthrough of your evidence and your decisions

Ground rules

  • Use only work you are permitted to share
  • Do not prepare any new analysis for this presentation; what you show should already exist
  • The deck is a starting point — the discussion is about your judgment

Scoring anchors

Exceeds
Tells a coherent hypothesis-to-evidence-to-decision story with specific data, honest failure, and a keep-or-kill call clearly connected to an area goal.
Meets
Describes what they built and what they measured, and makes a reasoned call between keep, cut, or reshape.
Below
Narrates the build as activity with no outcome, no evidence cited, and no decision made.

Response time

20 min

Positive indicators

  • Leads with the outcome and what the evidence showed
  • Distinguishes observation from interpretation in the story
  • Articulates the tradeoffs behind a keep-or-kill call
  • Cites specific events or metrics rather than impressions
  • Acknowledges what they got wrong and what they learned
  • Connects the feature's outcome to the area goal it served

Negative indicators

  • Polishes the story and omits the evidence that did not cooperate
  • Treats the build as the deliverable instead of the outcome
  • Cannot state the hypothesis the feature was testing
  • Blames users or tooling for a result they owned
  • Shows no evidence of reading usage data at all

Work Simulation Scenario

Scenario. You are a Forward Deployed Engineer II owning features in one product area. You have just shipped a prototype that moves the weekly-planning flow onto a new interaction model, behind a feature flag. This session extends the 'Collaborative Hypothesis Build' work simulation in your Peer Pairing & Delivery Quality round: the prototype is live, and you are about to run a feedback session with the operations lead at your largest customer — the user who shaped the original problem. The user has real reactions and a real agenda. Run the session, reshape the build in the moment, and decide what ships next while protecting the evidence you still need.

Problem to solve. Run the live co-building session: hear the user's real reaction, decide in the moment which changes to make now versus after evidence, and hold the line on the hypothesis you need to prove — then walk us through how you would instrument and measure the change.

Format

stakeholder-roleplay · 40 min · ~2 hr prep

Success criteria

  • You hear the real workflow cost behind the user's stated request
  • You make explicit now-versus-later decisions and say them out loud
  • You keep the user engaged while declining what the evidence does not support
  • You name the metric or event that will arbitrate the change

What to review beforehand

  • The Collaborative Hypothesis Build brief from the Peer Pairing & Delivery Quality round
  • The prototype's feature flag and the events currently instrumented
  • The last week of usage evidence for the new flow

Ground rules

  • This is a live conversation — decide in the moment; there is no later session
  • Do not produce any document; walk us through your approach verbally
  • The user cannot see the dashboard — you own the evidence
  • Close with a concrete commitment, not a vague 'we will see'

Roles in scenario

Operations Lead, Largest Customer (customer, played by cross_functional)

Motivation. Wants the new flow to actually save their team time, and is skeptical because the old flow worked badly for years.

Constraints

  • Has concrete, specific examples from their team's usage this week
  • Will push for the change they want regardless of the experiment design
  • Cannot see the usage dashboard — the candidate holds the evidence

Tensions to introduce

  • Opens with 'this is slower for my team than the old one' based on one anecdote
  • Asks for a change that contradicts the hypothesis being tested
  • Grows reluctant when the candidate proposes gating the change behind more measurement

In-character guidance

  • Speak from concrete team examples, not abstractions
  • Push back twice when the candidate resists the requested change
  • Softens if the candidate shows they heard the real workflow cost and explains the tradeoff

Do not

  • Do not solve the problem for the candidate
  • Do not escalate to hostility — stay at professional pressure
  • Do not accept a bare 'we will see'; do not refuse a clear rationale twice

Scoring anchors

Exceeds
Hears the real workflow cost, reshapes the build in the moment with explicit now-versus-later calls, and leaves the user committed to a measured follow-up.
Meets
Runs a genuine co-building session, distinguishes ask from cost, and lands a concrete commitment with a named arbiter metric.
Below
Appeases the user, ignores their friction, or ends the session without a decision or a measurable follow-up.

Response time

40 min

Positive indicators

  • Separates the user's stated request from the underlying friction
  • Makes in-the-moment decisions about what changes now versus after evidence
  • Commits to a concrete follow-up and names the metric that will arbitrate
  • Keeps the user engaged while declining the unproven ask
  • Ties the session outcome back to the feature-flag and instrumentation plan
  • Explains the tradeoff in the user's terms rather than hiding behind data

Negative indicators

  • Agrees to the user's full wishlist to keep the session happy
  • Dismisses the user's friction because the data does not show it yet
  • Lets the session drift with no decision or follow-up
  • Hides the tradeoff instead of explaining it
  • Commits to changes with no way to measure them

Progression framework

This table shows how competencies evolve across experience levels. Each cell shows competency at that level.

AI-Assisted Development & Tooling

4 competencies

CompetencyForward Deployed EngineerForward Deployed Engineer IISenior Forward Deployed EngineerStaff Forward Deployed Engineer
AI-Assisted Development & Agentic Coding

Uses agentic coding tools to scaffold features and refactor small modules under senior direction, managing sessions and verifying output.

Directs agentic coding tools autonomously across an assigned area, crafting prompts and managing sessions to produce working code fast.

Orchestrates agentic coding across a whole area and larger codebase, choosing when to delegate and designing the workflow others follow.

Sets the organization's AI-assisted development standards and tooling choices, measuring and raising the team-wide velocity they enable.

AI Output Review & Verification

Reviews AI-generated diffs for correctness and security with checklist discipline before merging, never accepting output on trust.

Audits agent output critically across an assigned area, catching subtle correctness and security issues and feeding fixes back into prompts.

Owns the verification bar for an area's generated code, designing review and CI checks that keep AI-assisted velocity honest.

Sets the governance for agent output across the organization, defining the verification pipeline that makes AI-generated code safe at scale.

Developer Tooling & Automation

Builds small internal scripts and tools that automate personal workflow friction, with human-in-the-loop checkpoints.

Builds packaged CLIs and internal tools for an assigned area that measurably speed up the team, keeping human-in-the-loop checkpoints.

Designs developer tooling and autonomous agents for a whole area, balancing automation against human judgment and onboarding the team.

Owns platform-level tooling choices that accelerate every embedded engineer, publishing tooling and standards others adopt.

LLM-Powered Feature Development

Prototypes hosted LLM features with guidance, wiring APIs behind guardrails and noting cost and quality concerns for review.

Integrates hosted LLM features end to end with cost and quality guardrails, evaluating them for quality, safety, and regression before and after shipping.

Designs the evaluation and guardrail patterns for an area's LLM features, weighing quality, cost, and failure modes in build decisions.

Sets organizational patterns for LLM feature development — evaluation harnesses, cost control, and safety review — that every team uses.

Delivery, Quality & Operations

5 competencies

CompetencyForward Deployed EngineerForward Deployed Engineer IISenior Forward Deployed EngineerStaff Forward Deployed Engineer
Continuous Delivery & Release Management

Ships small frequent deploys behind feature flags with preview links, following the team's rollout patterns and checking quality gates.

Owns the release path for an assigned area — flags, staged rollouts, and previews — as the default way to ship.

Sets the delivery cadence and rollout strategy for an area, using per-user targeting and staged rollouts to de-risk every deploy.

Sets the organization's release engineering standards, designing the platform capabilities that make small frequent deploys safe everywhere.

Instrumentation & Usage Analytics

Instruments shipped features with clean event schemas and reads dashboards and SQL to report what users actually did.

Owns instrumentation for an assigned area, configuring autocapture and defining the metrics that measure feature behavior.

Defines the metrics that measure an area's outcomes, connecting usage evidence to product decisions and reporting them credibly.

Sets the instrumentation and metrics standards across the organization, making usage evidence the shared basis for product direction.

Production Operations & Reliability

Triages incidents from alerts under direction, diagnosing errors from logs and tracing and escalating what is unclear.

Owns incident response for an assigned area, diagnosing errors from monitoring and tracing and keeping the pipeline observable.

Runs reliability for a whole area, designing alerting and tracing so incidents are caught and fixed before users feel them.

Sets organizational reliability standards and observable-architecture choices that keep prototype-born features dependable at scale.

Security & Vulnerability Management

Assesses vulnerabilities in AI-generated code with scanning tools and guidance, treating generated output as untrusted until proven secure.

Owns security review for an assigned area's generated code, shipping fixes for findings and keeping scanners in the loop.

Sets the security bar for an area, reviewing generated code and designing the scanning and review pipeline that catches issues early.

Sets organizational policy for securing AI-generated code, making security review a fast, built-in step rather than a bottleneck.

Test Engineering & Quality Assurance

Writes unit and integration tests for features built with AI assistance, covering the edge cases that keep generated code honest.

Designs test strategy for an assigned area's AI-assisted features, using tests as the verification net for agent-generated changes.

Sets the testing and quality bar for an area, designing edge cases and CI gates that keep refactored and generated code honest.

Establishes organizational testing standards for AI-assisted delivery, making test coverage the condition for prototype velocity.

Full-Stack Product Engineering

4 competencies

CompetencyForward Deployed EngineerForward Deployed Engineer IISenior Forward Deployed EngineerStaff Forward Deployed Engineer
Data Modeling & Schema Management

Designs simple relational schemas and seed data for scoped features, running migrations in staging and verifying them before moving on.

Owns schema changes for an assigned area, moving data safely through migrations and staging verification and keeping models aligned with product needs.

Leads data model decisions for a whole area, weighing schema evolution against prototype speed and coaching others on migration discipline.

Sets organization-wide conventions for data modeling and schema migration that keep prototype-speed development safe as features scale.

Full-Stack Service & API Development

Builds small, scoped services and type-safe APIs end to end under review, following existing stack patterns and starter templates to ship a working feature in a day.

Owns service and API features in an assigned product area, choosing integration patterns and keeping the data model, services, and UI coherent without handoff.

Sets the API and service patterns for a whole area, directing agentic tools to build and refactor modules and reviewing the architecture decisions behind them.

Defines cross-area service and API standards that every embedded engineer builds on, and uses them to de-risk platform-level bets with working prototypes.

Product UI Implementation

Implements responsive, accessible screens from an established design language, composing components into a coherent surface with review.

Owns the UI of features in an assigned area, extending the design language where needed and keeping accessibility and responsive behavior consistent.

Directs UI implementation across an area, turning session feedback into interface changes the same day and setting component conventions.

Sets cross-area UI standards and design-system choices that make prototype velocity possible without losing coherence or accessibility.

Rapid Prototyping on Real Data

Builds small prototypes on real product data within a day under a defined brief, keeping the data real and the scope tight.

Turns ideas from live sessions into runnable prototypes in the same session, on real data, and decides what is worth taking further.

Runs the prototype loop for a whole area — from session idea to working product in hours — and promotes the survivors without translation loss.

Uses rapid prototyping on real data to validate strategic bets before the team commits, modeling what a full build would require.

Product Strategy & Technical Leadership

4 competencies

CompetencyForward Deployed EngineerForward Deployed Engineer IISenior Forward Deployed EngineerStaff Forward Deployed Engineer
Knowledge Codification & Documentation

Writes session notes and short technical notes that capture what was learned, in the team's established formats.

Codifies workflows and decisions from an assigned area into runbooks and checklists that make the knowledge reusable.

Owns the codification of an area's prototype-to-production paths, producing skill files and runbooks the whole team builds on.

Designs the organization's knowledge system, publishing patterns and standards that let every embedded engineer reuse hard-won lessons.

Open Source Development & Maintenance

Contributes small fixes and documentation to internal or open-source libraries, following contribution and review conventions.

Ships small open-source libraries from solved internal problems, maintaining them with stable APIs and semver discipline.

Owns an open-source project's direction, triaging issues and setting release discipline that keeps dependents on stable versions.

Uses open-source standing to shape industry practice, shipping tooling that multiplies the team's — and the ecosystem's — speed.

Product Strategy & Technical Standards

Follows the team's AI-delivery standards and contributes to RFC and ADR discussions with observations from their work.

Shapes direction in an assigned area, evaluating tools for the stack and proposing standards grounded in usage evidence.

Sets an area's direction and standards for AI-assisted delivery, governing agent output quality and shaping cross-area product direction.

Shapes company product direction and sets the cross-area standards for AI-assisted delivery that the whole team builds on.

Strategic Validation & Growth

Validates scoped hypotheses with prototypes, reporting results and what a full build would require.

Validates area-level bets with prototypes before committing to a build, persuading stakeholders with prototype evidence.

Owns validation of an area's strategic bets, pressure-testing shipping speed on solo products and guiding what the team commits to.

Validates company-level strategic bets with working prototypes before the team commits, persuading leadership with evidence.

User-Centered Discovery & Experimentation

4 competencies

CompetencyForward Deployed EngineerForward Deployed Engineer IISenior Forward Deployed EngineerStaff Forward Deployed Engineer
Evidence-Driven Product Iteration

Tracks outcomes for a scoped prototype, cutting scope deliberately and citing usage evidence in the next build's requirements.

Owns a feature end to end from problem to shipped and measured, synthesizing usage evidence into the next prototype's requirements.

Owns outcome metrics for a whole area, deciding what to keep or kill from evidence and setting the iteration cadence.

Bases strategic bets on evidence rather than opinion, building the measurement discipline that lets failing directions be killed early.

Experimentation & A/B Testing

Runs small experiments from templates, capturing results honestly and reporting what the data shows without overclaiming.

Designs and runs experiments from A/B tests to small paid pilots, judging significance and keeping or killing on evidence.

Runs a sustained experiment cadence for an area, turning tests and pilots into decisions about what gets built next.

Designs experiments that validate strategic bets before the team commits, applying experimental rigor to company-level questions.

Live User Sessions & Co-Building

Observes live co-building sessions and logs what users show, supporting facilitation and noting reshaping opportunities.

Facilitates live sessions where users test the shipped product and reshape it in real time, turning the session itself into a build loop.

Designs and runs the live-session cadence for an area, using sessions to define what gets built and reshaping the product in the moment.

Uses co-building sessions to validate strategic directions, modeling how evidence from users shapes company-level product bets.

User Observation & Signal Gathering

Gathers user signal from observed sessions and session replays, taking structured notes that feed the next iteration.

Runs feedback loops on shipped features, diagnosing drop-off from replays and turning gathered signal into concrete next builds.

Owns the signal-gathering apparatus for an area — replays, feedback loops, and public channels — and synthesizes it into direction.

Reads user evidence across areas to influence company product direction, distinguishing durable signal from noise.