Your FDE onsite is next week: how to spend the days you have

By FDE Interview Prep, a SourceStrongAI company

The recruiter’s email says your onsite is next week. You have days, not weeks, and the pull is to open everything at once: a new system design book, a long problem list, every blog post the company ever wrote. Don’t. Spend Day 1 on a short diagnostic, done with no AI, to find which half of the job you are weaker on. Spend the middle days on timed practice aimed at that gap, plus a deep dive on your own project and your stories said out loud. Rehearse the day before instead of cramming, and keep the morning boring. This post is the short-notice version of the FDE interview guide, which covers every round in full.

First, the double bar

Before you plan a single day, know what the loop is checking. Baseten’s FDE lead writes that every FDE candidate must pass Baseten’s standard technical interview bar and, in parallel, a screen for product intuition and interest in working with customers; he calls it a “double-bar hiring process” (what each side sounds like in the room). ^[1]Source 1Forward deployed engineering on the frontier of AIPublisherBasetenSource typecompany blog Ramp’s engineering director says Ramp’s FDE candidates must pass the software engineering loop ^[2]Source 2What is a Forward Deployed Engineer? (FDE Explained) feat. Leo Mehr of Ramp (YouTube auto-generated English captions)PublisherdearCC (Clara Shih), YouTubeSource typerecorded talk or interview, and a former Palantir recruiter told First Round Review in February 2026 that Palantir’s early FDEs passed the same loops as software engineers. ^[3]Source 3So You Want to Hire a Forward Deployed EngineerPublisherFirst Round ReviewSource typenews report

Now the part that should shape your week. One poster on Blind, in India with 10 years’ experience, reported in May 2026 that in their Google FDE GenAI loop they solved the coding round, that the feedback on their deeply technical role-related knowledge round was “not technical enough to face customers or something like that”, and that they were rejected. ^[4]Source 4Google Rejected for FDE. Need immediate referralPublisherBlind (teamblind.com)Source typecandidate report on Blind One candidate reported on Reddit, in June 2026, that while job-hunting mostly in the FDE space they reached four final rounds, and that all four gave the same feedback (a great communicator, but technical skills not what the companies wanted), with some of it looking like a domain mismatch; they did not name the companies or the roles. ^[5]Source 5Good communicator, but technical skills not up to par; pivot options? (post by u/calculusbitch99)PublisherReddit r/cscareerquestionsSource typecandidate report on Reddit

Two reports are not a rate. Our reading: in both, good communication did not make up for technical depth the interviewers wanted to hear. So practice the depth, and don’t lean on the talking. If that feedback has already reached you once, the post on that rejection covers what to do with it.

Day 1: the diagnostic

Day 1 answers one question: where are you weakest under real conditions? A timed attempt tells you more than any self-assessment.

Step zero: ask the recruiter what the loop contains

Before anything else, send one email. Every later choice this week depends on the answer:

Could you share the rounds, how long each one is, the language or environment for coding, and whether any round allows AI tools?

Plan with what you have while you wait, then cut any block below for a round your loop doesn’t have.

The rules for the diagnostic tasks:

• No AI. No assistant, no autocomplete that writes the function for you, no chat window open. Google’s published hiring process says AI tools are not permitted during interviews. ^[6]Source 6Our hiring process - Google CareersPublisherGoogleSource typecompany hiring page Anthropic’s guidance for live interviews is no AI assistance unless Anthropic says otherwise. ^[7]Source 7Guidance on Candidates' AI UsagePublisherAnthropicSource typecompany website Check your own employer’s rules, and practice without AI either way. The lesson on AI rules by company and stage sorts out who allows what.
• Timed. Use the round length your recruiter gave you. If they gave none, pick one sitting and stop when the timer does.
• Out loud, recorded. Put your phone on voice memo. You will listen back tonight, and that recording is the most useful thing you make all week.

The algorithm problem you haven’t seen

Pick a medium problem you have not solved before. The slowest-endpoints question is a good one: parse web server logs and report the slowest endpoints by p95 latency. It looks like a warm-up, but it turns on definitions you have to make out loud before you parse anything, and that is the part worth practicing. Don’t read its framework until you have finished.

The bug fix in code you didn’t write

Customer work means reading code you didn’t write. Here is a small bug. The customer’s complaint: “The export always stops short. The last batch of records never arrives.”

def fetch_all(get_page):
    items, cursor = [], None
    while True:
        page = get_page(cursor)
        cursor = page["next"]
        if cursor is None:
            break
        items.extend(page["items"])
    return items

Find the bug, and write the test that fails on this code. Set a 10-minute timer. The answer is below.

def test_last_page_is_kept():
    a = {"next": "p2",
         "items": [1, 2]}
    b = {"next": None,
         "items": [3]}
    pages = {None: a, "p2": b}
    assert fetch_all(pages.get) == [1, 2, 3]

What you are grading is not whether you found it. It is the order you worked in: did you reproduce it with a test before changing code, and did you say what the customer saw? If you want a harder one, the unfamiliar bug question is in Pro.

The customer case

Both reports are about technical depth, and one poster had solved the coding round. So the technical side gets two tasks here, and the project deep dive later covers depth you have to explain. The customer side still needs one honest measurement. The free case at /try runs the building permits case against an AI customer on a ten-minute clock, and the score quotes your own words back to you. Run it cold, then read the score before you read anything else.

Reading your diagnostic: which gap to close first

Your recording will show more than one weakness, and you have time to close one or two. Here is how we sort them (our method, not an employer’s rubric).

Close the gap that would end a loop first. A silent but correct solution is easier to fix in days than a stalled one, and asking why before building can be drilled in a single evening. Not reaching a working solution takes the most practice, so if that is you, coding goes first every day and everything else shrinks around it.

The middle days: cases, coding, your project, stories

Every middle day has four blocks: your gap, a case or coding, your project, your stories. The diagnostic sets which goes first, while you are fresh, and gets the most time. The split is our method, not an employer’s rule. Our middle day is a 90-minute first block, then a 45-minute case or coding block, a 30-minute project block and a 20-minute stories block. Add breaks, and stop when time is up. Here is a sample week for someone whose Day 1 showed a coding gap:

If your gap was the case, swap the columns: a case first every day, and one timed coding problem in the short blocks.

Fewer days? With four days, drop Day 4 and move its stories into Day 5. With three days, keep Day 1, one coding day that also carries the project draft, and the day before. Never drop the diagnostic or the rehearsal.

Timed cases

If your loop has a case or role-play round, it is the open-ended one: a customer problem, a messy brief, a clock. Read the method on one page once, then run cases. After each run, pick the single lowest score and run again with only that fix in mind. For role-play rounds, the client round overview shows what to say in the first minute.

What the first minute looks like:

• Customer: “Permits take too long. Build us a dashboard.”
• Weak first line: “Sure, what data do you have?”
• Strong first line: “Before we pick a tool, which delay hurts most, and who feels it? If we get one thing right in three weeks, what is it?”

The strong line treats the dashboard as a guess at a solution, not the goal, and asks for the outcome that matters. That ticks the “ask why before you propose” box in your first sentence.

The common mistake: reading about cases instead of running them. Only the timer tells you anything.

Coding

Match the practice to what your target company tests. What FDE coding rounds test sorts the evidence company by company: algorithm problems, practical builds, someone else’s code or AI-assisted builds. Then, for every problem:

• say the brute force out loud before you optimize;
• state the complexity before the interviewer asks;
• write one test with numbers you can check by hand;
• name one thing a real customer’s data would break.

That last habit is the other bar showing up in the coding round. Something like: “I’m keying on email for now. If the CRM has a contact ID, I’d use that, because one person with two addresses would count twice.”

Your project deep dive

If your loop has a project deep dive, it is the one round where you pick the material, so it is the easiest to prepare in days. The project deep dive question asks for the problem, your design, what broke and what you would change. Prepare it like this:

1. Draw the architecture from memory on paper, then check it against the real thing.
2. Write down the numbers you measured yourself: load, latency, cost, error rate. Only real ones.
3. Pick the one decision you would change now, and why.
4. Write the three follow-ups you most fear, and answer each out loud.

The fear list is where the value is. If the question you dread is “why that database?”, your answer should start with the constraint, not the brand: “We needed transactions across orders and payments, and the team already ran Postgres.”

Stories out loud

Write down a handful of stories: something you owned end to end, a failure that was yours, a hard stakeholder, a time you changed your mind. Then say each one out loud, recorded, and cut until it lands in about a minute with a result at the end.

Practice your intro the same way. Each new interviewer may hear it first. End it with why this role, not with your last job.

The common mistake: writing stories and never saying them. A story that reads well often runs long, buries the result, and leaves out the part where you decided something.

The day before: rehearse, don’t cram

Nothing you learn today will be steady enough to use tomorrow, and a new topic mostly adds doubt.

• Run one full mock. One case, one coding problem and one story, back to back, timed, recorded. The mock interview post shows how to run one on your own.
• Make one card. Your project’s numbers, the first line of each story, and the questions you will ask each interviewer. Read it tonight and once in the morning.
• Settle the logistics. Address or link, the order of rounds, names if you have them, a charged laptop, a working camera and microphone if any round is remote.
• Stop early. Another problem tonight won’t change tomorrow; a rested head might.

The morning of the onsite

Keep it boring and warm.

• Solve one easy problem out loud, the kind you finish without thinking, to get your voice and hands working together.
• Say your intro once, out loud.
• Reread your card. Nothing else.
• If any round is remote, close every AI tool and every tab you don’t need before it starts.

Between rounds, reset. Don’t replay the last one in your head: the next interviewer was not in the room, and carrying a bad round into a good one is how one slip becomes two. For the common slips and their fixes, see the common mistakes post.

Three sentences worth having ready, because they save rounds:

• “Let me make sure I have the goal right before I start.”
• “I’ll start with the simple version and tell you where it breaks.”
• “I don’t know that yet. Here is how I would find out.”

Want every day set for you? The 5-day plan

If you would rather not build the days yourself, the 5-day plan sets each day’s blocks for you, built on the same idea: measure first, then practice the weak side under a timer.

Whatever you choose, don’t let Day 1 slip. Run the free case at /try today and let the score tell you where the rest of the week goes. If the diagnostic shows a gap the free material doesn’t cover, Pro opens every lesson and model answer, including the unfamiliar-bug question above, with a 7-day free trial, which covers this week.