Tell me about an unpopular project you worked on
Asked at:
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you operate when enthusiasm, support, or prestige are low. They want to learn whether you can understand why a project was unpopular, stay effective without becoming cynical, and make sound decisions in a situation that may involve skepticism, resistance, or morale issues. For more senior candidates, it also tests whether you can reshape the work, align others, or improve outcomes rather than simply endure it.
“Tell me about a project you worked on that most people weren't excited about.”
“Describe a time you had to drive work that had low support or low enthusiasm.”
“Have you ever been assigned a project that people were skeptical of or didn't want to do? What happened?”
“What's an example of a thankless or low-prestige project you took on?”
“Walk me through a project that faced a lot of resistance before or during execution.”
Key Insights
- You should explain why the project was unpopular in a nuanced way. 'Nobody liked it' is weak; strong answers show you understood the underlying reasons such as low visibility, maintenance burden, risk, unclear payoff, or prior failed attempts.
- Don't frame the story as 'everyone else was negative and I was right.' Strong candidates show respect for why others were hesitant, then describe how they reduced risk, clarified value, or adapted the plan.
- You need to show more than grit. Interviewers are often looking for judgment: whether you accepted the work blindly, or whether you improved the scope, execution, communication, or team experience around an undesirable project.
What interviewers probe atlevel
Top Priority
You do not need to own the whole project as a junior engineer, but you should show initiative within your slice instead of acting like a passenger.
Good examples
🟢I asked for the riskiest part of the work to be broken into smaller steps so I could help validate assumptions early instead of just taking tasks one by one.
🟢I noticed onboarding into that codebase was slowing everyone down, so I documented what I learned and shared it with the rest of the team to make the work less painful.
Bad examples
🔴I knew it wasn't a great project, so I just waited for clear tasks and made sure my tickets were done on time.
🔴There wasn't much I could do about the situation, so I kept my head down and completed what I was assigned.
Weak answers show compliance only; strong answers show the candidate improved execution within the scope they could influence.
At junior level, interviewers mainly want to see that you understood the context instead of treating unpopularity as random complaining.
Good examples
🟢The project was unpopular because it was mostly reliability work in an older part of the system, and the team had just come off a high-visibility feature launch, so the contrast was pretty stark.
🟢A lot of the hesitation came from the fact that a previous attempt had caused incidents, so people were worried we'd reopen that pain rather than actually improve things.
Bad examples
🔴People didn't like the project because it was old code, and honestly they were just avoiding hard work.
🔴It was unpopular because it wasn't exciting, so I just focused on finishing my tasks and ignored the negativity.
Weak answers reduce the problem to other people's attitude; strong answers identify the real source of resistance and show situational awareness.
Even as a junior engineer, you should show that you took others' concerns seriously instead of dismissing them as negativity.
Good examples
🟢The senior engineers were cautious because they had supported that area during past incidents, so I tried to learn from their experience before making changes.
🟢The project manager was worried about schedule impact, which was fair, so I made sure my updates were concrete and included what was still uncertain.
Bad examples
🔴Some teammates kept complaining, but I think they just didn't want to deal with messy work.
🔴QA was nervous about the change, but they tend to be cautious about everything, so we just moved ahead carefully.
Weak answers caricature others; strong answers assume others have valid reasons and respond respectfully.
Valuable
You should show a real result and one clear thing you learned that changed how you work.
Good examples
🟢We reduced a recurring source of support tickets, and I learned to ask earlier about why a project has resistance because that often points to hidden risks.
🟢The project stabilized an area that had been causing repeated issues, and I came away more proactive about documenting messy systems so others can move faster.
Bad examples
🔴The project shipped, and it taught me that sometimes you just have to do work you don't enjoy.
🔴We finished it eventually, so overall it was a good reminder to stay positive.
Weak answers end with generic life lessons; strong answers tie concrete outcomes to a specific behavioral change.
Example answers atlevel
Great answers
One unpopular project I worked on was cleaning up a fragile internal service that had been causing repeated support issues. It wasn't exciting work, and a lot of the team had more interest in the new product features we were also building. I was fairly new, so I started by asking why people were so cautious, and I learned that a previous change in that area had caused an incident. I took ownership of a small but risky part by building a simple test case first and then documenting the setup steps because even getting the environment running was slowing people down. That helped us catch one bad assumption early, and the docs saved time for the next engineer who joined the effort. The project reduced those recurring issues, and it taught me that when work seems unpopular, there's usually a real reason behind it that you should understand before jumping in.
An unpopular project I picked up was fixing accessibility problems in our admin dashboard — it was low-profile work and most of the team wanted to focus on new features. I volunteered because a friend who uses a screen reader had trouble with some workflows and I wanted to make the product usable for everyone. I started small: I reproduced the issues, added proper labels so assistive tools could describe controls, improved keyboard navigation, and fixed a few places where color contrast made text hard to read. I also created a short checklist that reviewers could use so these regressions wouldn't come back. A couple of customers reached out to say they could use the dashboard again, and the team now includes accessibility checks in our pull-request process, which felt like a real win for long-term quality.
Poor answers
An unpopular project I worked on was updating some older backend code that nobody really wanted to touch. It was mostly unpopular because people preferred feature work, but someone had to do it. I just focused on my assigned tickets and made sure I finished them quickly so the project kept moving. I don't think there was much else to do because the project was already defined. In the end we got through it, and it showed I can stay productive even when the work isn't very interesting.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late April, 2024
Meta
Mid-level
The project which you worked is unpopular and why it is.
Hello Interview Premium
Your account is free and you can post anonymously if you choose.