Która z form rekrutacji technicznej Wam najbardziej odpowiada?
Moje spostrzeżenia:
A Wy co sądzicie? Będę mega wdzięczny za Wasza odpowiedzi! Z góry piękne dzięki!
Czemu Leet Code ma sie nijak do pracy inzyniera, przeciez to jest problem solving?
Pair-programming jest najbardziej wiarygodnym, bo od razu widać jak kto pracuje.
Zadania domowe to może robić stażysta/junior chcący wbić się w rynek a nie osoba z x lat expa (No chyba, że adekwatnie zapłacą).
Leet code to zwyczajne oranie algo na zasadzie zakuć. Kilka tygodni takich zadanek i można w tym wymiatać na większości rozmów. Tylko pytanie jaką niesie to za sobą wartość?
lion137 napisał(a):
Czemu Leet Code ma sie nijak do pracy inzyniera, przeciez to jest problem solving?
Bo moim problem solving jest integracja, migracja, import i export. A nie pisanie z palca sortowania czy innych algorytmów, które można wygooglać :(
Pozostałe rekrutacje to czesto tylko rozmowa techniczna a czasem gra w sto pytan przy czym np pytania dla Javy się mocno powtarzają więc krąży opinia że można wygrać brutal force chodząc na dużo rekrutacji
W dawnych czasach jeszcze test był jak kolos na studiach a co będzie rezultatem tego kodu. Dobrze że tego już nie ma :D
Zdecydowanie najbardziej lubię pair-programming, a najmniej jak jest odpytywanie z samej teorii, które przybiera kształt egzaminu ustnego. Pair-programming (i w sumie zadanie domowe też) daje fajny punkt zaczepienia na pogaduchy o kodzie i wydaje mi się, że można w ten sposób lepiej zweryfikować poziom.
Najbardziej lubię pair-programming, ale w ankiecie źle mi się kliknęło xd
1h-1.5h max, a w tym opowiadanie o tym co się robiło i co robią w firmie oraz chwilka na kilka pytanek + kilka minut dla HRu
Pair-programming jest spoko, ale gdy można korzystać ze środowiska, które się zna (a nie jakiegoś webowego edytorka).
Pair-programming jest spoko, jeśli robisz ogólne dobre wrażenie. Wtedy możesz słabo zrobić, a i tak wypadniesz dobrze.
Ja zawsze bardzo słabo technicznie wychodzę na takich zadaniach. Jednak zauważyłem, że to zupełnie nie ma na celu badać poziomu technicznego, tylko raczej kodzenie jest pretekstem do pogawędki z drugim programistą i dopiero ta pogawędka o czymś świadczy (czy jest chemia, podobne spojrzenie na programowanie, dogadanie się).
Co też znaczy, że przy takich rozmowach to ten programista-rekruter też musi być dość rozmowny, bo jak będzie tylko zadawał pytania i słuchał, to już przegrałeś, bo nie ma rozmowy, tylko jest ocenianie skilla.
Leet Code sprawdza umiejętność rozwiązywania zadań Leet Code i ma się nijak do normalnej pracy.
Zadania algorytmiczne są tylko pretekstem do tego, żeby o nich porozmawiać później. Najlepiej chyba zrobić zadanie średnio dobrze, żeby było widać, że umiesz programować, ale na tyle źle, żeby potem programiści mogli się nad tobą popastwić, że zrobiłeś to niewydajnie i żeby mogli się pomądrzyć o złożoności algorytmicznej. Miałem kiedyś tak i dostałem ofertę pracy.
Zadania domowe nie są do końca fair, bo spędzasz kilka godzin nad czymś, co może kompletnie nic nie dać.
Zadania domowe są spoko, jeśli można się nauczyć czegoś nowego. Np. jakby mi dali zadanie domowe, żeby zrobić w Scali powiedzmy prosty serwer, to byłoby to dobre zadanie, bo Scali nie znam, więc byłoby jakieś wyzwanie, żeby w kilka godzin się nauczyć jej na tyle, żeby móc zrobić w niej zadanie domowe. Natomiast to samo zadanie w języku/technologiach, które już znam, to po prostu nuda.
żadne z powyższych, dla firm dla których pracowałem i pracuję nie musiałem nic z tego robić wystarczyła im rozmowa ze mną i omówienie projektów które robiłem.
@wopper: proponuję dodać do ankiety DevsKiller
xd:)
Na ostatniej rekrutacji najpierw gadaliśmy o projektach jakie robiłem w przeszłości i jest to myślę najlepsza opcja by wiedzieli w czym mam doświadczenie.
Potem przyszedł czas na kilka pytań z teorii ale powiedziałem wprost, że dostaną wyuczone formułki albo omawiam na podstawie jakiegoś kodu z githuba.
Może po prostu nie umiem tłumaczyć czegoś co nie mogę pokazać.
Ale tl:dr - rozmowa o projektach > zadanie domowe (bo sobie zrobie w wolnym czasie albo zleje) > wszystko inne
Cywilizowane i pragmatyczne testy online np. DevsKiller > brak praktycznej weryfikacji kandydatów
wopper napisał(a):
2. Zadania domowe nie są do końca fair, bo spędzasz kilka godzin nad czymś, co może kompletnie nic nie dać.
Tak jak i każda inna forma rekrutacji.
ledi12 napisał(a):
Pair-programming jest najbardziej wiarygodnym, bo od razu widać jak kto pracuje.
Zadania domowe to może robić stażysta/junior chcący wbić się w rynek a nie osoba z x lat expa (No chyba, że adekwatnie zapłacą).
Nie mam problemu z robieniem zadań domowych, i zdecydowanie wolę je od ograniczającego i stresującego pair-programming. Niespecjalnie potrzebuję wbijać się w rynek.
Ostatnio robiłem zadanko w Hackerrank jako pierwszy etap rekrutacji, poświęciłem ok. 30 minut i w sumie przyjemnie się kodowało. Nie wiem na ile to coś sprawdza ale musiałem doimplementować istniejący kod + testy, więc coś tam pewnie o mnie mówi jak piszę soft. Nie było jakiegoś niepraktycznego algo.
Trochę chyba wychodzi na to, że poświęcenie x godzin na zadanie domowe > stres związany z pair-programmingiem.
Żadna, nie mam czasu ani chęci na takie rzeczy. Rezygnuje z rekrutacji która wymaga tego. Nie mam potrzeby być w fancy firmach. A jest wystarczająca liczba firm które nie robią takich cyrków.
Wszystkie trzy sposoby są dla mnie spoko. O ile są zrobione dobrze (chodzi o konkretny wybór zadań - przede wszystkim niezbyt męczące, niezbyt "specyficzne").
Rezygnuję z rekrutacji, jeśli nie sprawdza się na nich umiejętności kodowania.
a co się w pracy generalnie robi?
pewnie czyta częściej niż pisze - no to dajcie coś do przeczytania i sprawdźcie jak kandydat rozumie "tekst pisany"
te wszystkie zadania, pytania na wyrywki itd, analizowania do samego spodu, aby potem w pracy mieć problem nawet z utrzymaniem wiedzy to po co one są?
rekrutacja techniczna jest trudna - szczególnie przy czymś tak abstrakcyjnym jak programowanie i moim zdaniem często ponosi fantazja, fajnie jakby kandydat był taki, siaki, owaki - jak przy telefonie - fajnie jakby miał milion funkcji i super baterię a na co dzień i tak korzysta się z 5 rzeczy na krzyż
Tego tu nie rozwiążemy w tym wątku, ale najlepiej dawać to co się robi
czyta się kod, dac do czytania
poryta domena, dać do rozkminy jakiś use case
używa się intensywnie jakiegoś narzędzia - dać zadanie, żeby było tam to narzędzie użyte
pracuje się z klientami, bez proxy typu BA czy TPM - gadać po angielsku i kazać zebrać wygania, opisać problem itd.
Kontekst tu jest kluczem (coś co jest ważne w tym projekcie, nie zawsze to jest umiejętność techniczna a np. język obcy)- nie ma moim zdaniem, jedynego słusznego szablonu na rozmowę techniczną - ale zawsze można się o to pokłócić :)
Imo dla mnie zadanie domowe, bo mogę sobie zrobić w czasie kiedy jestem najbardziej produktywny a rozmowy techniczne są w różnych godzinach często porannych, albo południowych a wtedy jestem słabo efektywny. Po ostatnich porannych rekrutacjach stwierdzam, że nie ma sensu coś takiego, albo popołudniowe/wieczorne rozmowy, albo zadanko domowe i omówić można być problemu.
Live Coding / Pair Programming jest moją ulubioną i najsensowniejszą formą sprawdzenia kandydata imo i najbardziej właśnie wychodzą mi takie rodzaje interview i najbardziej lubię i luźno się czuję w takim trybie prowadzenia interview, chyba, że trafię na gościa co wstał lewą nogą (raz mi sie zdarzyło) to po prostu kończę rozmowę, mówię, że skoro tak ostro jedzie to raczej nie chciałbym z nim współpracować i informuję, że rezygnuję z procesu rekrutacji i elo
Czitels napisał(a):
Imo dla mnie zadanie domowe, bo mogę sobie zrobić w czasie kiedy jestem najbardziej produktywny a rozmowy techniczne są w różnych godzinach często porannych, albo południowych a wtedy jestem słabo efektywny. Po ostatnich porannych rekrutacjach stwierdzam, że nie ma sensu coś takiego, albo popołudniowe/wieczorne rozmowy, albo zadanko domowe i omówić można być problemu.
No właśnie. Mogę z miejsca odpowiadać na pytania techniczne, na które znam odpowiedź, ale już live coding wymaga ode mnie pewnego skupienia / odpowiedniej energii. A ja nie wiem, jaki będę miał poziom energii danego dnia. Więc bywa tak, że na rekrutacji jest np. codebase jakiegoś projektu w React, a ja nie bardzo kontaktuje, żeby się wczytywać tego dnia o danej porze w czyjś kod.
Więc tutaj lepsze byłoby zadanie domowe, problem w tym, że firmy lubią szaleć z zadaniami domowymi. Np. podobny rodzaj zadania - zmodyfikować istniejącą apkę React. Na live codingu ta apka była dość prosta, kilka komponentów na krzyż (trudniejsze było w zasadzie zrozumienie intencji, co to ma robić i czego ode mnie rekruter oczekuje, żebym ja z tym dalej zrobił).
A jak w innej rekrutacji podobne zadanie ("zmodyfikować apkę React") jako pracę domową - to ta apka w React była dość rozbudowana, napisana dość chaotycznie i miałem długą listę tasków, co mam zrobić z tym. W pracy to byłoby zajęcie na cały sprint, żeby wdrożyć się w projekt, a później dopisać ileś ficzerów :D Ogólnie firmy szaleją z zadaniami domowymi. Live coding ma wady, ale ma też tę zaletę, że live coding bezpośrednio kosztuje firmę roboczogodziny pracowników, więc jest on ograniczony w czasie.
z zadaniami domowymi to polecam brac po prostu kase za czas poswiecony na ich zrobienie. Moje doświadczenie to część firm podziękuje ale część chętnie zapłaci niezależnie od efektów
Może ja tak trafiam ale wszelkie live coddingi, pair coddingi, zadania domowe itd to trafiają mi się przeważnie w firmach w PL. Szczególnie tych mniejszych. Miałem ostatnio chyba 5-6 rozmów w UK. Na jednej było zadanie o które sam poprosiłem bo chciałem mieć pewność co do oczekiwań firmy. A tak to tylko rozmowa o konkretnej technologii, jak bym rozwiązał dany problem itd. Mi o wiele bardziej tak coś pasuje. Przy takim rynku pracy jaki jest teraz nie mam zamiaru tracić czasu na jakieś cyrki i programowanie w vim’ie :) .
Jesli live coding to najbardziej podobalo mi sie podejscie jednej firmy do ktorej aplikowalem. Dostalem maly kawalek aplikacji (ale na tyle duzy, zeby sprawdzic czy umiem sie odnalezc w cudzym kodzie) i zrefaktorowac pewna funkcjonalnosc, towarzyszyl mi programista z rekrutacji, ktorego moglem podpytac o ewentualne szczegoly. Dobrze wspominam te rekrutacje, poniewaz ten typ live codingu byl dobrym odzwierciedleniem rzeczywistej pracy, przy okazji moglem tez wybadac charakter i podejscie do rozwiazywania problemow osoby, ktora miala mi "pomagac" czy tez bardziej sprawdzac moj tok myslenia.
kimikini napisał(a):
z zadaniami domowymi to polecam brac po prostu kase za czas poswiecony na ich zrobienie. Moje doświadczenie to część firm podziękuje ale część chętnie zapłaci niezależnie od efektów
A za normalną rozmowę, w której po prostu odpowiada się na pytania rekruterów też bierzesz kasę?
wopper napisał(a):
- Pair-programming jest spoko, ale gdy można korzystać ze środowiska, które się zna (a nie jakiegoś webowego edytorka).
- Zadania domowe nie są do końca fair, bo spędzasz kilka godzin nad czymś, co może kompletnie nic nie dać.
- Leet Code sprawdza umiejętność rozwiązywania zadań Leet Code i ma się nijak do normalnej pracy.
Ja np. jestem fullstackiem i robię sporo w Angularze, Javie, stawiam sporo rzeczy typu infrastruktura w Terraform, mam też dość szeroką wiedzę z K8S, nawet zrobiłem certa CKA na własną rękę.
No i na rozmowie jak ktoś mi daje algorytm do zaimplementowania to czuje się jakbym się cofnął 6 lat wstecz jak mnie z tego pytali zaraz po studiach. Ja już tych rzeczy nie pamiętam. Z algorytmów byłem najlepszy na studiach.
Mam teraz siedzieć wieczorami i grindowac LeetCode jak mam rodzinę i dzieci? XDD
Zacząłem robić sobie te zadania na Leetcode i nawet ciekawe, dla zabawy można to sobie porobić. No i nie zgodzę się, że to niepraktyczne. Porobiłem kilka problemów i miałem tak, że już myślałem, że dobrze zrobiłem, ale na jakimś edge case się wywaliło i musiałem poprawiać. Więc ładne proste rozwiązanie stało się nagle ifologią. Pouczające. Coś, co naprawdę się dzieje w produkcyjnym kodzie w przeciągu miesięcy (tj. naiwne optymistyczne rozwiązania stają się ifologią z powodu ciągłych zmian wymagań i tego, że się hakuje na szybciorga) możemy zobaczyć od razu i może następnym razem lepiej zaprojektować rozwiązanie, żeby uwzględniało te constrainty już od początku.
Może jakby więcej programistów robiło Leetcode, to później mogliby przenieść to myślenie na produkcję zamiast pisać najpierw naiwny kod, a potem dopisywać różne brzydkie haki. Ale może większość ludzi tak nie myśli i po prostu uczy się tego LC, żeby pozaliczać, a nie zależy im na rozwoju?
Może wyjdę teraz na ignoranta ale...
Skoro w pracy co chwila przepisujecie funkcjonalność X to coś jest nie tak? Wiadomo, że można każdą funkcję czy komponent opakować w kosmiczną warstwę abstrakcji dzięki której będa przygotowane do robienia tego co początkowo założył klient, do obsługi lotu na marsa i jako skrypt do gierki w Unity ale chyba przez to to się robi mało czytelne i zajmuje więcej czasu przez co wychodzi drożej?