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.
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.â
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.â
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.â
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.
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.
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.
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.
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.
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.
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.
â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.