Publiek technisch bewijs voor recruiters: wat het wel en niet kan vertellen

Cv's en LinkedIn-profielen vatten carrièregeschiedenis, rollen, ervaring en genoemde skills samen. Publiek technisch werk kan een extra laag toevoegen: een repository, een antwoord, een notebook of een post die u daadwerkelijk kunt bekijken. Die laag is nuttig wanneer ze relevant is voor de rol en eerlijk wordt beschreven. Het is geen oordeel over vaardigheid, senioriteit, of over of u contact moet opnemen.

Publiek technisch bewijs is die laag. Dit artikel legt uit wat het is, wat het redelijkerwijs kan ondersteunen, wat het niet kan bewijzen, en hoe u onzekerheid vastlegt zonder publieke activiteit tot een score te maken.

Dit is geen sourcingtutorial, geen GitHub-zoekgids, en geen veld-voor-veld profielwandeling. Voor de workflow vóór outreach gebruikt u Technische kandidaten onderzoeken vóór outreach. Deze pagina gaat over interpretatie: wat het bewijs betekent, wat het niet betekent, en hoe menselijk oordeel de controle houdt.

Beter bewijs. Menselijk oordeel.

Wat publiek technisch bewijs is

Publiek technisch bewijs is publiek beschikbaar technisch werk dat u redelijkerwijs aan een persoon kunt koppelen, gebruikt als onderzoekscontext voor een rol. Het omvat artefacten zoals repositories en projecten, open-source-bijdragen, pull requests en issuediscussies, antwoorden, notebooks, technisch schrijven, en publieke projectdocumentatie.

Het is bewijs voor een claim die u toetst. Het is geen complete carrière, geen kwaliteitscijfer, en geen aannamebeslissing.

Drie voorwaarden moeten kloppen voordat u iets als publiek technisch bewijs behandelt:

1. Het is publiek technisch werk, niet alleen een functietitel of een skillslijst.
2. U kunt het redelijkerwijs koppelen aan de persoon die u onderzoekt.
3. U gebruikt het om een specifieke vraag over de rol te onderzoeken - niet om te rangschikken hoe zichtbaar iemand is.

Als de identiteit onzeker is - een veelvoorkomende naam, een botsend handle, een persoonlijke site die van iemand anders kan zijn - stop dan. Twijfel over identiteit is een voorwaarde. Het is geen commentaar op vaardigheid.

Cv's en LinkedIn-profielen blijven nuttig voor carrièregeschiedenis: werkgevers, dienstverband en genoemde ervaring. Ze zijn aanvullende context. Ze zijn niet standaard publiek technisch bewijs. Voor het kanaalargument, zie waarom sterke developers op LinkedIn onzichtbaar zijn.

Bronnen versus bewijstypen

Houd waar u keek gescheiden van wat u vond.

Bronnen zijn platforms. De relevante voorbeelden hier sluiten aan bij de publieke platforms die Sonar Air bespreekt en ondersteunt: GitHub, Stack Overflow, Hacker News, Kaggle, en technische blogs of persoonlijke sites. Zie ondersteunde databronnen en minimalisatie voor die lijst. LinkedIn en cv's blijven in de kolom carrièregeschiedenis.

Bewijstypen zijn artefacten: repositories en projecten, open-source-bijdragen, pull requests en issuediscussies, antwoorden en discussies, notebooks, technisch schrijven, en publieke projectdocumentatie.

Een repository is geen platform. Een antwoord is geen bron. U kunt meerdere bewijstypen op één bron vinden, of hetzelfde soort bewijs op meer dan één bron. Scoreer mensen niet op het aantal platforms dat ze gebruiken.

Deze pagina bouwt geen volledige bron-naar-bewijs-tabel opnieuw. Houd het onderscheid, en interpreteer daarna wat u vond tegen een claim.

Bewijs gaat altijd over een claim

Interpretatie begint met een claim die u in één zin kunt schrijven. Niet "zijn ze goed?" Niet "zijn ze senior?" Een claim ziet er zo uit:

"Er is publiek bewijs van recent TypeScript-API-werk."

Elke bevinding is een uitkomst tegen die claim.

Bewijs gevonden. Er bestaat publiek technisch werk, het is redelijkerwijs aan de persoon te koppelen, en het is relevant voor de claim. Wanneer dat werk de claim daadwerkelijk helpt, noemt u het ondersteunend bewijs voor die claim. Dat is een modifier van bewijs gevonden, geen vierde uitkomst.

Geen publiek bewijs gevonden. Onderzoek vond geen nuttig publiek technisch bewijs voor de claim. Dit is neutraal. Het mag nooit betekenen: zwak, junior, ongeschoold, niet de moeite van contact, of afwijzen.

Kan niet concluderen. Er bestaat iets, maar het is te mager, te dubbelzinnig, tegenstrijdig, of te ver van de rol om de claim te ondersteunen.

Bewijs wordt geïnterpreteerd tegen een claim. Onbekend is een geldig resultaat.

Als u de claim niet kunt noemen, interpreteert u geen bewijs. U bladert.

Wat publiek technisch bewijs kan ondersteunen

Publiek werk kan bescheiden, specifieke uitspraken ondersteunen. Het kan die uitspraken niet opwaarderen tot kwaliteit, senioriteit of fit.

Als het artefact op GitHub staat, is een GitHub-profiel lezen als wervingssignaal de veldgids. Bij Q&A gebruikt u een Stack Overflow-profiel lezen als wervingssignaal. Deze pagina blijft bij de claim, niet bij de interface.

Wat publiek werk kan ondersteunen, en wat het niet kan bewijzen. Geen score.

Wat het niet kan bewijzen

"Kan niet bewijzen" betekent niet "bevat nul informatie." Een onderhouden API-repository kan nog steeds een nadere blik rechtvaardigen. Het bewijst nog steeds niet dat de persoon in uw team zal slagen.

Publiek technisch bewijs kan het volgende niet bewijzen:

Voor GitHub-specifieke grenzen, zie wat GitHub een recruiter wel en niet kan vertellen. Publiek technisch bewijs mag interviews niet vervangen. Het kan het eerste gesprek specifieker maken. Screening, gesprek en menselijk oordeel dekken nog steeds wat publiek werk niet kan zien. Waar ondersteunende AI in het spel is, geldt dezelfde grens: waar het bewijs eindigt en menselijk oordeel begint.

Ontbrekend, mager, tegenstrijdig en niet-relevant bewijs

Niet elk hiaat is hetzelfde. Benoem het type, en stop dan met vaardigheid daaruit afleiden.

Behandel afwezigheid als onvolledig bewijs. Behandel een tutorial-fork als mager of niet-relevant, afhankelijk van de claim. Behandel een Kubernetes-bio plus alleen JavaScript-boilerplate als tegenspraak om te onderzoeken, niet als een verborgen rankingstraf.

Onbekend is een geldig resultaat

Onbekend is een eerlijk label, geen mislukte zoektocht.

U mag onbekend verwachten bij senioriteit in privésystemen, job performance, teamfit, motivatie, salaris, beschikbaarheid, en het meeste closed-source-werk. "Onbekend" opschrijven voorkomt dat een hiaat stilletjes een afwijzing wordt.

"Geen publiek bewijs gevonden" is ook onbekend over de claim, met een preciezer onderzoeksresultaat: u keek, en de publieke laag hielp niet. Ga verder met het cv, een referral, of een vraag van de hiring manager. Verzin geen compliment over publiek werk om het gat te vullen.

Sterkere versus dunnere ondersteuning voor een specifieke claim

Wanneer bewijs beter of slechter is, zegt u sterkere ondersteuning voor deze claim of dunnere ondersteuning voor deze claim. Zeg niet sterkere kandidaat, zwakkere kandidaat, of een hogere rang op publieke zichtbaarheid.

Mogelijk sterkere ondersteuning voor een claim: herhaalde rolrelevante bijdragen; een eigen project met leesbare context; meer dan één relevant artefact over de tijd.

Mogelijk dunnere ondersteuning voor een claim: een eenmalige bijdrage; een fork zonder wijzigingen; een star of follow; een oud geïsoleerd artefact.

Stars, volgers, committotalen, contribution graphs en reputatietellers meten aandacht of volume in een community. Ze zijn geen kwaliteitsscore. Lees het artefact. Rangschik mensen niet op de teller.

Voorbeelden van zorgvuldige interpretatie

Deze vier voorbeelden zijn gelabeld als illustratieve composieten. Het zijn geen echte kandidaten, klanten of uitkomsten.

TypeScript-API's

Claim: Er is publiek bewijs van recent TypeScript-API-werk.

Bewijs: De persoon lijkt een TypeScript-backendrepository te onderhouden, met recente commits en gedocumenteerde API-architectuur.

Redelijk: "Er is publiek bewijs van recent TypeScript-backendwerk."

Niet redelijk: "Zij zijn een senior backend-engineer."

Geen nuttige GitHub-activiteit

Claim: Er is nuttig publiek GitHub-bewijs voor deze rol.

Bewijs: Geen repositories, bijdragen of discussies die u kunt gebruiken.

Redelijk: "Geen nuttig publiek GitHub-bewijs gevonden."

Niet redelijk: "Zij zijn technisch niet sterk."

Als een andere bron wel nuttig bewijs heeft, legt u dat vast als een aparte claim. GitHub-stilte is geen score voor de hele persoon.

Bekende repository, kleine bijdrage

Claim: Zij hebben substantieel publiek eigenaarschap in project X.

Bewijs: Een eenregelige documentatie- of typofix op een breed gesterde repository.

Redelijk: "Zij droegen een kleine documentatie- of typowijziging bij aan X."

Niet redelijk: "Zij zijn een core contributor van X."

Mager GitHub, geconcentreerd Stack Overflow

Claim: Er is publiek bewijs van PostgreSQL-werk.

Bewijs: GitHub toont één oud sideproject. Stack Overflow toont jaren gerichte antwoorden in PostgreSQL.

Redelijk: "GitHub-bewijs is mager; er is publiek bewijs van geconcentreerde PostgreSQL-Q&A."

Niet redelijk: "Stack Overflow-reputatie bewijst senioriteit." Reputatie is volume in een community. Diepte op tagniveau kan een claim over publieke Q&A ondersteunen. Het bewijst nog steeds geen niveau.

Veelgemaakte interpretatiefouten

Stars, volgers, commits of reputatie als kwaliteit behandelen. Die tellers zijn makkelijk te scannen en makkelijk verkeerd te lezen.

Geen publieke GitHub als zwakte behandelen. Professioneel engineeringwerk kan privé zijn of onder werkgeversbeperkingen vallen, dus een stil GitHub-profiel is geen bewijs van zwakte.

Eén artefact als een hele carrière lezen. Eén repository, één notebook of één populair antwoord is een schijf.

Een terloopse bijdrage tot eigenaarschap opwaarderen. Lees altijd de wijziging.

Aannemen dat publieke activiteit betekent dat ze een baan willen. Activiteit is geen intentie.

Publieke communicatie als teamfit op de werkvloer behandelen. Een heldere issuediscussie is geen bewijs van hoe iemand met uw team werkt.

Bladeren zonder claim. Als u de zin die u toetst niet kunt schrijven, leest u te veel in wat toevallig zichtbaar is.

Werk prijzen dat u niet las. Als u het artefact niet kunt noemen, zet het dan niet in outreach.

Hoe u bewijsnotities schrijft

Gebruik notities, geen score. Elke regel kan "ja," "nee," of "onbekend" zijn. Voeg geen percentages, rood/geel/groen-beoordelingen, of aanname-/afwijsregels toe.

Notities voor interpretatie, geen kandidatenbeoordeling.

Schrijf:

• Wat ik vond
• Waarom het relevant kan zijn
• Wat ik niet kan verifiëren
• Wat onbekend blijft
• Welke vraag ik daarna moet stellen

De volgende vraag is voor een gesprek, een hiring manager, of een andere bron - niet voor een verborgen rankingformule. Als de publieke laag leeg is, kan de volgende vraag over het cv gaan, over een referral, of over of u nog een eerlijke reden hebt om te schrijven.

Hoe Sonar Air bewijs weergeeft

Handmatige interpretatie werkt voor een handvol namen. Het wordt duur wanneer u dezelfde bronhop herhaalt over veel technische rollen.

Sonar Air is een platform voor onderzoek naar technisch bewijs en het ontdekken van kandidaten, voor recruiters. Het brengt rolrelevant publiek technisch bewijs samen van GitHub, Stack Overflow, Hacker News, Kaggle en technische blogs, zodat u de onderliggende context zelf kunt bekijken. Recruiters werken met rolcontext en openen matches met links naar het publieke werk erachter. U bepaalt wat het bewijs betekent.

Sonar Air scoort geen kandidaten en neemt geen geautomatiseerde wervingsbeslissingen. Taalmodellen, waar ze zijn ingeschakeld, kunnen helpen bij samenvattingen en queries. Ze worden niet gebruikt om mensen te scoren of te rangschikken.

Bekijk hoe Sonar Air werkt.

Veelgestelde vragen

Wat is publiek technisch bewijs?

Publiek technisch bewijs is publiek beschikbaar technisch werk dat u redelijkerwijs aan een persoon kunt koppelen - projecten, bijdragen, antwoorden, notebooks, schrijven - gebruikt als onderzoekscontext voor een rol. Het is geen score en geen aannamebeslissing.

Wat kan publiek technisch werk een recruiter vertellen?

Het kan bescheiden claims ondersteunen: technologieën die in publiek werk voorkomen, recente publieke activiteit, de vorm van een project, waarschijnlijk eigenaarschap versus een terloopse bijdrage, en hoe iemand werk in het openbaar uitlegt. Het kan algehele kwaliteit niet bewijzen.

Wat kan GitHub een recruiter vertellen?

GitHub kan publieke repositories, bijdragen en discussies tonen. Dat kan claims over publiek werk ondersteunen. Het kan senioriteit, performance of interesse in een nieuwe baan niet bewijzen. Voor GitHub-specifiek lezen gebruikt u de GitHub-profiel- en GitHub-sourcinggidsen hierboven.

Betekent geen GitHub-activiteit dat iemand zwak is?

Nee. "Geen nuttig publiek GitHub-bewijs gevonden" betekent dat de publieke GitHub-laag leeg of niet bruikbaar was. Professioneel engineeringwerk kan privé zijn of onder werkgeversbeperkingen vallen, dus een stil GitHub-profiel is geen bewijs van zwakte.

Kan publiek technisch bewijs senioriteit bewijzen?

Nee. Publieke activiteit mapt niet op senioriteit in privésystemen. Behandel senioriteit als onbekend, tenzij u ander procesbewijs hebt.

Zijn stars en committellingen nuttige wervingssignalen?

Als aandacht of volume, soms. Als bewijs van vaardigheid of senioriteit, of als bewijs dat iemand klaar is om aangenomen te worden, nee. Lees het artefact. Rangschik mensen niet op tellers.

Moet publiek technisch bewijs interviews vervangen?

Nee. Het kan een nadere blik ondersteunen en een specifieker eerste gesprek. Interviews, referenties en menselijk oordeel beslissen nog steeds over wat u in het openbaar niet kunt zien.

Slotgedachte

Publiek technisch bewijs kan een nadere blik op rolrelevant werk ondersteunen. Het kan kwaliteit, senioriteit of een aanname niet bewijzen. Interpreteer het tegen een claim. Leg vast wat u vond, wat u niet kunt verifiëren, en wat onbekend blijft. Ontbrekend bewijs is onbekend, geen afwijzing.

U blijft bepalen wat het bewijs betekent en wat u daarna doet.

Als u die bewijslaag tegen een rolprofiel wilt laten verzamelen zodat u die zelf kunt bekijken, bekijk hoe Sonar Air werkt.