How should a candidate re-rank prepared stories for an early-stage company versus a large one?
answer
- Same bank, different top
- Rank by what the role must buy
- Ownership width, risk price, decision style
- Working-style lines beat headcount inference
- Three promoted, four held in reserve
basics
~20 sRank by what the company has to spend engineers on. Early-stage teams reward scope cuts, ambiguity and shipping without support; large organisations reward coordination, safe migration and working across teams that do not report to you.
solid answer
~40 sThe bank stays the same and the top of it moves. I run the same seven stories against a company and promote three. For an early-stage frontend team, the ones that rise show me choosing what not to build, shipping something rough on purpose, and owning a surface with nobody to escalate to. For a large organisation, the same bank promotes different three: a migration that did not break the callers, a decision made with two other teams, a piece of work that survived a handover. The stories I demote are not weak, they are just answering a question this company is not asking. If the posting says `we ship small and often and expect engineers to talk to users`, cadence and user contact become the ranking key regardless of company size.
go deeper
Know that different companies want different examples from the same background. Before a conversation, pick which two or three of your experiences fit this role best rather than telling them in the order they happened.
Explain the ranking keys — how wide the ownership is, how risk is priced, how decisions get made — and show a concrete pass where the same set of experiences produces two different top threes.
Demonstrate that you check coverage as well as fit: a promoted set that all proves speed leaves you exposed. Show how the posting's working-style lines override a lazy inference from company size.
Own the case where the ranking exposes a real mismatch. Decide whether your record genuinely fits what the role must buy, and be able to say when the honest conclusion is that it does not.
## The bank is stable; the top three move Re-ranking assumes you already carry a set of tellable stories — say seven that you can deliver without notes. Preparation for a specific company is not writing an eighth. It is deciding which **three** go to the front, because those are the ones you will reach for on the first open question and the ones you will steer back to if the conversation drifts. The remaining four stay available. They are what you use when a question lands somewhere you did not plan for, and demoting a story says nothing about its quality — only that it answers a question this company is not asking. ## The ranking keys Stage is the crude version of the signal; underneath it are the real dimensions. **How wide is the ownership?** A small team hands one person a whole customer-facing surface. A large one gives a slice of a surface with defined edges. Promote stories whose scope matches: end-to-end ownership for the first, deep work inside a boundary plus clean interfaces for the second. **How is risk priced?** Where a mistake costs a rollback and an apology, stories about shipping something deliberately unfinished are an asset. Where a mistake reaches a very large number of people or a regulated process, the same story reads as recklessness and a story about a staged migration reads as maturity. **How are decisions made?** In a small team you decide and tell people. In a large one you build agreement first. Promote the story that shows the matching motion — cutting scope on your own judgment, or getting two other teams to accept a change to something they own. **Where does certainty come from?** Teams close to their users prize the story where you changed course after watching someone use the thing. Teams with heavy analytics or research functions prize the story where you framed the question those functions then answered. **What does the working-style paragraph say?** This is the direct evidence and it overrides your assumptions about size. A posting that says `we ship small and often and expect engineers to talk to users` makes cadence and user contact the ranking key whether the company is five people or five thousand. ## A worked pass Same frontend bank, two postings, both marked up in two colours and reduced to about four lines. **Posting A — small team, one product surface, weekly releases, engineers in user calls.** Promoted: the redesign cut into shippable slices; the feature deliberately launched without its settings screen; the week spent on session recordings that killed a planned feature. Demoted: the accessibility audit across many teams, the component-library migration. **Posting B — large organisation, one surface among many, shared design system, staged rollouts.** Promoted: the component-library migration that kept every consuming team building; the accessibility audit and how you got other teams to adopt its findings; the rollout that went out in stages with a rollback you actually used. Demoted: the deliberately unfinished launch, which here mostly raises questions about process. Nothing was rewritten. Six of the seven stories appear in one list or the other, and the *same* story can appear in both with a different opening beat. ## Where the ranking goes wrong **Ranking by how proud you are.** The story you most enjoy telling is the one you have polished most, which is not the same as the one this role needs to hear. **Ranking by recency.** Your most recent work is not automatically your most relevant, and leading with it because it is fresh wastes the opening question. **Assuming stage determines everything.** Large organisations contain teams that operate like small ones, and small companies sometimes carry heavy compliance constraints. The posting's own working-style lines beat the inference from headcount every time. **Promoting three stories that all prove the same thing.** Three variations on shipping fast leave you with nothing when the conversation turns to disagreement or to a decision you got wrong. Check that your top three cover different ground. ## The cheap test For each promoted story, complete this sentence in one line: *this is here because the role needs someone who ___.* If you cannot finish it from the four-line map, the story is in the top three for your reasons rather than theirs, and something else should take the slot.
- Can the same story sit at the top for two very different companies?Often, with a different opening beat. A redesign cut into slices can lead on autonomy and speed for one team and on migration safety for another, because both are genuinely in the same events. What must not happen is the same delivery for both — if the opening sentence is identical, you re-ranked nothing.
- How do you avoid promoting three stories that all prove the same trait?Check coverage before you check ranking. Write the one thing each promoted story demonstrates; if two lines match, swap one out for something from the reserve. A top three that is all speed leaves you empty when the conversation turns to a decision you got wrong or a disagreement you had to resolve.
- Does this ranking change between a recruiter screen and a later technical conversation?The ranking key does not, but the depth does. The screen usually gets the compressed version of the top story, enough to establish relevance. Later conversations get the same story with the middle expanded — the decisions, the tradeoff you took, what you would bound differently. Reordering between rounds is what creates the impression of inconsistency.
saying these in an interview costs you the question
- Ranking stories by pride rather than relevance to the role
- Leading with the most recent work regardless of fit
- Treating headcount as the only signal about a team
- Promoting three stories that all demonstrate the same trait
- Writing new stories for each company instead of re-ranking existing ones