Programatori: numarul de ani vs. experienta; Strategii de angajare

rezerved post

later edit:

Quote

vezi matale, asta cu "AS" prespune o irealitate,
de asta am spus, vorbiti din punctul in care va aflati, dezbateti fapte si consecinte

Quote

OC a spus destul de clar ca a chemat seniori, dar a primit aspiranti.

Daca ai cazuri similare suntem extrem de interesati cum le-ai tratat (practic, fara AS)

Buleandra94, on 16 martie 2019 - 19:02, said:

Topicul se axeaza pe ce castigi in urma unui interviu, un om pe post sau un post ocupat.

Edited by MarianG, 16 March 2019 - 23:13.

MarianG, on 16 martie 2019 - 22:24, said:

Hmm, cred ca iti inteleg punctul de vedere. Sugerezi ca singurul mod prin care OC poate primii informatii folositoare este daca cineva spune clar, anecdotic, cum a procedat intr-o situatie similara si nu daca cineva descrie cu ar proceda in situatia respectiva, daca s-ar lovi de aceasta problema. Eu unul nu sunt de acord cu asta, cand pun o intrebare sau cer sfaturi, nu cer doar de la cei care au trecut prin asta ci si de la cei care pot avea o solutie pentru asta (ex. cand pui o intrebare pe Stack Overflow nu trebuie ca cel ce raspunde sa se fi lovit de aceeasi problema, ci este indeajuns sa aiba raspunsul la intrebare sau o alternativa potrivita). Mi se pare putin ciudat sa respingi implicit o idee/solutie doar pentru nu are la baza o "intamplare adevarata" si sa nu consideri valoroasa, sau cel putin relevanta, parerea altuia legata de problema.


Cat despre recrutare, cum am spus mai sus, nu lucrez in HR, nu am background in HR, nu am sute de cazuri de povestit. Un exemplu, pentru recrutarea pentru un rol de Frontend Dev am ales din candidatii care au aplicat pe cei care aveau cele mai interesante proiecte realizate si in functie de profilul pe GitHub. Cei alesi au primit un mic test in care trebuia sa implementeze, in limbajul si framework-ul in care urmau sa lucreze, o parte foarte mica din proiectul la care lucram. Au avut cateva zile (de acasa) sa implementeze testul (o interfata in TypeScript + React), erau si care folosisera aceste tehnologii inainte si care nu. Dupa ce am primit aplicatiile, am analizat respectarea cerintelor, structurarea codului si daca au realizat ceva ce ii putea diferentia de ceilalti. Am ales candidatul final in functie de test + portofoliu (experienta) si de abilitatile de comunicare. Cei pe care i-am ales nu erau familiarizati cu TypeScript si erau destul de "juniori", insa consider ca s-au descurcat acceptabil si cele mai dese probleme nu erau date de necunoasterea limbajului ci de o anumita lipsa a cunostiintelor de baza si viteza (destul de redusa) cu care puteau gasi implementarea optima pentru o anumita cerinta. In final am ales o echipa de 2 programatori, insa dupa cateva luni am realizat ca este mai rapid cu o echipa mai mica, mai bine pregatita si cu o comunicare mai rapida decat cu o echipa extinsa in care pasarea/descrierea sarcinilor lua prea mult timp.

In cazul de mai sus insa, nu s-au dat drept "seniori", stiam inca de la inceput nivelul de experienta ca fiind unul destul de scazut. Ce am invatat din experienta asta este ca sunt foarte multi factori care nu pot fi testati daca timpul de care dispun cei ce fac recrutarea (si candidatii) este foarte limitat. Am stiut de la inceput ca nu sunt candidatii perfecti, insa a fost decizia potrivita sa oprim cautarea si sa alegem cea mai buna optiune din candidatii gasiti. A, si am mai invatat ca se poate sa ai impresia ca ai nevoie de o persoana pe un anumit rol, insa dupa ce acea persoana apare realizezi ca procesul de dezvoltare este ingreunat ci nu fluidizat sau ca "," calitatea produsului se degradeaza in loc sa se imbunatateasca.

Quote

sunt eu singurul deranjat de chestia asta?
este o practica normala sa pui oamenii la munca inainte sa ii angajezi?

Edited by MarianG, 17 March 2019 - 09:36.

depinde cat de mica era acea "parte foarte mica"
o clasa cu 5-6 metode de cate 10-20 randuri fiecare e o chestie ok pentru un test "pentru acasa"

Cand dai "teste pentru acasa" nu ratezi oportunitatea de a il vedea cum lucreaza? Modul in care lucreaza dezvaluie multe: vezi unde se blocheaza, daca are un mod de lucru fluent (stie pe unde sa dea click, etc - si da, multi oameni, inclusiv eu, nu mai sunt productivi cand te uiti la ei peste umar).

Eu de exemplu intr-un interviu, daca il vad ca se blocheaza undeva, dar se duce pe google sau in documentatia oficiala si stie exact ce cauta (terminologia corecta), atunci nu are deloc un minus pentru ca nu a stiut, ci un mare plus.

Il vad cum da scroll pe pagina, daca da clicuri anapoda ca o maimuta, sau chiar stie ce face si ce cauta si cum cauta (inseamna ca e rutinat in a cauta prin documentatia respectiva).

Daca dai pentru acasa, trebuie sa dai un proiectel mai maricel putin, ca sa faca mai multe commits, si sa incerci sa ii deduci modul de lucru din istoria git.

Opinii?

Edited by OriginalCopy, 17 March 2019 - 10:36.

Prefer un proiect nu foarte mare facut acasa si apoi discutii pe codul rezultat (daca nu e complet pe langa).
Prin tarile unde interviurile "la tabla" sunt la moda, am observat ca se creaza o cultura puternica impotriva testelor pentru acasa, pe principiul "pai ar trebui sa ma plateasca ca muncesc pentru ei..."

OriginalCopy, on 17 martie 2019 - 10:26, said:

il angajezi ca sa te uiti la el cum lucreaza, sau in functie de produsul finit?

dani.user, on 17 martie 2019 - 10:48, said:

Are avantaje notabile, da, dar cred ca trebuie sa fie mai maricel, nu doar 1-2 ecrane de cod, ci o duzina de clase. Depinde de ce nivel e pozitia, mid-level, senior...

Dar oare "proiectel pentru acasa" e potrivit si pentru juniori? Eu nu l-as folosi pentru juniori, din motivele expuse anterior.

_Smiley_, on 17 martie 2019 - 10:48, said:

Pana sa il angajez, il intervievez, si il intervievez ca sa aflu daca vreau sa il angajez sau nu.

_Smiley_, on 17 martie 2019 - 10:48, said:

o situatie este pe post, iar alta pe proiect

OriginalCopy, on 17 martie 2019 - 10:55, said:

klar.
un raspuns concludent la intrebarea "de ce il angajezi"

_Smiley_, on 17 martie 2019 - 11:03, said:

Ambele: ca sa vad ca scrie cod (inclusiv luarea de decizii si tot ce implica scrierea de cod) pentru a termina proiectele.

Sunt multi care scriu cod anapoda si termina proiectele, dar dubleaza sau tripleaza costurile de mentenanta ale lor.

Doar terminarea proiectului nu e suficienta. Trebuie sa fie si cu cap.

pai si toate astea nu le vezi in produsul finit, in codul pe care il preda respectivul?
ce rost are sa te uiti la el cum lucreaza?


de obicei atitudinea asta am vazut-o la programatori medii, fara experienta de hr sau conducere, ajunsi "lead" dupa ce au plecat seniorii din firma. insista pe terminologie, pe "sa-l vad cum lucreaza", pe sintaxa, pe onestitate (gen "mai bine sa admita ca nu stie").

pe "clean code" nu s-a axat nimeni ?

_Smiley_, on 17 martie 2019 - 12:27, said:

Iti explic si tie, ca poate esti obosit si nu ai citit ce am scris deja: ma uit sa vad cum lucreaza in timpul interviului pentru a vedea daca chiar stie limbajul sau nu. Mincinosii vor spune "am lucrat X ani in limbajul Y", dar ei nu stiu nici sintaxa, nici terminologia, iar asta inseamna ca sunt mincinosi.

E o strategie excelenta de identificare a mincinosilor. Si mincinosi nu vrea sa aiba nici mama hașreului.

lasand deoparte faptul ca nu reusesti sa intelegi ca tot ce vrei tu poti obtine din codul final, nu te deranjeaza sa stii ca performanta lui poate fi afectata de faptul ca stai cu ochii pe el in timp ce lucreaza?
in alt topic spuneai asa:

OriginalCopy, on 17 martie 2019 - 10:39, said:

scopul unui interviu e sa-ti dai seama de abilitatile candidatului, nu sa-i cauti nod in papura.

_Smiley_, on 18 martie 2019 - 07:25, said:

Bineînțeles că m-am gândit. Și bineînțeles că fac ce e nevoie pentru a îi da candidatului senzația de siguranță și amiciție pentru ca el să își arate cât nai mult din potențial. Dar "în secret" mă uit la cât de fluent se mișcă, și care e procesul lui, și compar cu alți candidați. Nu compar cu un ideal niciodată atins. Am un pool de candidați și din ei trebuie să aleg unul.

Intru și eu in discuția asta (destul de interesantă), din perspectiva unui incepător (așa sunt, și așa mă consider).

Am lucrat efectiv la aproximativ 5 proiecte (în diverse limbaje, in principal C++, C# (.NET Framework), Android (Java)). + altele proiecte mai mici (dar pe care nu le consider ,,proiecte”).

Ce pot să spun din perspectiva începătorului: Oricând pot discuta concepte din C++, putem aduce în discuție diferențele principale dintre limbaje (precum moștenirea multiplă, cu avantajele și dezavantajele ei, de ce C# nu permite moștinerea multiplă dar cum putem modela interfețe pentru a rezolva acest neajuns, etc.), despre avantajele și dezavantajele programării asincrone, despre concepte întâlnite în Android (precum LiveData, Intent) și echivalentul (dacă există) - sau modelarea ideii în alte tehnologii (gen .NET), etc.). Pentru OriginalCopy: Dacă nu știu ceva, zic nu știu, dar mă documentez (și chiar fac asta, in primul rand pentru mine, nu ca sa par interesat). E o rusine?

Dacă sunt la un interviu pe C#, este posibil să nu-mi pice fisa din prima la o întrebare extrem de banală: cum transmitem un argument prin referintă în cadrul unei metode? Poate durează un minut până îmi aduc aminte de ref și out (precum și diferențele, respectiv necesitatea initializării anterioare a argumentului trimis prin ref). Poate îmi vine în minte varianta din C, dacă in ultimele mele proiecte am folosit preponderent C.

Dacă scot porumbelul din gură și răspund "cu &". Pic interviul?

Dat fiind faptul că, de exemplu, doar C# cu .NET Framework are 10.000 (zece mii de pagini in format .PDF, dacă nu mă înșel și cu UWP) - cine dorește varianta scrisă și nu doc. online -, este absurd să spui că poți învăța (în sensul exersării fiecărui concept, testarea lui în Visual Studio) într-un timp rezonabil. Mai mult, nu are sens. Dacă cineva a investit timp in UWP, probabil nici nu a ajuns la jumătate că deja platforma a fost în moarte clinică. (ca popularitate)

Avântul tehnologic este atât de mare încât, cel puțin pe mine, mă depășește.
Să te pui ,,la punct” cu o tehnologie concretă? Nu îmbrățișez varianta aceasta. Sunt 2 riscuri: Uiți esența, și nu mai privești sistemul în ansamblul său, și doi la mână: Până ”termini” (sau ajungi la un nivel de senior), apare o altă tehnologie care rezolva în mare parte neajunsurile celei din urmă.

Și atunci tu ce faci? Mă adaptez.
În primul rând, îmi bat capul în principal asupra proiectului (și chiar acord un timp rezonabil pentru asta): de ce il fac?, e util?, ce asteptari are clientul? ce perspectiva de scalare exista? e viabil? - cu argumente. Apoi, încep partea de arhitectură: UML, consistența layer-elor (bineînțeles, după ce le identific), ce resurse utilizez?, ce design pattern-uri voi utiliza si de ce/la ce ma ajută? e oportun să introduc ACUM, în plus, un nivel de abstractizare superior, sau îl adaug doar de amorul artei?

De ce fac toate astea? Pentru ca mai incolo, tot eu voi plati nota de plata daca ceva nu e ok si trebuie sa refac o buna bucata din proiect. Eu nu am răbdare să refac zeci de mii de linii de cod. Defect profesional, recunosc. (cum, la fel, nu am răbdare să citesc (și să înțeleg mii de linii de cod) fără un UML în față, care să-mi arate contextul global) - iarăși, defect profesional. Poate cu timpul ...cine stie.

Apoi, partea tehnologica: Concret, sistemul trebuie să ruleze pe mai multe platforme: Android, iOS și Windows. Și acuma urmează studiul (da, culmea. Abia acuma ma intereseaza ce voi folosi, si de ce). Bun, le luăm pe rând:
- Pentru Android, ce am nevoie? Știu că am nevoie de un framework pentru DI (conform arhitecturii). Ok, mă ajută Dagger ...? Și aici iarăși putem discuta 10 pagini. La fel și pentru alte platforme..
- Am ales ca software Arch. pattern MVVM: Androidul mă ajută, mai ales începând cu integrarea in AAC. Ce variante am in Windows? Păi am MVVMLight .... etc.

Dacă aș fi acordat 5 ani unei anumite tehnologii, nu cred că eram in stare să fac tot ce am scris mai sus. Adică, să le și înțeleg... și să le exersez....

Eu nu am să mă consider (și nici nu vreau să fiu Senior), nici după ce o să am la activ proiecte de ordinul zecilor și nici documentații ,,citite” de ordinul zecilor de mii de pagini... (sunt doar la nivelul miilor).

Momentan mă concentrez pe proiect, lucrez project-oriented, iar in momentul implementarii propriu-zise acord timp si studiului. Și uite, îți dau un exemplu: voi avea nevoie de partea de A.I. (oferirea unor predictii de evolutie/prognostic conform tabloului clinic al unui pacient), pentru care Python ma va ajuta enorm. Apropo - nu am lucrat in Python.

Poate nu sunt cel mai productiv programator/inginer, si sunt constient ca in general nu sunt ceea ce se cauta. (in primul rand, experienta limitata + poate si viziunea mea din postul precedent). Eu ma simt multumit daca aduc plus-valoare societatii prin munca mea, sau daca suntem 4-5 persoane/proiect, care muncim cot-la-cot, chiar daca, pentru a fi remunerat faci un efort suplimentar (poate chiar triplu). Si, mai mult decat atat, banii nu vin instant, lunar la data fixa. (si nu - nu ma refer doar la freelanceri, macar refer chiar si la mici firme de genul start-up).

Fara sa-mi permit sa ma raportez la un asemenea monstru din industria IT, dar dau ca ex. Facebook care a inceput dintr-o joaca. Joaca a 5 studenți colegi de cameră la Harvard. Sunt multumit daca munca mea are macar a 100.000-a parte din impactul adus de Mark !   (si cred ca asa gandesc si firmele care nu se uita, avid, doar dupa profit ... instant daca se poate).

Edited by MarianG, 16 February 2020 - 20:32.

Rhesus, on 16 februarie 2020 - 17:39, said:

Una e limbajul, alta e biblioteca/frameworkul.

De la al 4-lea limbaj în sus, a învăța un limbaj e o banalitate. Dacă susții că ai programat în n limbaje, dar nu răspunzi corect la întrebarea cu referințe, atunci pun ceea ce spui sub semnul întrebării.

Deasemenea, la un interviu îmi place să văd și să iau în calcul skill matrixul tău.


Acest skill matrix are următorul format:

Secțiuni pentru: limbaje de programare, tehnici/metodologii/principii/practici, librării/frameworks, unelte, diverse, diferite limbaje/APIs.

Fiecare skill are coloanele: nume, nivel (1-5), ani de experiență și ultimul an folosit.


Dacă de exemplu văd un skill matrix stufos în acest format și faci o greșeală minoră la un skill la care nu susții că ai fluenta mare (ai nivel 1-3, nu 4-5), atunci înțeleg. Dar dacă susții că ești la un nivel ridicat, dar nu știi limbajul, atunci te-am ars.

Nu suport minciuna.

Dacă ești sincer si transparent cu ce știi și ce nu știi, ai o bilă albă.

Dacă îmi spui sincer "cred că referințele se fac cu & in C#, dar nu sunt sigur. Știu sigur ca în C++ asta e sintaxa, dar pot împrospăta rapid C#", iar punctezi.

Dacă ai doar C# pe lista de limbaje și greșești răspunsul, atunci te evaluez la nivel novice.

99% dintre aplicanți susțin că sunt mult peste nivelul la care sunt de fapt.

Știu asta pentru că și eu făceam așa la inceput.

Ff 10+ ani și am skill matrix atât de masiv încât nu mai e nevoie. Pentru că nu am stat pe scaun și am așteptat să treacă numărul de ani, ci chiar am lucrat la skill matrix.

La fel ca tine.