Przeglądanie Githuba przed rozmową o pracę

3
  1. Ile razy zdarzyło się wam przejrzeć czyjeś repozytorium na Githubie?
  2. Ile razy zdarzyło wam się, że rekruter przejrzał wasze kody na Githubie? Podasz przykłady konkretnych firm?
  3. Dlaczego to jest tak rzadka praktyka?

Z moich obserwacji wynika, że rekruterzy kompletnie nie przygotowują się do rozmów, nie czytają w ogóle CV ani nie otwierają linków z CV do bezpiecznych stron typu Github, żeby przejrzeć czyjś kod. Później na rozmowach dostajesz pytanie o "inner joiny" albo o przekazywanie zmiennych przez referencję i marnujesz swój czas. Często osoby z działu rekrutacji proszą o przyjście na rekrutację przez wiele miesięcy po czym rekruterzy "techniczni" w taki sposób traktują potencjalnych pracowników i psują na wejściu wzajemne relacje. W jaki sposób unikać takich sytuacji?

Edit: Nie mam nic przeciwko sprawdzaniu umiejętności na rozmowie. Jednak jeżeli ktoś kto przez całe życie pisze w Javie pyta cię np. o wyrażenia lambda i odpowiadasz mu o rachunku lambda przy czym ten ktoś czeka aż powiesz słówka kluczowe "interfejs funkcjonalny" i nie powie ci nawet, że oczekiwał innej odpowiedzi to skąd masz wiedzieć co taka osoba ma na myśli? Wydaje ci się, że odpowiedziałeś dobrze na wszystkie pytania po czym okazuje się, że nic nie umiesz i jednak szukają kogoś innego. Próba udowodnienia takiej osobie w sposób dosadny (zadając jej kontrpytania na tym samym poziomie), że jednak coś tam wiesz kończy się tym, że obie strony się po prostu murują w swoim zadufaniu i nawet jeżeli dostaniesz taką pracę to nie będzie się dobrze pracowało w takim środowisku. Jak diagnozować takie sytuacje możliwie szybko i ich unikać?

0

A w jaki sposób chciałbyś unikać takich sytuacji? nie masz wpływu na rekrutera, bo nawet nie wiesz kto cię będzie rekrutował :o

Możesz poczytać opinię o firmie lub znajomych popytać z branży.

1
  1. nigdy chyba, że mówimy o repo biblioteki której potrzebuje a coś niejasno działa.
  2. nie mam githuba publicznego
  3. nie wiem (ehh ikonka nie chce wskoczyć)
1

Zabawne jest, że mało w której firmie ktoś zadaje sobie trud, żeby przejrzeć Githuba - a z drugiej strony niejednokrotnie firmy dają zadanie rekrutacyjne, w której np. trzeba ściągnąć repo firmowe, wczytać się w nabazgrany tam spaghetti kod i zaimplementować w nim kilka(czasem kilkanaście) zmian. Niektóre firmy nawet rozpisują zadanie domowe w formie user stories.

Czyli ludziom z firm się nie chce nawet spojrzeć na Githuba, ale już od kandydatów tego wymagają i to w wersji zaporowej (mam wrażenie, że niektóre zadania domowe są nie po to, żeby sprawdzić umiejętności ale głównie po to, żeby odsiać niezdecydowanych/nie dość zdesperowanych, którzy po prostu nie mają ochoty spędzać kilku/nastu godzin na zadanie, za które nie dostaną kasy, ani nawet gwarancji nawiązania współpracy :D ).

Czyli niby rynek pracownika, a i tak asymetryczna sytuacja. Te wszystkie zadania domowe sprawiają, że kandydat musi więcej czasu spędzać na daną rekrutację i więcej od siebie dać, niż firmy, która nawet feedbacku często nie są w stanie napisać.

rekruterzy kompletnie nie przygotowują się do rozmów, nie czytają w ogóle CV ani nie otwierają linków z CV do bezpiecznych stron typu Github, żeby przejrzeć czyjś kod.

Możesz sam opowiadać o projektach na rozmowie, i sam się zaprezentować jakoś dzięki temu, poza tym przejąć rozmowę. Jak będziesz opowiadać o projektach, to mniejsza szansa, że cię zapytają z jakiegoś trudnego pytania technicznego.

5

Osobiście zawsze otwieram GitHuba do którego link kandydat podał w CV.
I efekt jest taki, że większość CV, które tego linka zawierają odrzucamy jeszcze przed rozmową bo kod tam to albo przeklejony tutorial albo, co autentycznie widziałem niedawno, projekt z commitami o treści „komit” czy „dużo zmian” i pustym plikiem Class1.cs w każdym podprojekcie.
Większość bardziej ogarniętych programistów jakich dostajemy na rozmowy akurat nie podaje repo więc trudno się do niego odnieść na rozmowie.

0

Mało kto uczestniczy w projektach Open Source. Kod firmowy ma zakaz publikowania. Dlatego nie ma kodu na GH.

Nazwy "Projekt dyplomowy na GitHubie" zaczęły używać szkoły programowania. Projekt a w rzeczywistości przeklepany setki razy tutorial na GitHubie miał zastąpić kursantom dyplom uniwersytetu.

Tysiące kursantów szkół programowania powtarza github, github, github.

Dlaczego nikt nie ogląda mojego githuba?!?!?!

5
  1. Raz.
  2. Raczej, nigdy, zresztą na moim GH nie ma czego oglądać.
  3. Bo jest to bezużyteczne? Skąd w ogóle masz mieć pewność że to są kody kandydata? Poza tym rekruterzy techniczni często nie chcą niepotrzebnie wprowadzać jakiegoś biasu do swojej oceny, więc nie googlują sobie kandydata i w ogóle nic na jego temat nie sprawdzają, dzięki temu są bardziej bezstronni i polegają tylko na tym co ktoś pokazał na rozmowie.

w Javie pyta cię np. o wyrażenia lambda i odpowiadasz mu o rachunku lambda

To znaczy że nie zrozumiałeś pytania.

5
  1. zawsze (jesli istnieje i jest wzglednie latwe do znalezienia, np link w cv)
  2. na wielu rozmowach moj github byl przynajmniej wspomniany (oczuwiscie nie mowa o https://github.com/katelx na ktory zagladam srednio raz w roku ;)), z takich firm co sa tez w polsce to w hsbc, goldman sachs, ubs
  3. nie wiem czy takie rzadkie no ale rzeczywiscie, to dosc glupie nie wykorzystac takiej okazji... wynika to chyba z malego zaangazowania i/lub swiadomosci rekrutujacych

betonowe podejscie spotyka sie z obu stron. sa rekruterzy (czesto gesto w bankach) ktorzy zadaja pytania zwiazane z problemem ktory dumnie rozwiazali samodzielnie i teraz na rozmowach oczekuja ze ludzie podadza im to samo rozwiazanie i tylko wtedy takiego kogos uznaja za wartosciowego ;)
z drugiej strony masa kandydatow (zwlaszcza tych bardziej doswiadczonych) cechuje sie irytujaca nonszalancja lub wrecz oburzeniem ze ktos mu zadaje zle pytania, takie co wg kandydata nic nie sprawdzaja (czytaj nie zna odpowiedzi)
mysle ze rekrutacja niekoniecznie odzwierciedla jak bedzie wygladala praca, wszystko zalezy od firmy/kandydata.

1

Mam wrażenie, że część osób wypowiadających się tutaj próbuje mnie przekonać, że skoro oni nie mają nic na Githubie albo 10 lat temu napisali jakiś kod, który w ich mniemaniu ich kompromituje to z tego względu nie powinno się zaglądać na Githuba i czytać kodów kandydata kiedy ten udostępnił do niego link w CV. Pojawiły się nawet aluzje do Facebooka i 4p. Tylko, że ja mówię tutaj o tym, że ktoś dobrowolnie wstawił linka do Githuba, a nie, że rekruter wystalkował ten link. Nikt o zdrowych zmysłach nie podaje dobrowolnie w CV linka do swojego Facebooka. Dlaczego osoba, która wstawiła link do Githuba i być może ma tam argumenty przemawiające na jej korzyść (lub niekorzyść) ma być traktowana tak samo jak osoba, która tego linka nie wstawiła?

Równie dobrze podczas rozmowy można uznać, że wpis o dyplomie uczelni wyższej też jest biasem i nie powinieneś czytać tej sekcji bo być może ktoś tam może mieć słabą uczelnię. Idąc dalej ktoś mógł pracować w firmie, która niedawno upadła i ta informacja też wprowadza bias do postrzegania tej osoby.

2

Ten „GitHub” i „portfolio” to jakieś mantry naszych czasów. IMO takie repo może zadziałać jedynie na niekorzyść - jak zobaczę jakieś krzaki, to nie zaproszę na rozmowę. Z drugiej strony, żeby osiągnąć efekt „wow”, raczej wolałbym zobaczyć kontrybucję do open source niż kolejną izomorficzną wersję Spring Petclinic. Moim zdaniem wannabe juniorzy szukają jakiegoś ekwiwalentu braku komercyjnego doświadczenia. IMO lepiej albo iść na studia i samemu doczytać o tym czego się obecnie używa, na rozmowie i tak sprawdzany jest raczej potencjał i umiejetność kombinowania, niż szczegółowe pytania jak działa dana technologia (w końcu to junior ok?). Albo, jak napisałem wyżej, sensowne PR-y do open source - to też w przypadku midów i wyżej.

5

Problem jest w tym, że pracując zawodowo nie ma co wrzucać bo kod który tworzysz nie jest twoją własnością lub zarabiasz na tym oprogramowaniu więc nie będziesz dzielił się z konkurencją. Więc mnie nie dziwi ktoś, że ktoś kto pracuje jako programista 10 lub więcej lat i nic nie ma na github'ie. Programy rozwijane po godzinach / hobbystycznie zwykle nie osiągają rozmiarów projektów komercyjnych (no chyba, że ktoś myśli o ich komercjalizacji). Ja sam na github'ie publicznie mam tylko kilka skryptów w pythonie, które wystawiłem dla konkretnej grupy osób (informatyka śledcza), Co do kandydatów uważam, że czasami kilka minut rozmowy wnosi więcej niż testowe przepytywanie. Jak człowiek jest zdolny, pracowity, umie sobie zorganizować pracę i ma podstawy to szybko się douczy.

6

Pracując w HSBC jako programista Scali miałem okazję dobrych kilka razy (albo w sumie nawet kilkanaście) być na rekrutacji po stronie sprawdzającego (a nie sprawdzanego kandydata). Mam więc pewną perspektywę na działanie działu HR i procesu rekrutacji. Moją historię trzeba podzielić na 2 etapy:

    1. etap to etap w którym zatrudnialiśmy do własnego zespołu, bo przenoszenie ludzi z Londynu do Krakowa nie przebiegało po myśli menedżerów (ekipa z Londynu wykruszyła się zbyt szybko, ekipa w Krk też była niestabilna i trzeba było uzupełniać braki, kontraktorzy z zewnętrznej firmy kosztowali zbyt dużo)
    1. etap to etap w którym byłem angażowany do rekrutacji do obcych zespołów (ale dalej z HSBC), bo bylem chętny i się sprawdzałem w roli rekrutera, a na miejscu jest niedobór Scalowców którzy mogli by rekrutować do nowych zespołów

Na etapie 1. było dość profesjonalnie. CVki dostawaliśmy z dużym wyprzedzeniem, był czas by przejrzeć profil kandydata. Rozmowy były tak długie jak tego chcieliśmy (a przez to że było kodzenie na rekrutacji to całość wydłużała się czasem do 3 godzin). Przez to, że rekrutowaliśmy do własnego zespołu to doskonale wiedzieliśmy czego chcemy od kandydata. Na początku mieliśmy problem z brakiem sensownych kandydatów, ale w pewnym momencie wyszedłem z inicjatywą. Korzystając z tego, że menedżer nie był stanie pracować (L4 czy coś innego) przeredagowałem ofertę pracy, potem do akcji dołączyli inni z zespołu i po wysłaniu przeredagowanej oferty (mniej bullszitu i straszaków, więcej zachęty i konkretów) do agencji rekrutacyjnych mieliśmy całkiem sporo sensownych kandydatów.

Etap 2. to już chaos. Ostatnio wyglądało to tak, że np o 9:30 dostaję sygnał "hej Piotrek, masz czas przepytać kandydata o 12:00"? Jako że jestem chętny na takie akcje to się zgodziłem (w międzyczasie jeszcze biorę prysznic, jem śniadanie i jadę do pracy - w końcu wcześniej planowałem sobie pracę z domu :) ). Dostaję CVkę zmieloną przez agencję rekrutacyjną i efektywnie jest w niej tylko zupa z buzzwordów. Nie wiem jaki jest projekt do którego rekrutuję, więc pytam o ofertę pracy. HRka nie spieszy się z podaniem jej. Tuż przed rozmową dostaję tę ofertę, ale konkretów tam jest może kilka zdań. Reszta to opis historii firmy (150 lat bycia liderem w dynamicznej branży i tam takie pierdu pierdu), lista benefitów czy inne nietechniczne mało ważne sprawy. Do tego okazuje się, że poszukują Senior Scala ze znajomością Javy, a nie Senior Java ze znajomością Scali, a więc albo oferta pracy jest lewa, albo dostałem nie to co trzeba. Wobec tego na rozmowie wprost pytam kandydata na jakie stanowisko aplikuje i jakie umiejętności mają się liczyć, by dopasować pytania do stanowiska. Na końcu HRki mi ślicznie dziękują że ogarnąłem sprawę. HRki to oczywiście uśmiechnięte sexi laseczki, które udają że wszystko jest spoko.

Jak widać sytuacja może się diametralnie zmieniać w obrębie tej samej firmy.

2
twoj_stary_pijany napisał(a):

Mam wrażenie, że część osób wypowiadających się tutaj próbuje mnie przekonać, że skoro oni nie mają nic na Githubie albo 10 lat temu napisali jakiś kod, który w ich mniemaniu ich kompromituje to z tego względu nie powinno się zaglądać na Githuba i czytać kodów kandydata kiedy ten udostępnił do niego link w CV

A ja mam wrażenie że to ty usilnie starasz się wszystkich przekonać że trzeba sprawdzać kod na Githubie i jak ktoś śmie tego nie robić.

1

Będę chciał przeglądać fajny projekt tutoriala to pójdę po oryginał na Udemy. W promocji za 39 czy 49 zł dostanę oryginalny kod z dobrym video.
Przeróbki mnie nie interesują.

Problemy podpadające pod najpopularniejsze buzzwordy #github #bootcamp #zostacprogramista nie interesują ludzi robiących rekrutacje.

Elektroda. Można zamknąć temat.

4

Cool story, ale jaki to ma związek z przeglądaniem Githuba? xD Rozumiem, że dostawałeś CV na szybko, przerobione i bez linków do Githuba, ale mówię o sytuacjach w mniejszych firmach gdzie oni widzą moje oryginalne CV i go nawet nie czytają. - twoj_stary_pijany 33 minuty temu

Weź pod uwagę, że:

  • projekty na GitHubie mogą być słabo udokumentowane, ciężkie do otworzenia, skompilowania, odpalenia, przetestowania, itd Nie wiadomo co jest boilerplatem, a co mięchem którym chcesz się pochwalić. Sam kod bez historii za nim też jest pewną niewiadomą - nie wiadomo czy kod jest posklejanym kodem z tutoriali czy może jednak natknąłeś się na problem który nie był rozwiązany ani w tutorialach ani w SO (czy innym miejscu indeksowanym przez Gugla) i musiałeś wykazać się własnym sprytem i kreatywnością.
  • nie pokazałeś nam jakie masz projekty na GitHubie i jak je reklamujesz w CV
  • ocena kandydata nie musi się kończyć wraz końcem rozmowy rekrutacyjnej - jeśli poopowiadasz na rozmowie o swoim projekcie który wystawiłeś na GitHuba to po rozmowie rekrutacyjnej ktoś może się mu przyjrzeć i może to wtedy pozytywnie wpłynąć na twoją ocenę.

Nieraz widzę na GitHubie projekty, które wydają się mieć ambitną tematykę, ale mają 0 dokumentacji. Stąd ciężko wywnioskować co taki projekt mówi o umiejętnościach programisty.

2

Weźmy pod uwagę że na wielu albo i większości kont (w tym na moim) większość projektów to są jakieś śmieciowe forki bo ktoś chciał coś sobie niestandardowo skompilować, a mało własnego kodu…

1

Potrzebna jest maść na konkretny rodzaj bólu.

@twoj_stary_pijany co najmniej pięć razy użył w argumentacji zestawienia github kontra studia i dyplom.

2

Jeśli ktoś nie ma co pokazać na GH to po co je wrzuca do CV? Można więc założyć, że skoro ktoś już dał link do GH to chce się pochwalić czymś. (Aczkolwiek w praktyce chyba każdy daje, bo inni dają)

0

Jest jeszcze jedna możliwość o której należy pamiętać. Czasem rekrutujący dostaje informacje o rozmowie 5 minut przed. Nawet nie ma czasu zobaczyć CV. Albo wie o rozmowie, ale o CV się nie można doprosić. Albo zapomni... Także nie tylko Githuba nie przejrzy ale samego CV. I owszem, może to świadczyć o czymś w firmie nie tak, ale nie koniecznie o pozycji czy pracy tam.

4
  1. Nie przeprowadzałem rekrutacji póki co.
  2. Na około ~10 rozmów na pewno przynajmniej jedna firma spojrzała na githuba. Pozostałe nic nie wspominały.
  3. Tak jak już zostało wspomniane, nie wiadomo na co patrzeć; nie wiadomo co jest autora, a co nie; brak dokumentacji, za dużo czasu potrzeba na pobranie projektu i uruchomienie go i pewnie wiele innych powodów

Jeśli potrzebujesz zaprezentować jakiś konkretny projekt/projekty myślę, że powinieneś jakoś je wyróżnić albo konkretnie je wyliczyć w CV wraz z linkami do repozytoriów. W repozytorium na pewno dobra dokumentacja, można konkretnie wspomnieć co robiło się samemu, a co z biblioteki albo od kolegi, jeśli aplikacja z UI, to załączyłbym na pewno screenshoty, jeśli webowa to najlepiej z działającym linkiem. Dobrze też (zwłaszcza w przypadku aplikowania na junior) mieć jakąś historię repozytorium, a nie jeden commit "komituję wszystko". Na pewno zwróciłbym w przypadków juniorów czy wszystko jest na jednym branchu czy jest chociaż kilka, żeby można było wywnioskować czy kandydat umie chociaż zrobić merga (co oczywiście nie jest dowodem, że umie i pewnie mało kto by tak głęboko grzebał, żeby sprawdzić, ale ja, jako kandydat, zrobiłbym tak na wszelki wypadek mimo wszystko jakbym miał czas : ) )

Wydaje mi się, że sztuką jest też naprowadzić rekrutera od samego początku na to o czym chce się z nim rozmawiać i myślę, że warto o tym już myśleć kiedy wysyłasz CV.

3

Wziąłem sobie do serca kilka rad, które tutaj się pojawiły.

  • W szczególności pooglądałem sobie repozytoria innych ludzi i zauważyłem, że faktycznie jest sporo osób, które mają same tutoriale. U mnie też się kilka takich znalazło, ale je poukrywałem.
  • Dalej, dodałem kilka opisów do swoich repozytoriów.
  • Pozmieniałem im nazwy. Tam gdzie w nazwie było np. tutorial, a był to mój kod, który gdzieś prezentowałem zmieniłem na nazwę, która jest bardziej opisowa co do samego projektu.
  • Opisałem jedno repozytorium w CV jako projekt i krótko wypisałem co w nim jest.
  • Usystematyzowałem nazwy kilku projektów i wpisałem do CV te projekty jako jedno z kilkoma przykładowymi linkami.

Uwagi:

  • Niestety kilku forków nie mogę usunąć bo autorzy projektów nie utrzymują ich już od wielu miesięcy i nie chcą mi zmerge'ować PRów, lub te PRy są może za słabe, ale ich potrzebuję/potrzebowałem.
  • Generalnie staram się usuwać stare projekty z CV natomiast w zależności od tego w czym chcemy szukać pracy to osobiście uważam, że trzeba mieć trochę kodu około dziedzinowego, który pokazuje, że od czasu do czasu sobie eksperymentujesz.
0

Ja bym przeglądał githuba, ale głównie activity, konkretnie chodzi o udostępnione pull requests, issues czy inne sprawy, których właściciel repo prowadził interakcję z innymi projektami. Sam może nic nie mieć (publicznego), zresztą jak @Wibowit wspomniał, są problemy z dokumentowaniem swojej pracy i wyjaśnianiem co to ma robić.

Myślę, że jest znacząca różnica, między kimś, kto ma 10 projekcików/crudów z tutoriala, a kimś, kto ma niby pustego githuba, ale ma choćby 1 zaakceptowanego PRa do jakiegoś dużego i popularnego projektu, którym zmienił coś więcej niż kilka literówek w dokumentacji, tudzież zgłoszone issues, które finalnie nie okazały są jego niezrozumieniem projektu.

0

Jak już @Silv odkopał ten wątek swoimi komentarzami to jak wygląda sytuacja 2021? Coś się zmieniło?

3

Dobry moment bo jestem "na bieżąco" i w trakcie procesów. Mam kilka projektów open sourcowych - dosyć niszowa tematyka ale wstydzić się nie wstydzę:
https://github.com/MarketSquare/robotframework-robocop
https://github.com/MarketSquare/robotframework-tidy

Brałem udział w kilku rekrutacjach ostatnio.
Pierwsza:
Programista Python, bardzo duży nacisk na open source, nawet podkreślili w ogłoszeniu oraz na screeningu, że ocenią i omówią moje contributions z githuba. Brzmi ciekawie więc biorę udział w rekrutacji. Dostaję informację, że pierwszy etap to "2h test na codility, koniecznie powtórz sobie algorytmy, grafy itp". Spędziłem tydzień na dodatkowej nauce (sam chciałem w razie podobnych sytuacji przy innych rekrutacjach). Test przeszedłem - faktycznie przydała się wiedza z algorytmów i ślepego klepania leetcode a Pythona tyle co ogarnąć prostego for-a. Drugi etap: 1h coding interview. Super, w końcu uda mi się pokodzić w Pythonie! Ale niestety nie, dostałem kolejne zadanie z grafów - i miałem kod pokrywający prawie wszystkie przypadki ale nie wszystkie więc podziękowali ;).
Podsumowując: chwalili się, że open source jest ważny ale jak zapytałem, czy wpadli na mój github to zaprzeczyli - podobno zrobiliby to później.

Druga:
Pierwsze spotkanie - miały być techniczne pytania i white board, firma z USA. Jednak przez pierwsze 30 minut rozmawiamy sobie na luzie o DevOps, QA i o życiu. Kiedy myślę, że dostanę w końcu konkretne pytanie usłyszałem "zawsze dajemy zadanie techniczne i trochę teorii ale zajrzałem na Twojego githuba i widzę, że znasz Pythona na tyle, że sobie odpuszczę". Etap zaliczony i skrócony bieg pozostałej części rekrutacji.

Wniosek: Jak to w IT, to zależy ;) Projekty open source robię bo lubię, na pewno mi nie zaszkodziły ale niestety nie zawsze udaje się ominąć typowych zadań testowych dzięki pokaźnemu repo. Dostać się na rozmowę dostawałem się i tak zawsze zanim zacząłem dodawać url.

0

Ale skąd pewność że to co na githubie to własność kandydata? Że nie napisał mu tego kolega albo nie poprzeklejał po prostu kodów ze stackoverflow? Skąd pewność że tej prostej części kodu nie pisał i poprawiał przez dwa tygodnie przed commitem. Dla mnie to żaden dowód umiejętności, i tak trzeba kandydata przepytać.

Zresztą weryfikacja i tak nie jest problemem - ja za każdym razem kiedy w cv jest link do githuba wchodzę ale prawie zawsze jest tam ten sam syf - zero inwencji twórczej, te samy projekty nie dużo bardziej skomplikowane niż "hello world". Pomysły jakby żywcem wzięte z https://what-to-code.com/ i podobnych - każdy klepnięty w dzień / dwa i brak aktywności poza tym
Nie widzę żadnej wartości takiego "portfolio"

4

@obscurity:

obscurity napisał(a):

Ale skąd pewność że to co na githubie to własność kandydata? Że nie napisał mu tego kolega albo nie poprzeklejał po prostu kodów ze stackoverflow? Skąd pewność że tej prostej części kodu nie pisał i poprawiał przez dwa tygodnie przed commitem. Dla mnie to żaden dowód umiejętności, i tak trzeba kandydata przepytać.

Serio uważasz, że nie umiesz odróżnić zlepku tutoriali i SO od samodzielnie napisanego kodu? o.O

0
somekind napisał(a):

Serio uważasz, że nie umiesz odróżnić zlepku tutoriali i SO od samodzielnie napisanego kodu? o.O

no właśnie umiem i zazwyczaj wygląda to właśnie jak zlepka tutoriali i SO

1

No to skoro umiesz, to chyba nie powinieneś mieć problemu ze stwierdzeniem, czy to zlepek czy autorski kod, więc pytania z początku Twojego posta nie mają sensu. :P

0

Interesujący wątek i posty tutaj, ponieważ z doświadczenia mojego i moich kolegów, nikt nigdy nie sprawdza Githuba, bo po prostu nie ma na to czasu (a czas pracy programistów jest drogi)

10

@Pinek:

Pinek napisał(a):

Interesujący wątek i posty tutaj, ponieważ z doświadczenia mojego i moich kolegów, nikt nigdy nie sprawdza Githuba, bo po prostu nie ma na to czasu (a czas pracy programistów jest drogi)

W firmie robiliśmy niedawno rekrutację na junior developera i sprawdzaliśmy każdemu kandydatowi projekty na GitHubie. Mało tego. Na rozmowie wyświetlaliśmy na rzutniku albo na współdzielonym ekranie ich własny kod i o nim gadaliśmy. Nie wiem, jak można lepiej zweryfikować kandydata bez żadnego doświadczenia. Jak ktoś nie miał projektów na GitHubie, to dostawał zadanie, żeby napisać projekt i wrzucić go na GitHuba, żebyśmy mieli o czym gadać.

Wiadomo, że to zajmuje czas, ale więcej czasu i pieniędzy będzie zajmowało użeranie się później z niekompetentną osobą, którą się zatrudni.

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