What if my job isn't technical?

Every job has something complex to someone: a policy, a process, a contract, a schedule change, a new system. Pick the one where you had to adapt to a specific listener.

Can I use an example from school or university?

Yes, especially as a graduate. Tutoring, explaining your project to a non-specialist panel or teaching a family member something all work.

How technical should I be when describing the topic?

Barely. One sentence on what the topic was is enough. The interviewer cares about your approach, not the subject.

What if my explanation didn't work the first time?

That can make a strong story. Say what didn't land, what you changed, and how the second attempt went.

Is this the same as "Tell me about a time you persuaded someone"?

They overlap, but persuading is about changing a decision. This is about understanding. Some stories do both; make sure you emphasise the part that's asked.

Tell me about a time you explained something complex simply

What this question really tests

Interviewers ask this for roles where you'll work with people who don't share your expertise: engineers with sales, analysts with managers, nurses with patients' families, accountants with business owners. They're listening for one skill: can you change how you explain something based on who's listening?

That means the most important part of your story isn't how complex the topic was. It's the audience. A story that spends a minute on the technical details and ten seconds on the listener misses the point.

Shape the STAR story around the listener

STAR part	What to include for this question	Rough time
Situation	The topic, and who needed to understand it	10–15 seconds
Task	What they needed to do with it: decide, approve, act, stop worrying	10 seconds
Action	How you adapted, and how you checked understanding	40–50 seconds
Result	What they did because they understood	15–20 seconds

Total: 75 to 90 seconds. The Action is where the skill shows, so give it the most time. See the STAR method guide for the basics.

Techniques to name in your Action

Interviewers like hearing how you simplified. Pick the two or three you actually used.

Technique	What it sounds like in your story
Start with what they care about	"I started with what it meant for their launch date, not with how the system works."
Drop or translate jargon	"Instead of 'latency', I said 'the delay before the page loads'."
Use an analogy	"I compared the database to a library with no catalogue."
One idea at a time	"I cut it to the three things they needed to know."
A picture or example	"I drew the two options on a whiteboard as two roads."
Check understanding	"I asked them to tell me in their own words what we'd do next."
Leave room for questions	"I stopped after each point and asked what was unclear."

Example answers

These are examples with made-up details. Use your own story.

Software engineer explaining an outage to the sales team

"Our app went down for about two hours during a big customer demo week, and the sales team was getting angry calls. My manager asked me to explain it at their Monday meeting. They needed two things: what to tell customers, and whether it would happen again. I skipped the technical root cause and started with the answer to their second question: it was one faulty update, and we'd added a check so the same kind of update can't go out untested. I compared it to a restaurant that now tastes every dish before it leaves the kitchen. Then I gave them three sentences they could use with customers, and asked one of them to say it back to me. Afterwards their manager asked me to write those three sentences into the sales FAQ, and the angry calls dropped off within the week."

Data analyst explaining a test result to marketing

"We ran a test on two versions of a sign-up page, and the result looked like a win, but it wasn't statistically reliable yet. The marketing lead wanted to roll it out immediately. I knew that explaining confidence intervals wouldn't help. So I said, 'If we flipped a coin ten times and got seven heads, would you bet the house it's a trick coin?' She laughed and got it. I then showed how many more days the test needed, in a single chart. She agreed to wait a week, and the final result was actually smaller than it first looked, so we avoided a redesign based on noise."

Nurse explaining a care plan to a patient's family

"A patient's family was confused and anxious about a change in their father's medication schedule after surgery. The doctor's explanation had been accurate but fast and full of terms. I sat with them, wrote the new schedule as a simple table with times and what each medicine was for in everyday words, and asked the daughter, who'd be helping at home, to walk me through the first day. She spotted something she'd misunderstood, and we fixed it before discharge. The family told the ward manager the table was the most useful thing they took home."

Mistakes to avoid

Mistake	Why it hurts	Try instead
Spending most of the story on the technical topic	Shows the opposite of the skill	Spend most of it on the listener and your approach
Making the listener sound slow	Sounds condescending	Show respect: they're experts in something else
No check for understanding	You don't know it worked	Include how you checked
No result	The explanation is only proven by what happened next	Say what they did differently
Using jargon while telling the story	Undermines your point immediately	Tell it in plain words, the way you'd explain it to them

That last mistake is common and worth testing: tell the story to someone outside your field. If they get lost, the interviewer might too.

Practise it out loud

This question rewards doing what it asks. If your answer is clear, it proves the skill twice. Say it out loud and listen for jargon you didn't notice. Speaking Coach can play a non-expert listener who stops you when you lose them, which is useful practice for the story and for the real explanations you give at work. The guide to explaining things simply has more techniques.