How to Explain a Technical Project in an Interview (The 12th-Grader Test)
I tell every candidate the same thing.
"Explain your project to me like I'm a 12th grader."
Not because interviewers are dumb. They're not. But if you can't explain what you did simply.. you probably don't understand it deeply enough.
And the interviewer can tell.
The candidate who sold doors
A few weeks ago I was coaching a candidate prepping for a data engineering interview. Strong work history. Real technical depth. A migration project at a supply chain company, pulling their data into one place.
She started practising the way most candidates practise:
"I built ETL pipelines using Azure Data Factory.. designed the database schema.. orchestrated workflows for incremental loads.."
I stopped her.
"What does this company even do?"
Long pause.
"They sell doors."
THAT'S where you start.
Same project, two answers
Here's how she'd been answering:
"I built ETL pipelines using Azure Data Factory and designed the database schema for an incremental migration."
Here's how she answered after we reworked it:
"The company sells doors. They had supplier data in one system, inventory in another, purchase orders in a third. When management needed a report, someone had to download Excel files from three places, manually combine them, and hope nothing was wrong. We built a pipeline to pull all of that into one place automatically. Now they can see — in real time — which suppliers are performing, what inventory looks like, and where the bottlenecks are."
Same project. Same technical work. Same Azure Data Factory.
But now the interviewer leans forward.
The 4 questions to answer — in order
Before any interview, write out your answers to these four questions in plain English. No tools. No frameworks. No stack names.
What does the business do? ("They sell doors.")
What was broken? ("Data lived in three systems. Reports took hours and had errors.")
What did you build? ("A pipeline that pulls everything into one place automatically.")
What changed for the business? ("Management can see supplier performance, inventory, and bottlenecks in real time.")
Once those four answers are clear.. then you can layer the technical detail back on top. Azure Data Factory. Schemas. Incremental loads. Whatever the role expects.
The order matters. Story first, stack second.
Why this works
Interviewers are people. Tired people. Often on their fifth interview of the day.
The candidates who get hired aren't the ones with the most acronyms. They're the ones the interviewer can repeat back to their manager 30 minutes later without re-reading their notes.
If your story is "ETL pipelines, schema design, Azure Data Factory" — your interviewer has nothing to repeat.
If it's "they sell doors, and we made the broken-report problem disappear" — they have a story. And people hire stories.
(Btw — if you've spent 18 months on a project and you can't summarise it in 4 sentences.. that's not the interviewer's problem to solve in the room. That's homework.)
The real test
The best engineers I know can explain their most complex work in the simplest terms.
Not because they think the interviewer is stupid. Because clarity is the proof of understanding.
That's not dumbing it down. That's leveling up.
Need help getting ready for interviews like this one?
At Wynisco, we coach international students and immigrants through the full US job search — positioning, resumes, mock interviews, and offer negotiation. 78% success rate. Average 52 days to placement. Average salary $95K. Alumni at JP Morgan, Amazon, Microsoft, and Meta.
Apply at wynisco.com • sachin@wynisco.com
— Sachin Rajgire, Co-Founder & CEO, Wynisco Inc.
Written by
Sachin Rajgire