Tell me about a complicated product that you made simpler
Asked at:
Oracle
Lockheed Martin
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers ask this to see whether you can recognize unnecessary complexity, understand what is making something hard for users or teammates, and drive simplification without losing important functionality. It is usually less about elegant design language and more about judgment: did you simplify the right thing, for the right audience, in a way that measurably improved outcomes? At higher levels, it also tests whether you can simplify systems and decisions across a team or organization, not just clean up your own local area.
“Describe a time you took something confusing or bloated and made it much easier to use.”
“What's an example of a product or workflow you simplified? How did you approach it?”
“Tell me about a situation where users were struggling with complexity and you helped reduce it.”
“Have you ever taken a feature that had become too complicated and streamlined it? What did you change?”
“Walk me through a time when you reduced complexity in a product without losing what mattered.”
Key Insights
- You should name who the product was complicated for and why. 'It had too many steps' is weaker than showing you understood the underlying source of confusion, risk, or friction.
- Do not frame simplification as just removing things. Strong answers show that you preserved what mattered, made intentional tradeoffs, and validated that the simpler version actually worked better.
- You will stand out if you show that simplification required judgment and influence, not just implementation. Explain how you decided what to cut, combine, re-sequence, or explain more clearly.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see that you understood what was confusing and did more than tidy surface details.
Good examples
🟢I noticed new users kept abandoning the setup flow at the permissions step, so I reviewed support tickets and saw the problem was unclear wording about why access was needed, not the number of fields.
🟢The dashboard felt busy, but after watching a few teammates use it, I realized the real issue was that similar actions were labeled differently in different places, so people couldn't predict what would happen.
Bad examples
🔴Users were getting stuck, so I changed the colors and moved a few buttons around. After that it looked cleaner, so I considered it simplified.
🔴The page had a lot going on, and I felt it was too complex, so I split it into two pages without really checking where people were getting confused.
Weak answers jump to cosmetic or intuitive fixes; strong answers show the candidate investigated what was truly causing confusion before changing anything.
A good junior answer shows you understood simplification is not just deleting things; it is choosing what to keep clear and what to hide or defer.
Good examples
🟢I kept the fields required for account creation and moved the rarely used settings to a later step so new users could finish the core task first.
🟢We wanted a simpler view, but some power users still needed advanced filters, so I hid them behind an 'advanced' section instead of removing them entirely.
Bad examples
🔴I removed several options from the form because they made it look busy, and I assumed people could ask support if they needed them.
🔴I combined multiple steps into one page to make it shorter, even though that made the instructions denser.
Weak answers simplify by stripping capability without considering consequences; strong answers balance ease of use with preserving important needs.
Valuable
Show that you cared about how real people experienced the complexity, not just whether the product looked cleaner to you.
Good examples
🟢I asked a support teammate what confused users most and used that to guide the changes instead of relying only on my own impression.
🟢I considered that new users and experienced users needed different things, so I simplified the default path without making familiar tasks harder for existing users.
Bad examples
🔴I found the workflow annoying, so I simplified it based on what I thought would feel more natural.
🔴Some teammates said the old screen was fine, but I assumed they were just used to it and moved ahead.
Weak answers center the candidate's taste; strong answers show they tried to understand the experience of the people affected.
You do not need perfect metrics, but you should show some evidence that the simplification helped people, not just that it shipped.
Good examples
🟢After the change, task completion for new users improved and support questions about that step dropped, which gave us confidence we had simplified the right thing.
🟢I asked a few teammates who had struggled before to try the new version, and they could finish without the extra explanation they previously needed.
Bad examples
🔴After the update, the screen looked much cleaner, so we considered the project a success.
🔴Nobody complained immediately after launch, which told me the simpler version was probably better.
Weak answers use aesthetics or silence as proof; strong answers use some credible signal that the experience actually improved.
Example answers atlevel
Great answers
In my last internship, I worked on an internal tool that let support agents create refund requests. The form had a lot of fields, and I noticed new agents kept asking which ones actually mattered, so I sat with two agents and looked through recent tickets to see where they were getting stuck. The real issue was that the form mixed required information with rare exception cases, so I suggested moving the exception fields behind an expandable section and rewriting some labels in plain language. I worked with my mentor and the designer, made the changes, and we tested it with a few agents before rolling it out. After that, agents were completing requests faster and the support lead said the number of clarification questions during onboarding dropped.
At my first full-time role at a small consumer-health startup, our app's first-run experience asked users for a long list of permissions and profile details before they could try anything, and we were losing a lot of people right away. I cared a lot about making technology approachable, so I sat down with four people who had uninstalled the app and watched them try to sign up while also reviewing the drop-off points in our analytics. The pattern was clear: people felt overwhelmed and didn’t understand why we needed so much information up front, so I proposed deferring optional profile fields and nonessential permissions until after users had tried the core feature, and rewrote the permission prompts to explain the benefit in plain language. I implemented the change with guidance from a senior engineer and the designer, and when we rolled it out the onboarding completion rate improved by about 20% and fewer users contacted support about setup. That taught me how small changes in flow and language can make a product far more welcoming.
Poor answers
I simplified one of our settings pages because it looked crowded. I removed a bunch of options from the main screen and grouped several things together, which made the page much cleaner. My manager liked the new layout, and I think it was better because there was less on the page. It was a good example of simplifying a product without overthinking it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late May, 2026
Lockheed Martin
Staff
Early February, 2026
Oracle
Senior
Late January, 2026
Oracle
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.