When the interview measures a conflict that isnโt yours

Direct answer: when an interview asks for a depth of skills disproportionate to the declared role, the problem is almost never you. More often it's a sign that two needs inside that company โ whoever decides strategy (and writes the posting) and whoever runs day-to-day operations (and will evaluate you every day) โ haven't quite agreed with each other yet. If they haven't resolved that misalignment, you inherit a bit of it too, on day one.
TL;DR
- Not a one-off: it's a pattern I've seen repeat, in a fairly similar shape, at more than one large, well-run company.
- The mechanism: whoever writes the posting is designing the organization they wish they had; whoever runs your final interview needs to cover a real, often urgent need. Neither is wrong from their own vantage point โ they just haven't talked to each other enough.
- The more hierarchy layers between whoever writes the posting and whoever runs the final interview, the more room the gap has to open without anyone noticing in time.
- A useful tell: if they ask for a long list of different skills, all at "senior" depth, it's likely they haven't fully decided what they want from that role yet.
- Reading the CV before the technical interview isn't a nice-to-have โ it's the bare minimum that separates a thoughtful evaluation from a somewhat random test.
The pattern, not the anecdote
I have watched a specific case where this showed up with almost textbook clarity. But it wasn't the first time I'd noticed it, which is why it felt worth writing up as a pattern in its own right โ more than a complaint about one interview that went sideways.
I've seen it at large, publicly traded or near-public companies, with long, carefully staged, multi-round selection processes โ the kind that on paper should have the right antibodies precisely because they're structured enough to afford doing it well. A large international consulting group, present across several European capitals. A well-known insurance/finance comparison platform in Italy. Different industries, different sizes, different countries โ with a surprisingly similar pattern at the interview stage: a posting that sketches an elegant, cross-functional role, and a final round that measures you against a narrower, more technical, more "operational" slice than the posting ever implied.
This isn't a statistical sample, it's pattern-matching on real but few cases. And it's precisely because it happens at companies that, on paper, "should know better" that it feels worth understanding the mechanism, rather than filing it away as bad luck.
The mechanism
A bridge role โ the kind that sits between two functions, growth/engineering, product/data, marketing/tech โ is almost always written by whoever wants it on the org chart, and evaluated by whoever has an immediate operational need. Two different time horizons: whoever writes the posting is designing the organization the company wishes it had six months from now; whoever runs the final interview needs to fill an empty seat on the team next week. One thinks in the abstract, the other thinks about the backlog sitting in front of them.
When these two horizons don't communicate enough โ and in a large organization, with several hierarchy layers between whoever decides HR strategy and whoever runs the final technical interview, that happens more easily โ the candidate ends up a bit squeezed in the middle. Measured against a document that nobody in the final interview room wrote, and that nobody in that room is really using to decide. No one needs to act in bad faith for this to happen โ if anything, the bad-faith version would probably be easier to spot and avoid. The real version is subtler, because everyone in the room is acting in good faith, and the misalignment happens anyway.
The signal worth reading in advance
When you're asked for a pile of skills that don't easily fit in the same role โ deep backend and deep frontend and SEO and analytics and experimentation, all at "senior" level, all within the same interview hour โ the problem isn't how much you know. It's more that whoever asks for all of it, together, at the same depth, likely hasn't fully decided what they actually want from that role โ often without even realizing it. And if they haven't decided before offering it to you, that misalignment doesn't vanish the day you sign: you find it waiting mid-week, in the form of two people asking for different priorities, neither one really wrong from their own vantage point.
There's also something simpler, almost trivial, that says a lot about how thought-through a process is: reading the CV before the technical interview shouldn't be optional. If my CV clearly states I've never dealt with a certain kind of problem, asking me to go deep on it doesn't measure my preparation so much as it measures how long it takes the interviewer to realize it during the call โ instead of five minutes earlier, by reading a document I sent specifically so it would be read.
The questions to ask before finding out the hard way
Three questions, asked in the first call, help surface the gap before it becomes your problem:
- Who actually decides my day-to-day backlog โ the person who just described the role to me, or someone else not in this room?
- What should I have shipped in the first 90 days, and who will judge whether I did?
- Is this a new position or a replacement โ and if it's a replacement, what did the person before me actually spend their time on?
If the answers to these three questions come from different people, with different priorities, that's not necessarily a dealbreaker yet โ but it's useful information to have before, not after.
Why sometimes it's better to just not go there
Not every internal conflict is a reason to turn down an offer โ every organization has some, and a bit of friction between strategy and operations is normal, almost healthy. It becomes a real warning sign when that conflict shows up in the selection process itself, before you're even inside: if nobody can give you a coherent answer, at interview stage, about what you'll actually be doing, it's likely that incoherence isn't a recruiting hiccup but the normal way that organization runs. If that's the case, better to know it before signing than to discover it three months in, when your direct manager and your "functional" counterpart ask for two different things in the same week, and it's on you to decide who to disappoint.
FAQ
How do I tell a "tough but fair" interview from one measuring an internal conflict?
A tough but fair interview goes deep on the areas the posting declared central. An interview measuring an internal conflict goes deep on marginal or absent areas, leaving behind the ones the posting presented as the core of the role โ that's where the gap between strategy and operations shows.
If I notice this pattern during the process, do I have to withdraw?
No, but it's worth making it explicit: ask directly, in a later round, who decides day-to-day priorities and how disagreements between the two functions get resolved. A clear, coherent answer is a good sign even if the conflict exists; the absence of a clear answer is a somewhat worse one.
Are large, well-structured companies immune to this?
Not necessarily โ if anything, the more hierarchy layers between whoever writes the posting and whoever runs the final interview, the more room there is for the gap to open without anyone noticing. Company size doesn't guarantee internal coherence, it's mostly a more polished-looking selection process.
If you're building a hybrid role at your company and want the posting and the interview to tell the same story โ before a sharp candidate figures it out for you โ this is exactly the kind of organizational misalignment I help untangle as a Fractional CTO: let's talk.
Related articles
- The worst bug does not break the feature. It breaks the view26 tools connected and working in production, the dashboard showed zero. The bug had been there for months for another product too, and nobody had seen it because whoever could notice had admin permissions.
- The legal chatbot that thought it was a record shopAn anti-hallucination guardrail written for e-commerce, applied to every tenant of the engine, made a legal assistant refuse a question about an โฌ864,000 public project. Why guardrails are domain code.
- How I Actually Use AI'How do you use AI in your work?' almost always gets a thirty-second answer that is a slogan. This is the long version: what I actually use it for, where I stop trusting it, and what really changes when producing costs almost nothing.