The FDE interview scorecard

What this is built on

• Google re:Work structured interviewing: predetermined questions with follow-ups, and rubrics with illustrative answers at four levels (poor, borderline, solid, outstanding). We use the same four-level idea.
• Behaviorally anchored rating scales (BARS): each score is defined by something you can observe, not an adjective.
• GitLab handbook: interviewers cannot see each other’s scorecards, every scorecard has pros and cons with specific examples, submit within 24 hours, and never compare candidates to each other.
• Greenhouse scorecard guidance: derive attributes from what success looks like at 90 and 365 days, keep them distinct, realistic, and few.
• Palantir decomposition round and FDE loop write-ups: clarify before solving, empathy for the end user, data reasoning, realistic scoping, iterating when pushed back on. Red flags include jumping to architecture before understanding the user, asking few questions early, and building the biggest system instead of the smallest useful one.

The scale

Score	Label	Meaning
1	Concern	Clear evidence they would struggle in this area on a real deployment.
2	Mixed	Some good moments, but gaps you would need to manage around.
3	Solid	Meets the bar. You would trust them with this on a real customer.
4	Strong	Raises the bar. You would want others on the team to learn from how they did this.

There is no middle score on purpose. Pick a side.

The four dimensions

1. Build

What it measures: Can they turn a fuzzy customer need into working, production-quality software, and choose the smallest thing that delivers value?

Signals to watch for

• Sketches the end-to-end path before going deep on any one part.
• Names real components, data sources, and APIs instead of staying abstract.
• Writes or describes code that would survive production: error handling, logging, failure modes.
• Scopes a first version that ships in days or weeks, with a clear path to the next one.

Anchors

• 1 Concern: Cannot get from the problem to a buildable plan, or designs a large system with no clear first version. Ignores how it fails. Code or design would not survive real use.
• 2 Mixed: Gets to a workable design, but misses important pieces (data access, auth, failure cases) or over-engineers one part while the rest stays vague.
• 3 Solid: Produces a clear, buildable plan with a sensible first version. Names concrete components and handles the obvious failure modes. Code is clean and readable.
• 4 Strong: All of Solid, plus makes sharp tradeoffs out loud, picks a first version that is small and clearly valuable, and anticipates operational issues (monitoring, rollback, cost) without being asked.

2. Discovery

What it measures: Do they find out what the customer actually needs, including what the customer did not say?

Signals to watch for

• Asks about the end user, the current workflow, and what “done” means before proposing anything.
• Follows up on vague answers until they get something specific (a number, a name, an example).
• Uncovers at least one constraint or fact the customer did not volunteer.
• Plays back a summary of the problem and priorities and checks it with the customer.

Anchors

• 1 Concern: Starts solving within the first few minutes. Asks few questions, or only technical ones. Accepts the first answer every time.
• 2 Mixed: Asks reasonable questions but stays on the surface. Finds some hidden facts by luck rather than by following a thread. Summary is partial or skipped.
• 3 Solid: Asks about users, workflow, data, and success criteria before solving. Follows up on vague answers. Finds most of the important hidden facts and summarizes accurately.
• 4 Strong: All of Solid, plus questions are clearly hypothesis-driven, they find the facts that change the solution, and the customer would feel understood. They notice when the stated problem is not the real problem.

3. Pushback

What it measures: Can they disagree with a customer or stakeholder honestly and constructively, protecting the outcome without damaging the relationship?

Signals to watch for

• Says no (or “not yet”) to requests that would hurt the outcome, and explains why in the customer’s terms.
• Offers an alternative or a tradeoff instead of a flat refusal.
• Holds a reasoned position when challenged, and changes it when given a good reason.
• Is honest about what they do not know or what the product cannot do.

Anchors

• 1 Concern: Agrees to everything, including unrealistic scope or timelines. Or the opposite: argues, gets defensive, or dismisses the stakeholder.
• 2 Mixed: Pushes back sometimes, but vaguely (“that might be hard”) or without offering a path forward. Folds under the first sign of pressure.
• 3 Solid: Clearly names the risk or tradeoff, ties it to the customer’s goal, and proposes an alternative. Stays calm and respectful.
• 4 Strong: All of Solid, plus turns the disagreement into a better plan the stakeholder is happy to own. Knows which battles matter and lets small ones go.

4. Shipping under pressure

What it measures: When things change or go wrong mid-stream, do they stay calm, re-plan, and still get something valuable out the door?

Signals to watch for

• Absorbs new information (the twist) and adjusts the plan instead of restarting or ignoring it.
• Reprioritizes explicitly: what gets cut, what stays, and why.
• Stays composed and keeps the customer informed.
• Ends with a concrete next step: who does what, by when.

Anchors

• 1 Concern: Freezes, gets flustered, or ignores the new information and keeps going with the old plan. No clear next step.
• 2 Mixed: Adjusts, but slowly or messily. Re-plan is vague, or they try to keep everything in scope and promise too much.
• 3 Solid: Acknowledges the change quickly, re-scopes with clear cuts, communicates calmly, and ends with a realistic next step and owner.
• 4 Strong: All of Solid, plus uses the change to sharpen the plan (for example, spots that the twist reveals the real priority) and leaves the customer more confident than before.

How to use it

1. Before the interview: each interviewer knows which dimensions they own. Every dimension should be covered by at least one interviewer across the loop, and ideally two.
2. During the interview: take notes on what the candidate said and did, close to verbatim. Write down quotes and specific moments, not impressions.
3. Right after (within 24 hours, ideally within 1 hour): score each dimension you own on the 1 to 4 scale. For every score, write at least one piece of evidence (a quote or a specific moment) that supports it.
4. Score independently. Do not read anyone else’s scorecard, and do not discuss the candidate with other interviewers, until yours is submitted.
5. Write pros and cons. Every scorecard has at least one of each.
6. Do not compare candidates to each other on the scorecard. Compare them to the anchors.
7. Debrief: start with each interviewer reading their scores and evidence before any discussion. Discuss disagreements by looking at evidence, not by persuading. If someone changes a score after debrief, note why.

Evidence note format

Dimension: Discovery. Score: 3. Evidence: At minute 6 asked “who looks at this report on Monday morning and what do they do with it?” which surfaced the ops manager as the real user. Followed up twice on “the data is mostly clean” and got the 18% duplicate rate. Did not ask about budget or timeline.

Red flags

Any one of these should be written up and discussed at debrief, regardless of scores.

• Starts designing or coding before asking who the user is or what “done” means.
• Talks more than the customer during discovery.
• Promises a timeline or feature they cannot know is possible.
• Blames the customer (“their data is bad”) instead of working with what exists.
• Dismissive or condescending toward non-technical stakeholders.
• Cannot explain their own design in plain language.
• Pretends to know something they do not, especially about a product or system.
• Ignores the twist and continues with the original plan.

The hire / no-hire rule

1. Any 1 (Concern) on any dimension = no hire, unless the debrief agrees the evidence was thin and a follow-up interview targets that dimension.
2. Hire requires: average of 3.0 or higher across the four dimensions and at least one 4 (Strong) somewhere in the loop.
3. Build and Discovery must both be 3 or higher. These are the two halves of the job. A strong builder who cannot discover, or a strong discoverer who cannot build, is a different role.
4. Two or more 2s (Mixed) = no hire for Senior and Staff. For Mid-level, two 2s can pass only if Build and Discovery are both 3+ and the 2s are in Pushback or Shipping Under Pressure.
5. A confirmed red flag overrides scores and defaults to no hire unless the hiring manager writes down why it is not disqualifying.
6. When in doubt, it is a no. A wrong FDE hire costs a customer relationship, not just a team seat.