Am discutat zilele acestea cu 4 oameni, toți programatori experimentați, toți pe care de a-și schimba locul de muncă. Și i-am “descusut” legat de interviurile tehnice pe care le dau.

Mi se pare incredibil că încă mai există companii se evaluează capacitatea tehnică a unui programator de nivel mediu și senior bazat strict pe teorie. Să ridice mâna cine a auzit următoarele întrebări la un interviu tehnic:

  • Îmi poți da un exemplu de pattern singleton?
  • Care este diferența dintre o clasă abstractă și o interfață?
  • Fără să folosești calculatorul, îmi poți spune ce afișează codul următor?

Din punctul meu de vedere, interviul de angajare trebuie să fie potrivit cu nivelul de experiență cerut și să simuleze cât mai bine munca viitoare. Pe lângă interviul de HR, pe care fiecare companie îl reinterpretează ca trupa Voltaj (piese diferite, dar aceeași muzică), și interviul tehnic trebuie să includă o analiză a persoanei din fața ta, de data aceasta din punct de vedere al capacităților tehnice.

Ce ar trebui să evalueze interviul tehnic: capacitatea persoanei de a se integra în echipa tehnică, dorința de învățare, capacitatea de documentare, capacitatea de a crea un algoritm, capacitatea de a cere ajutorul, deschiderea spre sugestii, deschiderea spre “ordine” tehnice, capacitatea de a găsi soluții originale, capacitatea de a improviza, etc

Ce NU ar trebui să testeze interviul tehnic: cunoașterea detaliată a sintaxei limbajului, modul în care este compilat/interpretat un set de instrucțiuni, aspecte teoretice legate de limbaj, etc.

 

Mai jos am pus un exemplu de interviu tehnic pe care care l-am folosit cu succes. E modul în care văd eu interviul de angajare. Nu am pretenția că este cel mai bun, dar îmi răspunde la toate întrebările pe care le am legate de potențialul viitor coleg.

Interviul este pentru un Middle Full-Stack Web Developer în tehnologii Java.

Interviul durează o oră și reprezintă un exercițiu practic pe care candidatul trebuie să-l facă cu calculatorul în față.

Se cere crearea unei aplicații web simple care să răspundă următoarelor puncte :

  1. afisarea obiecteler din DB (o singură tabelă) în browser sub forma de tabel
  2. afișarea unui buton ce face toogle pe o proprietate booleana a obiectului
  3. afișarea unui buton pentru fiecare rând din tabel care șterge înregistrarea corespunzătoare

Se pun la dispoziția candidatului:

  • server: Tomcat
  • baza de date: MySQL sau OracleXE
  • un IDE: Eclipse
  • acces la documentație: internet + browser
  • scheletul proiectului: mecanismul de build, mecanismul de deployment, librăriile necesare etc

Există, de asemenea, o capcană, ceva greșit în configurare. De obicei, o problemă de naming ce va apărea înainte de începerea efectivă a dezvoltării. Se spune candidatului că există undeva o capcană, însă nu se precizează unde.

Eu dădeam ca timp de rezolvare a exercițiului 40 de minute și lăsam candidatul singur. După 15 minute reveneam și întreabăm cum merge și dacă există ceva nelămuriri. De obicei, aici este punctul unde îți dai seama dacă omul se va descurca sau nu are nicio șansă. Unii candidați erau blocați pur și simplu. Fie nu reușeau să înțeleagă structura, fie nu treceau de capcană, fie nu înțelegeau cerințele (!). Deși înțelegeam ce se întâmplă, îi întrebam dacă au nevoie de ajutor și cu ce. Faptul că nu cereau ajutorul, ci voiau pur și simplu mai mult timp, e un mare “no go!” pentru mine.

La sfârșit, după exact 40 de minute reveneam și întrebam ce au reușit să facă din cerințe. De cele mai multe ori, nu totul. Asta e perfect acceptabil. Analizam câte puncte din cele cerute a reușit să faca și în ce ordine. Dacă unul nu a mers, a renunțat și s-a concentrat pe celelalte?

Ultimele 10 minute discutam cu candidatul ce soluție a ales, de ce, dacă s-a documentat, de ce nu ar face altfel, etc. De ce? Pentru a înțelege logica gândirii.

La sfârșit, după plecarea candidatului analizam codul scris de acesta: structura, ordine, comentarii, numele variabilelor, etc.

 

Din nou, interviul era potrivit pentru mine și firma mică pentru care făceam angajările. Unele criterii nu se potrivesc pentru companii medii și mari, în special cele ce lucrează în sistem de “outsourcing”.

Tu cum vezi un interviu tehnic de angajare ca programator? Ce te interesează să afli la interviu?

Btw, dacă te interesează un job în Java, ai aici unul foarte bun. Interviul nu este cel din exemplul dat mai sus 😉

 

 

Cum ar trebui să fie un interviul tehnic pentru programator?

One thought on “Cum ar trebui să fie un interviul tehnic pentru programator?

  • May 3, 2017 at 10:04
    Permalink

    Capcana in config soarta, nu am cum sa il detectez. Toata viata am programat pornind de la premiza ca softul IN care programez si configurare e ok. Habar nam cum si pe unde isi construieste classpath si DPath si restu necesare pt a genera un war de Tomcat Eclipse-ul sau Intelijj Ideea. O singura data am scris XML de config pt war de mana, dar ala avea optiuni de baza, nu SF-uri

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *