Sycamore
Sycamore3 open roles

Forward Deployed Engineer

San Francisco Bay Area, CA; New York, NYHybridMidFull-time

Posted Oct 14, 2026

The role in short

Embed with enterprise customers to design, build, and deploy production AI agents and agentic applications, owning the full lifecycle from discovery to adoption.

About Sycamore

Sycamore is building the trusted agent operating system for the enterprise. Our platform helps companies build, deploy, and orchestrate agentic apps that take on real operational work, with the security and control large organizations need.

We are a small, engineering-led team working directly with Fortune 500 enterprises. We have raised $65M from Coatue and Lightspeed, along with other investors and industry leaders.

The role

The simplest way to describe this role: you are the engineer in the customer room and the product engineer who ships what the room needs. You will map how an important workflow works today, find where an agent can create a measurable outcome, and build the application end to end, from the user experience and data model through agent tools, integrations, permissions, approval points, and the operational controls needed to run safely.

You own the full loop: discovery, implementation, realistic testing, deployment, production debugging, adoption, and iteration. Customer-specific product work belongs with you, and when the same runtime, connector, memory, or deployment need appears repeatedly, you work with Core AI or Infrastructure to turn it into a reusable capability rather than maintaining parallel custom implementations.

What you will do

  • Turn ambiguous enterprise problems into clear technical designs, working software, and measurable outcomes.
  • Build product surfaces for agent conversations, tasks, progress, approvals, artifacts, and operational workflows.
  • Design APIs and relational data models that accurately represent the customer’s domain and remain understandable as the product evolves.
  • Build agent instructions, tool interfaces, connector interactions, and durable workflow steps with explicit permission and failure behavior.
  • Navigate enterprise requirements around authentication, authorization, tenant isolation, data handling, deployment, observability, and change management.
  • Test realistic user journeys rather than stopping at isolated units or happy-path demos.
  • Travel to customer sites when working alongside users will accelerate discovery, delivery, or adoption.

The environment you will work in

Our current product environment includes TypeScript, React, TanStack, Tailwind, Python, FastAPI, typed data models, PostgreSQL, durable workflows, MCP-based tools and connectors, browser automation, and cloud-native deployment on Kubernetes.

We use automated tests, coding agents, traces, evaluations, and production feedback as part of everyday engineering.

This is context, not a checklist. We do not require previous experience with every language, framework, or vendor in our stack. Strong engineers who understand systems, learn quickly, and have shipped production software can become effective here without matching our tools one for one.

What we are looking for

  • 2-12 years of software engineering experience. We will make exceptions for exceptional people in either direction.
  • Strong software fundamentals across product design, APIs, data modeling, distributed systems, testing, and production debugging.
  • Evidence that you personally shipped and operated meaningful software, rather than stopping at prototypes or delegating the production work.
  • Product judgment. You can find the real problem behind a request, choose a useful first version, and decide what should remain customer-specific versus become reusable.
  • Comfort moving across user interfaces, backend services, data, agent behavior, integrations, and deployment when the outcome requires it.
  • A security-minded approach to enterprise data, permissions, credentials, approvals, and auditability.
  • AI-native. You use coding agents and modern models as a force multiplier while still owning the architecture, understanding the code, and explaining important decisions.
  • Clear communication and high EQ. You can work with a customer’s CTO, operators, security team, and engineers without losing technical depth.
  • Comfort with startup ambiguity, fast feedback loops, broad ownership, and regular customer travel.

Former founders, early product engineers, and forward-deployed engineers often do well here when they have retained real code and production ownership. That background is a signal, not a requirement.

What this role is not

  • It is not a pre-sales role that stops at a demo or architecture diagram.
  • It is not a solutions role that hands requirements to another engineering team.
  • It is not custom development without product judgment; repeated needs should improve the platform.

Interview process

  1. Application review and a 30-minute video screen with an engineer.
  2. Two 60-minute interviews: Coding and System Design
  3. A role-specific work trial, scoped to 6–8 hours in one agreed day with host check-ins, followed by a 60-minute presentation.

Why join

  • Work on AI systems that move from enterprise problems to production outcomes quickly.
  • Own the complete path from workflow discovery through adoption.
  • Shape both individual deployments and the product used across customers.
  • Join early enough to define how the engineering team operates and grows.
  • Receive competitive cash compensation and meaningful equity in the company you are helping build.

Prep for this interview

5 questions likely to come up at Sycamore, each matched to a line in this posting.

  1. 1Ownership and working with customers
    They wrote: “Comfort with startup ambiguity, fast feedback loops, broad ownership, and regular customer travel.”

    Tell me about a project where the requirements kept changing. What did you do?

    How to answer

    Why they ask: Ambiguity is the norm. They want proof you can keep moving without a clear spec.

    1. The project and why requirements kept moving
    2. What you did to pin them down (short demos, written decisions)
    3. The trade-offs you made to keep shipping
    4. The result, with a number if you have one

    Tip: Show how you reduced the change, beyond how you coped with it.

  2. 2Travel
    They wrote: “Travel to customer sites when working alongside users will accelerate discovery, delivery, or adoption.”

    How do you handle being on the road with customers for weeks at a time?

    How to answer

    Why they ask: Many FDE roles involve regular travel. They check you know what you're signing up for.

    1. Your past travel or on-site experience
    2. How you stay productive away from the team
    3. What travel level works for you, said plainly

    Tip: Be honest about what works for you. A mismatch here hurts both sides later.

  3. 3Discovery and scoping
    They wrote: “Navigate enterprise requirements around authentication, authorization, tenant isolation, data handling, deployment, observability, and change management.”

    Tell me about a time the customer asked for one thing but needed another.

    How to answer

    Why they ask: Good FDEs spot when a request is a guess at a solution. They want proof you can redirect a customer without losing their trust.

    1. What they asked for, and the detail that made you doubt it
    2. How you tested the doubt (shadowed users, looked at logs, ran a quick prototype)
    3. How you made the case to the customer
    4. What shipped and what changed for them

    Tip: Pick a story where you checked your hunch with data or users before pushing back.

  4. 4Integrations and APIs
    They wrote: “Design APIs and relational data models that accurately represent the customer’s domain and remain understandable as the product evolves.”

    Walk me through connecting our product to a customer's internal system that has no documentation.

    How to answer

    Why they ask: This happens weekly in the job. They want a calm, step-by-step method.

    1. Find who owns the system and get read access to a test environment
    2. Watch real traffic or logs to learn the data shapes
    3. Build a thin adapter with logging around every call
    4. Agree on how failures get reported, and who fixes what

    Tip: Talk about finding the owner of the system first. The code is the easy part.

  5. 5Data and SQL
    They wrote: “Strong software fundamentals across product design, APIs, data modeling, distributed systems, testing, and production debugging.”

    The customer's data is spread across five systems that disagree. How do you get one clean view?

    How to answer

    Why they ask: Real deployments rarely have one source of truth. They want a practical approach, not a perfect one.

    1. List each system and what it's the best source for
    2. Pick matching keys and decide how to handle records that don't match
    3. Load into one place with clear rules, and keep the raw copies
    4. Show the customer the mismatches; they often fix the source

    Tip: Name the system the business trusts most for each field, and get the customer to agree.

Not the one? Get the next one by email

New roles land here every day. Pick what you want to hear about.

FDE Info

Want the job, not just the posting? Learn how FDEs work.

FDE Info is our free weekly newsletter for forward deployed engineers: tools, field notes from real deployments, and how FDE teams hire and pay.

Free. One email a week. Unsubscribe in one click.

More at Sycamore

Similar roles at other companies

Sycamore

Hybrid

Apply