What should I know about you that isn't on your resume?
answer
- one theme, not a list
- say the theme in one sentence
- back it with a concrete example
- link it to this team's reality
- ninety seconds, then hand back
basics
~10 sProbes self-awareness and what you volunteer when nothing is prescribed. Name one working habit or motivation, evidence it with a single concrete moment, and connect it to how this team actually works.
how to answer
4 beats- the one thing: state the trait in a single sentencePick one habit or motivation and say it plainly, without hedging or a preamble about how hard the question is. One remembered theme beats three forgotten ones, so resist listing. Choose something genuinely absent from the resume — if it is already a bullet there, pick another.
- the evidence: one concrete moment where that trait matteredThirty to forty-five seconds. One situation, what you actually did, and what changed because of it, ideally with a number or a before-and-after. Attribute honestly — being clear about which part was yours is itself part of the signal here.
- the relevance: why it matters for the work in front of youConnect the trait to something specific about this team or role that you learned from the posting or the conversation so far. Aim at the working conditions, not at praising the company. Two sentences is plenty.
- close: hand it back rather than adding a second themeStop at about ninety seconds with a short line that invites a follow-up. Candidates who keep going here usually start listing, which dilutes the one thing they wanted remembered. Silence after a clear point is a strength, not a gap.
your answer
5 story prompts- Pick one working habit teammates have thanked you for, not a personality adjective.
- Find one moment in the last eighteen months where that habit changed an outcome.
- Check the trait appears nowhere on your resume; if it does, choose another.
- Name the cost of that habit in one sentence, ready for the follow-up.
- Say the whole thing aloud in ninety seconds and cut anything needing backstory.
draft and rehearse your own answer in a learn session
go deeper
The resume has already been read, so this probes judgment about relevance: what do you volunteer when nothing is prescribed? It also tests self-awareness and whether you can be personable without being unprofessional. A strong answer surfaces one working trait, evidences it with a real moment, and connects it to how the team operates.
The thing that isn't on there is that I'm the person who writes down what just happened. It sounds small, but it's the habit that has made me useful faster than my experience should allow. Concretely: our search-indexing service fell over one morning and took about four hours to come back, mostly because the recovery steps lived in one engineer's head and in a chat thread nobody could find. I wasn't the one who fixed it — I mostly watched. But that week I wrote the runbook: the three commands, the two dashboards, and what recovered actually looks like. I also added an alert on p99 crossing 800 milliseconds so we'd see the next one earlier. When it did recur, on-call had it back in 26 minutes and I wasn't in the room at all. I do the same with smaller things — why we chose one library over another, what we decided in a review and why. Partly that's for the team, and partly it's selfish: writing it down is how I find out whether I actually understood it. I mention it because you described a small team covering a lot of surface area. That's the setting where the habit compounds, and it's something I can contribute on day one while I'm still learning the codebase.
The trait is a habit, not an adjective, and it is evidenced by one moment with an honest attribution — the candidate says plainly which part was not theirs. The recovery time carries the result. It would weaken instantly if the runbook were described without the follow-up outcome.
What the resume won't tell you is that I'm the person in design review who asks what this does when it's wrong. Not as a gatekeeper — I just find failure modes more interesting than happy paths. An example: a teammate's design for a new pricing lookup had a retry loop with no ceiling on it, which on paper was fine. I asked what happens if the provider gets slow rather than returning errors, and we ended up adding a time budget and a fallback to the last cached rate. A couple of months later that provider degraded for about forty minutes, and instead of an outage we saw p99 move from 210 to 640 milliseconds while we served slightly stale prices. Nobody got paged. The habit came from an earlier stretch where we kept rediscovering the same class of problem, so I started running short written reviews after incidents. We've done nine now, and roughly half of them changed a design document rather than any code. I'm telling you this rather than saving it for a design round because it's as much a culture fit question as a skill one. On a team that doesn't want that question asked out loud in review, I'd be the wrong hire. From what you've described, I don't think that's you.
The trait is stated as a stance the candidate would defend, evidenced by a design-review intervention with a measured payoff and a practice they introduced. Naming the culture condition out loud is the mid-level move. It would downlevel if the example were only an opinion with no outcome behind it.
You are not expected to have production war stories. Pick a habit visible in your first months or your coursework — how you verify your own work, how you ask for help, how you take notes — and show one moment where it changed an outcome for someone other than you.
Choose something that made the team better rather than only you: a review habit, a tool you quietly maintain, the way you bring newcomers up to speed. Tie it to one situation where it changed a decision, not just a feeling.
The trait should read as a lever you apply across a team — how you make risk visible, how you make less experienced engineers faster. Be able to name what it costs when you overdo it, because a trait with no downside sounds invented.
Use the answer to state how you operate at organizational scale: the class of problem you get pulled into, the standard you hold, or the failure mode you keep teams out of. Land it as a stance you would defend, not as a personality quirk.
saying these in an interview costs you the question
- Listing hobbies with no link to how you work
- Repeating a resume bullet the interviewer has already read
- Volunteering personal or medical detail nobody asked about
- Claiming a trait such as fast learner with no example behind it
- Treating it as a joke question and giving nothing usable
- Naming three or four traits so none of them is remembered
- Where has that gotten you into trouble?Do not defend the trait as costless. Name the failure mode in one honest sentence and follow it immediately with the correction you now apply. Keep it small and specific to the habit you just described; this is a probe about calibration, not an invitation to open a full weakness answer.
- Would your teammates describe you that way too?Answer with evidence rather than assertion: something a teammate has actually said, what people come to you for because of it, or a line that shows up in your reviews. If it is a habit you are still building, say so and name who told you it was landing. A vague yes wastes the probe.