When the posting and the interview describe different roles

Direct answer: when a posting describes a hybrid role — a declared split like "60% frontend, 40% backend" — and the final interview spends almost all its time on one side of it, it is rarely bad faith. It is the symptom of an organisation where whoever wrote the posting and whoever decides the day-to-day work are two different people with two different needs. The gap shows up early, though: a hiring process produces four documents, and they do not say the same thing.

TL;DR

Postings for hybrid roles (growth/engineering, product/data, marketing/tech) often declare a clean split — and the final interview sometimes measures only one half of it, in depth.
The posting tells you more through what it worries about than through the percentages it declares.
The technical exercise is almost always the most honest job description in the process: it is written by whoever will judge the work, not by whoever wrote the posting.
The rejection email is a second-hand summary, written by someone who was often not in the room.
The lesson that holds regardless of outcome: what is not written down tends not to exist for whoever evaluates you once you are no longer in front of them.

Four documents, four different truths

A technical hiring process leaves four artefacts behind: the posting, the exercise, the final conversation, and the reply. We almost always read them in order, one at a time, each on its own. Read together they tell a different story — and in boundary roles, where two areas live inside the same position, that story often diverges from the posting's.

Take the recurring case. A growth/engineering posting: inside an engineering team, with a functional line towards marketing, a declared 60/40 split. The mission described in terms of visibility and growth, and among the responsibilities a pre-emptive warning — "without the role sliding into a pure SEO implementation function". Then the final interview takes the exact opposite direction from the one the posting worried about: almost all the time on increasingly deep backend questions, a handful of standard frontend questions closed in minutes, zero questions on the area the role was meant to report to functionally.

It is not an isolated case, nor unkindness from whoever runs it. It is a pattern, and each of the four documents signals it in its own way.

1. The posting: what it avoids matters more than what it promises

These postings are worth reading more carefully than we usually do, because they usually say more than they seem to on a first pass. Two things in particular are worth attention:

What's described as a requirement versus "a plus." Cross-functional skills — SEO, experimentation, analytics, growth — often end up in the "a plus" list, meaning optional, while generic technical experience ("having owned end-to-end applications") stays the core of the profile they're after. The declared split can be honest on paper and still not reflect what actually gets measured.
What the posting explicitly worries about preventing. A preemptive caveat like "this role shouldn't become just X" is a hint that someone inside the company has already seen that risk materialize at least once. It's often more informative than the percentage split itself.

2. The technical exercise: the most honest job description in the process

A good way to anticipate the gap between posting and reality is to look closely at the technical exercise assigned during the process, if there is one — it's often prepared by whoever will evaluate you operationally, not by whoever wrote the posting, which tends to make it more honest.

Well-designed exercises of this kind usually pose a few recurring design dilemmas, regardless of the company: the response contract is declared fixed, while the internal design is left open — the shape of the data you expose is sacred, how you produce it is your own business. Part of the task is deciding what not to put in a response: a reference pointing to a non-existent record — sent with empty fields, excluded, just logged? And the dataset size is almost always declared arbitrary, which rules out any shortcut relying on a fixed order.

A couple of signals, among many possible ones, tend to separate careful work from work that was simply generated by a tool: it's common, for instance, for an undocumented library update to break the build on the first try — whoever checks the dependency tree instead of trusting memory notices within minutes, not hours. And it's common, rereading one's own code calmly instead of considering it done the moment it turns green, to find a couple of real bugs — small contradictions between what the code does and what it claims to do — worth reproducing concretely before fixing, not just patching on the fly.

When an exercise's stack is lopsided relative to the split declared in the posting — built entirely around one side of the stack, say, with the other side bolted on — that's an early signal, not a coincidence.

3. The final interview: where the gap becomes visible

A pattern worth recognizing: when the final interview heavily skews its time toward one side of the declared role, the most revealing moment usually isn't a wrong answer — it's a reasonable question, asked of the wrong person. A legitimate systems question for a senior role, that nobody had promised to test for a profile declared mostly on something else entirely. Answering honestly, admitting a limit when it surfaces, is almost never the mistake — it's the moment it becomes visible that the conversation is measuring something different from what you were brought in for.

Another recurring signal: a question about using AI at work, dropped in early almost as a rite of passage, and never revisited — while the rest of the hour goes elsewhere. (It is a question that deserves more room than an hour-long interview leaves: I wrote about it separately.)

4. The rejection email: a second-hand summary

Rejection emails, in cases like this, tend to sound alike: they cite, generically, wanting "more depth across both areas" — hard to measure, when one of the two areas got four standard questions and zero follow-up. They also often mention a missing detailed breakdown of your own technical choices — worth comparing against how much was actually possible, or asked for, live during the interview itself.

It's not useful to read these emails with resentment. It's more useful to read them for what they are: a summary compiled by someone who wasn't necessarily in the room for the whole conversation, based on the partial notes of someone who was.

The thing that holds regardless of outcome

There's a part of situations like this that's on the candidate, not the company, and it's probably the most useful thing to take away. It's common, while preparing a technical exercise, to write a section covering your assumptions and design decisions — and then remove it before submitting, to hand the project back exactly as given, moving that content to the oral discussion instead, maybe because the exercise itself promised it would be covered verbally.

That's almost always the wrong call. What isn't written, for whoever is evaluating you when you're no longer in the room, tends to simply not exist. An interview lasts an hour and gets remembered imperfectly; a document stays, gets reread, gets cited in an internal evaluation you're not part of. If a piece of reasoning feels worth saying, it's worth writing down — not just saying out loud, hoping the right moment comes.

Why it happens

This isn't the first time I've noticed this pattern, which is why I gave it a separate, more general analysis: When the interview measures a conflict that isn't yours. The short version: a bridge role 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 that sometimes communicate less than they should. No bad faith is required for the gap to open.

Three questions for the first call

Three questions, asked in the first call, help surface the gap before you invest weeks:

Who actually decides this role's day-to-day backlog?
What's expected to have shipped in the first 90 days?
Is this a new position or a replacement — and if so, what did the person before actually spend their time on?

And a signal worth reading for what it is: the technical exercise, when there is one, is often the most honest job description you'll get — sometimes weeks ahead of the final interview.

Backend, or backend too?

It is the question worth surfacing, tactfully, whenever a role declared hybrid starts being judged on almost one side only. It does not need an accusatory tone: it needs clarity, and it is better obtained before signing than after three months.

For whoever is hiring, the same question turns around: does the posting you published and the exercise you assign describe the same role? If the answer is not obvious, the attentive candidate notices before you do — and the best ones leave without telling you why.

FAQ

How do I tell if a "hybrid" role is real, or just written that way?

Ask in the first call who decides the day-to-day backlog and what you should have shipped in the first 90 days. If the answers only describe one side of the declared split, that's probably the real role — the other side stays more aspirational.

Can a technical exercise really say more than the posting?

Often, yes. The posting is written by whoever wants to hire for a strategic need; the technical exercise is usually prepared by whoever will evaluate you operationally. If the exercise's stack is lopsided relative to the declared split, that's an early signal — not necessarily a coincidence.

Is it worth writing up your decisions even when you know they'll be discussed verbally?

Almost always, yes. An interview gets remembered imperfectly; a document stays and gets reread in an internal evaluation you're not part of. If an explanation feels relevant, better to write it down — not just say it out loud.

If you're figuring out how to structure a hybrid technical role — or want to make sure the posting and the interview tell the same story — this is exactly the kind of organizational misalignment I help untangle as a Fractional CTO: let's talk.