Salariu in functie de skill vs experienta

Salut! As dori sa aflu de la cei putin mai veterani cum se negocieaza salariile in IT. Normal ar fi sa primesti oferta in functie de skill-ul pe care il ai. Dar in 2-3-6 interviuri de 1-2 ore e posibil sa nu ai ocazia sa arati cam ce poti. In cazul asta, ce rol are experienta trecuta in cv? Doar le povestesti ce ai facut la firmele trecute si pe baza asta decid ei ce stii. Eventual la cateva luni de la angajare daca vad ca ai skill iti maresc leafa?

Salut. Eu sunt ceva mai veteran, dar pot sa-ti dau opinia mea. In functie de experienta care o ai in CV firmele te claseaza in junior, middle, senior, lead sau ceva de genul asta, pentru ca in general cand au o pozitie libera ea este incadrata in clasele astea.
Ai dreptate, in alea 1 -2 ore de interviu nu ai cum sa arati tot ce sti, si nici nu e asta ideea. In general cei care te intervieveaza vor sa afle cum gandesti, cum abordezi o problema, si daca ai niste cunostinte de baza. Si nu in ultimul rand ce fel de personalitate ai, daca te-ai integra usor in echipa/companie. Restul se bazeaza impresia care o produci. Evident in afara unor cazuri exceptionale cand sunt niste pozitii foarte specializate si acolo chiar vor sa afle ce skilluri ai.
Exceptia sunt firmele gen google, facebook etc, unde multele interviuri prin care treci au rolul de a filtra din candidati, sunt intentionat cat mai dificile posibil.
Treaba cu maritul salariului dupa cateva luni nu prea se intampla, in general anual se face o re-evaluare si daca chiar e cazul (gen ai fost angajat ca junior dar te descurci ca un middle) poti si mutat pe o treapta de salarizare superioara.
Bun, ceea ce povestesc eu e valabil mai mult in firme mari, corporatii, firmele mici nu au un proces asa strict.

1 Like

Diferențierea de junior/middle/senior/lead mi se pare ciudată. Adică din punctul meu de vedere există două categorii: Ai rezolvat problema sau nu.

Dacă nu, mă uit la:

  • Ai documentația completă? Dacă nu, ei bine, e normal să nu rezolvi problema.
  • Ți s-a explicat problema? Ah, nu, că ai primit un task cu descrierea „Mi se pare că ceva nu merge”. Clar, tot nu-i vina ta.

În schimb dacă ai și documentația și explicația problemei și nu știi să o rezolvi, well sorry, dar nu că nu ești junior, dar nu ești programator.

Anyway, foarte mult văd că managerii se bazează pe „Las’ că știe băiatul”. Îi aruncă un task și apoi el se cară. Și apoi iese o porcărie și la următoarea întâlnire dintre manager și client: Păi uite, n-am avut buget decât de niște juniori. Nu nene, nu te-ai ocupat să îi dai omului materialele necesare și să pregătești treaba, ești numai tu de vină.

Sau mai rău, încep cu întrebări de genul: Dar cât estimezi că o să dureze? Care e problema pe care vrei să o rezolvi?

Scuză-mă, dar eu sunt plătit să programez, nu să fac estimări sau să-ți fac ție munca. O să dureze cât trebuie să dureze. În programare nu poți să aloci 2 ore pentru ceva și la finalul lor te oprești din muncă și cât e făcut, asta e. Fie treaba e făcută până la capăt, fie nu e făcută deloc.

(Îl iubesc pe managerul ăsta. Nu merge baza de date. O repornește. Nu merge un server. Hai că-l repornesc. Are mereu soluția la toate, le repornește. Mama lor de coate-goale.)

1 Like

Multumesc pentru raspuns. Deci marile corporatii nu vad asa bine in detaliu, vad candidatii mai blurat. Gen ai terminat facultate, ai x ani experienta, ai cutare? Bun, te angajam. Fara sa ia prea puternic in calcul si ce ai facut in fiecare din etapele astea? Adica asta e logica, nu?

Conteaza ceea ce ai facut in masura in care este relevant pentru pozitie, adica daca sunt skilluri necesare pentru ea. Si da, in general se bazeaza pe experienta ca sa te inscrie in niste trepte de salarizare si responsabilitate.

1 Like

Funcția asta este o functie variadică. O grămadă de alte argumente trebuie luate în calcul - piață, firmă, proceduri, grilă salarială, buget, pregătirea, starea și interesele intervievatorilor; nu mai vorbim de sex, vârstă, religie, aspect fizic etc. Nici cercetătorii britanici nu au găsit încă o formulă cât de cât acceptabilă.

Ce poți face e să mai reduci din numărul argumentelor (să le fixezi) și să cauți o formulă particularizată pentru un anumit context. Cu alte cuvinte, pentru un anumit job te vei informa detaliat despre firmă, manageri, colegi, foști angajați, persoanele care te intervievează etc și tragi niște concluzii.

Extrem de rar. Chiar dacă veți stabili asta la angajare, de regulă, o mărire este greu de obținut ulterior. Dacă ai skill-uri și dacă acestea sunt într-adevăr esențiale pentru firmă, te ajută să obții o mărire de salariu în momentul în care anunți că ți-ai găsit în altă parte.

1 Like

Deci să înțeleg că ție, ca programator, nu ți se poate cere o estimare? Înțeleg că unele lucruri sunt mai greu de estimat, mai ales dacă implementezi pentru prima oară ceva funcționalitate, dar în general cred că ar trebui să știi cu aproximație cât timp îți va lua. Știi codebase-ul, știi ce feature-uri se cer, ar trebui să cam știi ce ai de făcut și cât îți ia.

Cum facem cu situația asta versus „nenorocitul de PM mi-a estimat prea puțin, ce bou e”. Nu-ți convine nici să-ți normeze alții munca, dar nici să o faceți împreună. Care e situația ideală?

2 Likes

În cazul proiectelor la care activez:

  • Documentația e în PDF-uri de sute de pagini. Nu că nu am chef să citesc, doar că mereu apar alte probleme de la:
  • Baza arhitecturii e la pământ. Managementul a decis la început ca baza de date nu e o prioritate. Acuma in fiecare zi ceva crapă si, desigur, trebuie reparat imediat;
  • codebase-ul la un proiect mare e scris de cineva care a învățat programare în timp ce-l dezvolta. Unele chestii merg ușor, unele lucruri sunt puse acolo fără rost și nici el nu mai ține minte de ce a pus un lucru sau altul în cod. Am lucrat la ceva săptămâna asta, 80% era balast.

Așa că estimarile sunt inutile. Am incercat de 2 ori, am vazut ce probleme au aparut pe parcurs si nu mai fac. Zilele trec cam asa: planuiesc sa lucrez la ceva. Dupa 5 ore mi-am dat seama ca am rezolvat alte chestii care au apărut pe parcursul zilei și nu am făcut nimic din ce mi-am propus.

Și management-ul încearcă să dreagă busuiocul acum. Adică dacă aș putea eu să lucrez 12 ore să repar toate deciziile proaste făcute de-a lungul anilor ar fi foarte fain. Și nu e ca și cum nu le-am atras atenția de vreo sută de ori.

Per ansamblu sunt 5 proiecte. Dacă aș putea să le fac pe toate, that would be just grand.

1 Like

Vorbim de estimări sau de time management? Una e faptul că estimezi că un task îți ia 8 ore dacă lucrezi doar la asta, iar timpul de implementare este cu totul altceva, mai ales dacă faci în timpul ăsta și suport sau bugfixing. În continuare, ție ți se pare normal să nu poți să estimezi cât îți ia task-ul X în condițiile în care ai funcționalitatea descrisă și știi codebase-ul? Dacă tu ai fi manager ai accepta „da” la întrebarea asta?

Fericitule. La mine sunt mii de pagini, si e incompleta si foarte proasta :slight_smile:

1 Like

Păi am început să fac și eu management. Cu omul cu care lucrez stau la începutul task-ului cu codul în față. Ne uităm amândoi, vedem ce trebuie făcut, ce avem și scriem ce lipsește.

Apoi are o listă cu pașii care trebuie să-i urmeze. La sfârșitul implementării ne uităm iarăși împreună peste cod, mai punem un spațiu, mai așezăm o acoladă, mutăm o constantă și dăm commit la cod.

El nu primește 3 cereri suplimentare pe oră. Plus că nu el îmi estimează cât îi ia, eu estimez cât îi acord, mai ales că are totul mură-n-gură.

Managementul adoră să dea ordine. „Ia să facem asta, te ocupi tu?”, „Cum merge cu ailaltă, totul ok?”. Când începe să vorbească cum e construită aplicația, 80% din timp habar nu are despre ce vorbește. Cred că în ultimii 3 ani nu s-a uitat 5 minute peste o linie de cod. Și trăiește cu impresia că ceva a fost implementat acum 6 luni când de fapt, țeapă, nu a fost timp suficient și treaba a fost mutată pe „altă dată”.

Offtopic: @RedGuard din cate povestesti esti overqualified pentru proiectele la care lucrezi.

Ontopic: Intr-adevar conteaza experienta, insa nu am intalnit situatii in care cunostintele tale sa nu fie luate in considerare in momentul in care se face o oferta. Intr-o discutie tehnica de 1-2 ore iti poti face o imagine de ansamblu despre cunostintele candidatului, eventual cateva exercitii/probleme in care sa vezi felul cum abordeaza problema.

In cazul in care asteptarile tale nu coincid cu oferta primita, vad doar doua situatii: fie incerci o negociere (le explici/dovedesti motivele pentru care ai respectivele asteptari financiare), fie cauti in alta parte.

2 Likes