Forward DeployedExpert-built kit

Forward Deployed Software Engineer

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

Interview content for Junior

54
What to ask. Competency and attitude questions, assigned to the right round.
340
What to listen for. Positive and negative indicators, per question.
21
What the hire must do. Capabilities with expected proficiency at each level.

Look inside: one question, as it appears in the kit

Pick the level you’re hiring. The sample changes with the level you select.

Round 2 · Core Craft & AI-Assisted Build32 competency questions

AI-Assisted Development & Tooling

AI-Assisted Development & Agentic Coding

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

Expected at Junior

Sample competency question

Give me an example of a time you used an AI coding tool to get work done. How did you steer it toward what you needed?

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

Positive indicators

  • Concrete prompts or course corrections
  • Mentions checking the output
  • Describes asking for review or help

Negative indicators

  • Used it once, cannot explain steering
  • Accepted output without checking
  • No awareness of when it goes wrong

Entry uses agentic tools under senior direction; the bar is basic working proficiency with supervised verification, not autonomous orchestration.

Ryan Mahoney

Why this role is hard · Ryan Mahoney

The hardest part of hiring a Forward Deployed Engineer is that no single resume signal predicts the job. The role asks an entry-level engineer to own a prototype from data model to interface, ship it to real users within hours, and keep their judgment even when most of the code was written by an agent. Most candidates have one side of that: they can code, or they can prompt a tool, but rarely both at a level that survives contact with real product data. The evidence I look for is a small artifact they built, then a live walkthrough where I watch them verify, cut, and explain what the agent got wrong. Someone who treats AI output as gospel is not an embedded engineer yet.

Everything in the download, in the order you’ll use it

Level guides for Junior, Mid, Senior and Principal.

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

Core Evaluation

Critical questions for this role

The competency and attitude questions below are where the hiring decision is made. They run in the live interview rounds and are calibrated to the level selected above.

32 Competency Questions

1 of 32
  1. Discipline

    AI-Assisted Development & Tooling

  2. Job requirement

    AI-Assisted Development & Agentic Coding

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

  3. Expected at Junior

    Entry uses agentic tools under senior direction; the bar is basic working proficiency with supervised verification, not autonomous orchestration.

Interview round: Core Craft & AI-Assisted Build

Give me an example of a time you used an AI coding tool to get work done. How did you steer it toward what you needed?

Positive indicators

  • Concrete prompts or course corrections
  • Mentions checking the output
  • Describes asking for review or help

Negative indicators

  • Used it once, cannot explain steering
  • Accepted output without checking
  • No awareness of when it goes wrong

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 a time you finished a task and had to make sure the notes or documentation around it stayed accurate. What did you actually do?

Positive indicators

  • Concrete: mentions specific notes, logs, or docs updated
  • Describes keeping records current as the work changed
  • Checked accuracy rather than assuming it

Negative indicators

  • Sees documentation as someone else's job
  • No example of keeping records current
  • Describes updating docs only when forced

Supporting Evaluation

How candidates earn the selection conversation

The goal is to reduce effort for everyone by collecting more useful signals before adding more interviews. Lightweight application prompts and structured screens help your team focus interview time on the candidates most likely to succeed.

Stage 1 · Application

Filter at the door

Runs the moment a candidate hits Submit. Disqualifying answers end the application; everything else is captured 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

Stage 2 · Resume Screening

Read the resume against fixed criteria

Reviewers score every application that clears the door against the same criteria. Stronger reviews advance to live interviews; weaker ones are archived without further screening.

Resume Review Criteria

8 criteria
Evidence of building a small feature from data model through API to UI, on real or realistic data, and making it usable rather than a static mockup.
Evidence of using AI coding tools to build software and of checking the output rather than accepting it blindly.
Evidence of putting work in front of real users and reshaping it from what they showed, rather than building in isolation.
Evidence of growing skill across the relevant stack and of turning adjacent or transferable experience into hands-on engineering practice.

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?

Stage 3 · During Interviews

Where the hire is decided

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

Work as you would on the job. You have 45 minutes. Build the endpoints from the brief, write one focused test, and be ready to explain your choices.

In the starter repository there is a Next.js + tRPC service with a notes table (Drizzle ORM) already modeled. Implement two new tRPC procedures on noteRouter: 'note.byId' returns a single note, and 'note.search' accepts a query string and returns up to 10 matching notes. Requirements: (1) validate inputs with Zod — an empty or whitespace-only query must be rejected; (2) return structured errors, never raw exceptions; (3) responses must not leak internal database fields; (4) write one focused Vitest test covering the validation behavior. Do not modify the database schema.

With AI

Same 45-minute task, with a twist: you may use the provided AI coding assistant to scaffold and implement, but you own the outcome. The brief contains two constraints the assistant does not know about — you must encode them and then verify the generated code against them.

Same starter repository and same brief as the individual version: implement 'note.byId' and 'note.search' with Zod validation, structured errors, and one Vitest test. This time the product owner added two constraints the AI assistant is not aware of: (1) search results must only ever return the current user's own notes — the service is multitenant even though the schema does not make it obvious; (2) the search route must degrade gracefully when the notes table grows past 100k rows — the naive LIKE query the assistant will suggest is not acceptable. Drive the assistant to produce a solution, then review its diff: decide which parts to accept, which to rewrite, and why. The decisions about module boundaries — where tenant scoping lives, where the search limit is enforced, and what stays in the procedure versus a service — are yours to make and justify.

Response time

45 min

Positive indicators

  • Rejects invalid input at the boundary with clear structured errors
  • Keeps the API surface minimal and type-safe end to end
  • Writes a test that pins the validation contract rather than implementation detail
  • Talks through the error-handling and limit tradeoffs when asked
  • Articulated which constraints the assistant could not have known and encoded them explicitly
  • Chose a search strategy with a defensible boundary decision and explained the tradeoff
  • Modified or rejected AI output with reasons, not just accepted the diff
  • Kept the generated code reviewable: clear module boundaries, no dead abstractions

Negative indicators

  • Bypasses validation or lets the database throw unhandled errors
  • Leaks internal fields or returns overly broad results
  • Writes no test, or a test that does not exercise real behavior
  • Accepted the generated unconstrained search and multitenant-unsafe procedure without comment
  • Let the assistant's module layout determine the architecture rather than the constraints
  • Could not name which parts of the diff were AI-written and which were theirs

Presentation Prompt

Walk us through how you would take a scoped prototype brief, decide what to watch for when users try it, and turn what they show you into the next build. Slides are optional — talking through your reasoning is fine. We care about how you frame the problem and what evidence would change your next step, not about seeing finished work.

Format

approach-walkthrough · 12 min · ~1 hr prep

Audience

Hiring manager and a cross-functional product partner — the same audience as the 'What Users Showed Me' round already scheduled for this level.

What to prepare

  • Reflect on a small prototype or project you built, ideally one that real users tried
  • Think through which two or three usage signals would tell you the prototype is working
  • Be ready to discuss what you would cut if the evidence said the scope was too big

Deliverables

  • A short verbal walkthrough (no slides required)
  • Optional: one screenshot or a single-page outline of a prototype you already built

Ground rules

  • Slides are optional; you can talk through your reasoning
  • Use only work you are permitted to share — no proprietary or unshareable material
  • This is a discussion of your approach; nothing needs to be produced in advance

Scoring anchors

Exceeds
Frames the problem, surfaces testable assumptions, and shows a tight evidence-to-next-build loop with specific signals and a clear cut decision.
Meets
Walks through a sensible approach with reasonable assumptions and at least one concrete signal that would shape the next step.
Below
Describes a generic build plan with no user evidence, no scope discipline, and no stated assumptions.

Response time

12 min

Positive indicators

  • Asks clarifying questions about the brief before proposing an approach
  • Names the assumptions they would test first and why those come first
  • Shows visible reasoning under ambiguity instead of locking to a fixed plan
  • Describes concrete, observable signals that would change their next step
  • Admits when evidence is thin and says exactly what they would watch for

Negative indicators

  • Jumps straight to a solution without framing the problem
  • Proposes a scope larger than a day-one prototype without justifying it
  • Cannot name any evidence that would change their mind
  • Claims certainty about users they have never observed
  • Defends a build instead of reasoning about what users showed

Work Simulation Scenario

Scenario. You are a Forward Deployed Engineer at a seed-stage B2B SaaS company that builds workspace tooling with its users. You are mid-process: you have already completed the 'Pairing Session on a Scoped Prototype' work simulation in the Peer Pairing & Quality Gates round. Today you sit with the product pod lead, who hands you a deliberately vague brief: 'Users keep starting the weekly planning workflow and abandoning it before the first task is created. Figure out what we should build to fix that and how you would prove it.' The pod lead has the usage dashboard, session notes, and the real product in front of them — but they will only answer what you ask. Drive the conversation: ask the questions that turn this vague brief into a scoped, testable prototype idea, and walk us through the prototype you would ship this week.

Problem to solve. Turn a one-line abandonment signal into a scoped prototype brief: ask the high-information questions you need, surface the assumptions you are making, and decide the thinnest version to ship on real data first — then walk us through your approach.

Format

discovery-interview · 20 min · ~1 hr prep

Success criteria

  • You surface the key unknowns: who abandons, where they stop, what they expected, and what evidence already exists
  • You converge on a prototype that can ship on real product data within a day
  • You name the usage signal that will tell you whether the fix worked
  • You cut scope down to something thin enough to test this week

What to review beforehand

  • The pairing-session brief from the Peer Pairing & Quality Gates round
  • The team's starter template and feature-flag pattern you would build on
  • One example of a keep/kill decision the team made on usage evidence

Ground rules

  • This is a discovery conversation, not a build session — no code is written and no plan is produced
  • The pod lead answers questions honestly but never volunteers information
  • Ask for the dashboard, replays, or session notes if you need them
  • Timebox your questions — converge on a decision, not an exhaustive brief

Roles in scenario

Product Pod Lead (informed_partner, played by hiring_manager)

Motivation. Wants to see whether the candidate can extract a shippable prototype brief from an ambiguous signal without being spoon-fed.

Constraints

  • Will answer any question the candidate asks, honestly and concretely
  • Has the usage dashboard, session-replay links, and feature-flag tooling available
  • Cannot spontaneously share information the candidate did not ask for

Tensions to introduce

  • Gently resists premature commitment to the first idea the candidate names
  • Holds back the strongest evidence (session replays) until the candidate asks for it
  • Answers effort questions with 'it depends' when the candidate asks about scope without constraints

In-character guidance

  • Answer plainly and helpfully when asked; give exact numbers when asked for data
  • Mention what users actually do ('the replays show they stop at the template step') only if the candidate asks
  • Stay warm and collaborative — this is a partner, not an adversary

Do not

  • Do not volunteer information the candidate did not ask for
  • Do not steer the candidate toward a preferred answer
  • Do not coach, hint, or fill silences

Scoring anchors

Exceeds
Extracts the decisive evidence with targeted questions, converges on a thin testable prototype, and names the exact usage signal that will decide keep vs kill.
Meets
Asks solid clarifying questions, surfaces the main assumptions, and lands a scoped prototype brief with a plausible validation signal.
Below
Guesses at root cause, proposes a build without questions or evidence, or cannot converge on any decision.

Response time

20 min

Positive indicators

  • Asks who is abandoning and what the expected behavior was before proposing a build
  • Requests the existing dashboard, replays, or session notes
  • Checks whether the data already answers part of the question
  • Proposes a thin prototype explicitly framed as a test rather than a feature
  • Names the one event or metric that would decide keep vs kill
  • Reflects the partner's answers back and adjusts the brief

Negative indicators

  • Guesses at the cause of abandonment without asking for evidence
  • Freezes or waits for the partner to propose the answer
  • Commits to a large build without checking scope
  • Never asks what data already exists
  • Ignores answers and repeats the original idea
  • Confuses a prototype for a polished product

Progression Framework

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

AI-Assisted Development & Tooling

4 competencies

CompetencyJuniorMidSeniorPrincipal
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

CompetencyJuniorMidSeniorPrincipal
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

CompetencyJuniorMidSeniorPrincipal
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

CompetencyJuniorMidSeniorPrincipal
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

CompetencyJuniorMidSeniorPrincipal
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.