Foarte multi spun că performanta la interviu cântărește enorm. Dar cum poate cineva in 2h să își facă o idee despre ce știi să faci când la majoritatea interviurilor se întreabă teorie sau probleme de algoritmica? In practica, de obicei, rar implementezi algoritmi sau structuri de date sau te gândești la teorie despre programare prea mult. De obicei se face mult debug, se implementează chestii care presupun lipirea de apeluri la biblioteci, de multe ori interne ( se pierde timp citind documentație).
Depinde de nivel. Daca e junior ar trebui sa fie usor sa-l evaluezi pe baza performantei la interviu, si nu doar pe baza de teorie si probleme. Aprofundezi unul doua subiecte si vezi cat de mult stie, si cum judeca cand nu mai stie.
Daca nu e junior poti evalua in ce masura experienta este reala, si cum a asimilat-o. A mers mai adanc in vreo problema, sau s-a multumit sa citeasca documentatie. Cu ceva timp in urma imi povestea un coleg de un candidat cu peste 10 ani experienta care in realitate nu stia decat partial o tehnologie, si atat.
Oricum problema e falsa. Ca intervievator trebuie sa-l evaluezi pe baza interviului. Te poti folosi de CV ca sa te ajute in structurarea interviului, si poti eventual dupa sa confirmi daca experienta e reala sau nu. Dar nu e responsabilitatea intervievatorului sa decida care conteaza mai mult, si daca candidatului ii va fi facuta o oferta sau nu.
Cel care ia decizia se uita si la opiniile intervievatorilor, si la experienta. Daca exista o diferenta prea mare intre evaluare si experienta poate cere clarificari, sau in cazuri foarte rare inca un interviu.
Performanța vine după experiență. Rar vezi pe cineva performant și cu putință experiență, poate doar local.
O concluzie personală este că un programator trebuie să învețe continuu, și trebuie să învețe pentru el. Dacă te complaci undeva călduț, nu te deranjează nimeni iar suma care intră în cont te mulțumește, după ceva timp vei realiza că rămâi în urmă cu cunoștințele pentru nivelul tău de experiență. Continuarea cred că ți-o poți imagina.
S-ar putea să nu fie răspunsul pe care îl cauți, dar sper că te ajută.
Performanta vine din intelegerea problemei/afacerii pentru care dezvolti. Poti sa fii cel mai rapid programator si sa stii C++ pe de rost, ca daca lucrezi pe o aplicatie medicala si nu intelegi procesul care trebuie implementat, nu faci mare lucru.
Deseori ca programatori gandim simplist: apelez un API, iau niste date, fac o pagina, omul alege, pun ceva logging, ceva validari si totul e roz.
Problema e ca nu poti folosi API-ul ala asa cum vrei, sunt anumite date care nu ti-e permis sa le folosesti legal. API-ul ti le da, contractul pe hartie zice altceva. Tu implementezi linistit si firma ajunge sa aiba probleme.
Sigur, lucrurile astea ar trebui clarificate de cineva din departamentul legal, dar…
Eu unul consider ca partea tehnica e acolo un 30%. Important e ca omul sa jongleze cu lejeritate cu structuri abstracte, sa le mute/roteasca/redenumeasca/extinda/grupeze astfel incat codul sa arate bine dar mai important: codul sa descrie un proces natural. Nu ceva cu tone de exceptii si IF-uri si clase similare dar nu prea similare.
Contează performanța, cât și experiența (nu neapărat industrială, dacă vorbim de juniori).
Contează să impresionezi prin ceva (creativitate, comunicare, inteligență). Nu trebuie să fii neapărat foarte tehnic. Oamenii evoluează în timp. Din păcate, la noi contează destul de mult să minți în CV și să știi 10001 framework-uri.
De ce zici ca partea tehnica e 30%, poti sa aprofundezi putin aici? Eu eram surpins de proces, in general lumea lucreaza pe proiecte banele, de mentenanta si cu 2-3 saptamani (uneori zile) invata teorie despre design patterns si probleme si merg la interviu. Dar daca el lucreaza de 3 ani intr-o firma, si la interviu il intreaba numai din teoria aia invatata in 2-3 saptamani, nu se testeaza cu adevarat ce stie sa faca omul.
E usor sa inveti IF/WHILE/FOR, e usor sa inveti despre tipuri de date sau clase, la fel cum e usor sa inveti cum te contectezi la baza de date si sa scrii query-uri.
Ce nu e usor e sa lucrezi cu limitarile date de business/afacere. De pilda noi ne luptam cu faptul ca toate preturile sunt in centi. Deci 100 de euro se scrie ca 10000. Si daca omul uita de regula asta, codul lui care de altfel e foarte bun, da rezultate gresite. Preturile in fiecare API vin diferit, le afisam diferit in functie de pagina, dar in baza de date trebuie mereu sa fie in centi.
Eu nu am mari asteptari de la firme si de la procesul lor de recrutare. Au si ei criteriile lor care pot sau nu sa coincida cu ale mele. Eu vreau sa lucrez cu oameni destepti si independenti. Oameni carora le explic o data si inteleg. Si cu atat mai mult apreciez un om care face ceva intr-o saptamana (in loc de 2 zile) dar care e robust (nu da exceptii/warning-uri/crapa din orice motiv), sigur, performant si a carui cod e usor de citit.