Describe a Project You Worked On? How to Answer

Here is how to answer "describe a project you worked on." In your first sentence, say what the project changed and what your part was. Then walk through the project in order, as proof, with two or three decisions you made. End with what you would do the same way again. Aim for about a minute, and let the interviewer ask for more.

Most people do the opposite. They start with how the project began and tell it in the order it happened, and the result shows up at the end, if there is time. This post shows how to turn that around, builds one example answer, and ends with a five-minute exercise you can do today.

What "describe a project you worked on" is really asking

The question comes in a few forms: "describe a project you worked on," "tell me about a project you are proud of," or "walk me through a recent project." Northwestern's career office lists versions of it, such as "tell me about a project you initiated," among its common behavioral questions (Northwestern Career Advancement). They all ask the same three things. What did the work change? What did you do, as opposed to the team? And can you explain it clearly to someone who was not there?

That third part is easy to miss. Explaining your work is part of most jobs, so a clear answer shows the skill while it describes it.

It is a behavioral question, the kind where your past work is the evidence. MIT's career office suggests giving most of a behavioral answer to the actions you personally took, about 60 percent, and keeping the setup short (MIT Career Advising & Professional Development). For a project answer, that means less about how the project started and more about the choices you made inside it.

Why project answers turn into a project history

A project lives in your memory as a timeline. First the request came in. Then you met with the team. Then you found the real problem. Then you tried something. Then, months later, it worked.

So that is how it comes out. You start at the beginning because the beginning is where the story starts for you. Each step needs the step before it to make sense, so you keep adding context. By the time you reach the result, most of the minute is gone, and the interviewer has spent it guessing where the story was going.

There is a second cost. A long setup is almost always about the team: what "we" were asked, found and tried. Your decisions, the part the interviewer came to hear, get squeezed into the last few sentences.

How to describe a project you worked on in four parts

Here is the shape. It fits inside the STAR method (situation, task, action, result). It only changes what you say first.

Part one, the result and your part, in your first sentence. Name the project, what it changed, and what you owned. "The project I would pick is our help center rebuild, which cut our weekly password-reset tickets by about half, and my part was choosing which articles to rewrite first."

Part two, the situation, in one or two sentences. Just enough for the result to make sense. What was wrong before, and who it affected.

Part three, your decisions, in three or four sentences. This is most of the answer. Pick two or three choices you made, say why you made each one, and say what happened.

Part four, what you would keep, in one sentence. One thing you would do the same way on the next project, or one thing you would change. Then stop.

Here is a made-up example for the rest of this post. Dana is a support team lead at a software company, interviewing for a customer operations role. Asked to describe a project she worked on, she says:

"The project I would pick is our help center rebuild, which cut our weekly password-reset tickets by about half, and my part was choosing which articles to rewrite first. We had over two hundred articles, most of them out of date, and customers were opening tickets instead of searching. I pulled three months of tickets and sorted them by topic, and I found that twenty topics made up most of the volume. I pushed to rewrite only those twenty first, instead of the whole help center, so we could ship in six weeks instead of six months. I also added a short link to the right article in our ticket auto-reply. Within two months the password-reset tickets were about half what they had been. What I would do again is start from the tickets, not from the articles."

About a minute. The result and her part are in the first sentence. The situation takes one sentence. Most of the answer is three decisions, each with a reason. The last line is what she learned, and then she stops.

Say "I" for your decisions and "we" for the result

Projects are team work, and it can feel wrong to say "I." So people say "we" for everything, and the interviewer cannot tell what you did. MIT's career office is direct about this: use "I" statements to show ownership, because "we" statements make it hard for an employer to understand your skills (MIT Career Advising & Professional Development).

You do not have to take credit for the team to do that. A simple rule keeps it honest. Say "we" for the situation and the result, because those belonged to the team. Say "I" for the decisions you made and the things you did yourself.

Listen to Dana's answer again. "We had over two hundred articles" is the team's situation. "I pulled three months of tickets" and "I pushed to rewrite only those twenty first" are her decisions. Nobody hearing it thinks she rebuilt the help center alone. They know exactly which part was hers.

If your honest part was small, say so and make it specific. "My part was the data for the first two weeks" holds up under follow-up questions better than a vague "we" that hides it.

Pick the project before the interview

You probably have several projects you could use. Choose one or two before the interview, so you are not picking under pressure. Three questions narrow it down.

Did it change something you can name? Fewer tickets, a faster report, a launch that shipped, a process people still use. If you cannot say what changed in one sentence, it is a hard project to describe.

Did you make real decisions in it? A project where you followed a plan is a weaker story than one where you chose between options. You need at least two choices you can explain.

Is it close to the job you want? A project that uses the skills this role needs does double work. It answers the question and shows the fit.

Two related questions are easy to confuse with this one. "Walk me through your resume" asks for one thread across all your roles, not one project, and our post on how to answer walk me through your resume covers that shape. And if your project is technical and the interviewer is not, the same result-first idea applies, with more care about plain words. Our post on explaining technical work to non-technical people goes through that part in detail.

Once you have picked, write a few lines of notes. Include a number only if you can say where it came from. A few lines are enough to keep the answer from turning into a timeline.

Say the first sentence out loud, then stop

Written down, the four parts look easy. Out loud, two things go wrong.

The first is the warm-up. "So, um, there are a few I could talk about, but I guess one that comes to mind is..." Every word of that delays the result. Pause for a second if you need to, then start with "The project I would pick is." Silence before the first sentence sounds like thinking. A warm-up sounds like searching.

The second is part three growing. Every step feels important, because you lived through it. Keep the decisions that changed the outcome and drop the rest. If the interviewer wants the timeline or the tools, they will ask.

When the interviewer digs in

Follow-up questions are common with this one, because a project has so much detail behind it. The same shape handles them.

"What was the hardest part?" Pick one decision and say what made it hard. "Deciding to leave most of the help center out of date for six weeks. Some of the team wanted to fix everything at once."

"What would you do differently?" One thing, about you. "I would have shown the ticket data to the team in the first week, not the third. It would have ended the debate sooner."

Try it now: practice in five minutes

You need your phone's voice recorder and a timer.

1. Pick one project. Write what it changed, in ten words or fewer, and your part, in ten words or fewer.
2. Write your first sentence: "The project I would pick is [project], which [what it changed], and my part was [your part]." Then write two decisions you made, with one reason each.
3. Start the recorder and the timer. Ask yourself out loud, "Describe a project you worked on." Answer from your notes, and stop near one minute.
4. Play it back and listen for two things only. Did the result arrive in your first sentence? Can you hear where "we" ends and "I" begins?
5. Fix one of those and record it again. If you have time left, answer "What would you do differently?" in two sentences.

On the second take, listen for whether the result moved closer to the front.

If you know your project well but the answer still comes out as a timeline when someone asks, that is a practice problem, and practice is how it changes. Sayforth is a 30-day iPhone program built for that: one question a day, answered out loud, and after you finish, your answer is drawn as one line so you can see whether your main point came early or late, with one change to try tomorrow. It is coming soon, and you can read how the daily practice works now.

Frequently Asked Questions

How do you describe a project you worked on in an interview?

Say what the project changed and what your part was, in your first sentence. Give the situation in one or two sentences, spend most of the answer on two or three decisions you made, and end with one thing you would do the same way again. Keep it to about a minute.

Should I say "I" or "we" when describing a team project?

Both, for different parts. Say "we" for the situation and the result, because the team shared them, and "I" for the decisions you made and the work you did yourself. That way the interviewer can hear your part without you taking credit for the team.

What if my project did not have a measurable result?

Name what changed in plain words instead: a process people now use, a launch that shipped, a problem that stopped coming back. Do not invent a number. A clear description of a real change is stronger than a figure you cannot explain.