Tell Me About a Time You Explained Something Complex to a Non-Expert

“Tell me about a time you explained something complex to someone without technical knowledge” appears in interviews for finance, consulting, engineering, data, healthcare and technology roles, and increasingly in general graduate schemes. Almost every job involves passing knowledge to people who do not share your background: a client who is not a specialist, a manager who needs the headline, a colleague in another team, or a customer who just wants the problem fixed. Employers want evidence that you can do this without confusing, boring or patronising the listener.

The question is also a quiet test of your own understanding. People who can only repeat jargon often cannot explain why something works. When you simplify accurately, you demonstrate command of the subject. At the same time, the interviewer is watching you answer: if your story about explaining things clearly is itself confusing, that tells them more than the content does.

Variants include “Describe a time you had to communicate technical information to a non-technical audience,” “How would you explain your degree topic to a ten-year-old?” and “Tell me about a time you had to simplify a difficult message.” All ask for the same thing: a specific example, a deliberate approach and an outcome showing the other person understood.

A good example has three ingredients: a genuinely complex idea, a listener with a real knowledge gap, and a reason the understanding mattered. Without the third, the story sounds like a classroom exercise. With it, the interviewer can see why your explanation changed something.

Graduates frequently assume they need a workplace story, but university provides plenty. Explaining a statistical method to a group-project teammate from another discipline, walking a relative through a financial decision, teaching a society committee how a budget works, or tutoring a younger student in a difficult topic all qualify. Internships and part-time jobs work equally well: onboarding a new starter, explaining a delay to a customer, or summarising a spreadsheet model for a manager.

Choose an example where the other person was visibly less informed than you and where there was a stake: a decision to make, a task to complete, a risk to understand. Avoid examples where the audience was another expert, or where the “complex” topic was something most people already know.

Your answer should use STAR (Situation, Task, Action, Result), but the Action section deserves its own structure here, because how you explained is exactly what is being scored. Break it into four moves that you can name out loud: Assess, Simplify, Check, Adapt.

Assess: understand the listener first

Before explaining anything, you worked out what the person already knew, what they needed to decide, and how much time they had. Say so. “I asked her what she already knew about the process, and it turned out she had never seen the report layout” shows empathy and method.

Simplify: choose the one idea that matters

Strong explainers cut material rather than compress it. Describe what you left out and why, then the tool you used: an analogy, a worked example, a diagram, a comparison to something familiar. Make sure the simplification stayed accurate; a memorable analogy that misleads is worse than a plain one.

Check: confirm understanding

Interviewers love this step because candidates often skip it. Describe how you tested understanding, for example asking the person to explain it back, offering a small scenario, or watching for hesitation. Avoid “Does that make sense?”, which invites a polite yes.

Adapt: change course when it did not land

The most convincing answers include a moment where the first approach failed and you tried another. That is evidence of flexibility, not weakness.

These condensed examples show the structure in different settings. Treat them as patterns, not scripts: interviewers can tell when an answer has been memorised, and your own details will always be stronger than borrowed ones.

1. Explaining a statistical result to a manager (internship)

Situation and Task: “During a marketing internship, I analysed a customer survey and found that a difference between two campaigns was not statistically significant. My manager wanted to cancel the weaker campaign and had no statistics background. I needed to help her decide without overstating the result.” Action: “I asked what decision she was making, then avoided the term p-value. I compared it to flipping a coin ten times: getting seven heads does not prove the coin is biased. I showed a single chart with the ranges overlapping, and asked her to tell me what she would conclude.” Result: “She decided to extend the test for two weeks rather than cancel it, and the longer data later showed a clear winner. I now lead with the decision, not the method.”

2. Teaching a coding concept to a group-project teammate (university)

A computer science student paired with a business student explained version control by comparing it to tracked changes in a shared document. When the teammate still avoided it, the student ran a five-minute live demonstration on the project itself. The team stopped overwriting each other’s files and delivered on time.

3. Explaining a delay to a customer (part-time retail or call centre)

Rather than describing a supply-chain problem, you asked what the customer needed the item for, offered two concrete options with dates, and confirmed which they preferred. The outcome could be a retained sale or a complaint avoided.

4. Walking a society committee through the budget (volunteering)

As treasurer you replaced a dense spreadsheet with a one-page summary showing income, committed spending and what was left per event. Committee members began questioning allocations they previously ignored, and the society avoided an overspend.

5. Explaining a medical or legal term to a relative (personal)

Use this only if you can keep it respectful and relevant. Describe how you checked what the relative understood, used plain language and a written summary, and helped them prepare questions for their appointment.

The difference between an average and an excellent answer is rarely the story itself. It is the level of detail about the audience, the technique and the result. Consider two versions of the same experience.

Weak: “In my last job I had to explain our reporting system to a new colleague who did not understand technology. I explained it clearly and she understood it, and she was grateful. I think I am a good communicator.”

Strong: “A new colleague in our sales team had to pull weekly figures from our reporting system but had never used a database. I asked her to show me how she currently tracked sales, then built the explanation around that: I compared the system’s filters to the columns in her spreadsheet. I wrote a four-step guide with screenshots, watched her do it once, and noticed she hesitated at the date filter, so I added a note. She ran the report alone the following week, and it saved her roughly an hour each Monday.”

Interviewers often probe after the first answer to test depth and to find out whether the story is genuine. Prepare short, specific responses to the most likely follow-ups, and make sure every figure and detail you mentioned can be explained.

Common probes include: “What did you decide to leave out?”, “What if they had still not understood?”, “How did you know they had understood?” and “What would you do differently?” Some interviewers ask you to explain a concept from your CV or degree on the spot. Treat that as the live version of the same question: ask a clarifying question about the audience first, pick one core idea, use a concrete comparison and then check understanding.

The most frequent error is using jargon while describing a story about avoiding jargon. Spell out any acronym or technical term you introduce, because the interviewer may not be from your field, and the irony will not go unnoticed. The second is picking an example where the audience was not really non-expert, such as explaining something to a peer who already knew the basics.

Other pitfalls include being condescending about the listener (“they just didn’t get it”), skipping the check for understanding, giving no outcome, and spending most of the answer explaining the technical subject itself instead of how you communicated it. The interviewer is scoring the communication, not teaching themselves a topic.

Last-minute checklist

• Example chosen: a real knowledge gap and a real stake.
• Four moves ready: Assess, Simplify, Check, Adapt, each with a detail.
• Analogy named: a specific comparison, and why it stayed accurate.
• Result stated: a decision, action or measurable saving.
• Timed: about two minutes spoken, with no unexplained jargon.