I walked into the interview unusually prepared.
Not “I memorised buzzwords and rehearsed fake enthusiasm” prepared. Prepared because this was actually my field. User experience. Systems thinking. Accessibility. Workflow analysis. Information architecture. The messy, complicated, deeply human layer underneath software that most people never even notice until something breaks and suddenly everyone’s a UX critic.
Years of this work. Not just doing it, but thinking about it at a level most people in the room probably haven’t needed to yet. I’ve untangled enterprise workflows that looked perfectly logical on paper and were quietly destroying the productivity of the people using them every day. I’ve sat in rooms where engineers confidently explain why the interface works fine, while the user in the next room over quietly develops a workaround because the actual flow made no sense to anyone outside the team that built it. That’s the job. Find the gap between what the product team believes and what the user actually does. Make it smaller.
The first interview went well. The conversations made sense. They talked about needing someone who could identify friction, understand users deeply, untangle workflows, and improve the experience of a complex production application. Good. That is exactly the kind of work I do best, and I said so without flinching.
Then came the technical interview.
Instead of discussing methodology, process, discovery, accessibility audits, research strategies, workflow mapping, or how I approach identifying systemic UX problems in a production environment, they opened their software and essentially said,
Use it like a normal person. Tell us what you’d click. Why you’d click it. What you’d change right now.
Immediately, I could see the trap.
Not because I couldn’t critique the software. Any designer, regardless of seniority, can walk into a product cold and start firing opinions into the air. Buttons too small. Navigation is confusing. Too many clicks to get here. Make this a modal. Move that there. Junior designers do this constantly, and I mean no disrespect, because surface-level criticism is easy. It’s fast and it sounds authoritative, and in a timed interview format, it performs brilliantly.
The problem is that real UX work is not improv theatre.
Any designer, regardless of seniority, can walk into a product cold and start firing opinions into the air. Buttons too small. Navigation is confusing. Too many clicks to get here. Make this a modal. Move that there.
A serious UX specialist understands that context changes everything. Before making confident recommendations, I need to understand who the users actually are. Are these power users who have been using this product for three years and have deeply embedded muscle memory? Are they new users being onboarded? Is this workflow optimised for speed, compliance, accuracy, or training cost? Are there regulatory constraints baked into the structure? Accessibility requirements that aren’t immediately visible? Legacy technical limitations the interface is working around? Existing analytics that already flag known pain points? Historical reasons that the workflow evolved this specific way, probably because someone had a very specific business problem in 2019 and nobody has touched it since?
Without that information, every “improvement” I offer is informed guesswork at best and actively harmful at worst.
You can laugh at that. Go on. But I’ve seen confident UX recommendations shipped into production that broke three downstream workflows the recommending designer had never been shown. Looked great on paper. Made intuitive sense in isolation. Worked terribly inside the actual ecosystem. The same way you can redesign an intersection and improve pedestrian flow while simultaneously making it worse for emergency vehicles, which nobody tested because emergency vehicles weren’t part of the brief.
Ironically, the more experienced you are, the more careful you become before making declarations. You accumulate enough scar tissue from past projects to understand how many invisible systems sit underneath a seemingly simple interface decision. You develop restraint. You develop the discipline to ask before you assume. You learn that the interface you’re looking at is almost never the whole story.
But interview formats like this one don’t measure thoughtful UX strategy. They measure performative confidence.
They reward the candidate who instantly speaks the loudest and critiques the fastest, not the person actually modelling the system internally before proposing meaningful changes. It was a format built to identify someone who can generate output quickly, not someone who generates the right output. The exercise was biased toward rapid external processing instead of deliberate analysis, and nobody in that room seemed bothered by the distinction.
And that is the part that still bothers me, if I’m being straight about it.
They were hiring for a UX expert. The job description said as much. But the evaluation method was built to filter for something much closer to live commentary. Not research thinking. Not systems analysis. Not careful workflow evaluation. Certainly not the kind of meticulous reasoning required to surface deep accessibility issues, operational friction, or architectural UX problems in an enterprise product used by real people doing real work under real pressure.
What they actually tested was who could improvise the appearance of UX expertise the fastest.
There is a version of a UX candidate who would have aced that interview, walked into that role, shipped changes with great confidence, and spent the next six months quietly making things worse in ways that don’t show up until someone does a proper research study. And there is a version of a UX candidate who paused, asked the right questions, tried to establish context before declaring conclusions, and got marked down for seeming hesitant.
I know which version I am. I’m at peace with that.
What I’m less at peace with is that the interview format couldn’t tell the difference.