Why the most capable professionals are often the hardest to hire — and what we’re all missing because of it.
The question that stopped me cold
I was sitting in a job interview. We were somewhere near Glostrup. The recruiter looked up from her notes and asked: “If your car breaks down, how will you get here?”
I answered. Calmly. Taxi. Trains. Working from home if infrastructure collapses entirely. The recruiter nodded and followed up: “But what if the buses don’t run either?”
I’ve been attending interviews for a long time. Freelance assignments. Permanent positions. I’ve learned to handle the unexpected question. But I still find myself sitting in the car afterwards, asking the same question I always ask: why?
Not why did they ask it. But why, when I came prepared to talk about two decades of real, hard-won expertise, were we talking about public transport?
If you’ve seen the short comedy sketch called “The Expert” on YouTube, you’ll recognise the feeling immediately. Anderson — the engineer in the room — is asked to draw seven red lines, all strictly perpendicular, some with green ink, and one transparent. He tries, patiently and precisely, to explain why this is not possible. Nobody listens. The task has been set. He is the expert. Surely he can figure it out.
It has nearly 25 million views. Because every technical professional who has ever sat in a meeting like that recognises Anderson instantly. And every time I leave an interview where we talked about commuting logistics instead of two decades of Linux, mainframes, and complex project delivery — I feel like Anderson.
What my CV actually says
I know what my CV looks like to the untrained eye. A lot of different assignments. Different industries. Different technologies. Short stints. Long stints. No obvious ladder going upward in a straight line.
To a recruiter scanning for stability, it can look like someone who couldn’t settle. Restless. Maybe difficult. A risk.
But here’s what it actually is: every single one of those assignments represents someone — a manager, a client, a company — deciding that I was the right person to send. Not a team. But me, specifically!
Because there was a problem that needed solving, and they needed someone who could walk in, figure out what the problem actually was, and fix it.
I wasn’t jumping around. I was being deployed.
I only fully understood this recently — after a recruiter gently pointed out that my CV showed “a lot of different assignments.” They meant it as a concern. I didn’t know what they were talking about at first. Now I do. They were looking at a map and expecting a staircase.
The sticky note on the desk
I joined IBM around Y2K. Linux was emerging fast, and I happened to be one of the few people in Denmark working with Linux and Open Source full time. IBM placed me in their Mainframe department — people who had been in the industry since the first PCs arrived in the country. They knew mainframes inside out. They knew very little about Linux.
So an unusual thing happened. I taught them. And they taught me. I learned z/VM, z/OS, fibre channels, LPARs, DASD storage. They learned Linux. We travelled Europe together — Böblingen, Frankfurt, Marseille, London — running proof-of-concept sessions, demonstrations, knowledge transfers. I was in my early thirties, teaching people with three decades of experience.
But here’s the part that shaped how I work to this day. My manager had a particular style of assigning tasks. A typical week looked like this:
“When are you coming into the office?”
“This week is Marseille. Next week Monday is customer A, Tuesday is customer B. Wednesday I’m free — is there something you need?”
“No, no. If we find time we can have a coffee.”
“Sure. See you Wednesday.”
Wednesday comes. My manager is busy. But there’s a note on the desk: “Something with Linux. Call customer XYZ. Ask for [name].”
No brief. No scope. No definition of done. Just a name and a phone number.
That was my assignment. For a very long time.
What that note represented was total trust. My manager couldn’t evaluate my work — he didn’t know Linux and Open Source well enough. He trusted me to understand the problem, develop the solution, and deliver. If I needed help, I had access to 300,000 IBM colleagues. Some of the best technical minds in the world. Redbook authors. R&D engineers. Lab researchers. I knew many of them personally, because I had done the work to build those relationships.
Failure was not an option. Not because anyone said so. But because the customer called me specifically. The expert.
And that really means something.
The cruelty of invisible expertise
The issue with being genuinely good at something is, that the proof disappears!
When you are the expert in the room, problems get solved cleanly. The customer sees an issue resolved. The manager’s sticky note gets handled. Nobody sees the accumulated pattern recognition that told you where to look first. Nobody sees the network you spent years building so you could call the right person at 4pm on a Friday. Nobody sees the hours of thinking before any action was taken.
The person who struggled and barely made it has a better story to tell in an interview. They overcame something visible. Whereas you just… solved it. Because that’s what you do.
The better you are, the less dramatic the story sounds.
There is an old story — it appears in print as far back as 1907 — about an expert machinist called back to fix a factory machine that nobody else could repair. He looks at it, taps it once with a hammer, and it runs. The bill he sends is substantial. The factory owner demands an itemised invoice. It arrives:
To tapping machine with hammer… £0 10s.
To knowing where to tap it………… £10 0s.
The story has survived for over a century because it captures something true. The tap costs nothing. The knowledge of where to tap is everything. And to the person watching from outside, all they saw was a man tap a machine with a hammer.
That is what invisible expertise looks like from the outside. A problem, then no problem. Clean. Effortless. Unremarkable. The years of accumulated knowledge that made it effortless? Those don’t appear on any invoice — and they certainly don’t appear on a CV.
And here is where Anderson’s problem and mine converge. In the sketch, the managers are not stupid — they simply have no framework for understanding the constraints the expert is describing. In an interview, the recruiter is not careless — they simply have no framework for reading a career that was built on trust and deployment rather than titles and tenure.
The expert is in the room. But the room wasn’t built for them.
The definition that changes everything
PMI defines a project as “a temporary endeavour undertaken to create a unique product or service.”
Unique. By definition.
So why do job postings for project managers ask for five years of experience in a specific sector, or a proven track record running the same type of project repeatedly? They are hiring for repetition in a discipline that is, by its own official definition, non-repeatable.
David Epstein, in his book Range, makes the case that in complex, ambiguous environments — exactly the kind of environment a project creates — generalists consistently outperform specialists.
People who have navigated variety develop something that repetition cannot build: the ability to recognise patterns across contexts, to transfer knowledge from one domain to another, to stay calm when the situation has no precedent.
Is it more valuable to have managed 100 identical projects, or 100 different ones? Across industries. Across technologies. Across teams and cultures and organizational structures?
According to the very definition of what a project is — the answer should be obvious.
And yet. The task has been set. Seven red lines. All perpendicular.
What I’ve stopped trying to explain — and what I will now say instead
I used to leave interviews frustrated. Not at the questions about buses and cars — those I can handle. But at the gap between what I came prepared to talk about, and what we actually talked about.
I’ve realised that the gap is structural. The hiring process was designed to evaluate a certain kind of career — the ladder, the linear progression, the deepening specialisation in one area. It is genuinely not equipped to read a CV that looks like a map instead of a staircase.
That’s not anyone’s fault. But it is everyone’s loss.
What I will start doing is saying it plainly, early in the conversation:
“I should mention — my CV looks like someone who moved around a lot. What it actually shows is a career built on being sent in to fix things. Every assignment is a completion, not a departure. If that’s the kind of experience you’re looking for, we should have a good conversation.”
Some interviewers may light up when they hear that. Those will be the right conversations.
Others may nod politely and ask about my commute.
What they both are actually looking at is someone who gets called by name. Someone their manager trusted with a sticky note and no instructions. Someone for whom failure was never an option — not because the rules said so, but because the customer was counting on them — and, what is more important, because of the character of this person.
Anderson would understand.
If this resonates with your experience — as someone who has been on either side of this table — I’d like to hear about it.
And if you haven’t seen “The Expert” yet — watch it. You’ll either laugh because of its absurdity, or ask about the bus.
About the author
Freelance tech lead and Project manager with a background in Enterprise IT – working with people, processes and technology. I’ve spent most of my career being sent somewhere to figure something out — usually with a sticky note as the only brief. I’m still available for that.
