How do you use a spike to de-risk a story?
This tests your ability to use agile spikes for targeted de-risking, not just vague research. A strong answer defines the specific question the spike will answer, proposes a strict time-box, and lists concrete deliverables like a decision or a better estimate.
What's really being asked
This isn't just about knowing the definition of a spike. It tests your ability to translate abstract risk into a concrete, time-boxed investigation with a clear purpose. Interviewers want to see that you can structure ambiguity, protect the team from open-ended 'research' tasks, and produce actionable knowledge that enables better planning and estimation for the subsequent feature work. It's a test of project management and technical leadership within an agile framework.
The full answer
A strong answer has four parts. First, clearly state the specific question the spike is meant to answer. Don't say 'research the API'; say 'determine if the third-party API's create-user endpoint can be called idempotently.' Second, propose a strict time-box, usually between a few hours and two days, to prevent scope creep. Third, define the concrete deliverables. These are never production code. They are things like a short document with a recommendation, a code snippet in a separate branch demonstrating a technique, a presentation to the team, or a revised estimate for the original story. Fourth, explain how these deliverables de-risk the original story and allow the team to proceed with a well-understood task.
The mistakes people make
The biggest red flag is describing a spike as an excuse to start coding the feature without a story. Candidates might say, 'I'd just start building it and see how far I get.' This misses the point of a spike, which is to gain knowledge, not to produce a partial feature. Another wrong answer is being vague about the outcome, like saying the deliverable is 'understanding' or 'knowledge.' A good answer makes the knowledge tangible. Finally, proposing a spike that lasts a full sprint is a red flag; it's too long and indicates the problem hasn't been broken down enough.
What usually comes next
'How do you estimate a spike?' (The answer is you don't give it story points, you time-box it). 'What happens if the spike fails or you don't get an answer in the time-box?' (The outcome is still knowledge: 'this path is not viable' or 'this is more complex than we thought and needs more focused research'). 'How do you convince a product manager to prioritize a spike that delivers no direct user value?' (Frame it as insurance; spending 1 day now saves 5 days of wasted effort later).
A concrete example
For a story to 'Integrate NewPaymentAPI,' a good spike proposal would be: 'Let's create a 1-day spike to answer: Can we build a proof-of-concept that successfully processes a test payment and handles their webhook for confirmation? The deliverable will be a 1-page summary with a go/no-go recommendation for this API, a link to a throwaway code branch, and a revised story point estimate for the full integration story, which we currently can't estimate.'
Interview question
Which characteristic best defines an effective agile spike for de-risking a story?
- a.It produces a small, functional piece of the feature to demonstrate feasibility.
- b.It is a time-boxed investigation to answer a specific question and yield actionable knowledge.Correct
- c.It allows the team to explore new technologies or architectural patterns without immediate delivery pressure.
- d.It results in a comprehensive design document for a complex component before development begins.
Why? this is the answer
An effective spike is defined by its strict time-box, its focus on answering a specific question, and its goal of yielding actionable knowledge to reduce risk for a subsequent story. Option A describes a common misconception where a spike is mistakenly used to begin feature development rather than gather knowledge.
Just read this? Test yourself on what you have been reading.
Read the original → mountaingoatsoftware.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles