The Most Common “Good CV, Bad Hire” Patterns in Tech – And How to Spot Them Earlier

Introduction: When a great CV doesn’t translate into great code

If you’ve been hiring in tech for a while, you’ll recognise this scenario. On paper, the candidate ticks every box: nice mix of languages, a big name company or two, maybe a “lead” title, and a neat list of projects. Interviews feel smooth. Everyone gives a cautious thumbs up.

Then the real work starts. Suddenly, the person who seemed “senior” cannot work independently, pushes half finished code, or freezes the moment requirements aren’t fully clear. The CV wasn’t wrong—but it wasn’t telling the full story.

This gap between paper credentials and on the job performance is not unique to one company. Studies looking at tech hiring pipelines have repeatedly found misalignment between what teams screen for (titles, tools, brands) and what actually predicts performance in modern software work, such as problem solving, collaboration, and learning speed.

The good news is that “good CV, bad hire” is not random. There are repeatable patterns that hiring teams can learn to spot much earlier.

Note: Written based on practical hiring experience in Singapore and Asia by Base Camp Recruitment.

Pattern 1: Big brands, small scope

One of the most common patterns is the candidate from a famous tech brand or unicorn, whose actual scope turns out to be quite narrow.

On the CV, “Software Engineer, [Well Known Company]” looks impressive. But inside these organisations, it’s very possible to own a tiny slice of a feature, with heavy support, established patterns, and strong guardrails. That is perfectly fine for their career—but it doesn’t always translate into the more ambiguous, end to end work of a smaller product team or startup.

How to spot it earlier

• Ask: “What exactly were you responsible for? What could break if you did your part badly?”
• Dig for examples that show ownership across the full lifecycle (problem, design, implementation, rollout, maintenance), not just “I wrote code for X module.”
• Use follow up questions: “Who made the final decision?”, “Who handled incidents?”, “Who spoke with stakeholders?”

If the answers consistently suggest a narrow, tightly managed scope, don’t reject them automatically—but calibrate your expectations and the level you’re hiring for.

Pattern 2: Buzzword heavy, fundamentals light

Another red flag is the CV that reads like a tech Twitter feed: Kubernetes, microservices, event driven, AI, serverless, all squeezed into a few lines. It looks current and exciting. But when you dig in, the fundamentals—data structures, debugging, basic security, SQL, version control discipline—are shaky.

Research on novice software engineers has shown that early career developers often over index on tools and under develop transferable problem solving skills, especially when most of their experience comes from short bootcamps or project based coursework.

How to spot it earlier

• In screening calls, ask candidates to explain one system they’ve worked on without naming tools first: focus on the problem, inputs/outputs, constraints.

• In technical interviews, balance framework questions with fundamentals: “How would you track down a production bug you can’t easily reproduce?”, “What trade offs did you make in that design?”

• Give a small design or debugging exercise rather than a pure algorithm test—see how they think with constraints close to your reality.

If tools come first and reasoning comes second, that’s a sign to pause.

Pattern 3: Strong solo coder, weak collaborator

Some candidates genuinely write good code but struggle with the “team sport” side of software. They may be defensive in reviews, disappear for days without updates, or be impatient with juniors and cross functional partners. Over time, this can cost more than a weaker but team oriented engineer.

In many post mortems of failed tech hires, managers mention not technical gaps, but issues like communication, adaptability, and attitude toward feedback as the main cause of mismatch.

How to spot it earlier

• Add one or two behavioural questions focused on collaboration:

‣ “Tell me about a time your pull request received heavy pushback. What happened next?”

‣ “Describe a situation where product or business priorities changed suddenly. How did you respond?”

• Use a pairing session instead of a solo whiteboard: let the candidate work with a potential teammate on a small problem while you observe how they explain, listen, and adjust.
• During debriefs, explicitly separate “technical skill” and “working with others” instead of collapsing them into one score.

You’re not looking for extroverts—you’re looking for people who can disagree constructively and share context.

Pattern 4: Impressive projects that never left the lab

Tech CVs often feature hackathon wins, personal apps, or university projects. These are valuable, but they can create a false sense of “production experience” when none of those projects had real users, real uptime requirements, or real consequences.

Experience from industry hiring shows that performance on academic or toy projects does not always generalise to messy, long running production systems with constraints and legacy code.

How to spot it earlier

• Ask: “Which of your projects had real users depending on it? What broke, and how did you fix it?”
• Probe release and maintenance: “How did you decide it was ready to ship?”, “How did you handle monitoring and incident response?”
• If most of their examples are short lived or never deployed, that’s fine for a junior role—but risky for a “senior” hire expected to handle live systems.

Pattern 5: Coached for interviews, untested for ambiguity

With the amount of interview prep material, templates, and AI tools available now, many candidates arrive extremely polished for standard interview formats. They know how to walk through STAR answers, they’ve practised common LeetCode problems, and their CV has been optimised by ChatGPT or similar tools.

What these tools can’t easily simulate is judgement in ambiguous, incomplete situations—exactly the conditions under which most real work happens.

How to spot it earlier

• Include a short scenario discussion:

‣ “You inherit a legacy service nobody wants to touch. It’s noisy in logs, but stakeholders are nervous about changes. What would you do in your first 30 days?”

• Look for signs of independent thinking, trade off awareness, and stakeholder management—not perfect textbook answers.
• Consider a work sample task that mirrors your actual environment (small design doc, code review exercise) rather than generic puzzles.

Pattern 6: “Senior” title, mid level behaviour

Titles have become very noisy in tech. A “Senior Engineer” in a lean, product centric team may operate like a staff engineer elsewhere, while in some organisations “Senior” simply reflects time served.

A recurring “good CV, bad hire” story is the person hired into a senior or lead role who struggles to operate without constant direction, avoids technical decisions, or cannot coach others.

How to spot it earlier

• Ask for specific examples of leadership, not just “I mentored juniors.” For instance:

‣ “Tell me about a technical decision you led that others initially disagreed with.”

‣ “Describe a change you drove that improved how your team worked.”

• Ask them to critique one of their own past systems: “If you had to redesign it now, what would you do differently and why?”
• During references, focus on scope and influence: “What decisions did they own? Who would come to them for help?”
• If the candidate’s stories always position them as a follower, consider a different level.

Tuning your process to catch these patterns earlier

The aim is not to become cynical about strong CVs. The aim is to adjust your hiring system so that a polished profile triggers better questions, not automatic approval. Research on structured interviews and fairer selection consistently shows that more structure reduces bias and improves prediction of job performance compared to ad hoc, instinct led interviews.

A few practical tweaks:

1. Re write your scorecards

• Move from “years of X, Y, Z” to outcomes and behaviours: ownership, problem solving, production experience, collaboration.
• Rate each dimension separately; don’t let one shiny brand or project overshadow everything else.

2. Change how you read CVs

• Scan for patterns over time (growing scope, varied problems) rather than counting tools.
• Note open questions you’ll probe in the interview instead of quietly assuming.

3. Add one real world work sample

• A short take home aligned with your stack, or a live pairing session on a realistic problem.
• Keep it lightweight and respect candidates’ time, but make sure it tests how they think in your context.

4. Use references for calibration, not character judgement

• Ask previous managers about scope, independence, and collaboration—not whether they “liked” the person.
• Look for consistency between CV, interview, and reference, rather than expecting perfect stories.

Closing thoughts

“Good CV, bad hire” stories are painful because they cost real time, money, and trust within teams. But they’re also valuable data. Each one reveals a blind spot in how we screen, interview, or decide.

In 2026, tech teams in Singapore and across Asia are hiring under real constraints—tighter budgets, hybrid setups, and expectations that keep changing. So a big-name company on the CV or a long list of tools isn’t enough by itself. The better question is: what’s the CV not telling us, and what should we ask to find out?

When you adjust your process to look beyond the surface—to scope, behaviours, and real world problem solving—the gap between “good on paper” and “good in the role” starts to close. That’s when strong CVs finally line up with strong hires.