O problemă cu procesele de recrutare

E o discuție pe Twitter, pornită sâmbătă, despre procesul de recrutare de designeri folosit de cei de la Monzo. Dacă te-ai lua după răspunsurile unor oameni, ai zice că Monzo n-ar trebui să găsească niciodată designeri noi. Pe scurt:

  • se uită la portofoliu și la răspunsurile la niște întrebări
  • interviu telefonic
  • încă o discuție telefonică
  • te pun să rezolvi un exercițiu
  • încă un interviu de tip workshop
  • încă un interviu pe teme mai generale

Răspunsurile sunt în zona “bă, ăia-s proști?” și “mă gândeam să aplic, dar m-am răzgândit“. Plus povești de la cei care au ajuns în faza de interviu sau de exercițiu. De exemplu:

  • pe un tip l-a căutat un recrutor de la Monzo. Om cu experiență, portofoliu, n-a ajuns în faza de exercițiu din cauză că răspunsurile lui… nu se potriveau cu cultura companiei sau ceva de genul ăsta
  • altul a rezolvat exercițiul, dar n-a trecut în faza următoare din cauză că nu le-au plăcut culorile, întâmplător paleta de culori a companiei – și pe care era cumva subînțeles că ar fi trebuit să o folosească

Pe de o parte, înțeleg partea legată de cultura companiei. Nu vrei să iei o vedetă care să nu se înțeleagă cu echipa sau care să fie vreun nesimțit care discriminează sau își jignește colegii. Or, Monzo se laudă cu un colectiv divers. Dar întrebările nu prea au legătură cu asta, ci sunt oarecum generale. Cum hotărăsc ei că tu ești potrivit, asta nimeni nu știe.

A doua e legată de cine te intervievează. Am văzut un caz în care omul care aplicase avea o experiență babană, iar intervievatorul era cineva cu nu știu câți ani mai tânăr. Întrebarea logică e: de ce nu sunt transparente criteriile?

Pe de altă parte, înțeleg logica unui exercițiu în condițiile în care nu ai văzut un portofoliu. Și e posibil ca un candidat să nu poată prezenta un portofoliu pentru că fie a lucrat cu un NDA, fie a lucrat în companii mari, unde procesul de design e diferit – în sensul că un designer nu desenează o aplicație întreagă, ci doar anumite features.

De exemplu, poate a fost responsabil doar cu umbrele. Știu că sună stupid, dar în companiile cu echipe mari, se întâmplă astfel de lucruri. Motivul principal e că un product designer ajunge să stea mai mult în ședințe decât în fața Photoshop-ului, iar un produs ajunge să fie spart în bucățele de care sunt responsabili o groază de oameni.

Dilema însă e următoarea: dacă ai un om care a lucrat zece ani, să zicem, la Apple, are sens să-i ceri portofoliu și să rezolve un exercițiu? Pentru că, din punctul meu de vedere, îl jignești dacă faci asta. Și am văzut chestii similare și la procesele de recrutare în zona de development. Hai să-ți dăm un exercițiu de cod.

Și situația e cam așa: îl rezolv, dar îmi plătești timpul pe care-l petrec rezolvându-l? Companiile, în general, se scuză cu chestii de genul “ar trebui să nu-ți ia mai mult de cinci ore“, dar mă uitam fix la un răspuns de-acolo. Cineva spunea că n-are cum să ia cinci ore, lui i-a luat zece ca să deseneze ce era de desenat.

Da, intervievatorului i-ar lua cinci ore pentru că a mai făcut asta. Poate o dată, poate de două, poate de cinci. Problema respectivă s-ar putea să fie nouă pentru tine. O să-ți ia 20, că și lui i-a luat tot atât, poate chiar mai mult, când a rezolvat-o prima oară. E un bias acolo.

Prin urmare, din punctul meu de vedere, când vine vorba de procese de recrutare, cred că două lucruri sunt importante: să vezi cum s-ar potrivi omul în cultura organizațională, respectiv cum gândește pe partea tehnică:

  • cultura organizațională e importantă pentru integrarea în echipă, respectiv pentru găsirea unor soluții pentru ca echipa să accepte un om care poate vede lucrurile diferit pe anumite teme, dar care e profesionist. În orice caz, logica e aceea că nu vrei un om toxic în colectiv
  • tehnica e o chestiune destul de abstractă, în sensul că sintaxa – în cazul codului – e mai degrabă secundară, important e modul în care găsești soluția. La fel și în cazul designului, nu contează în primă instanță cum arată, ci soluția pe care ai găsit-o la problemă

Nici codul și nici designul nu sunt matematică primară: ai un 2 și un 2, cum faci să ajungi la 4? Și chiar dacă ar fi așa, tot poți să destructurezi formula și să ajungi la 4 prin 1 + 1 + 2 în funcție de care abordare ți se pare mai eficientă.

Și mai e o chestiune: testele astea sunt și nu sunt relevante. Pe partea de cod, de exemplu, când aplicasem la UiPath, am găsit toate rezolvările problemelor de pe hacker-ceva la un simplu Google. Nu m-am apucat să le copiez, că era de porc, dar doar spun că oricine poate înșela sistemul.

Pe partea de design, exercițiul dat de Monzo era cel puțin tâmpit: desenează o interfață intuitivă de aplicație pentru un cuptor fără butoane. Singurul răspuns corect e: vrei intuitiv? Pune-i butoane și facem aplicația după. OK, e un exercițiu teoretic, dar… procedura cât de transparentă e?, cine își dă cu părerea despre execuție – un designer junior, un senior, HR-ul, product managerul sau șeful designerilor? Cine se uită pe portofoliul tău – care dintre ăia numiți mai devreme?

Și undeva prin thread-ul ăsta, Mark Boulton zice o chestie deșteaptă: orice designer senior știe să judece un portofoliu dacă e să fie el cel care angajează. Același lucru, în thread-ul inițial, l-a spus și Michael Beirut (șef la Pentagram), că ei au între unul și trei interviuri și nu dau niciodată exerciții pentru acasă.

Și același lucru e valabil și pentru cod. Meseria de developer e 40% gândit la soluție, 40% căutat soluții pe stackoverflow și 20% scris cod propriu. Sau cel puțin așa merge gluma. Și, până la urmă, la fel de valabil e și pentru design, că tre’ să cercetezi ce oferă competiția.

În fine, ideea e că dacă vrei oameni competenți nu trebuie să-i jignești. Iar multe dintre procesele de recrutare sunt o insultă la adresa candidaților buni. HR-ul nu poate să le facă pe toate. Poate evalua partea de soft skills, poate să-și facă o idee vagă despre experiență din CV și să recomande mai departe anumiți candidați, dar decizia finală ar trebui să aparțină unui om care se ocupă cu același lucru pe care-l va face cel ce a aplicat.

Bine, și mai e o problemă, anume a evaluatorilor. De exemplu, un designer va fi evaluat de șeful designerilor, care s-ar putea să se simtă amenințat de un candidat mai talentat decât el. Ceea ce, într-o corporație, e stupid, că uneori designerii vor doar să deseneze, nu să le ia altora – șefilor – pâinea de la gură doar de dragul de a sta în ședințe nesfârșite.