Validitate și corectitudine în testele software skills

Problema validității pe care nimeni nu vrea s-o admită

Compania ta folosește o evaluare Excel pentru roluri de analist financiar. Candidații scor înalt, îi angajezi, se onboarding-ează, șase luni mai târziu observi: nicio corelație între scorurile testului și performanța reală.

Unii care au scor înalt sunt acum cei mai buni performeri ai tăi. Unii se luptă. Unii care au scor scăzut s-au dovedit a fi competenți după ramp-up.

Testul tău nu măsoară performanța în job. Măsoară ceva — abilitate de test-luare, expunere anterioară la instrumentul specific, confort sub presiune de timp — dar nu lucrul pe care ți-l pasă.

Asta e o problemă de validitate. Și e comună pentru că nimeni nu validează testele de software skills după deployare.

Ce înseamnă de fapt validitatea

Un test e valid dacă măsoară ceea ce pretinde că măsoară și prezice performanța în job.

Testul tău de Excel pretinde că măsoară "abilitate Excel pentru analiza financiară." Asta măsoară?

• Un scor înalt prezice că persoana va produce modele financiare precise?
• Un scor scăzut prezice că se vor lupta?
• Sau scorul prezice altceva (încredere, viteză de test-luare, experiență Excel anterioară)?

Validitatea nu e despre faptul că testul e greu sau ușor. E despre faptul că testul prezice performanța viitoare.

Un test trivial poate fi valid dacă separă oamenii care vor reuși de cei care nu vor. Un test complex poate fi invalid dacă cei cu scor înalt nu depășesc de fapt pe cei cu scor scăzut în job.

Cum valideți testul vostru (după ce l-ați folosit un timp)

Așteptați șase luni după ce angajați oameni prin evaluarea voastră. Apoi:

1. Urmăriți performanța în job a 10–20 de oameni care au luat testul:

   • Scoruri înalte (80%+): Câți performează deasupra așteptărilor? (Urmăriți comparativ cu evaluări de performanță sau rezultate ale proiectelor.)
   • Scoruri medii (60–79%): Aceeași întrebare.
   • Scoruri scăzute (sub 60%): Aceeași întrebare.

2. Căutați corelație.

   • Validitate puternică: Cei cu scor înalt reușesc disproporționat. Cei cu scor scăzut se luptă disproporționat.
   • Validitate slabă: Scorurile sunt peste tot. Cei cu scor înalt și scăzut reușesc și eșuează în egală măsură.

3. Identificați ce prezice testul de fapt.

   • Dacă cei cu scor înalt excelează la construire de formule dar se luptă cu gândirea calității datelor, testul tău e valid pentru formule dar nu pentru analiză.
   • Dacă cei cu scor înalt sunt rapizi dar nu mai buni la raționament, testul tău măsoară viteză, nu abilitate.

4. Ascultați managerii de hiring.

   • Întrebați echipa: "Oamenii care au scor bun la test performează bine în job?" Dacă spun nu, aveți o problemă de validitate.

Asta nu-i știință perfectă, dar e mai bine decât a presupune că testul tău e valid pentru că pare greu.

Problema corectitudinii: Pe cine avantajează testul tău?

Corectitudinea nu înseamnă că testul e ușor pentru toți. Înseamnă că testul nu dezavantajează oamenii pe baza unor atribute neînrudite cu jobul.

Un test e nedrept dacă:

1. Necesită expunere anterioară la instrumentul exact (tool-specific bias)

Exemplu: "Scrie o măsură Power BI folosind CALCULATE și logica contextului rând."

Un candidat care a folosit Tableau timp de cinci ani va eșua la testul ăsta chiar dacă e analist mai bun. Știe conceptele; pur și simplu nu a memorat sintaxa Power BI.

Fix: Testează conceptul (agregare condițională) nu sintaxa. Lasă candidații să-și explice abordarea în pseudocod dacă trebuie.

2. Presupune context cultural sau socioeconomic (background bias)

Exemplu (mai puțin frecvent acum, dar se întâmplă): "Un analist de business trebuie să prezinte rezultate trimestriale la tablă. Construiește un dashboard pentru contextul ăsta."

Un candidat dintr-un background non-business s-ar putea să nu știe ce implică "rezultate trimestriale la tablă". Vor construi alt dashboard, vor scora mai scăzut și vor fi respinși — nu pentru că le lipsește abilitate de analiză, ci pentru că le lipsește context de business.

Fix: Furnizează context. Nu presupune experiență anterioară cu raportare corporativă.

3. Penalizează responsabilități de îngrijire sau constrângeri de timp (access bias)

Exemplu: Un test take-home de 6 ore.

Un candidat cu responsabilități de îngrijire ar putea scora mai scăzut la un test de 6 ore nu pentru că le lipsește abilitate, ci pentru că nu putea găsi 6 ore neîntrerupte. Un candidat cu un job de zi flexibil o poate face ușor.

Fix: Ajustează limite de timp sau oferă opțiuni sincrone. Două ore de muncă concentrată măsoară abilitate mai bine decât șase ore întrerupte.

4. Necesită acces la software sau stabilitate internet (infrastructure bias)

Exemplu: Un test live Power BI dashboard care necesită colaborare cu bandă largă și latență strânsă.

Un candidat dintr-o regiune cu internet slab se va lupta indiferent de abilitate. Va scora mai scăzut, va fi respins, și respingerea e neînrudită cu abilitatea lor.

Fix: Oferă alternative offline (fișier PBIX local, trimitere email) sau recunoaște bariera de infrastructură în interpretare.

5. Presupune fluență engleză pentru vorbitori non-englezi (language bias)

Exemplu: Un test cu instrucțiuni scrise complexe în engleză, chiar și pentru un rol care nu e în principal despre scriere engleză.

Un vorbitor non-nativ ar putea scora mai scăzut pentru că au neînțeles instrucțiunile, nu pentru că le lipsește abilitate tehnică.

Fix: Instrucțiuni simple, directe. Oferă clarificări. Evaluează lucrarea, nu calitatea scrierii.

6. Exploatează nervozitate (context bias)

Exemplu: Un test de live coding de 30 de minute cu tine urmărind.

Un candidat anxios ar putea să se blocheze și să producă muncă slabă chiar dacă e competent. Un candidat încrezător va produce muncă puternică sub aceeași presiune.

Fix: Asociază evaluări live cu take-homes. Take-homes măsoară gândire; evaluări live măsoară performanță sub presiune. Amândouă sunt valide; doar nu supraalimenta pe una.

Construirea unei evaluări mai echitabile

Folosește această listă de verificare înainte de a implementa orice test de software skills:

• Testează abilitatea sau instrumentul? Dacă ți-i pasă de gândirea de analiză, testează aia. Nu o face dependentă de a cunoaște Power BI în mod special.
• Presupune context anterior pe care nu-l măsor? Dacă rolul necesită context de business, include onboarding. Nu penaliza oamenii care nu au încă.
• E timpul realist pentru situații de viață diferite? Ar putea cineva cu responsabilități de îngrijire s-o termine? Dacă nu, ajustează timp sau format.
• Instrucțiunile sunt clare în limbaj simplu? Ar putea un vorbitor non-nativ înțelege ce se cere?
• Evaluarea permite căi diferite la același răspuns? Dacă Excel și Google Sheets amândouă funcționează, nu penaliza utilizatorii de Sheets.
• Măsor abilitate sau încredere? Scorurile înalte se corelează cu încredere sau cu abilitate reală? Rulează o verificare de validare rapidă.

Cazul special: Teste specifice instrumentului vs teste bazate pe concept

Unele roluri necesită cu adevărat instrumente specifice. Un analist financiar la o companie care folosește Excel extensiv probabil are nevoie de abilitate Excel.

Dar fi explicit cu privire la asta.

Evaluare specifică instrumentului: "Acest rol folosește Excel zilnic. Vom testa Excel în mod specific."

• Echitabil pentru candidații care cunosc Excel
• Neechitabil pentru candidații care cunosc conceptele în alte instrumente
• Potrivit dacă pregătirea cu instrumentul e de fapt necesară

Evaluare bazată pe concept: "Ne pasă de analiza datelor și modelare. Poți folosi Excel, Google Sheets sau Python — orice te-ai simți confortabil."

• Echitabil în tot mediul de instrumente
• Măsoară abilitate de bază
• Potrivit dacă alegerea instrumentului e flexibilă

Amândouă sunt valide. Doar fi clar care dintre ele faci.

Validitatea și corectitudinea nu se opun — sunt legate

Un test poate fi valid dar nedrept (performerii buni la test fac bine în job, dar testul avantajează anumite grupuri). Un test poate fi drept dar invalid (orice demografie performează asemănător, dar scorurile nu prezic performanța în job).

Cele mai bune evaluări sunt amândouă:

• Valide: Scorurile înalte prezic succes în job
• Corecte: Performanța la test nu se corelează cu grup demografic sau background

Pentru a obține amândouă:

1. Testează abilități reale folosite în job (validitate).
2. Elimină bariere neînrudite cu acele abilități (corectitudine).
3. Validează după hiring (măsoară dacă testul prezice de fapt performanța).
4. Verifică pentru bias demografic (anumite grupuri scor sistematic mai scăzut, și se potrivește cu performanța în job?).

Datele pe care ar trebui să le colectezi

Dacă angajezi 10+ oameni prin aceeași evaluare, urmărește:

Corelații de urmărit:

• Scorul testului se corelează cu evaluare de performanță? (Verificare validitate)
• Candidații din anumite background-uri se grupează în trepte de performanță diferite? (Verificare corectitudine)
• Ce altceva prezice performanța? (Semnal de interviu comportamental? Experiență anterioară?)

Aceste date îți spun dacă evaluarea ta funcționează și pentru cine.

Adevărul incomod despre testele software skills

Majoritatea platformelor de evaluare online pretind validitate și corectitudine. Rar au validat de fapt comparativ cu performanța în job. Au măsurat consistență internă (scorurile testului sunt fiabile dacă-l iei de două ori) și validitate de față (testul arată că măsoară ceea ce ar trebui).

Dar nu au urmărit: Oamenii care scor înalt reușesc cu adevărat în joburile pentru care sunt angajați?

Nu poți încrede o pretenție de validitate fără acele date.

Construiește propria validare. Angajează oameni prin evaluarea ta. Urmărește performanța lor. Ajustează. Repetă. După două cicluri de hiring, vei ști dacă testul tău de fapt funcționează.

Până atunci, tratează testele software skills ca semnale utile, nu ca determinanți. Un scor înalt justifică o conversație avansată și o previzualizare realistă de job. Un scor scăzut e motiv să investighezi mai adânc, nu o respingere automată.

Cel mai bun hiring combină semnale multiple: test de skills, interviu comportamental, probe de lucru și conversație cu membrii echipei actuale. Niciun test unic nu determină hire/no-hire. Asta-i cum rămâi atât valid cât și drept.