Based on a LinkedIn post originally published on 12 January 2026
I once went through a multi-stage interview process that became an interesting lesson in organisational alignment—or, more precisely, the absence of it.
The first conversations positioned the opportunity as a leadership role.
The organisation appeared to need someone who could build a function, establish direction and eventually scale a team. The discussion focused on leadership, operating under ambiguity and working across platform and engineering groups.
A subsequent interview with a company director reinforced that understanding. We discussed decision-making, organisational challenges and the responsibilities involved in creating a new capability.
Everything suggested that the organisation was recruiting a leader.
A later interview took an entirely different direction.
It focused on detailed, low-level technical questions more commonly associated with a senior individual-contributor position. The technical conversation itself was interesting, but its purpose came as a surprise.
It became clear that the people involved in the hiring process did not all have the same role in mind.
Two legitimate roles—but not the same role
There is nothing inherently wrong with either requirement.
An organisation may need a deeply hands-on senior engineer who spends most of the working day designing, implementing and troubleshooting technical systems.
It may instead need an engineering leader who builds a team, establishes priorities, creates an operating model, manages stakeholders and remains technically credible without personally implementing every component.
Both roles can be senior. Both can demand substantial technical knowledge. Both can contribute enormous value.
They are nevertheless different jobs.
The distinction affects:
how time is spent;
which outcomes define success;
what candidates should demonstrate;
how performance is evaluated;
what interview questions are appropriate;
and which person is most likely to succeed.
Treating the two roles as interchangeable creates confusion for everyone involved.
What a leadership-first role requires
A leadership-first position may include responsibilities such as:
defining the team’s mission;
recruiting and developing engineers;
establishing ownership and accountability;
setting priorities and roadmaps;
managing performance;
coordinating work across teams;
translating business risk into engineering action;
resolving organisational ambiguity;
and representing the function to senior stakeholders.
Technical depth remains important.
The leader must understand the systems sufficiently to evaluate risks, challenge assumptions, guide decisions and support experienced engineers. The role may also require direct technical involvement during incidents, architectural discussions or the early stages of building a new function.
However, the leader’s principal output is not personal code volume.
The output is a capable organisation that can deliver consistently without depending on the manager to make every technical decision.
What an IC-first role requires
A senior individual contributor is evaluated differently.
The organisation may expect that person to:
design and implement complex systems;
diagnose low-level technical problems;
produce and review code;
make detailed architectural decisions;
improve engineering practices through direct contribution;
mentor other engineers technically;
and act as an escalation point for difficult implementation problems.
This position may carry significant influence without formal people-management responsibility.
A senior IC may shape architecture across several teams and operate at a level comparable with senior management. However, the route to impact remains primarily technical and implementation-focused.
An interview for that role should therefore test current practical fluency in the technologies and problems the engineer will encounter.
Hybrid expectations require exceptional clarity
Some positions genuinely combine leadership and hands-on engineering.
This is common when a function is new or when a team is still small. A leader may initially design the architecture, establish tooling, implement foundational components and recruit the engineers who will eventually own them.
That model can work, but only if the balance is explicit.
Statements such as “We need someone strategic who is also hands-on” are not precise enough.
Candidates need to understand:
How many people currently exist in the team?
Are there approved positions to recruit?
How much time should be spent implementing?
Which technologies require current expertise?
Is the leader expected to participate in an on-call rotation?
Who owns the roadmap?
Who makes detailed technical decisions?
How will the balance change as the team grows?
Which outcomes matter during the first six and twelve months?
Without these answers, “hybrid” can become a way of combining two full-time jobs into one ambiguous position.
The interview process exposed the disconnect
During the technical interview, I addressed the issue openly.
I explained that if the organisation needed a senior individual contributor operating daily at a detailed technical level, I was not the correct candidate for that particular requirement.
If it needed a leader to build and scale a team—while retaining the space to re-immerse technically where necessary—that was much closer to where I could add value.
This was not an attempt to avoid technical accountability.
It was an attempt to define the job honestly.
The interviewer responded constructively and acknowledged that the expectations should have been aligned earlier.
That openness prevented the conversation from becoming defensive. It also transformed an unexpected interview into a useful discussion about what the organisation actually needed.
Interviews evaluate organisations too
Interviews are normally described as mechanisms for evaluating candidates.
They also reveal a great deal about the company.
A candidate can observe:
whether interviewers describe the same priorities;
whether responsibilities are understood consistently;
whether the hiring manager and technical team agree;
whether success criteria are clear;
whether the position solves a recognised organisational problem;
and whether the interview questions relate to the advertised work.
Contradictions do not automatically mean that an organisation is dysfunctional. Roles evolve, teams disagree and requirements sometimes change during recruitment.
The important question is whether the organisation recognises and resolves those contradictions.
If different interviewers are evaluating candidates for different jobs, the resulting hiring decision becomes unreliable. A strong candidate for the intended role may be rejected for failing an assessment designed for another role.
Alternatively, someone may be hired successfully and discover after joining that the actual expectations bear little resemblance to the opportunity described during recruitment.
The cost of an undefined role
Role ambiguity creates costs long before a person is hired.
Recruiters search for the wrong profiles. Interviewers spend time assessing irrelevant capabilities. Candidates prepare for expectations that later change. Decision-makers receive inconsistent feedback.
The cost becomes greater after employment begins.
An engineering leader hired to build a team may instead be expected to function as the principal implementer indefinitely. A senior engineer hired for deep technical work may discover that most of the role consists of recruitment, performance management and stakeholder coordination.
Neither person necessarily lacks ability. The organisation selected someone for one set of expectations and evaluated that person against another.
This often produces frustration, underperformance and unnecessary turnover.
Questions candidates should ask
Senior candidates can reduce this risk by asking direct questions early.
Useful questions include:
Is this fundamentally a people-leadership or individual-contributor role?
What percentage of the position is expected to be hands-on?
Does “hands-on” mean coding, architecture, incident support or technical oversight?
What team already exists?
Will I have direct reports from the beginning?
Is there an approved hiring plan?
What should be accomplished during the first six months?
Which outcomes would make the first year successful?
Who currently performs the work this role will own?
Why is the position open?
Do all interviewers share the same understanding of the role?
The answers may evolve, but substantial contradictions are important information.
Organisations should align before interviewing
Companies can prevent much of this confusion by conducting an internal role-alignment exercise before opening recruitment.
The recruiter, hiring manager, technical interviewers and senior stakeholders should agree on:
The problem the position exists to solve.
The principal outcomes expected from the person.
Whether the role is leadership-first, IC-first or genuinely hybrid.
The required level of current implementation fluency.
The team and budget available.
The decision-making authority attached to the position.
The competencies each interview stage will assess.
How interview feedback will connect to the actual responsibilities.
Every interview question should have a clear reason for being asked.
A technical exercise may still be appropriate for a leadership position, but the expected level and purpose should reflect the role. It may test architectural judgement, troubleshooting approach or the ability to guide technical decisions rather than current fluency with a narrow implementation detail.
Honest boundaries are part of seniority
I left the process without frustration or regret.
The experience reinforced an important lesson: seniority includes the ability to recognise where you can add value and where the match is not right.
Trying to perform whatever version of the role each interviewer imagines may keep a process moving, but it does not create a sound employment decision.
Being honest about fit protects both sides.
A candidate should not exaggerate current hands-on fluency merely to pass an interview. An organisation should not describe a leadership opportunity when it actually needs a full-time individual contributor.
The objective is not to “win” the interview.
It is to determine whether the organisation’s need, the role’s real responsibilities and the candidate’s capabilities genuinely align.
Sometimes an interview process answers that question by exposing the fact that the organisation has not yet agreed with itself.
That, too, is valuable information.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment