How to Answer "What Do You Do?" (With an Example That Got Cross-Examined)

Why do interviewers ask "what do you do?"

It looks like small talk. It is actually a compression test. The interviewer wants to know whether you understand your own job well enough to explain it briefly, and whether you think in outcomes or in activities. People who think in outcomes answer with results. People who think in activities answer with a list of meetings. The question also sets the raw material for the rest of the interview, because whatever you claim here is what gets probed next.

What does a weak answer sound like?

Here is the real opening from a recorded practice session, lightly cleaned of speech-to-text noise:

"I'm working as a product manager and my main expertise is to understand what our users really need. So I mainly make sure that I'm involved in collecting user interviews, aligning our strategy, our vision, and also making sure that whatever we are building is actually solving our customers' pain points. I bring the clarity into it and make sure we are not building on the noise."

The AI evaluator scored it 67 overall. Clarity 65, Structure 75, Conciseness 68, Confidence 68, and Impact down at 55. Notice something: the answer is not bad. It has a role, it has responsibilities, it even gestures at value. It fails for one precise reason. Every claim in it is unverifiable. "Understand what users really need" describes a hope. "Solving pain points" names an outcome without evidence that it ever happened. There is not a single number, project, or named result in the whole thing. The coaching feedback said it plainly: the responsibilities are generic, and the impact statement never connects to anything concrete.

What follow-up questions should you expect?

This answer got cross-examined for six turns immediately after. The full breakdown lives on its own page, but the short version: the interviewer went straight for "solving pain points" and asked what metrics prove a pain point is solved. Then it demanded an actual number. Then it asked the ownership question, "how did YOUR work drive that result," because the candidate kept saying "we." Then a one-sentence pressure test. The pattern to internalize is that follow-ups are not random. Each one attaches to a specific unsupported claim in your opening. Fewer unsupported claims, fewer places to bleed.

What does a strong answer look like?

Here is the rewrite, built from material the same candidate produced later in the session, once the pressure forced the good stuff out:

"I'm a product manager. Day to day, I dig through user research and behavioral data to find out why people drop off, then turn that into what we build next. In my last product, a flight comparison app, I found that users were leaving to book elsewhere because we were showing cached prices instead of live ones. We fixed the price refresh, and booking conversion doubled from 2 percent to 4 percent. That is really the job in one line. I find the actual problem underneath the noise, and I make sure the team builds against that, not around it."

Why this version holds up:

• The role lands in the first three words instead of arriving wrapped in qualifiers.
• The responsibilities are verbs you can picture. Dig, find, turn into what we build.
• The impact is a specific story with a mechanism. Cached prices, lost bookings, fixed refresh, doubled conversion.
• It pre-answers the ownership question. "I found" the insight, "we fixed" the code. Nothing left to corner.

The candidate had this story the entire time. The gap between the 67-point answer and this one is not knowledge or talent. It is knowing that the story belongs in the first 45 seconds, not held in reserve for turn three of an interrogation.

What structure should you use?

The framework here is Role, Responsibility, Impact, plus one proof point. Applied to this question:

1. Role. One sentence, no qualifiers. "I'm a product manager."
2. Responsibility. Two sentences of what you actually do, in verbs. If a sentence could appear in anyone's LinkedIn summary, cut it.
3. Impact. One concrete outcome. A number, a named change, a before and after.
4. Proof point. The one-line mechanism behind the outcome, which quietly answers "how" before anyone asks.

What are the most common mistakes?

Editor's note: all quotes come from one real recorded practice session, cleaned only of speech-to-text artifacts.