Tell me about an unpopular project you worked on
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.
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
For junior candidates, strong stories include specific actions that reduced confusion, risk, or friction on the project.
Good examples
🟢I built a small test case to verify one risky assumption before we touched the broader system, which saved us from taking the wrong approach.
🟢I wrote a short setup guide after struggling through the environment myself, and that cut onboarding time for the next engineers joining the effort.
Bad examples
🔴I mainly contributed by getting my coding tasks done quickly so the project could move faster.
🔴I kept asking for work and finishing it, which helped because the project needed execution.
Weak answers describe labor; strong answers describe actions that changed the project's trajectory or reduced risk.
Valuable
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
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.