The hardest CV to screen in technical recruitment is not the sparse one. It is the one that lists fourteen languages, nine frameworks, four cloud providers and three message brokers across a six-year career. Everything the role needs is technically present. Nothing tells you whether the candidate designed any of it or simply attended the stand-ups where it was discussed. Screening polyglot software engineer CVs at scale means learning to read for depth when the document is optimised to display breadth.
This piece works through what actually distinguishes architectural involvement from technology exposure, with an illustrative comparison of two profiles that a keyword parser would score as near-identical.
Why the Polyglot CV Defeats Keyword Matching
Keyword matching asks whether a term is present. The polyglot CV answers yes to everything, which means the screen returns a strong match and tells you nothing you can act on.
Three things drive this. Modern engineering genuinely is polyglot, so long technology lists are often honest. Candidates know screening searches for terms, so listing everything encountered is rational. And generative tooling has made it trivial to produce a technology section that mirrors any job advert exactly. The result is a document class where term presence has no discriminating power at all.
The information you need is still in the document. It is just not in the skills section.
What Architectural Involvement Actually Looks Like in Text
Engineers who have designed systems describe them differently from engineers who have worked inside them. The markers are consistent and they are hard to fabricate, because they require knowing how the work behaves.
Decisions with Alternatives
The strongest single signal. Someone who made an architectural decision remembers what they rejected. "Chose event sourcing for the ledger because we needed a full audit history, having ruled out change-data-capture as too fragile across schema migrations" is a design decision. "Worked with event sourcing" is exposure.
Look for the shape of a trade-off: two options, a constraint that selected between them, and a consequence accepted.
Failure Modes and What Broke
Real systems misbehave, and the people who owned them remember exactly how. Descriptions of the thing that went wrong in production, the limit that was hit, the assumption that turned out to be false. These are close to impossible to invent convincingly and rarely appear in generated text, because a model writing a flattering CV does not volunteer failures.
Scale with Specifics
Not "high-traffic" but "about 4,000 requests per second at peak, which is where the connection pooling broke". Concrete, awkward numbers indicate measurement. Round, tidy numbers indicate estimation or invention.
Ownership Across a Lifecycle
Depth shows in continuity: someone who designed a service, ran it in production, carried the on-call for it, and then had to migrate or deprecate it has seen the full consequence of their decisions. Candidates who describe only the building phase may never have experienced whether their choices were correct.
Influence on Other Engineers
Design documents, technical proposals, review standards, mentoring, and decisions adopted across teams all indicate technical authority beyond the candidate's own keyboard.
Migration and Rewrite Involvement
Legacy migration is where architectural understanding is most visible, because it requires comprehending a system nobody fully documents, and sequencing change without stopping the business. Candidates who have led one tend to describe it in detail, because it was formative.
An Illustrative Comparison
The following two profiles are composites constructed to make the point, not real candidates. Both applied for a senior backend role requiring distributed systems experience, Kubernetes, Go, and event-driven architecture. A keyword screen rates them as equivalent matches.
Candidate A
Skills section lists nineteen items including Go, Kubernetes, Kafka, Postgres, Redis, Terraform, gRPC, Python, Java, React, Docker, AWS, GCP, RabbitMQ and Elasticsearch. Role descriptions read: "Worked on microservices using Go and Kubernetes." "Involved in event-driven architecture with Kafka." "Contributed to CI/CD pipelines." "Collaborated with cross-functional teams to deliver features on time." Three roles in five years, each described in four similar bullets.
Evidence assessment: every required capability sits at tier one or two, mentioned, sometimes anchored to a role, never applied in a described way. No decisions, no constraints, no scale, no failures, no outcomes. This is not evidence that the candidate lacks depth. It is evidence that the document contains none, which is a different finding and should be handled differently.
Candidate B
Skills section lists seven items. Role descriptions include: "Split a monolithic order service into three bounded contexts over eight months, sequencing the extraction so the payment path moved last because it carried the reconciliation logic." "Moved inter-service messaging from RabbitMQ to Kafka when we needed replay for the reconciliation job; the migration was harder than expected because our consumers assumed at-most-once delivery." "Ran the on-call rotation for these services; the recurring incident was consumer lag during nightly batch, fixed by partitioning on customer rather than order." "Wrote the design proposal the platform team adopted for service boundaries."
Evidence assessment: distributed systems and event-driven architecture sit at tier five, applied, with constraints, scale, failures and consequences. Kubernetes appears but is not evidenced to the same depth, which is a real and specific gap. Go is evidenced in context.
What the Screen Should Conclude
Not "B is better". The useful output is more precise than a ranking:
- Candidate B has strongly evidenced distributed systems and event-driven architecture, with a specific gap on Kubernetes depth that should be probed.
- Candidate A's document evidences nothing about depth in any required area. The appropriate action is a short structured probe, not rejection, because a terse CV is not proof of shallow experience.
That distinction, between "evidence absent" and "candidate unsuitable", is the one that stops evidence-based screening from becoming a filter on writing ability. Candidate A may be excellent. The screen's honest position is that it cannot tell, and that is a finding worth routing rather than resolving silently.
The Anti-Signals Worth Encoding
A few patterns reliably indicate breadth without depth, and they are cheap to check.
- Version-free technology lists. Practitioners tend to remember which major version caused them pain. Lists with no version detail anywhere are usually inventories rather than experience.
- Hedging language. "Familiar with", "exposure to", "knowledge of" are honest signals of shallowness and should be scored as such rather than matched as present.
- Implausible density against tenure. Four cloud providers at production depth in three years is arithmetic, not judgement.
- Uniform bullet structure across a long career. Real memory is uneven; recent work is described in more detail than work from eight years ago.
- Collective attribution throughout. A document that never says "I" in a technical context may be describing a team's work rather than the candidate's contribution.
Screening This at Volume
The workflow that holds up when four hundred applications arrive for one senior role:
- Reduce the requirement list honestly. Most senior backend adverts list twelve technologies where two or three determine success. Identify those and set a minimum evidence tier for each.
- Stop scoring breadth entirely. A long skills list should accumulate no points. If anything, flag implausible density for a closer look.
- Extract evidence per critical requirement across the whole cohort, and review one requirement at a time rather than one candidate at a time. It holds the standard still and it is much faster.
- Separate "not evidenced" from "evidenced as shallow" in the output. They lead to different actions.
- Generate probes from the gaps and hand them to whoever runs the technical screen, so the first fifteen minutes resolves the actual uncertainty rather than covering general ground.
Step five is where the time comes back. A technical screener who opens with "tell me about the consumer lag problem and how you diagnosed it" learns more in five minutes than forty minutes of general architecture discussion produces.
Frequently Asked Questions
How Do You Assess Depth Versus Breadth on a Developer CV?
Ignore the skills list and read the role descriptions for decisions with rejected alternatives, described failure modes, specific scale figures, lifecycle ownership including on-call, and influence on other engineers. Those markers indicate design involvement. Technology names indicate only presence in an environment where the technology existed.
Is a Long Technology List a Red Flag?
Not by itself, since modern engineering genuinely spans many tools. It becomes a signal when the breadth is implausible against tenure, when nothing in the document is described in depth, or when the list closely mirrors the job advert while the role descriptions stay generic.
Should Terse CVs Be Rejected Under Evidence-Based Screening?
No, and a screening design that does this is broken. A terse CV means evidence is absent from the document, not that experience is absent from the candidate. The correct routing is a short structured probe on the critical requirements. Excellent engineers frequently write minimal CVs.
How Does This Handle Candidates from Non-Traditional Backgrounds?
Generally better than title or pedigree matching does. Evidence markers appear wherever real work was done, so a self-taught engineer who describes owning a production system with real constraints evidences depth that a credential-based screen would miss entirely.
Can This Be Automated, or Does It Need a Senior Engineer to Read Everything?
The extraction and classification can be automated: locating the relevant passages, identifying decision language, scale figures and failure descriptions, and assigning an evidence tier per requirement. The judgement stays with a human, who now reviews structured evidence rather than hunting through prose. That is what makes senior engineering review viable at volume.
The Point of All This
Technical recruitment leads are not short of matching candidates. They are short of confidence that a matching candidate can do the work. That confidence comes from evidence of decisions, constraints and consequences, none of which a skills section contains.
CVSense scores the context around a claim rather than its presence, separates absent evidence from weak evidence, and shows the source passage behind every assessment so a technical reviewer can check the reasoning in seconds. On a polyglot CV, that is the difference between a shortlist of people who listed the right things and a shortlist of people who built them.
Sources
Chartered Institute of Personnel and Development.
https://www.cipd.org/uk/
Information Commissioner's Office. Guidance on AI and Data Protection.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
National Careers Service. CV Sections and Advice.
https://nationalcareers.service.gov.uk/careers-advice/cv-sections
InsightCircle
