Principalul obiectiv al recrutării IT este găsirea oamenilor cu cele mai bune abilităţi tehnice și cel mai bun raţionament abstract. La drept vorbind, aceste abilităţi tehnice sunt precondiţii OBLIGATORII pentru orice angajare de succes în această industrie.
Concomitent, marii angajatori își orientează strategia de angajare prin căutarea și potrivirea celor mai bune "caractere" cu o funcţie scoasă la concurs. Acest lucru este de înţeles având în vedere că marile companii sunt mult mai stabile decât startupurile, deci marile organizaţii vor pune mai mare accent pe stabilitatea de lungă durată decât de rezultate extraordinare, de scurtă durată. Din aceste motive, personalul corporatist responsabil cu angajarea folosește două abordări.
O abordare utilizează formulare psihometrice, clasice, pentru angajare (de exemplu: câteva sute de întrebări la care trebuie dat un răspuns în 90 de minute).
A doua abordare utilizează teste de tip Situational Judgment (judecată situaţională). De exemplu, aceasta intervievare e folosită în special în etapa de pre-evaluare pentru candidaţii ce doresc un post la Comisia Europeană.
Testele psihometrice sunt frecvente în industria IT din România, dar în SUA/Canada candidaţii la slujbe în corporaţii IT au de trecut teste de tip Situational Judgement (judecată situaţională) faţă în faţă, nu în scris.
Practic, candidatului îi este prezentat un scenariu care se poate solda cu un conflict, scenariu în care intervievatorul și intervievatul joacă roluri, de exemplu rolul de programator senior. Urmează un schimb de replici în contradictoriu și o serie de argumente, iar intervievatul trebuie să faca cele mai bune alegeri pentru ca situaţa să ajungă la un rezultat pozitiv. Schimbul de replici poate deveni intens! Rolurile se pot schimba în timpul interviului sau la finalul acestuia. Dacă scenariul nu se finalizează cu succes, aplicantul este rugat să asigneze un procentaj de "vină" fiecărui participant.
Mult prea des se trece cu vederea o sursă de tensiune constantă care nu poate fi evitată: într-o echipă de development, inginerii IT au tendinţa de a nu fi de acord cu managerul de proiect. Tendinţa este de înţeles: programarea necesită mult efort și se bazează pe o educaţie complexă, dar gestionarea proiectului nu necesită aceste abilităţi într-o măsură atât de mare! Mulţi programatori spun că, dacă s-ar alege o persoană de pe stradă la întâmplare, am avea șanse mai mari să găsim o persoană mai potrivită decât cea care face parte din organizaţie la acest moment! De fapt, relaţia "putere politică versus educaţie" dintre programatori și manageri IT este inversă în comparaţie cu relaţia dintre soldaţi și ofiţeri: în industria software, un manager de proiect are calificări inferioare subordonaţilor săi!
Ca lucrurile să fie și mai ciudate, managerii văd că mulţi programatori nu stau bine la capitolul abilităţilor sociale și pot fi introvertiţi. Din experienţa personală, constat că cu cât un programator evită interacţiunea cu oamenii, cu atât mai mult se refugiază în lumea perfectă a matematicii și a știinţei calculatoarelor! Cei cu experienţă în industria IT știu că aceasta nu este o exagerare, ci un fapt real.
Aceste probleme de comunicare și atitudine sunt mult mai des întâlnite și mai vizibile în IT comparativ cu alte meserii de pe piaţă.
Cu cât e mai mare compania, cu atât mai mult se axează aceasta pe trăsăturile psihologice "bune" ale angajatului potenţial.
Este mai bine să fim pregătiti și să ne asteptam înainte de interviu la preconcepţii bazate pe diverse stereotipii: naţionalitate, regiune, gen, vârstă, statut familial sau orice altceva. Fiţi curioși și mai asertivi decât ar fi majoritatea românilor în timpul unui interviu!
Iată un exemplu real al unui scenariu de interviu unde este nevoie de Situational Judgement (judecată situaţională).
Ai cinci oameni în echipa ta: un manager de proiect, un arhitect, un lider de echipă și doi programatori, unul dintre ei fiind tu. Pentru a păstra lucrurile simple, nu vom lua în calcul celelalte roluri precum cea de tester sau analist business.
Este vineri, iar arhitectul a programat o întâlnire pentru a prezenta un modul critic ce trebuie dezvoltat săptămâna următoare când proiectul trebuie finalizat și dat clientului. Arhitectul prezintă designul propus, pe care îl evaluezi ca fiind bun, dar, la un moment dat, în timpul prezentării, găsești o soluţie mai bună. La finalul prezentării, arhitectul întreabă (iar aici începe piesa):
- Aici se încheie prezentarea mea. Dorește cineva să adauge ceva?
(Ce ai face?...)
După schimbul de idei dintre arhitect, jucat de intervievator, și programator, jucat de intervievat, înaintăm scenariul cu câteva zile.
Este următoarea miercuri la prânz, când mai ai la dispoziţie doar câteva ore de programare până la code-freeze, iar tu citești modulul implementat de colegul tău și observi că acesta nu a respectat deloc specificaţiile asupra cărora s-a convenit vineri, dar că a implementat soluţia ta pe care tu ai considerat-o mai bună decât cea propusă de arhitect!
(Ce faci? ...)
Aici urmează o discuţie aprinsă între doi programatori sau oricare din actorii (în funcţie de răspunsul la întrebarea: ce faci mai departe?).
La finalul improvizaţiei, dacă proiectul a eșuat, managementul vrea ca cel puţin o persoană să fie trasă la răspundere.
Ca programator, participant la acest scenariu, cum ai calcula și împărţi vina între cei cinci participanţi?
de Petra Ivașcu
de Emilia Toma
