I once wrote that if you can explain your experience clearly and logically, you’ll beat 85% of job seekers. That line came from my experience with the problems I see most often while coaching. I really do find that out of fifty students, only two or three can fully explain what they did, how they did it, what difficulties they hit, and what impact it had without me having to prompt them.
So when a student thinks her internship is too ordinary or her project too simple to be worth talking about, I usually start by having her actually tell it. A lot of the time, we don’t even get to comparing how impressive the project is; the basic facts already aren’t coming across clearly.
A disagreement within the team, for example, is a very common experience, and of course you can use it. But you need to make clear what your view was, which point the other person disagreed with, what each of you based your view on, how you discussed it, and how it was decided in the end. If you only say “I communicated proactively and we reached a consensus,” the interviewer has no way to judge what you did in that conversation.
The following problems are ones I run into again and again when I practice interviews with students.
Good Communication Starts with a Hierarchy of Information
In an interview, you don’t retell everything that happened in a project in chronological order. You decide what to say first, what comes later, and what to leave for follow-up questions.
One student opened with: “I built an Excel model to evaluate the performance of 200 bank branches.” The technical action was there, but the problem wasn’t. What needed to come first was the problem itself. The bank was using one set of sales targets to evaluate 200 branches operating in different markets, so managers could be penalized for market conditions they couldn’t control, and the project was about whether benchmarks should be reset by comparable groups of branches. Once you understand that problem, the clustering and the Excel model that follow make sense.
When you shape an answer, check four things: whether the result or the problem shows up early; whether your numbers have a point of comparison; whether the technical detail connects to business impact; and whether the listener can picture what happened. Not every answer has to lead with the result, but the most important information can’t stay buried behind routine process.
1. Understand the Question Before You Choose a Story
One student was practicing a behavioral question: how would you keep improving the quality of a product or service that was already getting good feedback?
As soon as she heard “improve quality,” she launched into a story she’d prepared and missed the condition “already getting good feedback.” I stopped her and had her listen to the question again. Fixing something people have already complained about and pushing for better when everyone thinks it’s fine show different kinds of judgment.
Another question asked what you’d do if, halfway through a project, you found the original goal might be wrong or might have unintended consequences. If your example is just about switching to a different way of executing, while the goal itself never changed, you may not really have answered the question.
When you prepare, underline the conditions in the question, then say in one sentence what the question is asking you to prove. Only after that should you pick an example from your own experience. If you didn’t catch the question in the interview, ask them to repeat it or check your understanding. That’s better than finishing a long answer and realizing you went off track.
2. Telling It Smoothly Doesn’t Make It the Right Example
One student told a story like this: she noticed revenue was falling short of target, found through analysis that the big clients had used up their budgets, turned to small and mid-sized clients instead, and ended the year about 2% above her KPI target.
She told it smoothly, with clear steps and a result. But I kept looking at whether the story raised another question in the listener’s mind: why hadn’t anyone paid attention to these clients before, and why was the problem only discovered so late?
After we talked it through, she added how the work was divided at the time: sales mainly brought in the leads, but her marketing team was also tied to the revenue target, so she stepped outside her usual role to find opportunities. That context affects how an interviewer understands what she did.
Her reflection at the end could be more specific too: how to check progress earlier, how to avoid designing plans only around big clients, and how to cover smaller clients together with sales. Explain what actually happened. Don’t just end with “I learned to be proactive.”
This example shows that when you choose a story, beyond whether the result looks good, you need to look at what it proves for the question at hand and what it might expose. Stories about failures or shortcomings can be told too, but you have to be able to explain your own responsibility and what you actually changed afterward.
3. When the Work Itself Is Interesting, Don’t Just Walk Through How It Was Made
One student talked about a creative video she’d made for a luxury brand client. She spent a long time on reviewing footage, finding a director, and holding weekly meetings, but covered what the video was actually about in a single sentence.
When I pressed her on what the video was about, she explained it clearly in Chinese: it followed one user through her day. In the morning she sees an ad as she opens an app; scrolling through her feed, she comes across the brand’s content; later ads connect her to physical stores and events. Stringing these scenes together showed the client how a user gets reached by different kinds of content over a single day, and also what competing brands had already tried.
That’s the part that made the creative idea and purpose of the work clear. The interviewer can’t see your portfolio, so you have to use words to let her picture it.
You can certainly talk about the process, but the space you give it should match how much it matters. Who was responsible, how you collaborated, and any key difficulties are worth keeping; routine meetings and coordination don’t need to be walked through step by step. If your most valuable contribution was the creative idea, explain the idea and the thinking behind it.
4. Tie Your Takeaway to This Story, Not to a Generic Lesson
That same student originally ended with “thinking from the client’s perspective to create a win-win.” It’s not wrong, but it could be tacked onto almost any story, so it’s hard to see what this particular experience taught her.
In that discussion, I wanted her to spell out something more specific. Sometimes clients don’t know what else is possible in how their content can be presented, and you have to show them, through concrete work, possibilities they hadn’t imagined. That’s more closely tied to her video concept and to what the question asked.
With my students’ answers, and with my own feedback, I’m hoping for that “I never thought of that” effect. But it has to come from real judgment, not from a big lesson tacked on at the end.
Ask yourself: if you moved this closing line to the end of a completely different story, would it still work without changing a word? If so, go back to the specific event and explain what you’ll do differently from now on.
5. A Few Experiences Can Answer Different Questions. You Don’t Need a New Story for Each One.
One student was told to prepare a different story for each of twenty or thirty behavioral questions. Memorizing them became miserable, and she started forcing difficulties and conflicts into her stories just to fit the questions.
I had her go back to the few things she had really done and tell them thoroughly. A single project can involve dividing up work, disagreements, time pressure, learning new methods, and making choices, all at once, and you can shift the emphasis depending on the question.
Take one group project. For a teamwork question, talk about how you worked together; for conflict, the disagreement and how it was handled; for learning, how you picked up something new. The facts stay the same; the length and emphasis can change.
The same applies when you switch roles. A student with audit experience applying for External Audit might focus on inventory, cash, and substantive testing. For Internal Audit, the parts of the same experience more worth expanding might be process, risk, controls, and independent review. The experience hasn’t changed; the lens you look at it through has.
But not every question can be forced onto a story you already have. If your story didn’t involve a change in goals, you can’t add a section to answer a “changing goals” question. And simply having been in a group doesn’t mean you can answer every leadership question.
When you organize your material, first build a table of events, then see which questions each event can support. That also makes it easier to spot which types of questions you don’t have a good example for yet, so you can keep thinking back instead of making something up on the spot.
6. Technical Projects Can Answer Behavioral Questions, if You Show Your Thinking
One student used a data project to answer a challenge question. She talked about class imbalance, using SMOTE, and how the model performed in the end, but “how I solved the problem” was reduced to two words, “learn online.”
I kept asking: what did you learn online, which methods did you come across, why did you choose this one in the end, how did you validate it along the way, and which results made you decide to adjust?
In that session, we organized it like this: she ran into class imbalance, researched different ways of handling it, compared when each applies and how much time each takes, chose an approach, then validated and adjusted. The strengths and weaknesses of specific methods have to be based on what the student really understands and the analysis she has actually done.
What this kind of question needs you to explain is your process of learning, judging, and solving problems. The technology is the specific setting, and it helps the interviewer see how you work when you face an unfamiliar problem. Swapping in a fancier tool name doesn’t answer that.
Self-Introductions and “Why”: Connect Your Experience to the Role
A self-introduction doesn’t need to start from your childhood, and it doesn’t need to give every experience equal time. Say where you are now and what your relevant background is, pick the experiences that best show what the role needs, and then explain why you want to do more of this kind of work.
I worked with a student who already had years of work experience. Her self-introduction was lively, but much of it was about how she became interested in the industry and how her early jobs helped her grow. In a job search, the interviewer needs to know more about what she can already take responsibility for now.
We cut down the early experience and gave the space to how she had moved from executing projects to making judgments and collaborating on a broader scale, then connected that to the roles she wanted. That “broader scale” has to be backed by real work. Changing “analyst” to “strategist” doesn’t make it a career upgrade.
The same goes for “why this company.” If your answer would still work with a different company’s name swapped in, it’s usually not specific enough. Draw on what the company or team actually does, your own experience, and what you’ve learned through networking to explain why this job is relevant to you.
When I do company research, I keep pushing on three questions: what does this company actually do, why do its customers need it, and why do they pick it over the alternatives? The first can’t just be a paraphrase of the website; you should be able to describe a concrete scenario of a customer using the product. The second is about what problem it solves. Only the third gets into competitive advantage, and there you keep pushing on “Why is it more accurate, faster, or more trustworthy?”
For example, “it’s a big platform and I can learn a lot” may be what you really think, but you need to go further: which kinds of business you want exposure to, why that connects to your next step, and which of your past experiences you’d keep using there. That’s how they’ll know you really understand what you’re applying for.
A company pays you because it expects you to create value. Being eager to learn is good, but you can’t only tell them what you want to get out of the job. You also need to say what you can contribute.
Using AI to Prepare for Interviews: Discuss First, Draft Later
These days AI can easily produce an answer that’s logically sound and sounds professional. The problem is that any candidate could say the same thing. So the first step in preparing with AI is, counterintuitively, not to have it write anything yet. First work out what the question is testing, and what real experiences, views, and trade-offs you have.
Next, have the AI discuss your answer with you from the point of view of the target role: what else someone who really does this job would care about, which variable your answer is missing, and which parts are just a generic framework. After that discussion, let it help you organize your wording. Then review it line by line, checking whether your most specific facts got cut and whether anything you don’t understand got squeezed in to sound professional.
Take a decision-making question. AI can easily list several factors to weigh. An answer that actually stands out goes further: which information you’d look at, what would make you change your mind, and how you’d make the final call. AI can help you explain your judgment better. It can’t have the judgment for you.