One of the parts of my job I enjoy most is helping candidates prepare for interviews.

When people hear “interview preparation,” they usually imagine rehearsing answers to common questions or picking up techniques to make a better impression. Those things have their place, but they aren’t really the focus of my sessions. My goal isn’t to create answers for candidates. It’s to uncover the experience they already have, then help them shape it into something clear and concise.

A while ago, I was preparing a candidate for a Systems Engineering interview. Like I do with every session, I started with one of the most common interview questions.

“Tell me about your experience.”

He explained that he supported ADAS development by communicating between his team in Japan, the software development team in Germany, and the customer.

It wasn’t a bad answer. It was also an answer that could have described hundreds of engineers.

The thing was, I already knew his background. He had spent nearly a decade as a Systems Engineer, had a strong software development foundation, worked directly with a major Japanese automotive manufacturer, and had become one of the key members of his team. There had to be much more to his role than what he had just described.

So I asked another question.

“What do you actually do?”

He paused, then explained that he was personally responsible for gathering customer requirements, understanding exactly what the customer wanted to achieve, discussing those requirements with development teams in Germany through regular meetings and daily communication, negotiating technical feasibility between both sides, supporting software debugging when issues arose, and acting as the primary technical interface throughout development.

Suddenly, I had a completely different understanding of his experience. Nothing about his career had changed. Only the way he described it.

That conversation captures something I see over and over. Most candidates don’t lack experience. They struggle to recognize which parts of it are worth talking about.

When Experience Becomes Routine

The longer someone works in a role, the more familiar their responsibilities become. After years of leading customer meetings, negotiating technical requirements, coordinating global development teams, and solving production issues, people stop thinking of them as accomplishments. They’re just part of the job.

Ironically, those routine responsibilities are often exactly what a hiring manager wants to hear about. They aren’t evaluating whether you can perform the basics of your current role. They’re trying to understand how you think, how you solve problems, how you communicate, and what level of responsibility you’ve actually carried.

Many candidates compress years of that into a few generic sentences. “I support development.” “I communicate with customers.” “I manage projects.” Accurate, but incomplete.

Responsibilities vs. Experience

A responsibility describes your job. Experience explains how you perform it.

“I support customer meetings” is a responsibility. But if I ask a few more questions, I might discover that the candidate actually leads weekly technical discussions with one of Japan’s largest automotive manufacturers, translates customer requirements into engineering specifications, negotiates development priorities with overseas teams, and resolves technical disagreements between multiple stakeholders.

Same responsibility. Very different conversation.

That’s why I rarely tell candidates what to say. Instead, I ask questions. What do you mean by “support”? Who do you work with? Who makes the decisions? What happens when requirements change? What problems are you responsible for solving? What happens if the customer and the development team disagree? What is your personal responsibility?

Eventually, almost every candidate reaches the same point.

“Well… actually…”

That’s usually where the interesting part begins.

The Second Move: Deciding What to Cut

Uncovering the experience is only the first half of the work. Once a candidate has laid out everything they actually do, the answer is often too long.

The Systems Engineer’s second response (requirements gathering, negotiating with Germany, debugging, acting as the technical interface) was a much more accurate picture of his role. It was also six things. In an interview, he wouldn’t want to recite all six. He’d want to pick the two or three that mattered most for that specific position and lead with those.

So after “well, actually…,” the next question I usually ask is something like: “Of everything you just told me, what are the two or three things a hiring manager most needs to hear?”

That’s where judgment comes in. A candidate applying for a technical lead role might emphasize the negotiation with Germany and the technical interface work. A candidate applying for a project management role might emphasize the coordination and stakeholder management. Same experience, different framing.

An interviewer isn’t collecting a list of activities. They’re trying to understand the value you bring, and a focused answer helps them understand that value far more quickly than an exhaustive one.

Candidates Often Answer the Question They Heard

One more pattern worth mentioning: candidates often answer the literal question being asked, while the interviewer is asking something bigger.

“Tell me about your experience” sounds like “list your responsibilities.” But the interviewer is usually asking, “Help me understand why I should trust you with this position.”

Those are very different questions.

The same thing happens elsewhere. “Why do you want to become a manager?” gets answered with “I’d like to develop my career.” Reasonable, but the interviewer wants to know what actually motivates you: whether you’ve mentored junior engineers, whether you enjoy developing people, what you’ve already done that shows leadership.

“Tell me about an accomplishment” gets answered with “My team solved an issue with Honda.” Fine as a starting point, but what was your role? What decisions did you make? What obstacles did you overcome? How did your contribution influence the outcome?

Those are the details that help an interviewer understand your experience.

Reflection, Then Editing

Explaining your experience isn’t just a communication exercise. It’s a reflection exercise, followed by an editing exercise.

Experience accumulates over years. Understanding your own experience takes reflection. Explaining it clearly takes practice. Explaining it concisely takes discipline. Knowing what to leave out is often harder than knowing what to include.

Many people have never stopped to think about the full scope of what they’ve done because they’ve been too busy doing the work. Sometimes all it takes is someone asking the right questions to uncover it, and then a few more questions to help them decide what actually matters.

After preparing hundreds of candidates for interviews over the years, I’ve found that the biggest breakthroughs rarely come from giving someone a better answer.

They come from asking enough questions that candidates begin to see their own careers differently.

The experience was always there. It simply needed to be uncovered.

And once it’s uncovered, it needs to be organized into a story that allows someone else to understand its value.

That’s why I don’t think of interview preparation as teaching candidates what to say.

I think of it as helping them discover what they’ve been doing all along.