skip to content

So what are you working on these days?

level: juniorimportance: nice to knowfreq 32%

answer

  1. plain words before job title
  2. one memorable specific, not a category
  3. proof told as a short story
  4. say the ask out loud
  5. hand the turn back

basics

~20 s

Asked where no role is on the table, so the goal is to be remembered and referred, not to sell. Answer in plain words, give one memorable specific, name a concrete ask, and hand the conversation back.

how to answer

5 beats
  1. what you work on, in words a non-specialist would use
    Open with the plain-language version before any title or stack. Ten to fifteen words. Titles mean different things at different places, so a sentence about what you actually do each week carries more information than a level name.
  2. the one detail that makes you memorable
    Add a specific about the current work that a stranger could repeat later. A surprising constraint, an unusual user group, an odd technical wrinkle. Categories are forgettable and specifics are not, so pick the detail you would tell a friend.
  3. a short proof told as a story, not a stat sheet
    One thing you changed and what happened, in three sentences with at most one number. In this setting the narrative shape matters more than the measurement, so keep the human consequence in and let the metric ride along.
  4. the ask, said out loud
    Name the kind of role, team or introduction you want. People help when they know what help looks like, and they cannot infer it. Keep it to one sentence and make it actionable rather than aspirational.
  5. hand the conversation back
    Close with a question about their work and stop talking. This turns a pitch into a conversation, and it is what makes the person remember the exchange rather than the monologue. Rehearse it so it does not feel abrupt.

your answer

4 story prompts
pick a story
  • Write how you would describe your current work to someone who is not an engineer.
  • Pick one detail about your project that a stranger could repeat a day later.
  • Name the specific introduction or team shape you would ask a helpful stranger for.
  • Reuse your recruiter-screen pitch here with everything tied to a posted role stripped out.

draft and rehearse your own answer in a learn session

go deeper

In a hallway or a career-fair conversation nobody is scoring you against a rubric, so the axis is different: clarity, memorability, and whether you are easy to advocate for. The listener is deciding, half consciously, whether they could describe you accurately to someone else tomorrow. A strong answer gives them one concrete handle and one actionable ask.

at junior level

Frontend, mostly. I'm at an insurance company on a small team, and right now we're pulling an internal reporting app off a charting library that stopped getting updates a few years back. It sounds dull and it mostly is, except that the people using it are underwriters who have thirty seconds between calls, so speed is the whole product. The reports screen is the bit I'd tell you about. It used to draw every chart on the page at once, so you'd open it, watch a spinner, and go make coffee. The main content took about 5.4 seconds to show up. I changed it to draw the first chart and load the rest as you scroll, and it's around 2.7 now. The coffee jokes stopped, which I'm choosing to count as a result. I've been doing this a bit over a year. What I'd like next is the same kind of work on something customer-facing, ideally somewhere with someone senior who does measurement properly and would let me learn it from them. If you know a team like that, I'd love an introduction. What are you working on?

why this lands

The signal is memorability plus an actionable ask: one odd user detail, one story with a single number, and a specific request the listener can act on. The register is conversational, which is correct here. Reciting this at screen-pitch polish, or ending before the ask, would waste the exchange.

at middle level

I run the frontend migration workstream for a benefits portal at a large employer-services company. In practice that means nine product teams are moving their screens onto one shared design system, and I own both the system and the sequencing of who moves when. The interesting part is that it mostly isn't a coding problem. The first two teams migrated fine, then it stalled, because everyone hit the same three unmigrated components and each team quietly wrote its own workaround. So I stopped accepting new adoption requests for a month, built those three properly, and published a per-route dashboard showing paint times before and after so teams could see their own progress without asking me. Thirty-four of fifty-one routes are on it now, and migrated routes show their main content in about 1.6 seconds median, against roughly 3.2 before. What I'm looking for is somewhere that job exists on purpose: owning a frontend platform other teams build on, rather than running it beside feature work. If your team has something shaped like that, or you know someone who does, I'd like to hear about it. How's your platform side set up?

why this lands

A scope statement and a diagnosis do the work: the speaker names why adoption stalled and what they changed about the process, which is the handle a listener can repeat in a referral. Dropping the closing question, or leaving the ask as 'open to opportunities', would collapse it into small talk.

for a junior

You will be tempted to apologise for your experience level. Do not: name what you have shipped and what you want to learn next, in that order. A specific learning goal is genuinely attractive to people who hire early-career engineers, and it gives them something concrete to match you against.

for a middle

This is where a memorable specialty pays. Say what you own now and what shape of seat you want, so the person can tell whether their team has one. A crisp scope statement travels further in a referral than any adjective you could pick.

for a senior

Assume you are being assessed for a seat that has not been posted yet, and pitch the problem you would want to be handed rather than the tools you use. Naming a constraint you would not accept is a strong signal at this rung and filters the conversation fast.

for a principal

Lead with the class of problem and the conditions you need to solve it, since your next move is more likely to be created for you than advertised. Be explicit about scope and reporting line early, because vagueness here wastes months of everyone's time.

saying these in an interview costs you the question

  • Giving a job title and stopping, leaving them to do the work
  • Delivering an obviously rehearsed screen pitch in a hallway conversation
  • Asking for a referral before the person knows what you actually do
  • Talking for two minutes without leaving a gap to respond
  • An ask so vague it cannot be acted on: 'open to anything interesting'
  • Jargon only your current team would parse, with no translation offered

  • Are you actively looking, or just keeping an eye out?
    Answer honestly and specifically, because the two answers get you different help. If you are looking, say so with a rough timeframe. If you are not, say what would make you move. Ambiguity is the one answer that gets you nothing, since it gives the other person no idea what to do with you.
  • Who should I introduce you to?
    Have a named shape ready before you walk in: a kind of team, a kind of company stage, or a role title. Making the person invent your ask for you usually ends the thread. If you genuinely do not know, ask them who they would talk to in your position, which is a request they can act on.
  • What made you pick that area to work in?
    Keep it to two sentences and make it a story rather than a value statement. A concrete origin moment is memorable and repeatable in a way that 'I've always been passionate about it' is not. Then hand the turn back, because this is a conversation and not a screen.

context

resolving links…