Landing an FDE interview without a referral: who to message, what to write, what proof to send

You know no one at the company you want to join, and clicking “Apply” feels like dropping your CV into a hole. According to a survey cited by ERE, engineers are most likely to respond when the person contacting them is the hiring manager.

By the end of this guide you will have four things ready to send: a recipient’s name, a message, a link to your proof and a follow-up.

This matters more than usual for FDE roles. Writing to a busy person who has never heard of you, and persuading them to give you their time, is something you will do again and again with customers.

You need three things before you start: a project you have put into production, a GitHub account, and a short list of open FDE roles. If you have no such project yet, do step 2 first. Without proof, even a well-written message is just an unsupported self-introduction.

Step 1: Who should you write to, and through which channel?

The person to find is the hiring manager, meaning the person who will manage you directly, not only the recruiter. The data ERE cites shows engineers respond most often to messages from hiring managers.

That survey asked people being recruited, not job seekers, so applying it to your situation is an inference. It still holds up: the person responsible for the team is the one who will most quickly see which of their problems your proof addresses.

On channel, 51% of engineers in the same survey preferred to be contacted about jobs by personal email, with LinkedIn InMail second. The survey is small, so treat it as a guide only. A sensible approach is to use email when you can find a public address and keep LinkedIn as the fallback.

Check: for each role, you have a specific person’s name and a way to reach them. If your recipient column just says “Recruiting team”, you have not finished this step.

Step 2: What proof will a stranger actually open?

A dev.to guide to becoming an FDE argues that one well-built end-to-end project is worth far more than ten toy demos.

The specific test is that the project shows you took a vague problem and turned it into a working system with evaluations (evals). A guide from Scaler sets a similar bar: the project should be integrated, deployed and in use, not a tutorial app.

Package that proof in three layers, from quick to deep. The first is a short demo video; a screen recording with voice-over is enough. The second is a case study or README written for a non-specialist. The third is the repo, with clean code, a tidy commit history and a live deployment.

A suggested README outline, shortened for illustration:

# [Project name]: [problem] for [who uses it]

## The original problem (how vague it was)
## How the problem was narrowed down
## The live system: [deployment link] · [demo video link]
## Measuring quality: what the eval covers and what it found
## Who uses it and what they say
## What would be fixed with more time

The “Measuring quality” section is where you show your system has evals, which is exactly the test above, so do not leave it empty. Check: send the link to a friend who does not work in tech. If, after watching the video, they can tell you what problem the system solves, your proof is ready.

Step 3: A four-part message

In the ERE survey, 39% of engineers ranked personalisation as the most important part of a cold message, ahead of every other factor.

Underdog.io, a recruiting platform, advises that when you have no referral you need to create a specific connection with the recipient, their work or the company. That connection takes the place of the introduction you lack.

That gives the message four parts. The subject line names the exact role rather than using a generic phrase. The opening line is the specific connection. The middle is one link to proof tied to their problem.

The final line is a small request, such as a 15-minute conversation next week. A template:

Subject: Forward Deployed Engineer – [project] solving [problem close to their product]

Hi [Name],

Your [talk / post / release] on [specific topic] matched a problem I hit
while building [project]: [one sentence on the vague problem].

I shipped it end to end – deployed, used by [who], with an eval for
[what quality means]. 3-minute demo + write-up: [link]

Would a 15-minute chat next week be useful to see if this fits
the FDE role on your team?

[Name] · [GitHub] · [CV link]

A LinkedIn message should be shorter than an email. The InMail version should keep only the connecting line, the link and the request. Check: delete the recipient’s name and read it again. If the message could still go to any company, it is not personalised enough.

Step 4: Follow up with a single link

Getting no reply is normal. Keep the follow-up very short, and instead of attaching more long documents, link to a case study in your portfolio. You can use the “Measuring quality” section from step 2 as the new angle, for instance one line on what the system can do after its latest improvement.

Check: the follow-up is no longer than three sentences and has no attachments.

Common mistakes

The first mistake is writing only to the recruiter and then waiting. The second is attaching five repos. The recipient will open none of them because they will not know where to start; one end-to-end project placed first works better.

The third is asking for too much, such as “could you look over my CV and refer me”, when a short call is far easier to agree to.

They replied. What next?

Every company has its own process, so take Palantir as an example. According to the interview guide from Aced (formerly Exponent), its FDE process includes a 30-minute recruiter call focused on your motivation. The story of why you built the project in step 2 is the best preparation for that call.

Palantir’s FDE interview process also includes a decomposition round, in which you break down an open-ended problem with almost no coding. Nearly every candidate faces this round.

The “How the problem was narrowed down” section of your README is the closest practice for it, because it forces you to explain how you cut a vague problem into steps.

How does this skill carry over to customer work?

On a customer site you will often write to a busy person who owes you nothing: an operations manager, a data engineer on the customer side, a project sponsor.

The formula stays the same: the right person with decision-making power, a specific link to their problem, proof they can review in a few minutes and a small request.

On your CV, you can show this skill as a one-line project description with a demo link, rather than a list of technologies. The person reading your message has never met you, so the message itself is the first test of whether you can work with customers.