Technical Interviews: How to Explain Your Projects and Problem Solving Skills
You know your work. You built the thing and fixed the bug and made the system faster. Then someone asks you to walk through a project and your mind goes blank. Or you are given a problem and you go quiet because you are thinking and the silence feels like failing.
This is a very common experience and it has less to do with skill than with habit. Explaining technical work out loud is a separate skill from doing it. The good news is that it can be practiced. This guide shows how to describe your projects and how to talk through problems so the interviewer sees how you think.
What interviewers are really looking for
The University of Virginia engineering career center notes that interviewers care more about how you reason through a problem and communicate it and catch your own mistakes than about a flawless first attempt. Northeastern University Career Development says something similar. Talking through your thinking lets the interviewer follow along and correct you early.
That changes the goal. You are not only trying to reach an answer. You are showing what it is like to work with you.
A simple frame for explaining a project
Northeastern advises discussing projects clearly including the problem and your approach and your decisions because interviewers often use this to gauge your depth. A short frame keeps you organized. Use five parts.
- The problem. What needed solving and who it mattered to.
- Your role. What you personally did as opposed to the team.
- The approach. What you chose and why.
- The trade offs. What you considered and gave up.
- The result. What happened and what you would do differently.
Here is an invented example. We needed reports to load faster because users were abandoning them. I owned the data layer. I compared caching results with rewriting the slowest queries and chose the rewrite because the cache would have hidden the real problem. Load times improved and I would add monitoring earlier next time. It takes under a minute and it shows a decision and a reason and a lesson.
Can you explain your most important project in two minutes to someone outside your field?
Try it out loud and time it. If you rely on jargon to fill the space you may not yet have a clear story. Start with the problem and the person it affected and then add detail only as needed.
Be honest about your part
Most work is done in teams. Say we when describing what the group did and say I when describing your own decisions. A clear line between the two builds trust and it prepares you for follow up questions. If an interviewer digs into a part you did not own say so and explain what you understood about it.
Talk through problems out loud
When you are given a problem start by asking questions. Northeastern suggests clarifying inputs and outputs and edge cases and constraints and scale before solving. UVA suggests stating your assumptions and comparing possible approaches and narrating your thinking as you go. Then review your solution and trace through it and consider edge cases.
- Restate the problem. Say it in your own words to confirm you understood.
- Ask clarifying questions. Cover input size and unusual cases and what a correct answer looks like.
- Share your first idea. A simple approach is fine to start. Say why it might be too slow or too limited.
- Compare options. Name one or two alternatives and the trade off between them.
- Build step by step. Explain what each part does as you write it.
- Test with an example. Walk a small case through your logic before you say you are done.
Want to practice explaining your work with feedback from someone who knows what interviewers listen for? Our interview coaching can help you build clear and confident answers.
Quick technical interview check
Tick what is already true for you. Nothing you tick is saved or sent anywhere.
0 of 5 completed
Listen for hints
Northeastern notes that an interviewer's suggestion may point to a better approach or may be testing how you adapt. Treat a hint as part of the conversation and not as a sign you are failing. You can say that is helpful and let me try that direction. Showing that you can take input and change course is a strength.
When you do not know something
It will happen. Northeastern advises saying so honestly and then reasoning through what you do know or stating a reasonable assumption and moving on. Avoid bluffing or getting stuck on one point. A calm line works well. I have not used that directly but here is how I would approach it based on what I know about similar tools.
What is a topic you tend to avoid in practice and how could you approach it calmly if it came up?
Name the topic honestly and then write one sentence you could say about how you would reason through it. Having that sentence ready makes the moment less frightening.
How to practice without burning out
Both sources stress practice. Northeastern suggests practicing explanations aloud and recording yourself to catch unclear or jargon heavy answers and working through problems with peers or mentors. UVA suggests working through problems on your own or with a partner or in workshops and writing code in a shared document or a text editor to mimic the interview setting. It also lists practice sites such as LeetCode and Pramp and Interviewing.io.
- Short sessions. Thirty focused minutes beat one long night.
- Aloud every time. Silent practice does not build the speaking skill.
- One recorded answer a week. Listen back for filler and jargon.
- A peer. Ask someone to interrupt with questions as an interviewer would.
Talk about a project that did not go well
Many interviewers ask about something that failed or fell short. This is a chance and not a trap. Choose a real example where the lesson was clear. Describe the situation plainly and what you tried and what you would change. Avoid blaming teammates or tools. A calm and specific account of a mistake often earns more trust than a story where everything went perfectly.
An invented example might sound like this. We shipped a feature without enough testing and it caused errors for some users. I helped fix it that week and then proposed a short checklist before each release. The checklist became part of how the team worked.
Be specific without oversharing
Specific details make a project believable. Name the tools you used and the size of the problem and what changed afterward. Use real numbers only when you have them and only when you are free to share them. If the work was confidential describe it in general terms. You can say I cannot share the exact figures but the improvement was meaningful to the team. Then move on to what you learned.
It also helps to bring a short list of projects to the interview in your head. For each one know the problem and your role and one decision and one result. You will not use every detail but you will feel ready when a question arrives.
Match your preparation to your field
Northeastern points out that expectations differ by field. Software roles tend to emphasize data structures and algorithms. Data science roles stress statistics and SQL and machine learning basics. Operations or systems roles focus on practical troubleshooting and design. Read the job posting and note which technical skills it stresses and refresh those fundamentals. Research the company's technology and the problems it solves so you can ask informed questions.
Your projects start on your resume. Our resume writing service can help you describe technical work in a way that sets up strong interview conversations.
Mistakes that hide your skill
- Silence. Long quiet stretches leave the interviewer guessing.
- Coding before clarifying. Ask first.
- Too much jargon. Explain so a smart outsider could follow.
- Claiming all the credit. Be precise about your role.
- Skipping the test. Walk an example through before you finish.
After your last interview or practice session what is one thing you wish you had said out loud?
Reflection is part of improving. UVA suggests noting what went well and what did not and which concepts to review and which questions you should have asked. Treat every interview as practice.
A one week plan
- Day one. Pick your three strongest projects and outline each in the five part frame.
- Day two. Say each outline aloud and record it.
- Day three. Practice one problem while narrating every step.
- Day four. Review the job posting and refresh two skills it stresses.
- Day five. Run a mock interview with a peer and write down what to improve.
The takeaway
A technical interview is a conversation about how you think. Explain projects with a clear problem and role and decision and result. Narrate your reasoning and ask questions and admit what you do not know. When you let the interviewer into your thinking they get what they came for and you get a fairer chance to show it.
Frequently asked questions
Should I talk the whole time I solve a problem?
Talk through your thinking at key moments such as your approach and your trade offs and your tests. Both Northeastern and UVA advise sharing your reasoning so the interviewer can follow along.
What if I get stuck?
Stay calm and say what you are considering. Northeastern suggests listening to hints and focusing on your process and managing your time.
How do I choose which project to discuss?
Pick work where you made real decisions and can explain the problem and your role and the result. Interviewers often use projects to gauge depth.
Is it fine to say I do not know?
Yes when you follow it with reasoning. Northeastern advises saying so honestly then working through what you do know and avoiding bluffing.
How many practice problems do I need?
There is no fixed number. Regular short practice with spoken explanations helps more than rushing through many problems silently. Reflect after each session on what to improve.
