Innovation: what interviewers score and how to find the story

Innovation in a hiring rubric means novel-to-the-context, not novel-to-the-world. Almost every candidate sets the bar far too high and then reports having nothing.

This lesson resets the bar. It defines what is scored, the signal that separates innovation from recklessness, and the phrasings — two of which are much easier than candidates assume, and one of which is a trap. Then it shows where to find the material you probably discounted: the best innovation story most engineers have is something they removed.

The definition

The bar is lower and the shape is stricter than people expect. Nobody is asking whether you invented something. They are asking whether you noticed that the obvious path was wrong and did something about it.

What it is not

It is not novelty. Choosing an unusual technology because it is unusual scores as a judgement risk, not as innovation.

It is not research. You do not need a paper, a patent, or a new algorithm. Applying content-addressed storage to a build cache, when everyone around you was using timestamps, is innovation in this sense — the technique is decades old and the application was new here.

It is not initiative (Section 6). Initiative asks whether you acted unprompted. Innovation asks whether the approach was non-obvious. A story can be one, both, or neither.

The three parts, all of which are scored

1. Recognising the default was wrong. This is the part interviewers care most about, because it is where the thinking is. Everybody else was doing X. Why did you stop and ask?

2. Generating a real alternative. Not "we could do it differently" — a specific, articulable option with a different cost profile.

3. Validating cheaply first. The strongest innovation stories contain a small, fast test before any real commitment. The signals below develop this; it is the difference between innovation and gambling.

Signals scored

Three positives, four negatives, and one signal that separates innovation from recklessness.

The positive indicators

1. You questioned an assumption nobody had stated. The observable form names the assumption:

"Everyone had been treating it as a storage-cost problem. The assumption underneath was that all fourteen variants get requested. Nobody had checked, because the pipeline predated anybody on the team."

2. You generated more than one alternative. Two options with different cost profiles is evidence of thinking; one option is evidence of a preference:

"There were three ways to do it: shrink the variant list, generate on demand and cache, or move the batch to a cheaper storage tier. The third was the safe one and would have saved maybe 15%. I costed all three before proposing."

3. You validated cheaply before committing. The highest-signal element, and the cheapest to demonstrate:

"Before writing any code I replayed thirty days of request logs against the variant list. It took an afternoon. 96% of generated variants were never requested even once, and the top three accounted for 91% of requests. That afternoon is what made the proposal credible."

The negative indicators

The one that separates innovation from recklessness

The cheap test. An unconventional decision without a validation step is a bet, and interviewers score bets as risk regardless of whether they paid off.

The test does not need to be sophisticated. Real examples of "cheap":

The last one is undervalued. Working ten real cases on paper has killed more bad designs than any amount of prototyping.

Questions asked

Six phrasings. Two of them are far easier to answer well than candidates assume, and one is a trap.

1. "Tell me about a creative solution to a hard constraint."
2. "Tell me about a time you did something unconventional."
3. "Tell me about a time you significantly simplified something."
4. "Tell me about a time you challenged the way things were done."
5. "What's the most innovative thing you've built?"
6. "Tell me about a time you found a much cheaper way to solve a problem."

What each is really probing

Question 5 is the trap

"What's the most innovative thing you've built?" invites a superlative, and superlatives push candidates toward their biggest project rather than their best-reasoned one. The result is usually a thin story about something large.

Redirect it:

"I'd answer that with something small, if that's alright — it's the one where the reasoning was most interesting rather than the one where the system was biggest."

Interviewers almost always say yes, and the redirect itself reads well.

Questions 3 and 6 are the easy ones

Simplification and cost-reduction questions are the friendliest in this competency and the most under-used. Most engineers have deleted something or replaced something expensive with something cheap and have never counted it as innovation, because it did not feel like inventing.

Finding that material is what the rest of this lesson is about.

Building the story

The best innovation story most engineers have is one they discounted.

Simplification beats invention

Two claims, both worth stating plainly.

Deletion stories score at least as well as invention stories. "I removed a system" contains a decision, a risk taken, a cost measured, and a durable outcome. "I built a system" often contains only the third.

Almost every engineer has one. A batch job you removed. A cache you deleted because you measured the hit rate. A configuration option nobody used. A service you folded back into its caller. A retry layer that was making things worse.

These are discounted because they do not feel like achievements. In a rubric they are among the strongest items available, because removing something requires proving it is not needed — which is harder than adding something.

The two tests

Test 1 — there was a default, and you can name why it was wrong here. Not wrong in general. Wrong for your traffic shape, your team size, your cost profile, your latency budget. The specificity is the evidence.

Test 2 — you have the cheap validation. What did you check before committing, how long did it take, and what result would have stopped you?

If you cannot answer test 2, the story is usable and weaker, and you should say so honestly in the telling: "I didn't validate it as cheaply as I should have — I was fairly confident from the access patterns and I'd do a log replay first if I did it again."

Where to look

The last row surprises people. Deliberately keeping something inelegant, for a stated reason, with a stated review date, is a legitimate innovation story — it shows you optimise for the real objective rather than for engineering aesthetics.

Level calibration