Interviews and what senior sounds like

FDE interviews test whether you can be trusted alone with a customer. Knowledge matters less than judgment: what you ask, what you build first, what you refuse to build, and how you adjust when the facts change. This chapter is about showing that judgment under time pressure.

What the loop is testing#

Formats vary by company, but most FDE loops combine a role-fit screen, practical coding, a debugging or existing-codebase exercise, an open-ended decomposition or customer case, an AI system design, a client role-play and behavioural questions. The interview prep page covers each round, its format and how it is scored. Underneath the formats, interviewers are looking for four habits.

• You clarify before you build, and your questions change the design.
• You choose the smallest useful thing, and say what you are leaving out.
• You think about failure and permissions without being prompted.
• You can explain a trade-off to an engineer and to an executive, in different words.

Palantir's public hiring pages describe the same emphasis: decomposing open-ended problems, solving technical problems with clean code, and working within existing systems. Practise against those habits, not against leaked question lists.

Six questions for open-ended cases#

"Help a logistics company with late deliveries" could go anywhere. Six questions keep you on track and make your thinking easy for the interviewer to follow. Go round them once quickly to sketch an answer, then again in more depth where the interviewer wants to dig.

Question 2 deserves the emphasis. Software earns its keep by changing what someone does: which delivery the dispatcher calls about, which invoice the clerk checks first. If you can't say whose action changes, a dashboard or a model is decoration. Once you can, the data you need, the screen they use and the measure of success mostly follow.

Name whose action changes. The design follows from that.

Running a 45-minute case#

Keep track of time out loud now and then: "I've got about fifteen minutes, so let me move to how this fails." Interviewers read that as leadership. Running out of time before you reach failure and rollout is the most common way strong candidates lose a case round.

Senior is not longer#

Under pressure, candidates pad. They list products, add boxes, and reach for the most autonomous design available. Interviewers are listening for something else: what you chose, what you dropped, and why.

Napkin maths that leads somewhere

Do the sizing out loud: eligible users, daily active, requests per user, average and peak rates, and the downstream calls each request makes. Then say what the number means for the design. The arithmetic is not the point. The sentence after it is.

When the interviewer changes the facts#

Many case rounds reveal information in stages on purpose: the data source you assumed doesn't exist, security won't allow an external model, a key user group was missing. They are testing whether you update or defend.

1. 1

   Acknowledge it plainly

   "That changes things." Don't treat it as an attack on your design.
2. 2

   Name the assumption it breaks

   "I'd assumed the inventory data was available in real time."
3. 3

   Say what changes and what doesn't

   Rework only the affected part, and keep the rest of the design.
4. 4

   Update the plan

   Adjust the pilot, the metric or the rollout, and say what evidence would cause the next change.

Coding rounds, including AI-assisted ones#

FDE coding problems tend to look like real work rather than puzzles: parse a messy file, reconcile two lists of records, paginate an API, handle rate limits and retries, cache results, de-duplicate events. Interviewers watch for three things: whether you state the input, output and edge cases before coding; whether you write code another person could maintain; and whether you test it, ideally by hand-tracing a case or two.

Some companies now let you use an AI assistant in the coding round. That changes what is assessed, not whether you are assessed. They watch how you break the problem down for the assistant, whether you read what it produces, and whether you catch its mistakes. Accepting a plausible but wrong patch is the fastest way to fail. Narrate your verification: "It's retrying the write without an idempotency key, so a timeout could double-charge. I'll fix that."

Stories with numbers#

Behavioural rounds for FDEs keep returning to a handful of themes: owning an outcome end to end, handling a difficult customer, saying no or reframing a request, recovering from a mistake, and learning something fast. Prepare one story for each, from your own work, with the situation, what you did, and the measurable result. A good story fits in two minutes and leaves room for follow-up questions.

If you lack customer-facing experience, use internal customers: the team that depended on your service, the stakeholder whose request you reshaped. What matters is the behaviour, not the job title. Chapter 17 covers how to build projects that give you stories worth telling.