Tell me about yourself.
answer
- open with current role and scope
- one proof point with a number
- past: only the steps that led here
- future: why this role, why now
- stop on time, hand it back
basics
~20 sTests whether you can shape a focused professional narrative when nothing is prescribed. Answer in about two minutes: present role and one proof point, the past steps that explain it, and why this role is next.
how to answer
4 beats- present: your current role, what you own, and one proof pointRoughly the first forty seconds. Name the team and the thing you are accountable for, then one measured result you can be drilled on. Say the number plainly rather than hedging it; this sentence is what buys you attention for the rest of the answer.
- past: the two or three steps that explain how you got hereAbout forty seconds. Narrate choices, not dates, and include only the roles that explain the trajectory — anything else gets one clause or is cut. Compress hard: this is the section that swallows the clock when candidates run long.
- future: why this role is the deliberate next stepTwenty to thirty seconds. Say what you want to be doing more of and how this specific role supplies it, using the language of the posting rather than flattery about the company. Vague ambition here undoes the specificity of everything before it.
- close: a hand-back line that invites the first follow-upOne deliberate sentence offering direction, such as an invitation to go deeper wherever is most useful. Then stop and let silence sit. Trailing off signals you had no plan for the ending, and the ending is what the interviewer writes down.
your answer
5 story prompts- Write your current-role sentence first: team, what you own, one number you can defend.
- Pick exactly two past roles that explain how you got here, then cut the rest.
- Choose one proof point you would happily be drilled on for ten minutes.
- Draft your future sentence from the job posting's own words, not from flattery.
- Say it aloud with a timer; if you pass two minutes, cut the past section.
draft and rehearse your own answer in a learn session
go deeper
It opens most loops because it is unstructured on purpose: with no constraints given, what you choose to say reveals prioritization, self-awareness and composure. Interviewers also use it to plan the rest of the hour, since the threads you seed become their follow-ups. A strong answer proves you can shape two minutes of relevant narrative and stop on time.
Right now I'm a backend engineer at an early-stage logistics company. There are three of us on the services side, and I own the shipment-tracking API — the endpoints customers poll and the worker that keeps them fed. The thing I'd point at is the read path on that API. It had been getting slower for months and we'd all quietly learned to live with it. I traced it to a lookup we were doing once per shipment leg instead of once per request, batched it, and p99 came down from 1,840 milliseconds to 390. It was the first change I owned the whole way through — the fix, the staged rollout, and the dashboard on-call watches it on now. Before that I spent a year building internal tools at a small agency, mostly reporting jobs and CRUD services. That's where I found out I like the part of the job where you go and find out why something is slow, which is why I moved toward backend work on purpose rather than drifting into it. What I want next is more depth on the systems side — real ownership of a service in production, and people ahead of me who'll tell me when my design is wrong. That's most of why this role caught my eye. Happy to go deeper on any part of that.
Present, past and future in about two minutes, with the proof point stated as a defensible before-and-after rather than a claim. The past section is one sentence of scope plus the reason for the move. It would downlevel if the fix were narrated as team work, or if the two prior jobs were narrated year by year.
I'm a backend engineer on the payments side of a startup that does subscription billing. I own the authorization service and the queue consumers behind it, and I'm in the on-call rotation for both. The stretch I'd point to is a nine-day stabilization push after a consumer backlog took card authorizations down for most of a business day. I owned the rewrite: moved from one ordered queue to per-merchant partitions, put a bounded retry with a dead-letter path behind it, and got p99 on the authorization call from 1,120 milliseconds down to 240. The part I'm prouder of is the load-shedding rule I added afterwards, which turned the next backlog into a graph rather than a page. Before payments I did about three years of internal platform work — service templates, the deploy path, that sort of thing. That's where I got comfortable owning something other engineers depend on, and it's why I moved into a domain where being wrong actually costs money. What I'm after next is a bigger blast radius, honestly. Your posting describes rebuilding the billing APIs around idempotency, and that's the exact set of arguments I'd want to be in — designing it, not just implementing someone else's version of it. I can start wherever is most useful to you.
The scope claim is ownership of a service in production plus the rotation, and the result names the prevention as well as the fix. The future beat cites something specific from the posting instead of generic ambition. It would downlevel if the rewrite were described without the design decisions behind it.
Lead with what you build now, even if that is coursework, an internship or a first role. One shipped thing you can be drilled on beats a list of technologies. Nobody expects scale from you; they expect clarity and a direction you chose on purpose.
Anchor in a feature or service you own end to end and name the technical center of gravity you have built — the domain you keep choosing. The future beat should sound like a deliberate next step rather than lateral drift.
Your scope should read as team and production ownership: what you are accountable for while it runs, the design and on-call surface you carry, and the through-line that explains your moves. A job list at this level reads as someone who has been assigned work rather than someone who has directed it.
Frame the answer as a thesis about the class of problem you take on, not a career sequence. Name the bet you are currently making at org level and what this role gives you that your present seat cannot. One sentence of scope, then the argument.
saying these in an interview costs you the question
- Starting at school and narrating every job in order
- Running past three minutes with no sign you noticed
- Reciting resume lines the interviewer has already read
- Making the substance personal — hometown, hobbies, family — with no professional thread
- Claiming ownership with no concrete result attached to it
- Trailing off into "so yeah, that's kind of me" instead of a deliberate close
- Pick one of those and go a level deeper for me.Expect this, and pre-build a ninety-second deep version of every thread you seed: context, the decision you made, the tradeoff, the result. Let them choose which thread; only steer if they hesitate. Keep it first-person and technical, and stop again at the end rather than sliding into a second story.
- How did you get into engineering in the first place?This is an invitation to be human, not to restart the life story. Give one or two sentences of origin, land on what it says about how you work now, and hand it back. Rambling here usually happens because the candidate felt the main answer was too thin — resist patching one answer with another.
- Anything you left out that you'd want me to know?Keep one reserve item you cut for time: a domain you know, a scale you have worked at, something recent you learned. Thirty seconds, then stop. Saying you think you covered it is perfectly acceptable and beats padding, but the reserve item is a cheap way to seed one more follow-up.
## One prompt, several wordings The same question arrives in several wordings, and they are all one prompt: - "tell me about yourself" - "walk me through your background" - "so, give me the two-minute version" - "why don't you start by introducing yourself" Treat them identically and deliver the same prepared narrative. The only variant worth hearing differently is an **explicit time box** — "give me the short version", "in a minute or so" — which is a request for the compressed pitch rather than the full opener, and you should have that cut ready as a separate thing. ## Why an unstructured opener is genuinely hard Every other question in the loop tells you what to talk about. This one does not, so the interviewer learns something from **your selection itself**: what you think matters, whether you can compress a career without flattening it, and whether you can talk for two minutes without a scaffold. They have already read the resume. Repeating it back adds nothing and burns the most attentive ninety seconds of the hour. ## The shape: present, past, future 1. Start with what you do now — team, what you own, one proof point. 2. Then the two or three prior steps that explain how you got here, narrated as choices rather than as dates. 3. Then why this role is the deliberate next step. Running it in **chronological order** instead is the single commonest structural mistake: starting at the beginning invites the full sequence, spends your best attention on your least relevant material, and often ends with the interviewer interrupting. ## Airtime Roughly: - forty seconds on the present - forty on the past - twenty to thirty on the future - and a closing line Total between sixty and one hundred twenty seconds. Past two minutes you are visibly not managing your own time; under forty-five seconds you have handed back an answer with no threads to pull, and the interviewer has to work to interview you. ## What counts as evidence - A before-and-after number you can defend under a drill-down. - A system you were accountable for while it was running, not just while it was being written. - A decision you made and can still justify. - Scale that is real for your level. What does not count: adjectives about yourself, technology lists, and team accomplishments narrated in the first person plural. One number, stated plainly and owned, outperforms three claims. ## Weak versus strong, concretely - **Weak** sounds like: I did a computer science degree, then I joined a company as a junior developer for about two years, then I moved to another company where I worked on their platform team, and then... That is a spoken resume with no shape and no signal. - **Strong** sounds like: naming the service you own, one measured result you drove on it, the two prior steps that explain the trajectory, and a specific reason this role is next. Same facts, but the second one has a **thesis**. ## The relevance filter Decide before the interview which two or three threads you want the interviewer to pull, and seed exactly those. Everything else gets one clause or gets cut. If a role does not explain how you got here, it becomes "and a couple of years of internal tooling work before that". You are not obliged to mention everything you have done; you are obliged to be honest about what you do mention. ## The hook ending Finish on a deliberate sentence — why this role, plus an offer of direction: "happy to go deeper wherever is most useful". Do not trail off into "so, yeah, that's kind of me". The last sentence is what the interviewer writes down and it is what they follow up on. ## How the bar moves - **Early-career** answers are judged on clarity and one credible piece of ownership. - **Mid-level** answers should show a technical center of gravity — a domain you have chosen. - **Senior** answers should read as accountability for systems in production. - **Principal** answers should sound like a thesis about a class of problem, with the current bet stated out loud. ## Rehearse aloud, do not memorize Write it, say it with a timer, cut from the past section first. A word-perfect recitation sounds like a script and collapses at the first interruption; a rehearsed outline survives one.