Sycamore
Sycamore3 open roles

Product Engineer, Applied AI

BengaluruHybridSeniorFull-time

Posted 24 days ago

The role in short

Embed with Fortune 500 customers to map workflows and build, deploy, and maintain production AI agents and integrations.

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, identify where an agent can create a measurable outcome, and build the application end to end. That can include the user experience, APIs and data model, agent instructions and tools, enterprise integrations, permissions, approval points, durable workflows, and the operational controls needed to run safely.

You own the full loop: discovery, implementation, realistic testing, preview and deployment, production debugging, adoption, and iteration. Your work does not end with a prototype, a requirements document, or a handoff.

Customer-specific product work belongs with you. When the same runtime, connector, memory, approval, or deployment need appears repeatedly, you work with Core AI or Infrastructure to turn it into a reusable capability instead of maintaining parallel custom implementations.

What the work looks like

In one week, you might:

  • Sit with a customer's operators and engineering team to map a manual process, its domain entities, edge cases, permissions, approval points, and success criteria.
  • Trace how the workflow connects to existing systems and determine which reads and writes an agent can perform safely.
  • Build a production application across the user interface, backend APIs, data model, agent behavior, tools, integrations, and human-review surfaces.
  • Exercise the real workflow in a browser, run backend and end-to-end tests, inspect traces and structured events, and fix failures before users encounter them.
  • Deploy a preview or development version, work through customer security and networking constraints, and stay close to usage after launch.
  • Separate the customer's specific business behavior from a reusable platform pattern, then contribute the shared primitive with the relevant Core AI or Infrastructure engineer.

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.
  • Debug across product code, agent behavior, integrations, infrastructure, and customer systems until the underlying failure is understood.
  • Stay accountable for reliability, adoption, and customer outcomes after launch.
  • Travel within India 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

  • 5-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 in this role 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 an ML research role focused on training foundation models.
  • It is not a narrow role defined by one programming language or layer of the stack.
  • It is not custom development without product judgment; repeated needs should improve the platform.

Interview process

  1. A 30-minute introductory conversation.
  2. Two 60-minute technical interviews, one focused on systems design and one on coding.
  3. A take-home assignment where you build and present a real solution using the tools you would use on the job.

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 India engineering team operates and grows.
  • Work as one engineering team across India and Palo Alto.
  • 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. 1Discovery and scoping
    They wrote: “You own the full loop: discovery, implementation, realistic testing, preview and deployment, production debugging, adoption, and iteration. Your work does not end with a prototype, a requirements document, or a handoff.”

    A customer says “we want AI in our claims process.” What do you ask in the first meeting?

    How to answer

    Why they ask: Most FDE work starts this vague. They want to hear you find the real problem before you pick a tool.

    1. Map the current process: who touches a claim, in what order, with which systems
    2. Find the slowest or most error-prone step and ask what it costs them
    3. Agree on one measurable goal (for example time per claim, or error rate)
    4. Ask what data you can access, and who signs off on security

    Tip: Ask about the work, not the technology. Who does it today, how long it takes, what a mistake costs, and how they'd know it got better.

  2. 2Integrations and APIs
    They wrote: “Build a production application across the user interface, backend APIs, data model, agent behavior, tools, integrations, and human-review surfaces.”

    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.

  3. 3Ownership 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.

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

    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.

  5. 5Cloud, deployment and security
    They wrote: “Deploy a preview or development version, work through customer security and networking constraints, and stay close to usage after launch.”

    The customer's security team sends a 200-question review. How do you handle it?

    How to answer

    Why they ask: Security reviews often block deals. FDEs help get through them.

    1. Start from your company's standard answers (SOC 2 report, past reviews)
    2. Answer clearly; don't oversell
    3. Bring in your security team for anything you're unsure of
    4. Keep the new answers for the next customer

    Tip: Reuse past answers, flag honest gaps, and offer a call for the hard questions.

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