Technical Hiring
Public Technical Evidence for Recruiters: What It Can and Cannot Tell You
CVs and LinkedIn profiles summarize career history, roles, experience, and stated skills. Public technical work can add another layer: a repository, an answer, a notebook, or a post you can actually inspect. That layer is useful when it is relevant to the role and described honestly. It is not a verdict on skill, seniority, or whether you should make contact.
Public technical evidence is that layer. This article explains what it is, what it can reasonably support, what it cannot prove, and how to record uncertainty without turning public activity into a score.
This is not a sourcing tutorial, a GitHub search guide, or a field-by-field profile walkthrough. For the workflow before outreach, use How to Research Technical Candidates Before Outreach. This page owns interpretation: what the evidence means, what it does not mean, and how human judgement stays in control.
Better evidence. Human judgement.
What public technical evidence is
Public technical evidence is publicly available technical work that you can reasonably tie to a person, used as research context for a role. It includes artefacts such as repositories and projects, open-source contributions, pull requests and issue discussions, answers, notebooks, technical writing, and public project documentation.
It is evidence for a claim you are checking. It is not a complete career, a quality rating, or a hire decision.
Three conditions have to hold before you treat something as public technical evidence:
- It is public technical work, not only a job title or a skills list.
- You can reasonably tie it to the person you are researching.
- You are using it to examine a specific question about the role - not to rank how visible someone is.
If identity is uncertain - a common name, a colliding handle, a personal site that may belong to someone else - stop. Identity doubt is a precondition. It is not a comment on skill.
CVs and LinkedIn profiles remain useful for career history: employers, tenure, and stated experience. They are complementary context. They are not public technical evidence by default. For the channel argument, see why great developers are invisible on LinkedIn.
Sources vs evidence types
Keep where you looked separate from what you found.
Sources are platforms. The relevant examples here match the public platforms Sonar Air discusses and supports: GitHub, Stack Overflow, Hacker News, Kaggle, and technical blogs or personal sites. See supported data sources and minimization for that list. LinkedIn and CVs stay in the career-history column.
Evidence types are artefacts: repositories and projects, open-source contributions, pull requests and issue threads, answers and discussions, notebooks, technical writing, and public project documentation.
A repository is not a platform. An answer is not a source. You might find several evidence types on one source, or the same kind of evidence across more than one source. Do not score people by how many platforms they use.
This page does not rebuild a full source-to-evidence map. Keep the distinction, then interpret what you found against a claim.
Evidence is always about a claim
Interpretation starts with a claim you can write in one sentence. Not "are they good?" Not "are they senior?" A claim looks like:
"There is public evidence of recent TypeScript API work."
Every finding is an outcome against that claim.
Evidence found. Public technical work exists, can reasonably be tied to the person, and is relevant to the claim. When that work actually helps the claim, say it is supporting evidence for that claim. That is a modifier of evidence found, not a fourth outcome.
No public evidence found. Research did not find useful public technical evidence for the claim. This is neutral. It must never mean weak, junior, unskilled, not worth contacting, or reject.
Cannot conclude. Something exists, but it is too thin, ambiguous, contradictory, or off-role to support the claim.
Evidence is interpreted against a claim. Unknown is a valid result.
If you cannot name the claim, you are not interpreting evidence. You are browsing.
What public technical evidence can support
Public work can support modest, specific statements. It cannot upgrade those statements into quality, seniority, or fit.
| Category | Reasonable statement | Caveat | Do not infer |
|---|---|---|---|
| Technology in public work | "Public work uses TypeScript APIs." | Tags and language bars are incomplete | Depth, production mastery, a complete résumé stack |
| Recent public activity | "There is recent public activity in this area." | Public recency is not the same as currently shipping | Availability or current employer stack |
| Type of project | "This looks like a maintained API service, not a tutorial clone." | Read the README or thread, not only the name | They run this in production |
| Ownership vs drive-by | "They appear to maintain this repo" or "this looks like a small contribution." | Authorship of every file is unverified | They built the whole system |
| Repeated vs one-off | "There is repeated public work in this area." | Volume can be noise | Seniority or productivity |
| Public technical communication | "They explain trade-offs clearly in this thread or post." | Public OSS norms differ from workplaces | Team fit or leadership |
| Documentation habits | "The README explains setup and constraints." | Documentation is optional and uneven | They will document internally |
| Contribution context | "The pull request is a docs fix, not a feature." | You need the actual change | Fame of the project equals their skill |
| Role relevance | "This artefact is relevant to our API requirement." | Relevance is role-specific | Perfect fit |
| Visible breadth or depth in the public layer | "Public evidence is concentrated in PostgreSQL answers." | Only the public slice is visible | Whole-career breadth |
When the artefact lives on GitHub, reading a GitHub profile as a recruitment signal is the field-level guide. When it is Q&A, use how to read a Stack Overflow profile like a hiring signal. This page stays with the claim, not the interface.
What public work may support, and what it cannot prove. Not a score.
What it cannot prove
"Cannot prove" does not mean "contains zero information." A maintained API repository can still justify a closer look. It still does not prove the person will succeed on your team.
Public technical evidence cannot prove:
| Topic | Why the public layer is not enough |
|---|---|
| Overall engineering quality | You are reading a slice of self-chosen public work, not a graded career |
| Seniority in private or professional systems | Side projects and public volume do not map to staff-level scope behind a firewall |
| Actual job performance | Public repos do not show your constraints, priorities, or codebase |
| Team fit | Open-source manners are not your team's working agreement |
| Leadership quality | Maintainer status or a popular post is not people leadership at work |
| Workplace communication | A clear README is not evidence of how someone communicates with a product manager |
| Motivation | Activity shows public engagement with technical work, not drive in your role |
| Salary expectations | Public technical work does not reveal salary expectations. |
| Availability or job-search intent | Public activity does not reliably indicate whether someone is open to a new role. |
| Authorship of all work in a repository | A repository may include work from multiple contributors, generated code, or reused code, so authorship needs context. |
| Success in closed-source environments | Private professional work is often invisible |
For GitHub-specific limits, see what GitHub can and cannot tell a recruiter. Public technical evidence should not replace interviews. It can make the first conversation more specific. Screening, conversation, and human judgement still cover what public work cannot see. Where assistive AI is involved, the same boundary holds: evidence ends and human judgement begins.
Missing, thin, contradictory, and irrelevant evidence
Not every gap is the same. Name the type, then stop inferring skill from it.
| Gap type | What it means | What it does not mean |
|---|---|---|
| Absent | No useful public technical evidence found for this claim | Weak, junior, unskilled, or not worth contacting |
| Thin | Something exists, but there is too little context to support the claim | Automatic reject |
| Contradictory | Public artefacts point in different directions | A score will resolve it; ask the next question |
| Irrelevant | The work is real, but it does not speak to this role | Negative evidence against the person |
Treat absence as incomplete evidence. Treat a tutorial fork as thin or irrelevant, depending on the claim. Treat a Kubernetes bio plus only JavaScript boilerplate as contradiction to investigate, not as a hidden ranking penalty.
Unknown is a valid result
Unknown is an honest label, not a failed search.
You should expect unknown on seniority in private systems, job performance, team fit, motivation, salary, availability, and most closed-source work. Writing "unknown" keeps a gap from quietly becoming a rejection.
"No public evidence found" is also unknown about the claim, with a more precise research result: you looked, and the public layer did not help. Continue with the CV, a referral, or a hiring-manager question. Do not invent a public-work compliment to cover the hole.
Stronger vs thinner support for a specific claim
When evidence is better or worse, say stronger support for this claim or thinner support for this claim. Do not say stronger candidate, weaker candidate, or a higher public-visibility rank.
Potentially stronger support for a claim: repeated role-relevant contributions; an owned project with readable context; more than one relevant artefact across time.
Potentially thinner support for a claim: a one-off contribution; a fork without changes; a star or follow; an old isolated artefact.
Stars, followers, commit totals, contribution graphs, and reputation counters measure attention or volume in a community. They are not a quality score. Read the artefact. Do not rank people by the counter.
Examples of careful interpretation
These four examples are labelled illustrative composites. They are not real candidates, customers, or outcomes.
TypeScript APIs
Claim: There is public evidence of recent TypeScript API work.
Evidence: The person appears to maintain a TypeScript backend repository with recent commits and documented API architecture.
Reasonable: "There is public evidence of recent TypeScript backend work."
Not reasonable: "They are a senior backend engineer."
No useful GitHub activity
Claim: There is useful public GitHub evidence for this role.
Evidence: No repositories, contributions, or discussions you can use.
Reasonable: "No useful public GitHub evidence found."
Not reasonable: "They are not technically strong."
If another source has useful evidence, record that as a separate claim. GitHub silence is not a score for the whole person.
Famous repository, small contribution
Claim: They have substantial public ownership in project X.
Evidence: A one-line documentation or typo change on a widely starred repository.
Reasonable: "They contributed a small documentation or typo change to X."
Not reasonable: "They are a core contributor to X."
Thin GitHub, concentrated Stack Overflow
Claim: There is public evidence of PostgreSQL work.
Evidence: GitHub shows one old side project. Stack Overflow shows years of focused answers in PostgreSQL.
Reasonable: "GitHub evidence is thin; there is public evidence of concentrated PostgreSQL Q&A."
Not reasonable: "Stack Overflow reputation proves seniority." Reputation is volume in a community. Tag-level depth can support a claim about public Q&A. It still cannot prove level.
Common interpretation mistakes
Treating stars, followers, commits, or reputation as quality. Those counters are easy to scan and easy to misread.
Treating no public GitHub as weakness. Professional engineering work may be private or covered by employer restrictions, so a quiet GitHub profile is not evidence of weakness.
Reading one artefact as a whole career. One repository, one notebook, or one popular answer is a slice.
Upgrading a drive-by contribution into ownership. Always read the change.
Assuming public activity means they want a job. Activity is not intent.
Treating public communication as workplace fit. A clear issue thread is not evidence of how someone works with your team.
Browsing without a claim. If you cannot write the sentence you are checking, you will over-read whatever is visible.
Praising work you did not read. If you cannot name the artefact, do not put it in outreach.
How to write evidence notes
Use notes, not a score. Every line can be "yes," "no," or "unknown." Do not add percentages, red/yellow/green ratings, or hire/no-hire rules.
Notes for interpretation, not a candidate rating.
Write:
- What I found
- Why it might be relevant
- What I cannot verify
- What remains unknown
- What question to ask next
The next question is for a conversation, a hiring manager, or another source - not for a hidden ranking formula. If the public layer is empty, the next question might be about the CV, a referral, or whether you still have an honest reason to write.
How Sonar Air represents evidence
Manual interpretation works for a handful of names. It gets expensive when you repeat the same source-hopping across many technical roles.
Sonar Air is a technical evidence research and candidate discovery platform for recruiters. It brings role-relevant public technical evidence together from GitHub, Stack Overflow, Hacker News, Kaggle, and technical blogs so you can review the underlying context yourself. Recruiters work with role context and open matches with links to the public work behind them. You decide what the evidence means.
Sonar Air does not score candidates and does not make automated hiring decisions. Language models, where they are enabled, may help with summaries and queries. They are not used to score or rank people.
Frequently asked questions
What is public technical evidence?
Public technical evidence is publicly available technical work you can reasonably tie to a person - projects, contributions, answers, notebooks, writing - used as research context for a role. It is not a score or a hire decision.
What can public technical work tell a recruiter?
It can support modest claims: technologies that appear in public work, recent public activity, project shape, likely ownership versus a drive-by change, and how someone explains work in public. It cannot prove overall quality.
What can GitHub tell a recruiter?
GitHub can show public repositories, contributions, and discussions. That can support claims about public work. It cannot prove seniority, performance, or interest in a new job. For GitHub-specific reading, use the GitHub profile and GitHub sourcing guides linked above.
Does no GitHub activity mean someone is weak?
No. "No useful public GitHub evidence found" means the public GitHub layer was empty or not useful. Professional engineering work may be private or covered by employer restrictions, so a quiet GitHub profile is not evidence of weakness.
Can public technical evidence prove seniority?
No. Public activity does not map to seniority in private systems. Treat seniority as unknown unless you have other process evidence.
Are stars and commit counts useful hiring signals?
As attention or volume, sometimes. As proof of skill, seniority, or hire-readiness, no. Read the artefact. Do not rank people by counters.
Should public technical evidence replace interviews?
No. It can support a closer look and a more specific first conversation. Interviews, references, and human judgement still decide what you cannot see in public.
Final takeaway
Public technical evidence can support a closer look at role-relevant work. It cannot prove quality, seniority, or a hire. Interpret it against a claim. Record what you found, what you cannot verify, and what remains unknown. Missing evidence is unknown, not a rejection.
You stay in control of what the evidence means and what to do next.
If you want that evidence layer gathered against a role profile for you to review, learn how Sonar Air works.
Sonar Air team
Writes about evidence-based technical recruiting and multi-platform developer sourcing at Sonar Air.
About Sonar AirMore from the blog
More articles on technical hiring are coming soon.
Back to blog