Why Curveballs Are Different

Most of your prep is for the predictable surface area. You have banked stories for leadership, conflict, failure, ambiguity, and technical depth. You have rehearsed your 'tell me about yourself' and your 'why this company'. The standard onsite questions are mostly variations on those, and STAR plus story banking handles them.

Then the interviewer asks: 'Tell me about a time you had to convince someone to do something they did not want to do, when you also were not sure they were wrong'. Or: 'If you had infinite engineering resources for one week, what would you build?'. Or: 'Tell me about the most awkward professional moment you can talk about'. Or: 'Imagine you find out a senior engineer on your team has been falsifying their on-call response times. Walk me through what you do.'

These are not questions your story bank was built for. The first is a values probe with two layers (persuasion plus honest uncertainty). The second is a pure hypothetical that does not have a real event to anchor in. The third is an unstructured probe of self-awareness through an unusual surface. The fourth is an ethics dilemma where the right answer is not obvious and the framing matters more than the conclusion.

The failure mode is recognisable. The candidate freezes, then says something flat ('that is a great question, let me think'), then produces a hedged half-answer that does not satisfy the question. The interview slides off the rails and the candidate spends the rest of the round re-stabilising.

This lesson teaches the moves that prevent that.

The Categories of Curveball

Knowing the category before you answer changes which moves are available. Five common categories:

1. Truly novel hypotheticals. 'If you could redesign our hiring process, what would you change?' 'How would you build X if you had only one engineer for one quarter?' These ask for thinking you do, not a story you tell. STAR does not apply. The interviewer is grading judgement, taste, and how you reason in real time.

2. Unusual-surface probes. 'Tell me about the most awkward thing that has happened to you at work'. 'Tell me about a time you got really excited about something at work that nobody else cared about'. 'Walk me through the strangest decision you have ever made'. These are STAR questions in disguise but with a surface most candidates have not banked for. The interviewer wants a real event; they are testing whether you have the range to find one outside your default templates.

3. Values probes. 'Tell me about a time you disagreed with a decision but went along with it'. 'Walk me through how you would handle a situation where your manager asks you to do something you think is wrong'. These are designed to test your actual values under pressure rather than the values you list when asked directly. The interviewer is grading not just what you would do, but how you reason about it.

4. Ethics dilemmas. 'A coworker confides in you that they are interviewing elsewhere. Your manager asks you directly if your team has retention issues. What do you do?'. 'You discover a security flaw that would take six weeks to fix, but you are mid-sprint on a launch. What is your move?'. These are designed to surface how you trade off competing obligations. The interviewer is mostly grading your reasoning, not your conclusion.

5. Brain teasers framed as behavioural. 'How many software engineers do you think it would take to rebuild Slack from scratch?'. 'If our company doubled in size next year, what is the first cultural problem we would hit?'. These are estimation or strategic-thinking questions wearing a behavioural costume. The interviewer is grading your structured-thinking-under-uncertainty, not a story.

The first move when you hear a curveball is to silently classify it. The category determines your next move.

The 5-Second Pause

The single most important technique for curveballs is also the simplest: pause for about 5 seconds before you start answering.

Most candidates feel they need to start speaking immediately, because silence feels uncomfortable. But for an unexpected question, 5 seconds of explicit silence is far stronger than 5 seconds of filler ('um, that is a really interesting question, let me think about it for a second, hmm'). The filler version takes the same wall-clock time and produces a worse answer because you spend the seconds talking instead of thinking.

The phrase that gives you permission to take the pause: 'Let me think about that for a moment'. Said once, in a measured tone, then actually pause. The interviewer almost always nods and waits. They are not annoyed; if anything, they are reassured. A candidate who reflexively jumps into a half-answer is signalling that they cannot handle the moment. A candidate who takes a beat, thinks, and then delivers a structured answer is signalling exactly the opposite.

What you actually do during the 5 seconds:

1. Classify the curveball (which of the five categories above).
2. Identify whether you have a real event you can redirect to (and whether redirecting is honest).
3. Pick the structure for the answer (a STAR-shaped story, a structured framework for a hypothetical, a values stance with a worked example).

Five seconds is enough to do all three if you are practised. Practising is part of the prep for this lesson.

The Redirect-to-Real-Event Pivot

For categories 2 and sometimes 3 (unusual-surface probes and values probes), the question is technically open-ended but the interviewer almost always wants a real event. The most reliable move when you have one is to redirect:

'Let me think about that... I think the closest thing I have actually experienced is...'

Or: 'Rather than answer that hypothetically, let me ground it in something that actually happened to me last year, which I think hits the same shape.'

Why this works: real events are richer than hypotheticals, contain detail the interviewer can probe, and let you score on STAR signals you have practised. A grounded story is almost always stronger than the cleanest hypothetical.

When the redirect is the right move:

• The question is asking for evidence about you, not your thinking. ('Tell me about a time you...' or 'Walk me through how you have handled...').
• You have a real event that genuinely fits the question's shape.
• The interviewer has not already explicitly framed the question as a hypothetical.

When the redirect is dishonest, and you should not do it:

• The question is explicitly hypothetical. 'Imagine that...', 'Suppose...', 'If you were in the position of...' These are not asking for redirect; the interviewer wants to see how you reason about a constructed scenario.
• You do not actually have a real event that fits. Pretending you do, with a vague story that does not quite map, is worse than answering the hypothetical honestly.
• The interviewer has just rejected an earlier story and asked the question to push you out of your prepared zone.

A practical heuristic: if redirecting requires you to bend a story so that it almost-but-not-quite fits, do not redirect. Answer the question as posed.

Answering Pure Hypotheticals

When the question genuinely is hypothetical, you cannot redirect. You have to do the thinking out loud, and you have to do it in a structure the interviewer can follow. Three things that make hypothetical answers strong:

1. Surface your assumptions explicitly. A hypothetical is under-specified by design. State the assumptions you are making before you answer. 'I am going to assume the team is around 5 to 10 engineers, the company is past product-market fit, and we are not in active fundraise. If those assumptions change, the answer changes, but let me work the version with those assumptions.' This buys you optionality; if the interviewer wants you to assume differently, they will tell you, and you can adjust.

2. Decompose the problem before answering. A strong hypothetical answer almost never starts with the conclusion. It starts with a brief decomposition: 'There are really three things I would think about here. The first is X, the second is Y, the third is Z. Let me work through each.' This gives the interviewer a roadmap and gives you a structure to navigate. Even if your conclusion ends up being weak, the structured reasoning around it scores.

3. Surface the trade-offs and pick. Hypotheticals are designed so that the right answer depends on values. State the trade-offs ('the conservative approach optimises for X at the cost of Y; the aggressive approach optimises for Y at the cost of X'), then state your pick and the reasoning. Do not hedge to the end. The interviewer wants to see what you would actually choose, not a list of options.

A hypothetical answered this way takes 60 to 90 seconds. The structure (assumptions, decomposition, trade-offs, pick, reasoning) is more important than the conclusion.

Answering Values Probes and Ethics Dilemmas

For values probes and ethics dilemmas, the interviewer is grading the reasoning more than the conclusion. The shape of a strong answer:

1. Acknowledge the tension. 'There are two real obligations in conflict here, and I want to name them before I answer.' This shows you see the problem clearly. Most candidates rush past the tension and answer as if the right move is obvious; the interviewer often picks the question precisely because it is not.

2. State the principle you would apply. 'The principle I would lean on is...' Examples: honesty over comfort in feedback; safety over speed in production; institutional commitments over personal loyalty when they conflict. A principle is more durable than a one-off decision.

3. Walk through the application of the principle to the specific scenario. What would you actually do, in concrete steps? What would you say first? Who would you talk to? In what order?

4. Acknowledge what is hard. A strong values answer ends with a sentence acknowledging the cost of the choice. 'The thing that makes this hard is that the senior engineer is also a friend, and the right call costs the friendship.' This is not weakness; it is the candidate signalling that they understand the choice has a cost and they are willing to pay it. Sanitised values answers ('it is a clear choice, I would just do X') sound naive.

For an ethics dilemma specifically, lean toward action that protects the institution and the people in it, while being honest about the costs. Avoid two failure modes: the strategically clever answer that protects nobody but yourself, and the moralising answer that judges the people in the scenario.

Worked Curveballs

Four worked examples, one per category (we are folding values probes and ethics dilemmas into one example since the structure is the same).

Curveball 1: Pure hypothetical

Question: 'If you could redesign your team's on-call rotation from scratch, what would you change?'

'Let me think about that for a moment... [pause]

I am going to assume we are talking about a 6-person backend team with one production-critical service, current rotation is one engineer per week with a primary and a backup, and the team has been live for about two years. If those assumptions are off, the answer would change.

There are really three things I would look at. The first is fairness: who pages whom and at what hour. The second is sustainability: does the rotation produce burnout. The third is competence: does the rotation actually train the team to handle incidents well.

On fairness, I would split the rotation into business-hours and after-hours blocks rather than full weeks, because in my experience full weeks load the burden onto whoever happens to be unlucky that week. I would also publish the page-out distribution monthly so the team can see if one person is taking more than their share.

On sustainability, I would set a hard ceiling: if any engineer takes more than two pages outside business hours in a week, the next week is a forced off-rotation week. The cost of this is occasionally fewer hands on the rotation; the benefit is that nobody hits the burnout cliff that destroys teams I have seen elsewhere.

On competence, the change I am most opinionated about is mandatory pairing on the first three incidents a new engineer takes. Real on-call training does not happen in tabletops; it happens when a new engineer takes a real incident with a senior engineer pairing in voice. That investment of senior time is expensive and it pays back tenfold in incident quality six months later.

If I had to pick one of those as the most important: it would be the pairing model. Fairness and sustainability are necessary; the competence move is the one that compounds. The thing that makes this question hard is that all three changes have real costs (more rotation overhead, more senior time spent), so a leader recommending all three has to also recommend what to give up to pay for them.'

What is happening: assumptions surfaced first, three-way decomposition, trade-offs acknowledged, a pick named, the cost of the pick acknowledged. The candidate did not have a banked story for this; they reasoned cleanly in real time.

Curveball 2: Unusual-surface probe (redirected to real event)

Question: 'Tell me about the strangest professional decision you have made.'

'Let me think... [pause]

The thing that comes to mind is a decision I made about three years ago that probably qualifies. I had been at a Series A startup for about a year, doing well, on the path to a senior role within the next quarter. A friend who had left the company a few months earlier reached out and asked if I would consider joining a tiny three-person team that was working on a project that, on paper, made no sense: a developer-tool library in a niche language, no obvious business model, and the founder was prickly enough that everyone I asked told me not to do it.

I went and joined for six months. It was the most interesting six months of my early career. Almost every assumption I had about how engineering teams should work got tested and most of them got revised. We shipped the library, it never made meaningful revenue, and I left for what eventually became my current role.

The strange-decision part is that I took a 30% pay cut and gave up an imminent promotion to do it. The reason I did it, looking back, was that I had a hunch the team would teach me how I really wanted to work, and I was right; I could not have learned the same things at the bigger company at the same speed. The cost was real (the pay cut compounded across the year, and the role I returned to was lateral, not the senior role I had been about to get). The benefit was that almost everything I now do well as an engineer, I learned during those six months.

What it taught me about my own decision-making is that when I have a strong hunch about a learning environment, I should weight it heavier than the financial and title comparison, because those compound much slower than the learning does.'

What is happening: the candidate redirected from 'strangest decision' (which sounds open-ended) to a concrete real event. They told a real STAR-ish story with the trade-off explicit, the cost acknowledged, and the meta-lesson that connects to who they are now. The redirect is honest because the event genuinely fits the question, and the answer is far stronger than any hypothetical they could have constructed.

Curveball 3: Values probe with redirect

Question: 'Tell me about a time you disagreed with a decision your team made but went along with it anyway.'

'Let me think... [pause]

The clearest example I have is from about two years ago. The team was deciding to deprecate an internal tool I had been the primary maintainer of for the prior year. I disagreed with the decision: I thought the tool had a six-month tail of users we were going to disrupt, and I thought the engineering cost of maintaining it for that tail was lower than the cost of the disruption.

I made the case in two design review meetings and one async write-up. The team listened, asked good questions, and ultimately decided to deprecate anyway. The decision was not unanimous, but it was clear. I went along with it.

The reason I went along with it, even though I still thought the call was wrong, is that I had had my full hearing. The team had not dismissed my view; they had considered it and disagreed. At that point my obligation shifted from arguing my case to executing the team decision well. So I led the deprecation, wrote the migration guide for the affected users, and ran the customer communication.

The interesting part for me is what happened next. About four months in, my prediction turned out to be partially right (we did disrupt about 30 users in ways that took our customer success team a meaningful amount of time to handle), and partially wrong (the engineering cost of the migration was lower than I had estimated, and the codebase health benefit was higher than I had estimated). On balance the team had made the right call, even though I had not seen it at the time.

What I learned is that when I disagree with a team decision after my full hearing, the right move is to commit. Not because my disagreement is wrong, but because the team needs to be able to act, and a member who keeps relitigating after the decision is the wrong kind of member. I have found this lesson harder to live than to state, but it has held up.'

What is happening: the candidate redirected from the values-probe phrasing to a real event. Tension named (disagreement with the call), principle stated (full hearing then commit), application described (what they actually did during the deprecation), cost acknowledged (their prediction was partially right). The values are demonstrated in the work, not asserted as a list.

Curveball 4: Pure ethics dilemma

Question: 'You discover that a senior engineer on your team has been falsifying their on-call response times to make their on-call performance look better. They are also a long-time friend. What do you do?'

'Let me think about that for a moment... [pause]

There are two real obligations in tension here. One is to the team and the company: on-call data is load-bearing for incident review, and falsified data corrupts decisions other people are making. The other is to the friend: a personal relationship that has presumably been honest for a long time and that I do not want to damage casually.

The principle I would lean on is that institutional honesty about load-bearing data is non-negotiable, but how it gets surfaced matters. The friend deserves the chance to fix this themselves before it becomes a formal issue.

So the actual sequence: first, I would talk to them directly, in private, before doing anything else. I would tell them what I had seen, that I was struggling with it, and that I wanted to give them the chance to either explain something I was misreading or to correct it themselves before I had to escalate. I would ask them what they wanted to do about it.

If they corrected the data and committed to honest reporting going forward, I would still likely tell my manager that the on-call data quality has been a problem on the team and that we need a better verification process, without naming them specifically. The systemic fix is needed regardless.

If they pushed back, denied it, or asked me to keep it quiet, I would escalate to my manager. At that point the institutional obligation outweighs the personal one. The conversation with the manager would be factual: what I saw, what I did about it, what response I got.

The thing that makes this hard is that the right call costs the friendship in some form. Either I confront them, which is uncomfortable, or I escalate, which is more uncomfortable. I would not pretend that does not matter. But the principle holds: institutional commitments in conflict with personal ones, when the institutional commitment is about honesty in load-bearing data, the institutional one wins. I would do the right thing and absorb the relational cost.'

What is happening: tension acknowledged explicitly, principle named (institutional honesty about load-bearing data), application walked through in concrete steps, cost acknowledged at the end. The answer is not sanitised; the candidate names the relational cost honestly. They do not moralise about the friend, and they do not protect themselves by avoiding the action.

Two Things to Avoid

Two failure modes specific to curveballs that you should watch for in your own answers.

The clever-answer failure. When candidates feel cornered, some try to be clever: a counterintuitive twist, a 'well actually' reframe, an ironic observation about the question itself. Do not. The interviewer is asking the question seriously and wants the answer seriously. Cleverness reads as deflection. The honest, structured answer is almost always stronger than the clever one.

The hedge-everything failure. The opposite failure: refuse to commit to any answer, list every possible option, and end with 'so it really depends'. This is the candidate trying to avoid being graded by avoiding answering. The interviewer is grading the commit more than the conclusion; refusing to commit fails the grade. State your assumptions, name your trade-offs, then pick.

A Quick Drill

Fifteen-minute drill, ideally with a friend or colleague:

1. They ask you three curveballs at random from across the five categories. They do not warn you in advance.
2. For each, you take the 5-second pause out loud, classify the question silently, and then answer in 60 to 90 seconds using the appropriate structure.
3. After each, they give you 30 seconds of feedback on whether the answer hit the structure for that category.

Do this once per week in the run-up to a big loop. The pause becomes natural; the classification becomes faster; and your repertoire of real events to redirect to grows.

Bridge to the Next Lesson

This lesson taught you to handle questions outside your prepared bank. The next lesson, Behavioral Interviews for Senior / Staff / Principal Roles, takes a different cut: how the same kinds of questions are graded differently as the level rises, and how to recalibrate your story selection and delivery for the staff bar specifically. Together, these two lessons cover the breadth axis (the kinds of questions you can be asked) and the depth axis (the level at which you are being graded), which are the two ways behavioral rounds get harder for senior candidates.