To answer “tell me about a time you explained something complex to a non-technical person,” choose a moment when someone needed to understand a technical topic to make a decision, then show three moves: you started from what they needed to decide, you translated the idea with plain words and one good analogy, and you checked that they understood before moving on. Interviewers are testing audience-first communication, not how much you know. End with the decision they made and a measurable result.
What is the interviewer really testing?
Engineers, analysts, data scientists, IT staff and anyone in a specialist role spend a lot of time explaining their work to people outside their field: executives, clients, sales teams, patients, end users. If they cannot follow you, they cannot make good decisions with your work. This question checks whether you can bridge that gap.
The underlying challenge has a name. In a 2006 Harvard Business Review article, Chip and Dan Heath described the “curse of knowledge”: once you know something well, it is hard to imagine not knowing it. The idea is often illustrated with Elizabeth Newton's 1990 Stanford study, in which people who tapped out the rhythm of well-known songs badly overestimated how many songs their listeners would recognize. They could hear the tune in their heads; the listeners could not. Experts explaining their work face the same gap.
Interviewers listen for:
- Audience awareness. You figured out what the person already knew and what they needed to decide.
- Translation. You replaced jargon with plain words, analogies, examples or a simple visual.
- Checking for understanding. You confirmed they got it, rather than assuming.
- Respect. You never talked down to them, and you treated their questions as useful.
- Impact. Your explanation led to a better decision or outcome.
How do you answer “tell me about a time you explained something complex”?
Use the STAR method in this order:
- The audience and the decision. Who needed to understand, and what they had to decide or do.
- The complex topic. One sentence on what made it hard to explain.
- How you prepared. What you learned about their starting point and what they cared about.
- How you explained it. The analogy, example or visual you used, and what you left out on purpose.
- How you checked understanding. A question you asked, or having them explain it back.
- The result. The decision they made, a number and what changed afterward.
Your answer itself is a test of the skill. If you fill it with acronyms, the interviewer will notice. Explain the technical part of your story the way you explained it to the stakeholder.
Which techniques make an explanation land?
Name at least two of these in your Action section. They give the interviewer concrete evidence of how you communicate.
| Technique | What it means | What it sounds like |
|---|---|---|
| Start with the decision | Lead with why it matters to them, then the how | “You need to choose between two options by Friday. Here is the difference.” |
| One strong analogy | Map the idea onto something they already understand | “Technical debt works like a credit card balance: the interest grows if we don't pay it down.” |
| Concrete example | Use their data, their customer, their numbers | “Here is what happened to last Tuesday's orders.” |
| Cut on purpose | Leave out detail they do not need for the decision | “There are five causes; two of them matter for this choice.” |
| Simple visual | One chart or sketch instead of a dense slide | A before-and-after diagram with three boxes |
| Teach-back check | Ask them to restate it in their own words | “How would you explain this to your team?” |
Three example answers we wrote
These are examples we wrote to show the structure, not real candidates' answers. Replace the details with your own.
Example answer we wrote: software engineer explaining technical debt to a CEO
Situation: I was a senior engineer at a 40-person startup. Our CEO, who came from sales, kept asking why new features took twice as long as they had a year earlier. He was considering hiring three more engineers to speed things up.
Task: I needed him to understand that our main bottleneck was an aging billing module, not headcount, so he could decide where to invest.
Action: I skipped the architecture diagram. I told him technical debt works like a credit card balance: every shortcut we took to ship faster added to the balance, and now the interest, extra time on every change, was eating our capacity. Then I made it concrete with his own roadmap. Of the last ten features, seven touched billing, and those took an average of 11 days against 4 for the rest. I offered two choices: hire now, or spend six weeks paying down the billing debt first. Then I asked him to explain the trade-off back to me as he would to the board, which surfaced one misunderstanding about whether customers would notice the work.
Result: He approved the six-week rebuild and paused one of the three hires. Afterward, features touching billing dropped to about five days on average. He started using the credit card analogy in board updates, and he asked me to give a short tech-debt update every quarter.
Example answer we wrote: data analyst explaining statistical significance
Situation: I was a data analyst supporting the marketing team at a subscription company. The marketing director wanted to roll out a new email subject line to all customers because it had a higher open rate after one day of testing.
Task: The difference was not yet statistically meaningful, and I needed her to understand why waiting a few more days mattered without lecturing her on statistics.
Action: I asked what she would do with a coin that landed heads six times out of ten. She said she would not assume it was rigged. I told her our one-day result was in the same position: the gap could easily be luck. I showed one chart with the two open rates and a shaded band for the range of normal day-to-day variation, and the bands overlapped. I told her how many more days of data we needed, five, and what result would change my recommendation. Then I asked how she would summarize it for her team. Her version was clearer than mine, and I used it in the follow-up email.
Result: She waited. After a full week, the new subject line was no better than the old one, so we avoided switching all 200,000 subscribers to it. She now asks for a test duration before any campaign test starts, and our team added the shaded-band chart to its standard report template.
Example answer we wrote: IT administrator explaining multi-factor authentication
Situation: I was the IT administrator at a law firm with about 60 staff. After a phishing attempt nearly succeeded, the partners agreed to require multi-factor authentication, but many staff saw it as extra hassle and kept postponing setup.
Task: I had to get everyone enrolled within a month, which meant explaining why it mattered to people who did not think of themselves as technical.
Action: I ran three 20-minute sessions instead of sending another policy email. I compared a password to a house key, which can be copied without you knowing, and the second factor to a deadbolt only you can open from your own phone. I used the near-miss phishing email itself, with names removed, as the example, since everyone had received it. I demonstrated the setup on a projected phone screen, then sat with each group while they enrolled. At the end, I asked people what they would do if they got an unexpected sign-in prompt, to check that they understood the point, not just the steps.
Result: Enrollment went from 35% to 100% in three weeks. In the following quarter, two staff members reported unexpected sign-in prompts to me right away, and both turned out to be blocked attempts on their accounts.
Weak vs strong answers
| Part of the answer | Weak | Strong |
|---|---|---|
| Audience | “Some business people” | A named role and the decision they had to make |
| Explanation | “I simplified it” | The actual analogy or example you used |
| Detail | Re-explains the technical topic in jargon | Explains it the way you did for the stakeholder |
| Understanding | “They seemed to get it” | A teach-back or question that confirmed it |
| Attitude | “They didn't understand anything technical” | Treats their questions as useful |
| Result | “The meeting went well” | The decision made, plus a measurable outcome |
Follow-up questions to expect
- How did you know they understood?
- What would you have done if the analogy had not worked?
- What did you choose to leave out, and why?
- Can you explain [a concept from your résumé] to me right now as if I were not technical?
- Tell me about a time you explained something and it did not land.
The live version, “explain this concept to me now,” is common in technical and analyst interviews. Prepare two or three concepts from your own work with an analogy ready for each, and keep each explanation under a minute.
Mistakes to avoid
- Showing off the complexity. The interviewer does not need to be impressed by how hard the topic was. They need to see that you made it easy.
- Condescension. Words like “they just didn't get it” or “I had to dumb it down” suggest you look down on colleagues.
- No check for understanding. Without it, you only know that you talked, not that they learned.
- A story with no decision. Explaining for its own sake is weaker than explaining so someone could act.
- Rambling. If your answer runs long, it undercuts the skill you are describing. Our guide on how to stop rambling in interviews has a fix.
This story pairs well with others in your bank. See the full list of “tell me about a time” questions, plus our answer guides for persuading someone and handling a difficult customer, which often reuse the same communication habits.
Practice it
Practice this answer out loud, because the skill being tested is spoken explanation. Record yourself, then listen for jargon you would not use with a non-technical listener. Draft the parts in the free STAR story builder if that helps you get started.
Then rehearse with follow-ups. A browser-based AI mock interview can put this question to you out loud and score your spoken answer out of 10 with what to fix. The desktop app can also build a mock interview from your résumé and the job description, so the questions match the role. Both are free for 15 minutes a day with no account.
Test your explanation on an AI interviewer
Answer out loud, get a score out of 10 and specific fixes, then run it again. Free for 15 minutes a day, no account needed.
Try a free AI mock interviewFAQ
What is a good example of explaining something complex?
A good example is one where a non-specialist needed to understand a technical topic to make a decision, such as a CEO choosing between hiring and fixing technical debt, or a marketer deciding whether test results were reliable. Show the analogy you used, how you checked understanding and the decision that followed.
What if I am not in a technical role?
The question works for any specialist knowledge: explaining a legal clause to a client, a medical instruction to a patient or a budget model to a manager. Anything your audience did not know and needed to act on counts.
Should I explain the technical topic in detail in my answer?
No. Explain it the way you explained it to the stakeholder, in plain words. The interviewer is judging how clearly you communicate, so a jargon-heavy answer works against you.
What is a teach-back check?
It means asking the other person to explain the idea back in their own words, for example "how would you explain this to your team?" It shows you confirmed understanding instead of assuming it.
How long should the answer be?
Aim for about two minutes. Keep the technical background to one or two sentences and spend most of the time on how you explained it and what happened next.
What if the interviewer asks me to explain a concept on the spot?
Start with why it matters, use one analogy, give one concrete example and stop within about a minute. Then ask whether they would like more detail on any part.