realfast is hiring

Forward Deployed Engineer

For engineers who can understand the problem and build the solution.

Full-time and contract roles are available. An FDE works inside the customer's systems: their codebase, data, and production environment. You use agents for routine work, make the technical decisions, and stay involved through launch. The role, reading list, and interview process are on this page.

The job, in five statements

You talk to the client's people first, then write the code.

The FDE playbook

Six pages, one role.

What the role involves, how we work, and what we expect.

01 · The role

One engineer, end to end.

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: agents handle implementation; engineers make the calls.

02 · Not consulting

You stay until it runs.

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

Start with the people who use it.

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

A small senior team, supported by 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 while engineers make the calls. 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

A practical delivery cycle.

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

Breadth and sound judgment.

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 measure the result in the customer's business.

How an FDE runs a fleet

One engineer. Several agents. A review before release.

  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 client work

Real situations from client work, with our response to each one.

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 coding agent submits the application.

Point your coding agent at join.realfast.ai It sets up your profile and submits the application. We review your agent configuration and one session log to see how you work, not how you describe your work.

join.realfast.ai fde The application process.

README.MD

Your agent submits the application. You handle these two steps:

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.

Interested in the role?

If this sounds like the work you want to do, apply through your agent.

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