realfast is hiring

Forward Deployed Engineer

For engineers who can defend every line an agent wrote for them.

Full-time and contract. An FDE works inside the customer's systems: their codebase, their data, their production. You direct a fleet of agents against one agreed metric, and you answer for what ships. The role, the reading list, and every stage of the bar are on this page.

The job, in five statements

You talk to the client's people first, then write code. Not the other way round.

The FDE playbook

Six pages, read sideways.

What the job is, what it isn't, and how it runs, one page at a time. Keep scrolling.

01 · The role

One engineer, the whole problem.

Most engineering jobs work like this: you build one capability, polish it, and ship it to many customers you will never meet. The FDE role runs the other way. You embed with a single customer, bring many capabilities to their one problem, and stay until it is solved. You talk to the people who live with the problem, find what is actually broken, which is rarely what the brief said, and ship production software against it.

The output is never advice and never a prototype. It is a working system, in their environment, moving a number they care about. And what you learn there feeds back into the platform, so the next engagement starts further ahead than the last one did.

⌐ From the culture doc: AI is the senior engineer. Humans are the architects.

02 · Not consulting

Consultants advise. FDEs ship.

The comparison comes up in every intro conversation, so let's settle it. A consultant's deliverable is a recommendation: a deck, a roadmap, a handover. They leave before the consequences arrive. An FDE's deliverable is running software, and you stay for the consequences: the deploy, the pager, the number that moved or didn't.

The lineage is older than the name. In the 90s, the best engineers in the world were consultants working Monday to Friday on client floors. The first wiki, TDD, and the agile movement all came out of that work. Then consulting became body shops, and no self-respecting engineer wanted the title. Palantir gave the same job a tactical name and made it cool again. That's the job. The name just recovered.

⌐ From the field: BoardRoom's link to the Australian Securities Exchange, rewired in under seven weeks.

03 · The actual work

Talk first. Then build.

A working day starts with people more often than code. You sit with the team that owns the problem and pull the real constraint out of their heads: the thing they mention in passing, not the thing in the ticket. Then you build: workflows, data pipelines, platform extensions, and fixes for whatever production surfaced overnight. The stack is whatever the customer runs.

None of it is throwaway work. Field code gets reviews, tests, monitoring, and a deploy path, because it lives in someone else's production long after you have moved on. You watch the live system constantly. That is where the truth is, and it is usually different from the meeting.

⌐ From the field: a 25-year-old financial core, mapped with 80% less of the client's time.

04 · At realfast

Two to five senior engineers, and a fleet of agents.

Here is the realfast version. We send two to five senior people where other firms send forty, because agents handle the routine width of the work and judgment stays human. We embed with software-driven enterprises on problems that are urgent, high-stakes, and stuck: the ones that have already survived a committee or two. Applied-AI sits in the operating model itself, not bolted on afterward: strategy and engineering are one team, often one person.

Two things are non-negotiable on every engagement. What we ship belongs to the customer: their product, their platform, their repo. And every engagement is tied to one business metric, agreed before code is written. If the number doesn't move, nothing else we did matters.

⌐ Sidu, on every customer call: if we don't move the number, you're not happy with us, don't pay us.

05 · How we run

The rhythm repeats.

Every engagement runs the same shape. Understand the business before the model. If the customer can't name the number they want moved, finding it is the first deliverable. Analyze the real data in full before writing a single rule, because the data always disagrees with the documentation. Then ship a working slice fast and iterate with the customer in the loop, weekly, so trust is built on things they can use rather than progress reports.

Before anything goes live, test at scale against their own historical data. Confidence has to come from evidence, not vibes. And when it ships, every reusable pattern goes back into the platform. That compounding is the whole model: each engagement starts further ahead than the last one did.

⌐ From the field: a university's month-end close went from three days to under ten minutes.

06 · The traits

Judgment, breadth, and nerve.

The FDEs who thrive here share a shape. They are at home in unfamiliar codebases, the five-million-line kind nobody fully understands anymore. They are self-directed, because nobody writes your spec here; you write the customer's. They carry a customer empathy that survives contact with production, and a breadth that beats purity: frontend, pipelines, agents, whatever the problem actually needs.

Above all of it sits one discipline. Always be working on the single most valuable thing. Everything that doesn't need judgment is already being automated. What's left is the job.

We don't ship features. We move the metric.

How an FDE runs a fleet

One engineer. Many agents. Every loop ends in judgment.

  1. You sit with the client's people and write the brief. An agent can act on it: the codebase, the constraint, the date.

  2. Agents take the routine width: map the flows, draft the tests, read the branch logic, hundreds of files in parallel.

  3. Everything lands back on you. You review with the client's experts, and they become reviewers, not narrators.

  4. The new path must match the old one on the client's own historical data before anything switches.

  5. Switch over, watch it hold, write down what hurt. Then the next constraint. The loop is the workstyle.

fleet / run

The reading list

The realfast reading list.

We hire readers. Nobody quizzes you on these. Read a few anyway. They shaped how this place works, and the application asks what reading changed for you.

Open the full catalogue (45)

Everyone · 25

  • Eric S. Raymond · essay
  • Eric S. Raymond, to Linus Torvalds, 2000 · email
  • Poul-Henning Kamp, FreeBSD list, 1999 · email
  • Fred Brooks · paper
  • Eric S. Raymond · essay
  • Ray Dalio
  • Marty Cagan
  • Patty McCord
  • Daniel Kahneman
  • Peter Thiel & Blake Masters
  • Ben Horowitz
  • Andy Grove
  • Andy Grove
  • John Doerr
  • Steve Krug
  • Strunk & White
  • Fred Brooks
  • Steve Blank
  • Eric Ries
  • Eliyahu Goldratt
  • David Kushner
  • Paul Graham
  • Mary & Tom Poppendieck
  • Donald G. Reinertsen
  • Kent Beck

Developers · 15

  • Abelson & Sussman
  • Robert C. Martin
  • Michael T. Nygard
  • Eric Evans
  • Dave Thomas & Andy Hunt
  • Martin Fowler
  • Kent Beck
  • Steve McConnell
  • Michael Lopp
  • Ben Moseley & Peter Marks · paper
  • David L. Parnas · paper
  • Seth Gilbert & Nancy Lynch · paper
  • Roy Fielding · thesis
  • Dorian Taylor · essay
  • Alberto Savoia · humour

Designers · 2

  • Susan Weinschenk
  • Alan Cooper, Robert Reimann, David Cronin & Christopher Noessel

Extended canon · 3

  • Elizabeth Pisani
  • Robert M. Pirsig
  • Nassim Nicholas Taleb

Field notes from a client's floor

Not a test. The judgment the job runs on. The situation, and what we'd do.

01 / 07

Day two on a client's floor. Their staging environment has no usable data. The demo is Thursday. Their platform team's queue is six weeks deep.

What we'd do

Thursday doesn't move because their backlog is long. You write the seed generator, which takes an evening, and you tell them you did. The date was the commitment; the missing data was an obstacle, not a change of scope.

How you apply

There is no form. Your agent applies for you.

Point your coding agent at join.realfast.ai It sets up your profile and applies. We read the artifacts that matter: your agent config, and one session log. How you actually work with agents, not how you describe it.

join.realfast.ai fde This is the actual process.

README.MD

Your agent applies. These two are on you:

01 · The next step

Mandatory after setting up agent

Express interest. We'll email your assignment shortly after.

A one-minute form: name, email, phone, the role, your notice period, and expected comp so we can align on budget early.

Fill the form

02 · After the form

Mandatory after setting up agent

One quick conversation before your assignment lands.

Three questions with our AI screening assistant, under five minutes. The transcript and recording go straight to the hiring team. Your assignment is sent once both steps are done.

# 3 questions, under 5 minutes total.

# Have three books ready that changed how you work. The agent will ask what you read and why.

# Speak naturally; no right or wrong answers.

# Quiet environment and a working microphone.

# Recorded; reviewed async by the hiring team.

First name, and the email you used in the form:

⎇ MAIN ● UPDATED TODAY 6 STEPS · 8 STAGES · BAR RAISER AT 08

realfast / fde · the bar

Clear the bar.

Think you clear the bar?

If that's the work you want, not the story of it, we'd like to hear from you.

Apply through your agent

✳ We built this page with AI in the loop. Every line was read by a person before it shipped, and the em dashes are intentional.

First published
Publisher
Format
On the list under
Free to read
Elsewhere

What it argues

Pulled books collect in your shelf, bottom right, and survive a reload. Nobody checks the list. It is here so you leave with something to read.

Your shelf

The books you pulled. They survive a reload.

how you apply

Keyboard · this page speaks vim

j / k
next / previous section
g g · G
top of the page · the close
x
arm the start lights
l
run the fleet loop
b
the reading list
a
how you apply
?
this map
esc
close any panel