Zadania rekrutacyjne - wezwanie do bojkotu

5

@szydlak:
Ja jestem zdania, ze w ogole code review jest jedna z najlepszych form wspomagajacych rekrutacje, bo:

  1. Kazda firma moze sobie wygrzebac jakiegos starego MRa gdzie cos refactorowali, wyizolowac ten fragment i dac osobie postronnej nie ujawniajac przy tym jakichs wrazliwych informacji.
  2. Mozliwosci sa nieograniczone, mozna tam wplesc bugi, nieoptymalne implementacje n^2 z calkiem prostym rozwiazaniem itd.
  3. Jest to genialne wprowadzenie do glebszych rozmow z kandydatem, bo mozna sprawdzic jego tok rozumowania, postrzeganie roznych konwencji czy w ogole podejscie do pisania kodu.
  4. Takie "sztuczne" code review bedzie najbardziej zblizona sytuacja z jaka kandydat spotka sie w pracy
  5. Nie jest to tak stresujace jak live coding wydumanych problemow algorytmicznych
  6. Nie ma ludzi, ktorzy grinduja code review, w odroznieniu od leetcode itp
4

Tak, ale code review nie sprawdza umiejętności pisania kodu. Są ludzie którzy umieją wyłapywać smaczki, albo jakieś bugi, ale programować już nie. Jeżeli firma sprawdza w tej sposób to dla mnie jest to red flag, że prawdopodobnie utrzymaniowka, albo projekt w stylu 2 tygodnie szukaj błędu i dopisz ifa.

0

Live coding czy zadania domowe niby to sprawdzaja? W pracy nie tworzysz sobie nowego projektu, ktory skonczysz w 2 godzinki tylko dodajesz nowe funkcjonalnosci do istniejacego oprogramowania, ale moze znajdujesz tylko takie oferty gdzie robisz przy greenfieldach to nie zamierzam sie klocic.
Kiedy jakis znany programista-youtuber mowil, ze najwazniejsza umiejetnoscia programisty jest szybkie i sprawne odnajdywanie sie w kodzie napisanym przez innych ludzi i ja sie z tym w 100% zgadzam.

P.S. Nie pracuje w zadnej utrzymaniowce z dopisywaniem ifow :)

0
Seken napisał(a):

W pracy nie tworzysz sobie nowego projektu, ktory skonczysz w 2 godzinki tylko dodajesz nowe funkcjonalnosci do istniejacego oprogramowania

W wielu miejscach tak nie robisz właśnie i w tym problem. Ewentualnie dodajesz jakąś [CIACH!] którą normalnie dodałbys w jeden dzień, ale schodzi Ci to o wiele dłużej, bo musisz się dokopać jak to zrobić, żeby nie skopać tego. Slaby kod, brak dokumentacji, kiepski CI i building system a potem jeden task na sprint. Potrzebujesz rok-trzy na wdrożenie się w kod, żeby pamiętać co gdzie jest. No, ale też nie wiem czym dla Ciebie jest nowa funkcjonalność.

Jeszcze jest drugi typ, który ostatnio spotykam wśród znajomych a mianowicie pisanie mnóstwa UTkow do istniejącego już kodu. Twórców brak. Nie takie łatwe, ale ja osobiście czułbym niedosyt.

Branża to c++ bo wiem że też w Polsce specyficzna.

9

Ja już wielokrotnie to mówiłem- żadna forma rekrutacji nie sprawdza dobrze kandydata. Czy to podczas live codingu czy rozmowy technicznej można wyłapać słabszych kadydatów (ale i "odstrzelić" tych lepszych). Dopiero okres próbny daje jakiś obraz danego człowieka. Bo umówmy się- samo pisanie ładnego kodu ze 100% pokryciem testami to połowa sukcesu, ale są jeszcze inne, nie mniej ważne elementy:

  • programista dostaje taska i... musi zrozumieć o co chodzi albo umieć dopytać o co chodzi (z tym bywają problemy)
  • musi się wpasować w zespół (koder może dobry, ale nie da się z nim dogadać, bo nic nie mówi, jest niemiły i współpraca z nim to dramat)
  • mając taska musi wiedzieć gdzie i jak go zrobić (ileż miałem przypadków kiedy nowy programista oczekiwał, że wskażę mu konkretny numer linii w danej klasie, którą ma zmienić/ dodać i było zero własnej inicjatywy, analizy istniejącego kodu itd.)
  • trzeba wiedzieć i rozumieć nad jakim projektem w ogóle pracujemy, co ten soft robi itd.

Z perspektywy kilkunastu lat spędzony w IT, po tym jak widziałem dziesiątki ludzi podczas onboardingu, prowadziłem wiele rozmów kwalifikacyjnych dochodzę do wniosku, że jak na 20 kandydatów trafi się jedna osoba, która w większości spełnia ww. punkty, to jest dobrze.

8

@micheangelo:
O to to!

Kiedy jeszcze pracowalem w Polsce to w kazdej firmie 100% oceny stanowily szczegolowe kwalifikacje.

Prawda jest taka, ze fajnego pracownika mozna doksztalcic, natomiast buca z problemami psychocznymi, ktory bedzie przepisywac dobry kod, bo ma byc tak jak on chce, juz sie naprawic nie da (bez psychotropow).

W sumie w usa tez sie tacy zdarzaja. To niebezpieczne jednostki, bo maja oczytane kazde zadanko rekrutacyjne i kazdy podpunkt dokumentacji, ale ich ego i zryty beret rozwala wszystko.

Wczoraj np. Jeden taki szpec stwierdzil, ze musi NATYCHMIAST zaktualizowac framework, bo tak. Wymusil na jakims leszczu akceptacje jego PRa i wywalil produkcje. W ogole procedury nie powinny na to pozwalac, ale ok. Placa mi to sie nie czepiam.

0

Zapytam z ciekawości - dostał ktoś kiedyś porządne code review po wysłaniu zadania?

Ja nigdy, ostatnio jak robiłem to znowu to samo, ja piszę cały weekend zadanie a w odpowiedzi "zapraszamy na kolejny etap". Wkurzyłem się trochę i powiedziałem, że umówię termin jak tylko dostanę CR - czekam od 3 listopada, zaczynam podejrzewać, że go nie dostanę w ogóle.

Jak ktoś dostał, to w jakiej firmie?

0
Czitels napisał(a):

Jeżeli firma sprawdza w tej sposób to dla mnie jest to red flag, że prawdopodobnie utrzymaniowka, albo projekt w stylu 2 tygodnie szukaj błędu i dopisz ifa.

O to to właśnie xD. Więc podziękowałem :]

1
micheangelo napisał(a):

Ja już wielokrotnie to mówiłem- żadna forma rekrutacji nie sprawdza dobrze kandydata. Czy to podczas live codingu czy rozmowy technicznej można wyłapać słabszych kadydatów (ale i "odstrzelić" tych lepszych). Dopiero okres próbny daje jakiś obraz danego człowieka. Bo umówmy się- samo pisanie ładnego kodu ze 100% pokryciem testami to połowa sukcesu, ale są jeszcze inne, nie mniej ważne elementy:

  • programista dostaje taska i... musi zrozumieć o co chodzi albo umieć dopytać o co chodzi (z tym bywają problemy)
  • musi się wpasować w zespół (koder może dobry, ale nie da się z nim dogadać, bo nic nie mówi, jest niemiły i współpraca z nim to dramat)
  • mając taska musi wiedzieć gdzie i jak go zrobić (ileż miałem przypadków kiedy nowy programista oczekiwał, że wskażę mu konkretny numer linii w danej klasie, którą ma zmienić/ dodać i było zero własnej inicjatywy, analizy istniejącego kodu itd.)
  • trzeba wiedzieć i rozumieć nad jakim projektem w ogóle pracujemy, co ten soft robi itd.

Z perspektywy kilkunastu lat spędzony w IT, po tym jak widziałem dziesiątki ludzi podczas onboardingu, prowadziłem wiele rozmów kwalifikacyjnych dochodzę do wniosku, że jak na 20 kandydatów trafi się jedna osoba, która w większości spełnia ww. punkty, to jest dobrze.

Moim zdaniem to rozmijasz sie z idea rozmow rekrutacyjnych. Nie sprawdze dobrze kazdego kandydata, ale tez nie o to tutaj chodzi. Gdybym mial rozdawac umowy na okres probny kazdemu zainteresowanemu to firma szybko by upadla. Nawet jezeli zalozymy, ze nasze rozmowy rekrutacyjne maja skutecznosc rzedu 75% (czyli 1 na 4 slabe osobe jakos sie przecisnie) to zaoszczedzamy kupe czasu, nerwow i pieniedzy.
Stad rozmowy rekrutacyjne powinny byc jak najbardziej zblizone do rzeczywistosci, zeby ten wskaznik byl jeszcze lepszy, a przede wszystkim zeby kandydat tez wiedzial na co sie pisze.

Podejscie Ja już wielokrotnie to mówiłem- żadna forma rekrutacji nie sprawdza dobrze kandydata. sugeruje zeby to wszystko olac i tylko rzucac moneta przy zatrudnieniu :).

tl;dr Oprocz poszukiwania "idealnego" kandydata chodzi tez o zminimalizowanie szans na zatrudnienie ludzi, ktorzy beda (swiadomie lub nie) sabotowac projekt.

1
micheangelo napisał(a):

programista dostaje taska i... musi zrozumieć o co chodzi albo umieć dopytać o co chodzi (z tym bywają problemy)

IMO ten punkt raczej bada ogólny stan zespołu niż świadczy jednostkowo o nowym programiście. .

To, czy programista zrozumie taska nie zależy przecież tylko od programisty, ale czy taski są dobrze opisane. A jeśli nie są dobrze opisane, to programista może dopytywać, ale to czy będzie w stanie dostać brakujące informacje będzie zależało od tego, czy ludzie są chętni do pomocy, którzy na dodatek są na tyle komunikatywni, że mu tych informacji udzielą (swoją drogą dlaczego zakładać, że to nowy programista ma o wszystko się dopytywać? Pewne pytania można przewidzieć zawczasu, a jeśli można przewidzieć zawczasu, to czemu nie napisać taska bardziej precyzyjnie albo czemu nie udokumentować czegoś albo czemu nie zrobić jakiegoś większego onboardu/wprowadzenia dla tych, którzy są nowi w projekcie?)

musi się wpasować w zespół (koder może dobry, ale nie da się z nim dogadać, bo nic nie mówi, jest niemiły i współpraca z nim to dramat)

I znowu - to działa w obie strony. Jeśli są jakieś zgrzyty komunikacyjne to zwykle jest to odpowiedzialność więcej niż jednej osoby.

  • mając taska musi wiedzieć gdzie i jak go zrobić (ileż miałem przypadków kiedy nowy programista oczekiwał, że wskażę mu konkretny numer linii w danej klasie, którą ma zmienić/ dodać i było zero własnej inicjatywy, analizy istniejącego kodu itd.)

Co innego brak inicjatywy, a co innego obycie z projektem. Można mieć inicjatywę, a dalej nie rozumieć, jak konkretny moduł w dużym projekcie się łączy z resztą. Osoba z dłuższym stażem w projekcie będzie widzieć to, co osoba nowa niekoniecznie zauważy.

  • trzeba wiedzieć i rozumieć nad jakim projektem w ogóle pracujemy, co ten soft robi itd.

Czyli wiedza dziedzinowa i chęć poznawania takiej. O ile samą wiedzę dziedzinową można poznać, to myślę, że ważniejsze jest, czy ktoś jest jakkolwiek zainteresowany aspektami produktowymi, czy może widzi tylko kod (w sumie sam kiedyś patrzyłem tylko na kod). Bo bez tego nie będzie miał kontekstu nie będzie zainteresowany tym, co ten soft robi.

Czyli to bardziej miękki skill - umiejętność szerszego spojrzenia - niż twarda wiedza.

1
Pętliczek napisał(a):

Zapytam z ciekawości - dostał ktoś kiedyś porządne code review po wysłaniu zadania?

Zawsze, jedno co prawda absurdalne (teksty w stylu: za mało zdefiniowanych inferfejsów), drugie konkretne - z merytorycznymi uwagami, na które dostałem szanse merytorycznie odpowiedzieć.

1

Właśnie dostałem przydział w pracy na przygotowanie sposobu rekrutacji nowych devów no i cholera nie wiem :D ktoś wyżej podsumował, że cokolwiek jest proponowane, to złe :D

Myślałem nad dosłownie 15 minutowym "live codingiem", gdzie kandydat wcześniej zostaje poinformowany, że potrzebuje mieć działające środowisko pod daną technologię. Na rekrutacji w którymś punkcie dostanie link do gita, musi sklonowac projekt (na udostępnianym ekranie), zbudować i rozwiązać proste zadanie (typu napraw fizzbuzz+3 żeby test przechodził). Sprawdzi podstawowe obeznanie z kodem, czy wie jak uruchomić test (nawet via IDE, nie musi być z linii poleceń). Chodzi o generalne obycie. Co sądzą wyrocznie z 4p? Takie krótkie zadanko poza rozmową o doświadczeniu/projektach.

0

@TerazOdpowiemNaKomcie: wg mnie na plus. Miałem raz podobną rekrutację, tylko dostałem namiary na RDP i tam było już i IDE i projekt do odpalenia, który nie działał. Fajny sposób, bo widać takie rzeczy jak ktoś myśli czy umie korzystać z debuggera.

Ale znów, inne wyrocznie stwierdzą, że może nie zna IDE albo jak ktoś się patrzy to się stresuje, więc nie dogodzisz wszystkim :D

2
TerazOdpowiemNaKomcie napisał(a):

Właśnie dostałem przydział w pracy na przygotowanie sposobu rekrutacji nowych devów no i cholera nie wiem :D ktoś wyżej podsumował, że cokolwiek jest proponowane, to złe :D

Myślałem nad dosłownie 15 minutowym "live codingiem", gdzie kandydat wcześniej zostaje poinformowany, że potrzebuje mieć działające środowisko pod daną technologię. Na rekrutacji w którymś punkcie dostanie link do gita, musi sklonowac projekt (na udostępnianym ekranie), zbudować i rozwiązać proste zadanie (typu napraw fizzbuzz+3 żeby test przechodził). Sprawdzi podstawowe obeznanie z kodem, czy wie jak uruchomić test (nawet via IDE, nie musi być z linii poleceń). Chodzi o generalne obycie. Co sądzą wyrocznie z 4p? Takie krótkie zadanko poza rozmową o doświadczeniu/projektach.

to chyba zalezy z jakim expem ludzi szukacie.
Bo dla kogos kto ma 5lat expa to troche szkoda 15min. Lepiej zapytac go cos z archtiektury aplikacji, jakis scenariusz pod optymalizacje niz takie kodingi.

1

A ja lubię zadania, ale tak na maks 2h. Lepsze to niż "jakie znasz wzorce projektowe".

5

Chcialem Wam powiedziec, ze sexworkerki z roksy i escort sa bardziej szanowane od nas. Dalismy sie zeszmacic ponizej wszystkich istniejacych zawodow.

Osobiscie obstawiam, ze to ostatni rok dobrych zarobkow w IT, bo nie ma drugiej branzy, ktora tak daje sie szmacic.

Przy kolejnej rekrutacji pojawil sie temat zadanie domowego.

Chatgpt zrobil je za mnie, posklejanie tego na gicie zajelo mi godzine.

Lacznie:

  1. rozmowa techniczna - 1h. Efekt - amazing,
  2. Zadanie domowe - 1h. Efekt - amazing,
  3. Rozmowa techniczna z cto, live coding, 2 zadanie - pelen sukces.

Teraz jestem zghostowany od tygodnia. Pewnie z powodu zmian w cenniku unity, ale typy z Illuvium nawet nie maja rigczu, zeby przeprosic, ze zajeli mi 4 godziny, na ktorych wypadlem amazing, tylko milcza. Trzeba bylo zostac lekarzem.

4

No taki jest rynek i trzeba się z tym pogodzić ew nigdzie nie aplikować :D Wiele firm robi dzisiaj sztuczne rekru dla zbadania rynku.

Osobiście odrzucam oferty z zadaniami domowymi, czy etapami dłuższymi niż 2 spotkania, bo szkoda mojego czasu.

0

Od jakiego okresu widujecie zadania domowe i w jakich technologiach? Ja obserwuję rynek, chodzę w miarę regularnie na rozmowy i nie dostałem ani jednego zadania do tej pory.

@renderme: czyli nie było amazing skoro zostałeś zghostowany, albo chciałeś za dużo, proste.

10

Chwalcie się bardziej jakie wspaniałe warunki macie w IT a wyborcze i Onety niech piszą o was artykuły że pracujecie 2h za 20k msc, niewartościowany informatyk potrzebuje poklasku. Sami sobie zgotowaliście ten los. Prostak ze wsi jak wskoczy na trochę wyższy poziom życia musi się obnosić dookoła ile zarabia i jakim jest kozakiem. Dzieci bogatych starych nie pchają się do IT, idą na inne studia lub otwierają swój biznes, bo w IT całe życie spędzasz przed kompem. Idą do zawodów w którym mają kontakt z człowiekiem, bo dobre znajomości są więcej w życiu warte niż spędzenie życia przed monitorem. W IT pracują niedowartościowani ludzie, którzy podbudowują sobie ego tym, że napisali najoptymalniejszy kod według wzorców projektowych, który każdy nietechniczny człowiek ma w dupie, a zachwycają się nad tym jak gdyby byli drugim Snowdenem albo tym hackerem Mitnickiem.

Gdybyście o swoim zawodzie mówili, że jest trudny, wymaga analitycznego umysłu, ciągłej pracy w skupieniu, koncentracji, kreatywności. Praca źle wpływa na zdrowie, na wzrok, kręgosłup, jest wyczerpująca psychicznie, bo godzinami, podczas pisania kodu i intensywnego myślenia z nikim nie rozmawiacie. Kto wie może pracodawcy płaciliby wam większe stawki, ale jeśli kreujecie się na bogów, wymiataczy z lekką pracą to czemu się dziwić że firmy wymagają więcej z roku na rok a stawki sukcesywnie spadają?

Naucz się nowych technologii, rób zadania pod rekrutacje poświęć na nie pół dnia, a za ten czas nikt ci nie zapłaci. Dodatkowo z roku na roku coraz większa konkurencja. Największe portale medialne pisały i zachęcały do przebranżowienia do IT, na fb czy w mieście bilbordy reklamujące bootcampy po 10-15k z hasłami "Chcesz zarabiać 15k? Idź na 1msc bootcamp i zostań programistą! Dajemy gwarancję pracy."

9

przeciez co 2 osoba sie mnie teraz pyta czy faktycznie teraz w IT jest tak zle. Chetnie potwierdzam! Nic lepszego sie nie moglo przytrafic, niescie zla nowine, spread fud, for the win. zespol ciesni nadgarsta, rwa kulszowa, otylosc, nadwaga i miazdzyca, to was czeka nerdy nieszczesne w tej branzy. Lawka, crunch stres i (ro)zwolnienie to wasze drugie imie. Ja do biznesu juz kolejny rok dokladam, a znow jakies nowe technologie ida, boze jedyny znow 10h przed kompem, oczy mnie bola, krople juz nie pomagaja. Hemoroidy wyskakuja, dupa boli. Czat dzipiti mi robote zabiera i kurde nie wiem co dalej, kolega z boxa obok ma depresje przez to, a drugi juz nie ma na rate kredytu.

0

Jest okropnie. Gruszki w owocowy czwartek, zamiast jabłek? Dramat

9

Póki co z tego wątku wyczytałem, że:

  • podczas rekrutacji kodu można wymagać od juniora, od seniora nie
  • seniora absolutnie nie można pytać o frameworki, bo przecież wszystko jest w dokumentacji
  • w żadnym wypadku nie można od seniora wymagać podstaw
  • kodowanie na rekrutacji jest zakazane bo programista może tego nie ogarnąć
  • według ludzi, którzy gdy coś im w życiu nie pójdzie to od razu biegną płakać online - najważniejsze są skille miękkie
  • to rekrutujący zajmują programistom czas, w drugą stronę to nie działa
  • to, czy programista zrozumie taska nie zależy od programisty

Dawajcie dalej, dobrze idzie.

0
wartek01 napisał(a):

Póki co z tego wątku wyczytałem, że:

  • podczas rekrutacji kodu można wymagać od juniora, od seniora nie
  • seniora absolutnie nie można pytać o frameworki, bo przecież wszystko jest w dokumentacji
  • w żadnym wypadku nie można od seniora wymagać podstaw
  • kodowanie na rekrutacji jest zakazane bo programista może tego nie ogarnąć
  • według ludzi, którzy gdy coś im w życiu nie pójdzie to od razu biegną płakać online - najważniejsze są skille miękkie
  • to rekrutujący zajmują programistom czas, w drugą stronę to nie działa
  • to, czy programista zrozumie taska nie zależy od programisty

Dawajcie dalej, dobrze idzie.

  1. jak najbardziej racja, ciężko zaufać juniorowi, z seniorem jest prościej
  2. +1
  3. +1, bez podstaw nie byłby seniorem
  4. kodowanie to tylko dla juniorów i może midów, dla seniorów imo ważniejsze są sprawy architektoniczne do sprawdzenia
  5. +1
  6. no w sumie to tak, rekruterzy zarabiają na rozmowach z nami, my za to nic nie dostajemy a w czasie rozmowy moglibyśmy machnać jakiegoś taska z jiry
  7. to zalezy od tego jak zostanie zdefiniowany i czy analityk jest ogarnięty i potrafi w jasny sposób przekazać swoją wiedzę
5

@Escanor16: Chyba nigdy nie byles na rekrutacji po stronie weryfikujacej kandydata, jesli myslisz ze aplikujacemu na seniora latwiej zaufac i zna podstawy, bo inaczej nie bylby seniorem XD

1
wartek01 napisał(a):

Póki co z tego wątku wyczytałem, że:

  • podczas rekrutacji kodu można wymagać od juniora, od seniora nie

Tylko, że tu nie ma z czego się śmiać.
Z pozoru może się wydawać dziwne, ale tak faktycznie - największe wymagania są wobec początkujących, muszą udowodnić, że się nadają. W znaczeniu takim, że człowiek z doświadczeniem (senior) nie przeszedłby rekrutacji na juniora, ale przeszedłby tą na seniora.
Co więcej strzelam (ale tylko strzelam - nie znam się), że w wielu innych dziedzinach jest tak samo (lekarze, złodzieje trakcji, budowlańcy).

0
jarekr000000 napisał(a):

Tylko, że tu nie ma z czego się śmiać.
Z pozoru może się wydawać dziwne, ale tak faktycznie - największe wymagania są wobec początkujących, muszą udowodnić, że się nadają. W znaczeniu takim, że człowiek z doświadczeniem (senior) nie przeszedłby rekrutacji na juniora, ale przeszedłby tą na seniora.

Cytując klasyka: "Trzeba się śmiać, w przeciwnym razie człowiek zwariuje".

Programowanie nie przypomina pod względem rekrutacji pracy lekarzy czy budowlańców, gdzie faktycznie po iluśtam latach o podstawach się zapomina - bo np. w twojej klinice operacje oka robi się za pomocą jakiejś metody X, podczas gdy "podstawy" to metoda Y. Programowanie przypomina bardziej pracę dziennikarską czy naukową, gdzie podstawy są ciągle potrzebne. Jeśli dziennikarz ma problem z napisaniem prostej notki prasowej to nie napisze też dużego reportażu - i tak samo jest z programistami. Jeśli senior nie potrafi zaklepać względnie prostego problemu to nie należy łudzić się, że gdy zacznie dostawać superskomplikowane zadania to sobie z nimi poradzi.

2
jarekr000000 napisał(a):
wartek01 napisał(a):

Póki co z tego wątku wyczytałem, że:

  • podczas rekrutacji kodu można wymagać od juniora, od seniora nie

Tylko, że tu nie ma z czego się śmiać.
Z pozoru może się wydawać dziwne, ale tak faktycznie - największe wymagania są wobec początkujących, muszą udowodnić, że się nadają. W znaczeniu takim, że człowiek z doświadczeniem (senior) nie przeszedłby rekrutacji na juniora, ale przeszedłby tą na seniora.

To jest tylko pół prawdy. Największe wymagania co do klepania głupich algosow czy zadanek domowych? Załóżmy, że tak chociaż ja osobiście tego nie przeżyłem.
Rozmowy na mida/seniora to bardzo dużo sytuacji z życia wziętych. Przykładowo każdy kto korzystał jednocześnie z kolejek i baz danych będzie wiedział czym jest outbox pattern albo chociaż intuicyjnie wie jak rozwiązać problemy spójności. Ktoś na entry levelu takich problemów nigdy nie napotkał, więc nie spodziewam się żeby znał rozwiązanie.
Z juniorem nie pogadasz o architekturze mikroserwisow czy o tym jak pisać porządne testy żeby nie mieć wszystkiego zamockowanego od góry do dołu. Ja osobiście wcale nie uważam tych tematów za łatwiejsze.

Podsumowując moim zdaniem senior przeszedłby znaczną część rozmów na juniora pomijając pato rekrutacje oparte o wypytywanie o najmniejsze szczegóły. A junior (o dziwo) nie przeszedłby żadnej porządniejszej rozmowy na stanowisko seniorskie.

2
Seken napisał(a):

To jest tylko pół prawdy. Największe wymagania co do klepania głupich algosow czy zadanek domowych? Załóżmy, że tak chociaż ja osobiście tego nie przeżyłem.

OK - uprościłem, jestem cięty na seniorów - bo często to goście co utkwili na lata w jednej technologii, jednym typie projektów i bardzo nie ogarniają.
Ale typowy senior często wyłoży sie na podstawach:

  • kruczki z języka i algorytmów, które junior musi znać,
  • uwzględnianie warunków brzegowych, przepełnień (tak rozpiernicza seniorów codility),
  • znajomość definicji (senior może i na rozmowie wymacha rękoma, ale jak będzie egzamin i trzeba będzie wpisać czym się różni heurystyka od algorytmu to pewnie odpadnie),
  • posługiwanie się IDE :P
2
jarekr000000 napisał(a):
Seken napisał(a):

To jest tylko pół prawdy. Największe wymagania co do klepania głupich algosow czy zadanek domowych? Załóżmy, że tak chociaż ja osobiście tego nie przeżyłem.

OK - uprościłem, jestem cięty na seniorów - bo często to goście co utkwili na lata w jednej technologii, jednym typie projektów i bardzo nie ogarniają.
Ale typowy senior często wyłoży sie na podstawach:

  • kruczki z języka i algorytmów, które junior musi znać,
  • uwzględnianie warunków brzegowych, przepełnień (tak rozpiernicza seniorów codility),
  • znajomość definicji (senior może i na rozmowie wymacha rękoma, ale jak będzie egzamin i trzeba będzie wpisać czym się różni heurystyka od algorytmu to pewnie odpadnie),
  • posługiwanie się IDE :P

Jeśli senior niespełniający tych warunków pracuje jako senior w jakiejś firmie to może należałoby się zastanowić po co od niego wymagać rzeczy wymaganych na juniora. To logiczne, że junior musi znac przyziemne tematy (takie które są do zastąpienia przez gpt) bo to on finalnie klepie taski na bazie architektury, wymagań i całej otoczki wymyślonej przez jednego bądź kilku seniorów. Na prawdę nie rozumiem podniecania się kuciem na blachę tematów, które są do ogarnięcia przez byle bota. Nie sądzę by ordynator zajmował się obsługą respiratora. Mnie u seniora bardziej interesuje jak podchodzi do problemów, jak godzi ogarnianie długu technicznego vs wymogi biznesowe nowych featurow, na jakie konfy jeździ, jakie czyta książki by się rozwijać.

Edit. Wymaganie pisania algorytmów to wgl iks de w dzisiejszych mocach obliczeniowych dostępnych za pół darmo. Chyba że aplikujesz do nasa lub innych rozwiązań gdzie moc jest ograniczona z różnych względów to inna sprawa.

I od razu odbijam argument "FAANG tak robi", robi tak bo mają tysiące chętnych do bycia małpkami za setki tysięcy USD rocznie. Jak przyjdzie Google do Polski z ofertą 1mln pln rocznie to też mogę kuć i udawać, że wszystko jest różowe. No ale oni kładą 25k brutto za wymogi te same co w US. xd

3
itsme napisał(a):
jarekr000000 napisał(a):
Seken napisał(a):

To jest tylko pół prawdy. Największe wymagania co do klepania głupich algosow czy zadanek domowych? Załóżmy, że tak chociaż ja osobiście tego nie przeżyłem.

OK - uprościłem, jestem cięty na seniorów - bo często to goście co utkwili na lata w jednej technologii, jednym typie projektów i bardzo nie ogarniają.
Ale typowy senior często wyłoży sie na podstawach:

  • kruczki z języka i algorytmów, które junior musi znać,
  • uwzględnianie warunków brzegowych, przepełnień (tak rozpiernicza seniorów codility),
  • znajomość definicji (senior może i na rozmowie wymacha rękoma, ale jak będzie egzamin i trzeba będzie wpisać czym się różni heurystyka od algorytmu to pewnie odpadnie),
  • posługiwanie się IDE :P

Jeśli senior niespełniający tych warunków pracuje jako senior w jakiejś firmie to może należałoby się zastanowić po co od niego wymagać rzeczy wymaganych na juniora. To logiczne, że junior musi znac przyziemne tematy (takie które są do zastąpienia przez gpt) bo to on finalnie klepie taski na bazie architektury, wymagań i całej otoczki wymyślonej przez jednego bądź kilku seniorów. Na prawdę nie rozumiem podniecania się kuciem na blachę tematów, które są do ogarnięcia przez byle bota. Nie sądzę by ordynator zajmował się obsługą respiratora. Mnie u seniora bardziej interesuje jak podchodzi do problemów, jak godzi ogarnianie długu technicznego vs wymogi biznesowe nowych featurow, na jakie konfy jeździ, jakie czyta książki by się rozwijać.

Edit. Wymaganie pisania algorytmów to wgl iks de w dzisiejszych mocach obliczeniowych dostępnych za pół darmo. Chyba że aplikujesz do nasa lub innych rozwiązań gdzie moc jest ograniczona z różnych względów to inna sprawa.

Jak dla mnie to taką odpowiedzią pozamiatałeś i nie ma na nią kontrargumentu.
Wieloryby mają płetwy, ale nie mają kopyt i skrzydeł, bo do życia w wodzie nie byly im potrzebne.
Nie ma powodu ich za to krytykować, że zbędne cechy u nich zanikły, wykształciły się natomiast użyteczne.

Jeżeli ktoś pracuje w programowaniu 15 lat i pewna wiedza została u takiej osoby zatarta, to oznacza, że ta wiedza jest zbędna w jego zawodzie. Jak budowałem dom to pamietałem, jak wyglada procedura uzyskiwania pozwolenia na budowe. Teraz tego nie wiem, bo jest mi to zbedne. Jak będę potrzebował, to się nauczę, bo nauczyłem się uczyć.

Moze jeszcze powinno się oprocz jakichs bzdurnych definicji, których używa się raz na 20 lat, wymagać znajomości geografii Japonii, bo w sumie, czemu nie. Moze kiedys sie przyda.

Z moich obserwacji wynika, że osoby, które są takimi "pasjonatami" raczej są szkodliwe dla firm i projektów. Są zaburzeni, skoncentrowani na jakieś zbędnej perfekcji, czesto przekonane o swoim geniuszu, z gory zakladaja, ze wiedza jak zrobic cos lepiej i ze rozwiazanie ktore jest dobre trzeba natychmiast usunac z produkcji i wydac 40% budzetu firmy na przepisania go na nowo, zeby bylo "czystsze", a przede wszystkim zrobione przez nich... Ja jak widze kogos takiego, to od razu wlacza mi sie czerwona lampka, bo jest jakies 10% szansy, ze to niegrozny pasjonat i 90%, ze to zakompleksiony d... ktory bedzie wszystkich negowal, zadziaral nosa, krytykowal czyjes doswiadczenie, bo on zna 5 zbednych definicji i pisze po pracy solvery sudoku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1