Am scris ceva: 7 career anti-patterns for your developer job search

[horia141 (Horia Coman)]

@kilogrammer

Intreb serios, cum functioneaza treaba asta. Mai stiu companii care spun asta. Adică, dacă n-am lucrat deloc cu NodeJS de pilda, Ma accepta firma ca voi fi noob dar ma plătește ca un avansat? Așa de darnici sunteți?

Da. Vasta majoritate a inginerilor n-a pus mana pe Node sau TypeScript pana sa vina la noi. Cred ca avem 1-2 cu experienta intr-un mediu de productie. 90%+ din bagajul de cunostinte, practici, modele, etc ale unui dev sunt independente de limbaj sau tool-uri. Daca e nevoie de un cache intr-un sistem pentru ca $motive, nu cred ca il pui daca folosesti Java, si uiti daca folosesti Ruby.

Interviurile de coding sunt in ce limbaj vrei tu. Doar sa poti sa explici ceiluilalt ce se intampla.
Interviul de system design e o discutie in principiu. Poate mai schitam niste diagrame.

Idealul nostru - si cred ca unul bun in general - pentru un “test” de interviu este sa fie simplu de inteles, agnostic de background, si cu potential adanc de explorat. Nu atingem acest nivel ofc. In special din cel de system design iti dai seama de experienta anterioara a omului, cum a gandit proiecte mari in trecut, cum a sapat prin diverse sisteme (DB-uri, sisteme distribute, etc.), cum intelege teoria, cum o aplica intr-un caz dat, cum se gandeste la NFR-uri, etc.

Apoi dupa cum ziceam si in articol, majoritatea oamenilor de pe backend fac un release in prima sau a doua saptamana. Inainte era chiar in primele zile, dar am mai marit procesul de onboarding global. In particular cu Node, cel mai mare challange e sa te adaptezi la control-flow-ul mai special wrt “the event loop”. Dar asta dureaza cateva ore de citit sau consultat cu vre-un coleg la indemana. In rest daca ai folosit Spring/ASP.NET/Laravel/Django/RoR/etc e usor sa intelegi framework-ul intern.

In 3.5 ani de cand sunt aici chiar n-am auzit pe nimeni din 400+ ingineri cati au trecut prin zona de backend sa se planga ca nu s-a adaptat la Node. O fi ceva de Node. Si cu siguranta daca alegeam Haskell avam alta discutie, dar e o plaja mare mare de echivalenta tehnologica in care poti presupune ca un om Senior o sa-si pastreze competenta.

[anon31094663]

@horia141

90%+ din bagajul de cunostinte, practici, modele, etc ale unui dev sunt independente de limbaj sau tool-uri

Big like pentru treaba asta.

Cunostintele de limbaj si tool conteaza doar pe proiecte simple, pe termen scurt.
O data ce e vorba de un proiect de amploare, un dev bun care nu cunoaste tool-urile si limbajele folosite la proiect bate unul slab care le cunoaste. Pur si simplu le invata iar skill-urile ii permit sa recupereze si sa depaseasca.

Mai e ceva ce conteaza mult mai mult decat tool-uri si limbaje: domain knowledge. In unele cazuri (sa zicem mai catre extreme) e preferabil sa-l inveti pe unul tabula rasa cu software-ul sa programeze, decat invers, sa iei unul care-i meserias la software si sa-l inveti cunostintele despre domeniu.

[AlleXyS (Alexandru Tudor)]

eu am plecat de la 3 ani de .Net Core pe Scala (incadrat ca mid). Majoritatea anunturilor sunt cu X ani experienta in limbajul Y. Sunt si companii care gandesc mai departe decat cifrele astea.

Greu la inceput, tot ce aveam de rezolvat, ma gandeam cum as fi facut-o in vechiul limbaj, iar dupa ce rezolvam, cautam best practices, de ce rezolvarea a e mai buna decat b

[iamntz (Ionuț Staicu)]

@kilogrammer

Adică, dacă n-am lucrat deloc cu NodeJS de pilda, Ma accepta firma ca voi fi noob dar ma plătește ca un avansat?

Dacă stai puțin strâmb și gândești drept, diferențe prea mari între PHP, Ruby și Python nu sunt. Sigur, sunt mici chestii de sintaxă sau de tooling diferite, dar conceptele sunt aceleași.

Cred că 90% dintre problemele avute de mine când am codat în alte limbaje au fost doar de tooling (e.g. „cum funcționează pip vs composer?”) nicidecum de „ce e ăla un array?”.

Dacă vrei, e ca și cum vorbești cu un italian: chiar dacă nu știi toate dedesupturile limbii, prinzi suficient pentru a înțelege ce vrea să spună interlocutorul.

---

Ceea ne duce la următoarea întrebare (fac fork mai târziu dacă e nevoie): experimentați cu alte limbaje, ce nu le folosiți „în producție”? (i.e. just for fun)

[kilogrammer]

Cunosc si eu bine aceasta abodare, si am lucrat in proiecte cu limbaje sau/si tehnologii pe care nu le stiam. E de notoriotate ca tehnologiile se schimba la 3-5 ani.

@horia141

90%+ din bagajul de cunostinte, practici, modele, etc ale unui dev sunt independente de limbaj sau tool-uri.

90%? Adica mai putin de 10% din tot ce tinem in cap e specificitatea limbajului + a framework-ului + a librarariilor + a toolingului?

Come on.

Da, in toate limbajele or fi existand variabile, operatori, functii (clasele sunt oricum tot functii) sau da, toate librariile au API, sau da, toate tooling-urile au o configurare, dar fiecare are foarte multe specificitati. Foarte multe.

Daca inmultim cu un 2,3 limbaje si tehnologii nu vad cum toate astea ar fi sub 10%. Sau vorbim atunci de genii? Zi-mi te rog daca voi angajati numai genii, asa stiu despre ce vorbim. Eu nu ma calific.

@horia141

, cum a gandit proiecte mari in trecut, cum a sapat prin diverse sisteme (DB-uri, sisteme distribute, etc.), cum intelege teoria, cum o aplica intr-un caz dat, cum se gandeste la NFR-uri, etc.

Foarte corect, dar eu vad asta ca un skill si topic separat.

@horia141

In 3.5 ani de cand sunt aici chiar n-am auzit pe nimeni din 400+ ingineri cati au trecut prin zona de backend sa se planga ca nu s-a adaptat la Node. O fi ceva de Node

Eu nu m-am referit la incapacitatea cuiva de a putea sa-si insuseasca si sa lucreze cu ceva nou. E ca si cum ai spune ca unui miner ii e frica de intuneric.

Indoiala mea e legata de chestiuni practice, care ma intereseaza direct: salariul oferit.
Oferiti acelasi salariul cuiva care are zero experienta in NodeJS exact ca a unuia care are 15 ani de experienta?
Poate da, si face sens daca 1) ce face omul respectiv nu e ceva foarte complicat, e mai mult business logic, si 2) daca are suportul necesar, exista code review si guidance adevarate.

@AlleXyS

Greu la inceput, tot ce aveam de rezolvat, ma gandeam cum as fi facut-o in vechiul limbaj, iar dupa ce rezolvam, cautam best practices, de ce rezolvarea a e mai buna decat b

Asta e abordarea corecta, felicitari pentru pasiunea de a face lucrurile cum trebuie.
Dar gandeste-te ca esi tu angajatorul, success in a-ti da seama de la interviu ca Gigel va avea toata daruirea necesara sa faca asta, every day, si dandu-i salariul ca unui senior in acele tehnologii, desi n-a lucrat deloc deloc cu ele. Caci despre asta e vorba.

@iamntz

Dacă stai puțin strâmb și gândești drept, diferențe prea mari între PHP, Ruby și Python nu sunt. Sigur, sunt mici chestii de sintaxă sau de tooling diferite, dar conceptele sunt aceleași.

Conceptele sunt aceleasi, n-am zis asta. Dar de la concepte pana la practica e cale foarte lunga.
Pune tu un developer care are experienta doar cu programarea pe desktop in Windows si care n-a lucrat deloc pe web, sa se ocupe de o aplicatie web cu tot ce tine de tooling si configurare (webpack). Dupa cateva zile in care tu esti cel care te ocupi sa il ajuti, productivitatea la voi doi va arata ca o problema de fizica lichidelor, cu doua vase comunicante

[iamntz (Ionuț Staicu)]

@kilogrammer

Pune tu un developer care are experienta doar cu programarea pe desktop in Windows si care n-a lucrat deloc pe web, sa se ocupe de o aplicatie web cu tot ce tine de tooling si configurare (webpack).

Evident că nu va fi la fel de productiv ca cineva cu ani în spate și nu va ști toate dedesupturile limbajului/framework-ului. Dar în una-două luni e up to speed. Coroborat cu faptul că oricum este nevoie de trei-șase luni pentru a asimila^[1] un coechipier, eu cred că e rezonabil.

Știu că e anecdotic, dar cunosc oameni care nu au avut probleme^[2] în a schimba complet limbaje: de la .net la PHP sau de la PHP la Go. Tranziții făcută în câteva săptămâni.

---

1. borg style ↩︎

2. au avut cel mult nemulțumiri, că în limbajul nou se fac lucrurile greșitdiferit față de limbajul vechi. ↩︎

[kilogrammer]

@iamntz

Știu că e anecdotic, dar cunosc oameni care nu au avut probleme[2] în a schimba complet limbaje: de la .net la PHP sau de la PHP la Go. Tranziții făcută în câteva săptămâni.

Nu mi se pare anecdotic. Eu am trecut prin asta. Dar nu cred ca putem generaliza. Ideea mea e ca depinde de ce taskuri ai.

[RedGuard (Red)]

Și noi avem oameni care au început cu PHP la noi, venind de pe alte tehnologii, și acum sunt mai buni ca mine.

[tacheshun]

Framework dev vs Fundamentals dev (opinie interesanta aici de la minutul 38). Eu unu am fost un framework dev la un moment dat. Am realizat mult prea tarziu ca de fapt fundamentele conteaza mult mai mult. Ma bucur totusi ca am realizat intr-un final.

Se leaga foarte bine si de specificul companiilor romanesti si cum vad ele oamenii tehnici.Cost Centers vs Profit Center, primul tip de companie intalnindu-se intr-o proportie mult prea mare in Romania, din pacate.

Un Cost Center nu e interesat de “fundamentals guys”. Pentru ca are clienti care vor azi in productie un wordpress customizat ca sa porneasca o campanie. E ok, si se fac bani din asta, tot dev esti, dar nu ai cum sa speri la salariile unor companii din partea cealalta. Aia care vad programatorii drept Profit Center.

Un Profit Center nu este interesat de “framework guys”. Un framework guy face misto de interviurile unde esti intrebat algoritmi si structuri de date pentru ca asa e cool si “cand a trebuit tu sa scrii un mergesort de la 0 la jobul curent?”. Realitatea insa e alta: un “fundamentals guy” invata un framework in cateva saptamani.

Fundamentals* insa, pentru majoritatea framework guys, se invata in ani si doar cu efort si multa dedicatie. Mai ales dupa o anumita varsta. Vorbesc din prioprie experienta.

Daca esti un Profit Center si ai un produs cu multe sute de mii de useri concurenti, te intereseaza foarte mult ca programatorii tai sa aiba macar idee de Big O notation. Nu mai intru in detalii ca e evident unde bat.

• • prin Fundamentals ma refer la BigO notation, algoritmi, structuri de date, tehnici de programare, dar si system design, networking, sisteme de operare(si nu, nu ma refer la cum sa minimizezi ferestre in macos).

[anon31094663]

Gata, m-am convins!

Limbajul si framework-urile sunt mai importante decat cunoasterea fundamentelor, etc.

O sa le trimit un e-mail la astia sa schimbe descreierea jobului: https://careers.astrazeneca.com/job/gothenburg/principal-scientist-computational-chemistry/7684/15723242784

Sa treaca la cerinte obligatorii python si machine learning (neaparat detaliat la nivel de framework-uri, nu asa), si doar la eventuale plusuri toate celelalte, e clar ca python e cel mai important acolo

[mih11]

@tacheshun

Un Cost Center nu e interesat de “fundamentals guys”. Pentru ca are clienti care vor azi in productie un wordpress customizat ca sa porneasca o campanie. E ok, si se fac bani din asta, tot dev esti, dar nu ai cum sa speri la salariile unor companii din partea cealalta. Aia care vad programatorii drept Profit Center.

De unde impresia asta ca firmele de tip cost center fac doar proiecte superficiale?

[tacheshun]

Ma gandeam eu ca exemplul cu wordpress poate nu este cel mai bun…

Nu neaparat ca fac proiecte superficiale cat vad oamenii tehnici ca un rau(cost) necesar.

De aici rezulta mai multe efecte: Management supra-dimensionat(am lucrat intr-o companie care avea urmatoarele layere de management tehnic: Tech lead, Manager, Senior Manager, Director, Senior Director, VP of Engineering, SVP of Engineering si CTO), prezenta unor pozitii dedicate de pseudo-management precum Scrum Master sau Agile Coach(pozitii care nu aduc valoare), tracking pe timp lucrat pentru masurarea efortului pe taskuri, samd.

O companie ca Uber de exemplu, care pretinde ca vede angajatii ca Profit Center, are o ratie de 50 de engineers la 1 product guy/girl. Nu ajungi manager in niciun layer daca nu stii sa scrii cod, nu au pozitii dedicate pentru SM/AC, si lista poate continua. Uber e doar un exemplu pe care il cunosc. Dar mai sunt o gramada companii inclusiv in RO care fac asta. Doar ca nu se lauda suficient cred.

[serghei (Serghei Amelian)]

@tacheshun

Tech lead, Manager, Senior Manager, Director, Senior Director, VP of Engineering, SVP of Engineering si CTO), prezenta unor pozitii dedicate de pseudo-management precum Scrum Master sau Agile Coach(pozitii care nu aduc valoare), tracking pe timp lucrat pentru masurarea efortului pe taskuri, samd.

Asta sună mai degrabă a banc

Managerii americanii si cei japonezi au decis sa se intreaca intr-un concurs de canotaj. Ambele echipe s-au antrenat din greu. In ziua cea mare, se simteau pregatiti. Japonezii au castigat cu un avans de doi kilometri. Americanii au fost extrem de descurajati ca au pierdut. Moralul lor s-a prabusit.

Managementul a decis ca motivul unei infrangeri atat de zdrobitoare trebuie aflat, asa ca au angajat o firma de consultanta care sa investigheze problema si sa recomande actiuni corective.

Consultantul a aflat ca echipa japoneza a avut opt oameni la vasle si unul la carma; americanii au avut un om care vaslea si opt oameni la carma. Asa ca, dupa un an de studii si milioane de dolari cheltuiti ca sa analizeze problema, firma de consultanta a ajuns la concluzia ca sunt prea multi oameni la carma si prea putini la vasle in echipa americana.

Pe masura ce se apropia ziua cursei din anul urmator, structura manageriala a echipei americane a fost complet reorganizata. Noua structura cuprindea: patru manageri de carma, trei manageri zonali de carma si un nou sistem de urmarire a performantelor pentru omul de la vasle, ca sa i se asigure stimulent in munca.

Anul urmator, japonezii au castigat cu un avans de patru kilometri.

Umiliti, cei din corporatia americana l-au concediat pe vaslas pentru performante slabe si au acordat managerilor o prima, pentru ca au descoperit unde era problema.

[geosoft1 (George Calianu)]

Sigur bancul e cu americani? Ca pare mai mult cu … romani?

[scheffgames (Adrian Larion)]

@serghei

Managerii americanii si cei japonezi au decis sa se intreaca intr-un concurs de canotaj. Ambele echipe s-au antrenat din greu. In ziua cea mare, se simteau pregatiti. Japonezii au castigat cu un avans de doi kilometri. Americanii au fost extrem de descurajati ca au pierdut. Moralul lor s-a prabusit.

Asta imi aminteste de cealalta povestioara cu japonezi si americani:

Americanii comanda de la o firma japoneza niste piese. Ei specifica un numar de maxim 3 piese defecte la 10,000 piese bune.
Japonezii satisfac comanda si trimit 2 cutii. Una cu 10,000 de piese bune. Una cu 3 piese defecte - per specificatii

[tekkie (Georgiana Gligor)]

@anon31094663

O sa le trimit un e-mail la astia sa schimbe descreierea jobului: https://careers.astrazeneca.com/job/gothenburg/principal-scientist-computational-chemistry/7684/15723242784

Atata ca acesti oameni nu cauta un programator, ci un scientist care isi poate materializa conceptele in cod. Dovada:

We are looking for a drug hunter with a PhD (or equivalent experience) in computational chemistry

Si nu se asteapta sa fie direct productizabil codul noului angajat. La noi echipe intregi productizeaza outputul scientistilor.

[anon31094663]

@tekkie

Atata ca acesti oameni nu cauta un programator, ci un scientist care isi poate materializa conceptele in cod.

Nu cred ca exista vreun programator undeva care nu materializeaza niste concepte in cod.

In cazul asta e o situatie mai particulara, conceptele sunt ‘ceva’ mai complicate… din nou o situatie mai spre limita pentru a iesi in evidenta ceva.

[horia141 (Horia Coman)]

@kilogrammer

90%? Adica mai putin de 10% din tot ce tinem in cap e specificitatea limbajului + a framework-ului + a librarariilor + a toolingului?

I stand by this claim. Poti sa o iei si ca “marea majoritate” a knowledge-ului.

Poate merita nuantat aici. Clar daca ai nevoie de un update la WordPress aduci un expert WP sa-ti faca treaba asta. Sau daca vrei sa optimizezi niste query-uri SQL suparate aduci pe cineva priceput. Ca proiect, sau permanent. Dar din nou, astea sunt 1% din munca intr-o organizatie mare de produs. Desi poate sunt 99% dintr-un consulting shop.

@kilogrammer

Indoiala mea e legata de chestiuni practice, care ma intereseaza direct: salariul oferit.
Oferiti acelasi salariul cuiva care are zero experienta in NodeJS exact ca a unuia care are 15 ani de experienta?

Da. Node nici nu apare in discutia de interviu decat ca raspuns la intrebarea candidatului “ce tech stack folositi?” Exista diferentiere ofc la compensation, dar experienta cu NodeJs (sau cu vre-o tehnologie speifica) nu e un parametru. Ne uitam la chestii gen experienta cu sisteme distribuite, big data, etc. Si cineva care e ft strong in zona asta are alt fel de “deal” decat cineva care vine cu experienta de alt gen (sa zicem embedded).

@kilogrammer

Poate da, si face sens daca 1) ce face omul respectiv nu e ceva foarte complicat, e mai mult business logic, si 2) daca are suportul necesar, exista code review si guidance adevarate.

Sunt confuz. Ce anume ar trebui sa faca devs intr-un business daca nu “business logic”? Si poate sa ajunga extrem de complex

[mih11]

La Nokia erau la un moment dat mai mult de 7 nivele de la CEO pana la “regular Joe” si chiar aveau rolurile pe care le-ai enumerat Eu eram undeva la 10 nivele distanta de CEO si tin minte ca s-au decis sa introduca limita asta de 7 nivele. Au comprimat atunci cateva nivele inferioare si au rezolvat problema.

Uber nu cred ca e peste tot profit center, de exemplu m-as astepta ca daca ar avea site-uri de dezvoltare in Polonia, Romania, etc, sa fie centre de cost care nu se axeaza pe maximizare de profit ci pe optimizare de costuri la nivel global in companie.

[wooot]

@mih11

Uber nu cred ca e peste tot profit center, de exemplu m-as astepta ca daca ar avea site-uri de dezvoltare in Polonia, Romania, etc, sa fie centre de cost care nu se axeaza pe maximizare de profit ci pe optimizare de costuri la nivel global in companie.

Uber inca nu face profit, cum nu fac nici majoritatea ‘unicorn’ -urilor sau alte cornurilor (lyft, doordash,revolut etc etc ). Profitul nu a fost/e un important pas strategic, deci e greu de dezbatut un statut de profit center in momentul de fata.

Probabil nici Bolt nu face profit vazand pierderile anuale si marketingul agresiv, dar aici @horia141 ne poate spune mai multe.

Idea acestor businessuri este de a crea monopoluri, care pot aduce o gramada de bani intr-un timp foarte scurt, dupa care pot deveni prea mari sa se prabuseasca.