@PoteznyProgramista: A jakie trudne jest programowanie bez frameworków, stojąc na głowie z jedną ręką związaną z plecami ! No ale takie umiejętności niezbędne każdemu Programiście to sprawdzają tylko w naprawdę ekstra firmach.
0
2
@Czulu: Nie mam zamiaru z nikim wchodzić w takie dyskusje, gdzie 90% projektów w Polsce to ten sam framework i orm. Programowanie bez frameworków i abstrakcji jakie dają jest znacznie trudniejsze, aczkolwiek jest to używane i sam pracowałem w takich projektach - przykładowo pisałem bibliotekę, która musiała mieć najmniejszą ilość zależności zewnętrznych. To, że taki spring ma autowired, czy możliwość definiowania beanów, to nie znaczy że należy wszystko pchać jako beany, ale to chyba wiedza tajemna. Ile projektów widziałem, to zawsze pchanie wszystkiego do kontenera i później zdziwienie, że testy długo zajmują. Tylko po co o tym dyskutować? Tak, dobre firmy sprawdzają twoje umiejętności programowania, a nie klepania w frameworkach. Nadal to podtrzymuje, z tego co wiem FAANG nie sprawdza twojej wiedzy o milionie frameworków, które się zmieniają co parę lat, tylko twoje rozumowanie, ale co taki Google może wiedzieć, nie?
1
z tego co wiem FAANG nie sprawdza twojej wiedzy o milionie frameworków, które się zmieniają co parę lat, tylko twoje rozumowanie, ale co taki Google może wiedzieć, nie
To żaden argument. Google inne podobne firmy zwyczajnie mają swoje własne wewnętrzne frameworki więc nie interesuje ich specjalnie czy znasz X czy Y, bo i tak mają coś własnego zamiast tego ;)
0
@Shalom: Jakie wewnętrzne frameworki? To nie są firmy, które tworzą własne frameworki, bo chcą być trendy. To tak jakby facebook, który zatrudnia jednych z najlepszych inżynierów pisał własną implementację Cassandry, czy memory cache, bo tak. Tak nie jest, używają Cassandry i Memcached, więc serio nie rozumiem tego stwierdzenia o własnych frameworkach. Nikt cię nie będzie pytał na rozmowie o prace w takich firmach o CQL w Cassandrze, tylko zapytają o consistency, czy consistent hashing. To samo powiedzmy z googlem, mają wewnętrzne frameworki? To jest duża firma, może i mają coś wewnętrznego, ale jeszcze nie słyszałem aby pytali na rekrutacji do powyższych firm o frameworki, a z tego co wiem to używają między innymi vue.js, czy angulara.
0
@PoteznyProgramista:
Nie rozumiem. Mówisz, ze frameworki be i dajesz argument ze złego używania tych frameworkow, gdzie ktos za duzo zależności przeniesie do kontenera.
Czym innym jest zla praktyka a czym innym technologia.
Nawet propo testow to ich szybkość w projekcie nie jest najważniejsza, nie ma to priorytetu. Biznes nawet ma je gdzies.
Ważna jest logika idąca za adnotacja, ona będzie mogła ulegac zmianom kosmetycznym w następnym frameworku.
Klepanie takich transacional, byle gdzie, jest w stanie wiecej popsuć niż myślisz. A jeżeli nie bedziesz wiedział tego podczas pisania to dowiesz się z produkcji.
2
Jeśli firma odpytuje ze specyficznych problemów, programowania bez frameworków itp bo są to sprawy relewantne do projektów którymi się zajmuje to spoko. Rzecz w tym że większość firm które chcą zadawać takie pytania, i tak je**e zwykłe crudy w angularze, reakcie i springu.
0
Przez ostatnie 4 lata jak szukałem robótki to 3 razy trafił mi się live coding.
Pierwszy: poprzedzony zadaniem domowym. Live coding przeszedł i dostałem oferte.
Drugi: poprzedzony zadaniem domowym. Live coding przeszedł i dostałem oferte.
Trzeci: poprzedzony testem online coś w stylu codility (ale 20 zadań na 3h) wynik 65%. Live coding przeszedł i dostałem oferte. Ale tutaj najmniej się spodziewałem, ze względu na to, że test online słabo poszedł.
Mi się taki sposób rekrutacja podoba.
1
Z perspektywy kandydata, najlepiej byłoby gdyby mógł wybrać pracę domową albo live coding. Oczywiście standard rozwiązania zadania domowego nie powinien budzić zastrzeżeń i zadanie powinno być omówione podczas spotkania live/video. Chodzi o to, że programiści potrafią się mocno zblokować jak ktoś patrzy im na ręce podczas rozwiązywania zadania.
Codility/hackerrank/etc uważam za bezsensowne. Jedyne co jest bardziej bezsensowne to zatrudnianie na podstawie samej rozmowy (często nawet niewiele mającej wspólnego z techniczną) i ma to silne odzwierciedlenie w jakości projektu/zespołu.
1
Mi np live coding nigdy nie wychodzi, mimo że już mam lata doświadczenia to zawsze się na tym wykładam. Związane jest to z tym że z algorytmów typu Codility byłem dobry jak kończyłem studia i byłem na świeżo. Teraz po latach jak się robi w Springu czy JEE i przychodzi live coding to mówię od razu rekruterowi że to już nie ten moment na tego typu zadania.
1
Ja nie biorę udziału w rekrutacjach gdzie jest live coding, bo moim zdaniem jest to świadomie wykorzystywane jako socjotechnika do zbicia pewności siebie programisty. Według mnie dobrym rozwiązaniem jest w 1 etapie rozomowa z HR(sprawdzenie angielskiego i skili miękkich), 2 etap zadanie na które kandydat ma określony czas i 3 etap okres próbny w firmie na realnych projektach.
1
Kawka napisał(a):
Ja nie biorę udziału w rekrutacjach gdzie jest live coding, bo moim zdaniem jest to świadomie wykorzystywane jako socjotechnika do zbicia pewności siebie programisty. Według mnie dobrym rozwiązaniem jest w 1 etapie rozomowa z HR(sprawdzenie angielskiego i skili miękkich), 2 etap zadanie na które kandydat ma określony czas i 3 etap okres próbny w firmie na realnych projektach.
@Kawka: 1h live codingu i wiesz więcej niż z zadania które jest na kilka godzin. Stresujesz się kodując na żywo? To idź na parę rekrutacji żeby się oswoić. Przychodzą ludzie którzy chcą >8k na rękę a nie potrafią pobrać wszystkich postaci ze swapi.dev i wyświetlić
5
mechanix napisał(a):
Kawka napisał(a):
Ja nie biorę udziału w rekrutacjach gdzie jest live coding, bo moim zdaniem jest to świadomie wykorzystywane jako socjotechnika do zbicia pewności siebie programisty. Według mnie dobrym rozwiązaniem jest w 1 etapie rozomowa z HR(sprawdzenie angielskiego i skili miękkich), 2 etap zadanie na które kandydat ma określony czas i 3 etap okres próbny w firmie na realnych projektach.
@Kawka: 1h live codingu i wiesz więcej niż z zadania które jest na kilka godzin. Stresujesz się kodując na żywo? To idź na parę rekrutacji żeby się oswoić. Przychodzą ludzie którzy chcą >8k na rękę a nie potrafią pobrać wszystkich postaci ze swapi.dev i wyświetlić
No właśnie często tak do końca nie jest, niektórzy ludzie nie potrafią sobie radzić ze stresem nawet po przejściu 20 rozmów. Tu też jest ryzyko, że live coding odstrzeli wartościowego człowieka, który dużo wie i potrafi, ale zżera go stres. Gdyby usiadł spokojnie, bez patrzenia na ręce, to spokojnie to i to mógłby zrobić, a tak stres go zabija. Prawda jest jednak taka, że idealnej metody rekrutacji nie ma, nawet okres próbny nie weryfikuje kogoś w 100%.
4
O ile w pracy nie robisz live coding (a nie robisz) to live coding odsiewa potencjalnie wartościowych kandydatów. Pamiętaj że część (moim zdaniem większa) osób które przeprowadza rekrutację się na tym nie zna i robi to źle (ale pracodawca się o tym nie dowie bo skąd, po prostu dowie się "kandydaci są kiepscy"). A rekruterowi też może nie zależeć na zatrudnieniu - w końcu to dla niego konkurencja będzie po podyżki.
Poza tym, każda rekrutacja jest inna, jak ci jakiś rodzaj nie leży to idziesz gdzieś indziej. Ja nie chodzę na live coding, nie uczestniczę też w rekrutacjach gdzie jest > 3 etapy (śmierdy pierdy z tym działem, z tą panną, z tym dzidakiem, ma być szybko i na temat). Przecież rekrutacji masz tyle że możesz chodzić po linii najmniejszego oporu
6
Pracownik odporny na stres jest lepszy niż pracownik nieodporny na stres. Nie wy to kto inny.
4
Z reguły zadania na LC są banalnie proste. Jakieś algorytmiczne zabawy mające na celu sprawdzić sposób myślenia kandydata oraz to jaki kod piszę. Nie rozumiem co tutaj krytykować? Bardzo często nie trzeba nawet dosłać działającego rozwiązania, żeby się dostać. Zwyczajnie może spodobać się sposób podejścia do problemu co dla pracodawcy może oznaczać prognozę na dobrego pracownika.
Fun fact -> W obecnej pracy na rozmowie miałem LC i nie do końca uzyskałem oczekiwany wynik rozwiązania. Zadziałał tutaj głównie stre, który spowodował pustkę w głowie. Swoją drogą po 10min po rozmowie momentalnie rozwiązanie pojawiło mi się w głowie :D Prace dostałem.
W innej firmie na LC zadanie wykonałem w 100% prawidłowo mimo niejasnych instrukcji przeprowadzającego. Roboty nie dostałem.
Samo LC jest również szansą na poznanie drugiej strony i wstępne wrażenia jak może wyglądać pisanie kodu po ichniejszej stronie. Dla przykładu cieszę się, że nie dostałem pracy w tej drugiej firmie - Gość (architekt XD) uprawiał ifologie na dziennikach, gdzie je od razu chciałem to zautomatyzować w prostej pętli - Nie spodobało się.
0
a mi się raz w pracy pisze dobrze i szybko a raz się stresuję bo mam jakiś życiowy zakręt i nie idzie bo myśli mam gdzie indziej, czy to jest powód żeby mnie nie przyjąć bo miałem na rozmowie akurat ten dzień że mi gorzej poszło?
programowanie to nie sprint i jednorazowy live coding tylko gra zespołowa
1
A ja za chwilę mam 2h live codingu xd pozdrawiam
0
Nie widzę różnicy między zadaniem domowym a live codingiem jeśli masz zły dzień. Tak czy siak jak trafisz na zły dzień na rozmowie to masz o wiele większą szansę być odrzuconym. To życie, jak pójdziesz na randkę zamyślony jakimś fuckupem w robocie to też nie wróżę sukcesu - jeśli musisz to przełóż rozmowę.
2
LC miałem dwa razy i dwa razy po tym dostałem ofertę. Zdecydowanie wole takie coś niż jakies zdania domowe czy codility. Ostatnio na rozmowie zostałem zapytany (tak ogólnie) jak powinno się zaimplementować Open Close Principle. Powiedziałem, że to zależy od konkretnego przypadku więc ciężko jednoznaczenie odpowiedzieć. (Dla mnie to pytanie trochę zbyt ogólne). I roboty nie dostałem bo nie znam wystarczająco dobrze SOLID xD
2
Generalnie od jakiegoś czasu rekrutacje dzielę na sensowne i takie, w których rzuca się zadaniem domowym na wejściu. LC jeszcze na własnej skórze nie przerobiłem, ale znacznie więcej widzę w tym sensu niż w taskach, na które trzeba poświęcać kilka wieczorów i zwykle nie można liczyć nawet na podstawowy feedback (tak przynajmniej obserwuję ze swoich rekrutacji juniorskich w tym roku). Dla mnie to naturalne, dla porównania na rekrutacjach prawniczych dostawałem np. case'y do rozwiązania albo pisma do przygotowania, więc analogicznie w programowaniu można sobie wyobrazić próby rozwiązania jakichś konkretnych problemów. Jeśli rekruter jest kompetentny, to zdaje sobie sprawę, że rozwiązanie nie będzie idealne, a może nawet nie uda się go dokończyć, bo programowanie to praca twórcza (wymagająca czasu na spokojny pomyślunek) i zespołowa,więc zwróci uwagę przede wszystkim na podejście do problemu, sposób pracy, umiejętność działania pod presją (bardzo istotny). Tak to widzę i jeśli będę miał okazję na LC przy rekrutacji to chętniej na taką propozycję odpowiem niż na enty task rekrutacyjny z wymaganiami rozpisanymi na kilka stron.
0
W dobie rozmów online gdzie odpowiedzi na pytania udziela pomocnik siedzący obok to zadanie domowe ma kompletnie zerową wartość.
3
Jest tyle pracy dla ludzi z expem mid+ że jak tylko widzę live coding to odpuszczam rozmowę i dziękuję za spotkanie. Osobiście za bardzo się stresuję taką formą rozmowy rekrutacyjnej.
2
Z mojego doświadczenia live coding jest przeprowadzony źle, albo w ogóle oderwany od rzeczywistości. Byłem na wielu rekrutacjach i w chwili obecnej mam taki pogląd, że jak czegoś nie wiesz, to nie dlatego że tego nie umiesz, tylko nie miałeś okazji tego wykorzystać bo nie było to na przykład potrzebne.
Kiedyś na rozmowie, jeszcze na początku mojej kariery, zapytano mnie czym jest mutable (wtedy pierwszy raz się spotkałem z tym słowem kluczowym) - z tego co zauważyłem w automotive jest to dość często wykorzystywane - niemniej nigdy wcześniej nie mialem potrzeby skorzystania z podobnego mechanizmu. Poza tym rozmowa poszła gładko. Natomiast przez tego mutable nie otrzymałem propozycji. Jakbym w pracy nie miał internetu to pewnie miałbym problem z rozkminieniem do czego to jest, ale wystarczy sobie wklepać i odpowiedz mamy od razu. Teraz pytanie, czy takie odsiewanie przez to, że się czegoś nie wie ma sens? To zależy. Śmieszne jest to, że odsiano mnie przy tak błahej sprawie. Akurat ja się cieszę, że się tam nie dostałem bo nie widziałbym się w automotive. Ale w takim razie na pewnym etapie coś poszło nie tak, bo straciliśmy czas żeby przejść przez 3 etapy.
Na innej rozmowie mialem zestaw pytań czysto teoretycznych, które po pierwsze korzystało się dawno, a poza tym nie widziałem podparcia w tym co mogłoby mieć miejsce w projekcie. To oznacza, że taka rekrutacja była kompletnie nie trafiona.
Na jeszcze innej rozmowie - gdzie poszło mi dobrze (przynajmniej tak myślałem) - podczas rozmowy z HR tak się na mnie patrzyli jak na jakiegoś zabójcę. Nawet nie specjalnie chcieli mi zadawać jakiekolwiek pytania - wtedy widziałem, że jestem już praktycznie skreślony (może na rozmowę z HR poszedłem zbyt pewny siebie że dobrze mi poszła rozmowa techniczna, choć prawdziwy powód po dziś dzień nie jest mi znany).
Tak na prawdę na te kilkadziesiąt rozmów tylko kilka było dobrych i jedna naprawdę dobra.
Ta naprawdę dobra to była prezentacja z wybranego przez siebie tematu związanego z programowaniem. Osobiście miałem mieszane uczucia, ale muszę przyznać, że taka forma jest najlepsza ze wszystkich a to dlatego że:
- ma się dowolność, można przedstawić dany problem i jak się to samemu rozumie (łatwo zweryfikować czy aplikant wie o czym mówi)
- jest czas na przygotowanie tylko w tym temacie (na inne rozmowy też nie raz trzeba się przygotować, ale nigdy nie wiadomo p co będą pytać)
- można przytoczyć jakieś sytuacje z poprzednich prac albo studiów
- ma się kontrolę nad przeprowadzoną prezentacją, oczywiście jeśli druga strona jest w porządku.
- przedstawia prawdziwy obraz nabytej wiedzy, łatwo zweryfikować czy temat jest wykuty na blachę
Na pewno minusem może być to, że nie wszyscy będą czuć się komfortowo w obecności przykładowo 4-5 osób, które będą obserwować każde słowo.
Jak dla mnie taka prezentacja była najlepszą formą rozmowy rekrutacyjnej.
Jeszcze na koniec mam swój osobisty wniosek, który jest wspólny dla znacznej większości rekrutacji, a mianowicie brak odpowiedzi, albo mała informacja „dziękujemy”. To jest powód dla którego wszyscy na te rozmowy idziemy jak dzieci we mgle bo nie znamy swoich słabości i nie wiemy gdzie wg rekrutera popełniliśmy błędy.
Przydałoby się też określać, że czegoś nie wiemy albo popełniamy błędy fundamentalne, ale procesy są zrobione tak, żeby tylko dostać pracownika, a nie żeby robić komuś łaskę wysyłając wartościowa informacje zwrotną.
2
Fajny link, lista firm ktore nie robia typowego whiteboardingu: https://github.com/poteto/hiring-without-whiteboards
1
jorgus napisał(a):
Na pewno minusem może być to, że nie wszyscy będą czuć się komfortowo w obecności przykładowo 4-5 osób, które będą obserwować każde słowo.
Ot, takie zwykłe perypetie rekrutacyjne...
Pamiętajmy jednakowoż że firma nie rekrutuje bo ma być ci komfortowo, rekrutuje bo szuka najtańszego z najlepszymi ficzerami żeby na twoich plecach zrobić kupę hajsu a ty będziesz robił X i Y bo to lubisz i/lub lubisz pieniądze które oni dają.
1
jorgus napisał(a):
Jak dla mnie taka prezentacja była najlepszą formą rozmowy rekrutacyjnej.
Mi by się nie chciało przygotowywać, bo by zajęło to więcej niż 1-1.5h rozmowy technicznej.
Poza tym, załóżmy, że potrzebuję backend developera do rozwoju aplikacji javowej, który by nie był również totalnie zielony w sprawach devopsowych. No i przyjdzie mi np programista embedded, przedstawi super prezentację o STMach, ARMach, jego własnym line-followerze i quadrokopterze no i fajnie, tylko co mi z tego? :P Nie ma dopasowania.
0
@Patryk Maleszko: Zgadzam się, raczej nie wezmą kogoś tylko ze względu na jeden czynnik, ale tak jest niemal zawsze.
@Pinek: racja, ale dlatego jest dowolność w tematyce, wtedy druga strona ma szanse określić czy temat zakrawa o obszar czy nie, a jak chcieli by wiedzieć coś więcej to nie można zapytać?
2
Jest jeszcze jeden powód dlaczego to robią - zasada zaangażowania - takie Google i Amazon* maja najtrudniejsze rozmowy, wymagają mieć whiteboarding w mały palcu - dlatego ze jak poświecisz na to wiele godzin swojego życia za free i jak już łaskawie będą chcieli cię zatrudnić to podając nawet niższa kwotę pewnie jej nie odrzucisz - psychologia. Firmy te do perfekcji opanowały ciecie kosztów i manipulacje, korumpują rządy, pomagają inwigilować obywateli - przy tym dymanie studenciaków, co jeszcze wiele o zyciu w korpo wiele nie wiedza, na kasę to male piwo.
Przy tym wiedza ze będziesz wiernym kopaczem i zrobisz wszystko co będą chcieli - czy to sensowne, etyczne a przy okazji zapłacą mniej bo w puzzle algorytmiczne dobrze robią najczęściej ludzie po studiach wiec nie będą za dużo chcieli $$$ i dziękowali laskowemu panu z ameryki.
- Amazon dodatkowo chce żebyś miał wykute ich kreteńskie Leadership values i abys wykazał ze jesteś 100% gotów robic nadgodziny żeby lysy krezus miał jeszcze więcej $$$.
3
Kucie na blachę algorytmów przez około rok, dwa lata do niektórych firm to moim zdaniem zjawisko psychologiczne, które ma na celu wymuszenie pewnych rzeczy.
5
Oczywistym jest, ze trzeba pocwiczyc przed.
No ale właśnie to się kłóci z ideą posiadania tej umiejętności jeśli musisz ją specjalnie ćwiczyć (sztucznie!) przed rekrutacją.
Skoro nie umiesz tego dzięki codziennej pracy (rzeczy które umiesz tak po prostu to te rzeczy które naprawdę są potrzebne) to znaczy że nie są one potrzebne.
Wyjątkiem są takie stanowiska na których NAPRAWDĘ są potrzebne te algorytmy - przez 12 lat pracy w tym zawodzie nie spotkałem takiego stanowiska (chociaż mam kolegę kolegi który podobno tego używa).