In about thirty seconds, tell me who you are and what you do.
answer
- role and level in one line
- one specialty, not four
- single proof point with a number
- what you want next, one sentence
- stop before forty-five seconds
basics
~20 sTests whether you can compress your value into one memorable claim under a time limit. Lead with your current role and one narrow specialty, back it with a single concrete proof point, and close with what you want next.
how to answer
5 beats- who you are right now, in one lineCurrent role, rough experience level, and the domain you work in. Present tense, no chronology, about eight seconds. If you are between roles, say what you do rather than what you last were: the tense change alone reframes the whole pitch.
- the one specialty you want to be called forNarrow from your role to the single area you want probed. Discarding your other real strengths here is the point, not a loss; they will come up under questioning. One sentence, and resist the urge to hedge it with 'and also'.
- one proof point with a number in itThe longest beat, roughly forty percent of the airtime, and still only two or three sentences. Name the thing, the before, and the after. One number only, and make it a measured one you can defend if they ask where it came from.
- what you are looking for nextOne forward-looking sentence naming the kind of work or seat you want. This is what turns an introduction into a candidacy, and it is the beat people most often drop. Keep it about the shape of the work rather than a list of technologies.
- a clean stop that hands the turn backEnd on a full stop, not a fade. A short line that invites the next question works well, and silence works better than filler. Trailing off undoes a good pitch in three seconds, so rehearse the last sentence until you can land it.
your answer
5 story prompts- Write your current role, level and domain as one spoken line under fifteen words.
- Name the single specialty you want to be probed on, and cut the other three.
- Pick one result from the last two years with a number you could defend.
- Draft your closing ask as one sentence about the work, not the tech stack.
- Time the pitch aloud and cut it until it lands under forty-five seconds.
draft and rehearse your own answer in a learn session
go deeper
Openers like this probe communication under compression and self-awareness: can you state your value without a warm-up, and do you know what you are actually good at? The specialty you name sets the frame for the rest of the screen, because that is what gets probed next. A strong answer proves focus, evidence-backed self-assessment, and a clear direction of travel.
I'm a frontend engineer, about eighteen months in, on internal tools for an insurance claims platform. The part I want to be called for is making data-heavy screens fast. The one I'd point at is claim search. It rendered eleven table sections on load, and Largest Contentful Paint on it was 4.3 seconds on the machines our claims staff actually use. I changed it to paint the first section and fetch the rest on demand, and it came down to 2.1. The tickets from people double-clicking search because they assumed it had frozen stopped with it. What I want next is that kind of work on something customer-facing rather than internal, where load time is treated as part of the feature. That's mostly why I wanted this call.
The proof beat does the work: one screen, one measured before-and-after, and a human consequence that shows the candidate watched what happened after shipping. Read aloud this lands near fifty seconds; drop the support-ticket sentence and you are at the forty-five the question actually allows. A second screen or a second number breaks the clock.
I'm a frontend engineer six years in, and I own the component platform behind a large claims console: the design-system package, the app shell, and the rendering conventions three product squads follow. My proof point is the shell. The busiest workflow took 3.6 seconds to paint its main content, because the entry route pulled the old vendor runtime on every load. I split it into a critical path and a deferred remainder, and moved grid and icon rendering into the shared package so squads stopped reimplementing them. That workflow is at 1.8 seconds now, and fourteen of twenty-two screens are across. What I'm after next is the same platform seat on a product with external users, holding a performance budget for the org instead of renegotiating it screen by screen.
Ownership of a shared surface, plus a mechanism others used without the speaker present, is what separates this rung from good individual delivery. The close names a seat, not a technology. This runs near fifty seconds aloud — the migration-checklist detail and any second metric are the first things to cut when the asker says thirty.
Lead with what you can already do unsupervised, however small the surface. One thing you built or fixed end to end, named concretely, beats a tour of a bootcamp curriculum or a list of coursework. Naming your stack is fine here; naming ten is not.
Your specialty should be a real area with peer-scope evidence behind it: a feature, a component, a subsystem you owned through to production, with a number attached. The listener should finish your thirty seconds knowing which ticket they would hand you first.
Pitch leverage, not output. The proof point should be something that changed how a team works or how a system behaves under load, and the close should signal the seat you want, not just the technology you enjoy.
Frame the class of problem you get hired to solve, and cite a mechanism rather than an artifact: a standard adopted, a review practice that stuck, a way of measuring that outlived your involvement. Compress harder than anyone else, because the temptation to inventory a decade is strongest here.
saying these in an interview costs you the question
- Starting at university and narrating every job since
- Running two minutes when the asker said thirty seconds
- A specialty so broad it fits any engineer alive
- Adjectives instead of evidence: passionate, detail-oriented, fast learner
- No forward-looking close, just trailing off with 'so, yeah, that's me'
- Listing technologies with no claim about what you did with them
- What kind of role are you looking for next?Have a one-sentence answer that names a seat and a constraint, not a wish list. Say what kind of work you want more of and what you would rather do less of, then stop. Vagueness here reads as availability rather than intent, and it makes you hard to advocate for internally.
- Where did that number come from?Be ready to name the tool or dashboard, the population it measured, and whether it was your measurement or someone else's. If you estimated, say you estimated and give the basis. A candidate who defends a soft number confidently loses more than one who says 'that was our own instrumentation, on real user sessions, not a lab run'.
- That's a broad area. What specifically do you own in it?This is the interviewer testing whether your specialty is real. Narrow immediately to a concrete surface and a concrete decision you make about it, ideally with the boundary named: what falls to you, what falls to someone else. Widening the claim under this probe is the worst available move.
## The prompt and its variants The same request arrives in many shapes: *give me the quick version*, *summarize your background in a minute*, *who am I talking to?*, *before we dive in, a quick intro*. Recruiters use it to open a screen; hiring managers use it to set the frame; a panel uses it when someone joins late. Treat them all as one prompt with one prepared answer. The compressed pitch is deliberately shorter than the full structured opener you would give when an interviewer asks you to walk them through your background — thirty to sixty seconds, one proof point, no chronology. ## The formula Four moves, in order: **role and level**, **the one specialty you want to be called for**, **one proof point**, **what you want next**. The proof point takes the most airtime, roughly forty percent, and it is the only place a number belongs. Everything else is one sentence each. The hardest of the four is the specialty, because compressing means discarding. Most engineers can honestly claim three or four areas, and the instinct is to list them so nothing is lost. The listener hears four claims and retains none. Pick the one you want the rest of the conversation to be about, and let the others surface later under questioning — they will. ## Weak versus strong A weak pitch is a resume read aloud in chronological order. It starts furthest from what the listener cares about, arrives at the present just as their attention is gone, and offers no claim they can repeat to a colleague. A strong pitch is built so that if the listener remembers exactly one sentence, that sentence is useful to you. A second failure is the abstraction trap: *I work on performance and developer experience across the frontend*. True, unfalsifiable, unmemorable. The repair is a specific: which surface, which users, which measurement. Specificity is what makes a pitch sound lived rather than assembled. ## Evidence that actually lands In descending order of strength: a measured before-and-after on something users experienced; a shipped artifact other people now depend on; a decision you made and its consequence; a scope statement (what you owned, alone). Only the first carries a number, and one number is the ceiling for thirty seconds. Two numbers in a pitch is a report, not an introduction. If your work genuinely has no metric — plenty of good work does not — substitute adoption or scope. *Three teams build on it now* is evidence. *It was very successful* is not. ## One pitch, three rooms Keep a single core pitch and change only the close. In a recruiter screen, the close points at the conversation you are in. At a meetup or a conference hallway, the close is an ask and a handback, because there is no role on the table and the goal is a second conversation. For an internal move, the opener changes instead of the close: skip the background the listener already has, and open on the specialty and what you would bring to their team, since your reputation is already partly in the room. ## How the bar moves The structure is constant across seniority; the object of the proof point changes. Early on it is a task completed well. In the middle it is a surface owned. Later it is a team unblocked or a system's behaviour changed. The most common senior mistake is not being too thin but being too long — a decade of material and no willingness to cut. Rehearse against a clock, out loud, and cut until it fits.