Potrzebujesz** testu programistycznego. Ale to powinno być 5-10 minut. Najwyżej 30 minut. Nie ma 2 godzinnego testu, który powie ci dokładnie, jak dobry jest programista. Nie będziesz w stanie stwierdzić, czy ciągle pisze kod, czy zawsze poprawnie komentuje, czy wymyśla nieczytelne bałagany “sprytnych” rozwiązań problemów, itp. W ciągu 2 godzin, jedyne co osiągniesz, to dowiesz się, kto szczerze kłamie na temat znajomości języka/programu.

Z wyjątkiem tego, że powinieneś być w stanie dostrzec szczere oszustwa w znacznie krótszym czasie niż 2 godziny. 5 minut pisania FizzBuzza i 2-3 szybkie pytania dotyczące specyficznych cech językowych powiedzą Ci, czy są one absolutnie bezwartościowe. I to jest najlepsze, co możesz zrobić w rozmowie kwalifikacyjnej.

Pozwól, że powiem Ci, co bym pomyślał, gdybym otrzymał 2 godziny egzaminu na przywilej prowadzenia rozmowy kwalifikacyjnej:

“Albo ci ludzie myślą, że to ma wartość, co oznacza, że nie mają pojęcia, co robią, LUB, wiedzą, że to strata czasu, ale z jakiegoś powodu (prawdopodobnie ślepo po biurokracji HR), są skłonni marnować czas kandydatów przed zatrudnieniem nawet kandydata. Wyobraź sobie, co mogą sobie wyobrazić, gdy mi zapłacą.

Tak czy inaczej, nie chcę tam pracować.”

Jest jeszcze jedna rzecz, która może odpędzać kandydatów: Długość twojej rozmowy kwalifikacyjnej. Masz ludzi robiących rozmowę telefoniczną. Potem test w domu, który mają tydzień do końca. Potem przechodzisz przez testy. Potem ustawiasz rozmowę twarzową z kierownictwem. Potem (zakładam, że) robisz kilka wywiadów osobistych. Potem wracasz do faceta, którego chcesz zatrudnić. Ile to zajmie? 2 tygodnie? Dłużej?

W tym czasie dostałem już 3 oferty. Przyjęłam jedną i zaczynam w przyszłym tygodniu. Myślisz, że pójdę zrobić twój dwugodzinny test?

Laat ik beginnen met te zeggen dat het aannemen van medewerkers in het algemeen een pathetisch onnauwkeurige wetenschap is, en dat je verschillende resultaten zult krijgen, wat je ook probeert. Dat gezegd hebbende, vond ik dat ik mijn gedachten hierover moest delen.

Ik denk dat programmeeroefeningen een mislukking zijn, vooral omdat je mensen krijgt die wanhopig zijn en veel te veel tijd hebben om het af te maken. Als ze een fulltime baan hebben, zou je moeten vragen hoeveel tijd/mentale energie ze van hun huidige werkgever nemen om voor iemand te werken die ze niet eens betaalt. Wil je dat ze dat soort dingen met je doen?

Bovendien, als ze goed zijn, zijn ze waarschijnlijk met veel werkgevers aan het interviewen. Raad eens welke ze prioriteit zullen geven? Degenen die niet vragen om projecten af te ronden voordat ze zelfs maar aan de telefoon komen met een ingenieursmanager.

Er is ook het probleem van plagiaat. Tuurlijk, ze komen in het persoonlijk gesprek aan het licht, maar tegen die tijd heb je al de tijd verspild van (vermoedelijk) hoogbetaalde mensen bij het bedrijf dat deze persoon interviewt.

Mijn huidige bedrijf heeft het goed gedaan, en dit is de weg die ik zou inslaan in jouw positie. Geef ze een kleine taak die misschien maar 90-120 minuten zou moeten duren, en vertel ze in het commentaar te verantwoorden waarom ze voor die manier van oplossen van het probleem hebben gekozen. Dit is iets dat kan worden gedaan in een nacht, en zal u inzicht geven in hun denken.

Ik kan u nu al vertellen dat als ik een project krijg dat 8+ uur duurt om te doen, ik hen bedank, maar ik ben niet geïnteresseerd. Ik heb een goede baan en een leven. Als een manager dat als een probleem ziet, zegt me dat ze zich niet zouden bekommeren om mijn work/life balance op het werk (vooral als ze er niet om geven voor ik het heb). Geen enkel bedrijf, behalve misschien Google, Apple of Facebook, kan daar mee wegkomen.

W moim doświadczeniu, projekty typu “take-home” nie eliminują złych programistów, i prawdopodobnie sprawiają, że dobrzy programiści znajdują pracę, w której nie muszą skakać przez obręcz, żeby porozmawiać z kierownikiem ds. rekrutacji. Dobry programista może łatwo uzyskać telefon i rozmowę osobistą. Każdy dodatkowy obręcz, przez którą muszą przeskoczyć, będzie oznaczał, że pójdą łatwiejszą drogą i przeprowadzą rozmowę kwalifikacyjną (i zostaną zatrudnione) przez kogoś innego, kto zapłaci tyle samo. Jeśli każesz ludziom skakać przez obręcze, upewnij się, że widzą, że jest to warte ich czasu z get-go.

Zły programista może trwać tak długo, jak chcą. Nie zobaczysz, że trwa to 4x dłużej, zobaczysz tylko zakończony test. Nie zobaczysz też, żeby poszli do Google albo do kumpla po pomoc z oświadczeniem if.

Moja ostatnia firma to zrobiła, a zdecydowana większość osób, które przyprowadziliśmy na osobisty wywiad zawiodła Fizz buzz (około 65%). Myślę, że stało się tak dlatego, że nieumyślnie wyeliminowaliśmy dobrych, zajętych ludzi, którzy nie potrzebowali wywiadu z inną firmą, a w tym samym czasie wymachiwali łatwym wywiadem przed złymi programistami.

Co moim zdaniem powinniśmy byli zrobić zamiast tego

Zamiast dać ludziom zadanie do zabrania do domu, które zajęło 15-20 minut do oceny, powinniśmy byli zrobić 15-20 minutowy wywiad przez Skype'a, gdzie zadawaliśmy pytania jak Fizz buzz. Zajęłoby to tyle samo czasu, ale prawdopodobnie wyeliminowałbym złych programistów przed dwugodzinnym wywiadem osobistym.

FYI -> Oto bardzo szczegółowy artykuł o Fizz-buzz i ogólnych praktykach prowadzenia wywiadów.

Kontrastowy widok, od kogoś w okopach po obu stronach tego pytania. Podejrzewam, że ta odpowiedź będzie przyciągać głosy w dół, ale jest to bardzo świadoma opinia, wypracowana na przestrzeni kilkudziesięciu lat w tym biznesie. Ponieważ lubię to robić, wciąż piszę kod codziennie na własny użytek i jako hobby w moim “obfitym wolnym czasie”, ale byłem również ostatecznym decydentem o zatrudnieniu kilkudziesięciu programistów i pomagałem w rozmowach i doradzałem przy zatrudnianiu dość dużej liczby innych.

Lawrence ma rację: zatrudnianie jest żałośnie nieudolne. Ale z czasem stajemy się w tym coraz lepsi. Więcej niż rozmowy twarzą w twarz, więcej niż trywialne pytania, krótkie wyzwania związane z programowaniem na miejscu są coraz bardziej istotną częścią tego procesu: nie tylko ze względu na umiejętności, ale i nastawienie.

Zauważ, że powiedziałem “krótkie ”. Dajemy kandydatom laptopa ustawionego z odpowiednio zainstalowanym Zaćmieniem (naszym wybranym IDE), gdy przychodzą na rozmowę. Prawidłowo ustawione oznacza, że mają dostęp do źródła jdk, ale nie mają dostępu do Internetu i są proszeni o nie używanie telefonów komórkowych podczas testu. Dostają godzinę na rozwiązanie od zera do pięciu problemów, zaczynając od “FizzBuzza”, a kończąc na złożoności do czegoś na zamówienie prostego wielowątkowego systemu producenta/konsumenta.

Nikt nigdy nie rozwiązał wszystkich pięciu w ciągu godziny i nie spodziewam się, że ktokolwiek kiedykolwiek to zrobi (mogę napisać rozwiązania dla pięciu w komfortowych warunkach w mniej niż godzinę, ale oczywiście widziałem problemy i rozwiązałem je wszystkie wcześniej, więc nie jestem uczciwym testem).

Nawiasem mówiąc, mieliśmy pozornie doświadczonych programistów zawód, aby FizzBuzz był dobry. Powiem to jeszcze raz: mieliśmy garstkę kandydatów, którzy nie ukończyli poprawnie FizzBuzza. Zazwyczaj nie podążając za wskazówkami, ale czytanie specyfikacji jest istotną częścią bycia programistą.

Mamy ich, którzy piszą kod tutaj na miejscu, zamiast dawać im pracę domową z kilku powodów, częściowo z powodu ryzyka oszustwa, a częściowo po to, aby dać każdemu kandydatowi równe szanse na rozwiązanie problemów. Obracamy również problemy w zestawie i poza nim, a następnie omawiamy rozwiązania z kandydatami.

Czuję się niezwykle mocno w tej kwestii. Nigdy nie widziałam, aby kandydat odmówił przyjęcia stanowiska lub zrezygnował z rozmowy kwalifikacyjnej z powodu naszego testu programistycznego. Ale może mieć na to wpływ fakt, że mówimy rekrutującym, którzy nam służą, że proces ten obejmuje programowanie na miejscu. Możemy więc po prostu nie widzieć kandydatów, którzy uważają, że poproszenie ich o napisanie godzinnego kodu jest “bezpłatną pracą”. Jeśli tak, to dobra zabawa. Jeśli uważają, że godzina kodowania jest bardziej jak “praca” niż godzina odpowiadania na trywialne pytania, albo że ich odpowiedzi na problemy z testami mogą przynieść cokolwiek pożytecznego, nie potrzebuję ich postawy.

Kiedyś mieliśmy jednego kandydata, który narzekał na test, bo uważał, że jest za bardzo starszy, żeby się wykazać (to nie są spekulacje - powiedział). I dobrze sobie radził z wyzwaniami, i miał całe nasze doświadczenie. Ale był strasznym pracownikiem: najwyraźniej myślał też, że jest za stary, by się uczyć lub kierować, i w końcu musieliśmy go wypuścić.

Jedną z rzeczy, o których zdecydowałem przez lata, kiedy to robiliśmy, jest to, że każda firma, która nie zrobiła** testu, ma mniejsze szanse na to, by mnie zatrudnić. Podobnie jak ich odpowiedzi na pytania jak to, czego używają do kontroli źródeł itp., czy testy firmowe mówią mi dużo o tym, jak dobre są w biznesie rozwoju oprogramowania.

Więc co powinieneś you robić? Powinieneś robić to, co sprawdza się w Twojej organizacji, ale moja rada to kontynuować testy, ale robić je na miejscu, w ramach wywiadu. Powiedz im z góry, że to część procesu i zrób to zanim spotkają się z wyższą kadrą kierowniczą (ale najpierw powinieneś się z nimi spotkać, aby pomóc im się uspokoić). I naprawdę: pomiń rozmowę z kierownictwem wyższego szczebla, jeśli się nie uda. Nie martw się o popularność wśród kandydatów lub plakatów w Internecie. Koszt złego zatrudnienia jest o wiele gorszy niż koszt opóźnienia do czasu dobrego zatrudnienia.

Why no at home tests?

Even if we ignore the possibility of cheating, and the reverse-filter which causes good and honest candidates to avoid companies with at-home coding tests, the value of at home coding tests is limited.

If it’s for a senior position , a senior developer with people skills will be able to tell within less than 10 minutes if the senior developer on the other end of the phone is any good, or is just making up stuff. Nie będziemy wiedzieć, jak dobry jest dokładnie, ale będziemy wiedzieć tyle, jeśli nie więcej, niż mówi nam każdy możliwy test kodowania w domu.

Jeśli chodzi o stanowisko niższe , nie oczekujemy wiele, jeśli chodzi o wiedzę techniczną. Szukamy entuzjazmu, chęci do nauki i talentu - żadnego z nich nie dostrzegamy w domowym teście kodowania. Jest zbyt wiele rzeczy, o których juniorzy mogą być nieświadomi. Jeśli ich zatrudnimy, i tak musimy ich przeszkolić.

Jak testować zamiast tego?

Jako filtr, daj im 10 minut na rozwiązanie wariacji FizzBuzz na miejscu podczas pierwszej rundy rozmów kwalifikacyjnych lub, jeśli jesteś zalany dobrymi CV i potrzebujesz innego filtra, zrób to przez Skype'a przed pierwszą prawdziwą rundą rozmów kwalifikacyjnych.

Po przejściu przez filtry, musisz wiedzieć więcej o możliwościach kodowania Twoich kandydatów. Polecam spędzić 30 minut do maksymalnie 2 godzin na programowaniu parami lub recenzjach kodu - prawdziwej pracy, a nie na ćwiczeniach. Powtórz 1-2 razy z różnymi partnerami. Zaletą programowania w parach i recenzji kodu jest to, że programista ma już wystarczającą wiedzę, aby się do tego przyczynić.

Nie martw się, że test jest inny dla każdego zatrudnionego - celem procesu zatrudniania nie jest znalezienie osoby, która uzyska najlepsze wyniki w kilku mierzalnych i powtarzalnych testach. Celem jest wynajęcie jednej osoby, która dobrze wykona pracę.

Oto kolejna kwestia, której nie widzę ujęta w istniejących odpowiedziach (które, jak sądzę, dobrze poruszają ten temat w ogóle). Przyjrzałbym się uważnie i poważnie temu, jak długo zajmuje to ludziom dokończenie. Odbyłem cztery rozmowy kwalifikacyjne, podczas których miałem do zrealizowania ćwiczenie z programowania, z których każda była robiona inaczej (i każda miała swoje wady i zalety). Dwie z tych czterech rozmów (numer 3 i 4 poniżej) trwały znacznie dłużej niż powinny, a obie zakończyły się rezygnacją z nich z powodu trudnego poziomu. Opisałem je poniżej i uszeregowałem je od najlepszych do najgorszych z mojej perspektywy.

1. Podczas wywiadu technicznego usiedli mnie przy komputerze, który miał osłabioną wersję ich bazy kodowej i kazali mi rozwiązać trzy stosunkowo krótkie problemy z tym związane (znaleźć i naprawić błąd, który celowo dodali, dodać nowe pole do tabeli informacyjnej, itp.) ). Dali mi dokładnie godzinę na zrobienie tego, a po godzinie przeanalizowali moje rozwiązanie i sposób podejścia do problemów. Dało im to lepszy wgląd we mnie jako programiście, przy jednoczesnym respektowaniu mojego czasu, poprzez skrócenie go do minimum i na temat.
2. Podczas wywiadu technicznego kazali mi pracować nad problemem, który napotkali w trakcie opracowywania na tablicy, a jednocześnie mogli odrywać od nich pomysły. Była to najkrótsza opcja, a jednocześnie dająca im szansę zobaczenia, jak radzę sobie z problemami i jak bardzo mogę wykonać niezbędną pracę.
3. Podczas rozmowy technicznej (na stanowisko młodszego Rubina na Rails Web Development) zlecili mi zbudowanie od podstaw aplikacji internetowej, która będzie poruszać się po stronie internetowej, wypełniać wiele formularzy w trakcie ich prezentacji, usuwać dane z wynikowej strony i prezentować je użytkownikowi. Powiedzieli, że to powinno być szybkie ćwiczenie, i może to było dla programisty wyższego szczebla, ale mając tylko rok doświadczenia zawodowego w tym momencie, spędziłem cztery godziny próbując dostać to wszystko do pracy przed poddaniem się i wyjazdem do domu (wszyscy ankieterzy zostawili godziny przed moimi, bo to była popołudniowa rozmowa, powiedzieli, że powinienem po prostu zapisać gotowy program, kiedy skończyłem). Jest to niedorzeczne zadanie na wymienione stanowisko, nie dało im pojęcia o moich zdolnościach kodowania i wydawało mi się, że po prostu starają się uzyskać darmową pracę z umowy. Nie trzeba dodawać, że nawet nie chciałem tej pracy do czasu, gdy opuściłem ten dzień.
4. Zanim nawet odbyłem rozmowę techniczną, dali mi zadanie stworzenia aplikacji internetowej, która wykorzystywałaby API używane przez ich firmę do “zrobienia czegoś interesującego”. To było dokładnie tak szerokie, jak to brzmi. Wymagało to ode mnie następujących czynności zanim nawet spróbuję stworzyć aplikację: stworzyć konto programisty dla API, pobrać zestaw programistyczny API, stworzyć publicznie dostępną aplikację internetową (z innym kontem programistycznym), nauczyć się API i stworzyć repozytorium danych, do którego dostęp będzie możliwy za pomocą API. To oczywiście trwało wiele godzin tylko po to, aby rozpocząć pracę, a wkrótce po rozpoczęciu pracy w samej aplikacji internetowej, dostałem inną rozmowę kwalifikacyjną, a wkrótce potem ofertę pracy, więc przerwałem pracę nad zadaniem. To jest szalona rzecz, aby mieć w ramach procesu rozmowy kwalifikacyjnej, ponieważ kto chce włożyć cały ten czas i wysiłek w rozwój programu tylko po to, aby mieć małe szanse, aby przejść dalej w procesie rozmowy kwalifikacyjnej?

Tak więc, aby odpowiedzieć na pytanie bardziej bezpośrednio, należy mieć ćwiczenie programowania? Tak, ale upewnij się, że jest ono dopasowane tak, aby sprawdzić, na czym naprawdę Ci zależy, i nie wymaga tony obcej pracy dla rozmówcy. Czy chcesz wiedzieć o ich algorytmicznym myśleniu? Dajcie im problem z algorytmem. Chcesz wiedzieć o ich stylu kodowania? Dajcie im problem z kodowaniem. Chcesz dowiedzieć się o ich procesie rozwoju? Porozmawiaj z nimi na temat ich procesu rozwoju, gdy rozwiązują problem.

Zacznę od:

• Dostałem do wykonania w domu testy, które trwały od 15 minut do 10 godzin.
• Dostałem do wykonania testy online.
• Dostałem do wykonania testy do FizzBuzza i inne modne testy internetowe na białych tablicach.
• Zostałem zapytany o pokrywy studzienek kwadratowych i okrągłych.

Krótko mówiąc, miałem do czynienia z różnymi sposobami obsługi wywiadów przez deweloperów. Szczerze mówiąc - poważnie wątpię, żeby większość osób przeprowadzających ze mną rozmowy kwalifikacyjne zrozumiała nawet, jakie są potencjalne wyniki każdego z tych testów i ostatecznie po prostu zatrudniła ludzi, czy ich “lubią”, czy też nie.

Zanim w ogóle wystawisz ofertę pracy, powinieneś usiąść i przejść dokładnie przez to, co próbujesz zatrudnić, a “deweloper” nie jest odpowiedzią, przynajmniej nie jest właściwą. Dobrą odpowiedzią na to byłoby coś w rodzaju “eksperta od domeny hipotecznej”.

Znalezienie kogoś, kto może napisać trochę kodu lub wyszukać w google, jak zastosować dany wzór jest banalne w porównaniu ze znalezieniem kogoś, kto był w branży, w której jesteś i może wykorzystać tę wiedzę. Innymi słowy, gdybym zatrudniał się w firmie zajmującej się dokumentacją hipoteczną, wziąłbym kogoś, kto mógłby mówić o różnicy między 15-letnim kredytem stałym i ARM, a kimś, kto mógłby napisać algorytm sortowania bąbelków w 2 minuty. Powodem jest to, że “normalni” biznesmeni robią wszelkiego rodzaju dziwne wymagania i eksperci domeny mogą łatwiej dotrzeć do serca tego, co potrzebne, podczas gdy ktoś, kto nic nie wie, chętnie doda rzeczy, które są bezużyteczne lub sprawiają, że aplikacja jest naprawdę zła.

Wracając do pytań, tylko zadawać go / no go pytania.

Czy jest krytyczne, że osoba może powiedzieć różnicę między metodą wirtualną i abstrakcyjną? Może być, zazwyczaj nie jest. Założę się, że spora część programistów ledwo wie, kiedy używać tych słów kluczowych, ale to nie są twoje super gwiazdy, to ranga i plik, który używa nie może kodować bez projektantów wizualnych.

Czy to krytyczne, aby dostrzec, gdy zapytanie jest otwarte do zastrzyku sql? Dla pozycji Sr - absolutnie; dla pozycji Jr. nie. Jest to coś, co można łatwo wytrenować i obsługiwać za pomocą przeglądu kodu. Stąd powód, dla którego chcesz, aby sr. znał to w środku i na zewnątrz - aby mógł trenować juniorów.

Czy krytyczne jest, aby znał dokładną wartość maksymalną typu danych Int32? Normalnie nie - ten poziom trywialnej wiedzy jest tym, do czego służy google, ale być może Twoje wymagania dotyczą kodowania na urządzeniach z ograniczeniem pamięci - w tym przypadku: absolutnie.

Przeprowadzam wywiad i zatrudniam programistów. Nie wysyłam testów do domu - zbyt łatwo jest mieć pomoc przyjaciela. Nie korzystam z serwisów testowych online - biorąc pod uwagę to, jak punktacja musi być zautomatyzowana, jest to trywialne dla gry. Nie proszę kandydatów o wypisanie odpowiedzi na fizzbuzz - prawie każdy widział ten test i powinien znać odpowiedź na pamięć; wszyscy inni weszli na pole w ostatnim roku i są junior’s. Nie zadaję też błahych pytań - umiejętność recytowania odpowiedzi oznacza zazwyczaj, że już wcześniej słyszałeś to pytanie.

Co robię, żeby przeprowadzić wywiad z ludźmi:

• proszę ich o opisanie wcześniejszego lub dwóch projektów. W tym momencie zależy mi tylko na tym, aby zapewnić im komfort i zachęcić ich do rozmowy. Jeśli nie rozumiem, co mówią, nie mogę z nimi pracować.

• Zadaję im kilka konkretnych pytań dotyczących technologii, której potrzebuję. Jeśli jest to serwer SQL, zapytam o aktualizację na dołączeniu. Jeśli jest to HTML, przekażę im 10 liniowy plik html z kilkoma klasami css i zapytam o wyjście. Są to trywialne pytania do ludzi z doświadczeniem w tych dziedzinach i szybko wyplenienie pretendentów.

• Jeśli szukam Sr. dev to zadam pytania o wiedzę domenową. Nie chodzi tu o skrajne sprawy, ale raczej o podstawowe zasady. Jeśli potrzebuję, abyś poprowadził projekt z zakresu księgowości, to lepiej poznaj podstawowe zasady księgowości.

• Jeśli szukam seniora deva to zapytam o projekty domowe. wszystko co chcę wiedzieć to rodzaj stosowanej technologii. To powinno cię zorientować w tym, co naprawdę chcą robić. Innymi słowy deweloper C# prawdopodobnie nie będzie robił domowych projektów w php. Szczerze mówiąc, nie oczekuję od jr dev zbyt wiele, poza tym, że będzie można go trenować. Jeśli oni aktywnie pracują nad projektem zwierzęcym to mogę ich szkolić. Jeśli są tym typem, który potrzebuje ludzi, aby powiedzieć im, co mają robić, są o wiele większe firmy, w których ci faceci mogą pracować.

Nie wymyślam tych pytań na bieżąco, potencjalne odpowiedzi są rozważane z wyprzedzeniem i pasują do wzoru go/no go. Jeśli pytanie nie pasuje do tego, to nie jest istotne. Pytam też każdego kandydata o te same pytania, chyba że jestem w 100% przekonany, że ich nie zatrudnię, w którym to momencie przerwę rozmowę kwalifikacyjną.

Jeśli z jakiegoś powodu nadal nalegasz na wysłanie do domu testu - upewnij się, że umiejętności wymagane do pomyślnego ukończenia tego testu W rozsądnym czasie są to umiejętności, na których Ci zależy.

Miałem jedną firmę, która dała mi test do domu, który wiązał się z napisaniem niestandardowego kryptograficznego dostawcy usług. Ukończyłem ten test, ponieważ był on nieco interesujący; zatrudnili mnie. W żadnym momencie nie robiłem niczego, co poza dodaniem kilku numerów, byłoby zdalnie związane z bezpieczeństwem, kryptografią, a nawet matematyką. Zastanawiam się, ile osób odjechało z tym testem?

I used to be a firm faithver in coding tests and whiteboard coding, but I’ve started to realize that they’re pretty much useless, because

What are you testing, anyway?

A whiteboard test, or short programming test gives you some insight into the individual, but really not that much. Chyba, że planujesz, że ktoś spędzi czas pisząc kod na tablicy lub w stylu FizzBuzza.

What do you want?

You want someone who is:

• passionate
• willing to learn
• able to solve problems*
• resonably technical
• going to help your team improve

*Uwaga, większość programistów rozwiązuje swoje problemy wiedząc jakich terminów szukać w Google.

ostatnia rzecz, którą chcesz zatrudnić to ktoś, kto nie pasuje do Twojego zespołu, bo go przeciągną w dół.

How Can You Test For These?

• Zapytaj ich o projekt, który im się podobał. Jeśli nie chcą o tym mówić, spróbuj wyrazić delikatne niedowierzanie, np. “Nie możesz zrobić X, prawda?” Jeśli jest to coś, co jest ich pasją, poprawią cię. To również pomoże Ci dowiedzieć się, czy są techniczni, czy nie.
• Zapytaj ich o rzeczy, których ostatnio się nauczyli. Albo o to, czego nauczyli się z projektu, nad którym pracowali.
• Zapytaj ich o to, jaki był ich ostatni raz (lub czas), kiedy brakowało im jakiejś wiedzy. W jaki sposób zdobyli potrzebne im informacje? Czy poszli do kolegi z zespołu? Czy szukali w Internecie?
• Zapytaj ich, czy jest coś, co chcieliby zobaczyć w swoim obecnym/ostatnim zespole. Czy potrzebowali lepszego przekazywania wiadomości? Więcej recenzji kodu? Więcej testów? Więcej automatyzacji?
• Zapytaj ich, jaka technologia ich ekscytuje i dlaczego.

Jeśli masz kogoś, kto jest kompetentny technicznie w tej rozmowie, to najłatwiej będzie powiedzieć, czy ta osoba będzie najgorsza na świecie. Przykład: przyszedł do nas dzieciak i przeprowadził wywiad - powiedział, że w skali 1-10, jego umiejętności w zakresie Javy były jak 7-8. Chyba nawet nie wiedział, że Java została skompilowana do pliku w słoiku, który później został skompilowany do języka maszynowego przez JVM. Ja bym się ocenił może jako 2 lub 3 i I to wiem.

Nasz CTO zadał mu to samo pytanie w wywiadzie poprzedniego dnia, a nasz CTO zadzwonił do niego i wyjaśnił, że nie ma mowy, żeby był 7-8.

Nasz CTO zapytał go również o jego ulubiony projekt, który miał związek z ręcznymi skanerami. Nie potrafił jednak wytłumaczyć nic na temat ich działania, ani tego, że wykorzystywali sondaże, aby zapobiec czekaniu na autobusy. Nie potrafił wytłumaczyć ani jednej technicznej rzeczy.

Ten facet nie został zatrudniony.

Dowiedz się, jakich atrybutów szukasz, a następnie wymyśl, jak przetestować dla those

Ale ja really need to see how she codes!

Okay, to dobrze - ale jeśli nie będzie kodować w silosie, najlepszą rzeczą do zrobienia będzie zatrudnienie jej jako wykonawcy dla małego, dobrze zdefiniowanego projektu. Może dodasz możliwość ściągnięcia niektórych plików z FTP, a następnie zrzucenia ich do swojej bazy danych. Coś prostego, co nie wymaga dużej/żadnej wiedzy domenowej.

Zleć swoim kandydatom pracę z istniejącym pracownikiem lub dwoma, i zapłać im za ich czas. Będziesz mógł zobaczyć dokładnie, jak pracują i jak dobrze pracują z zespołem. Czy dobrze się komunikują? Czy łatwo się frustrują? Czy są wytrwali?

Istnieją are rzeczy, które możesz zrobić, aby zatrudnić lepszych pracowników… ale konkurs programistyczny prawdopodobnie nie jest jednym z nich.

Z punktu widzenia osoby poszukującej pracy, zazwyczaj unikam miejsc, których zakodowanie zajmuje ponad godzinę. Raz byłem w tym miejscu, które wymagało prawie 3-dniowego projektu kodowania java. Zrobiłem to wszystko i facet był nawet pod wrażeniem, ale powiedzieli mi, że zatrudnili kogoś innego po drugim etapie rozmowy kwalifikacyjnej. Więc po tym, jeśli przyjdę do firmy, zignoruję/przejdę każdy projekt, który wymaga więcej niż kilka godzin do ukończenia. Mój czas jest tak samo cenny jak ich i raczej nie marnuję go na rzeczy, które nigdzie mnie nie zaprowadzą.

Z tym powiedziane, jeśli twoje kodowanie jest zbyt długie, może ludzie nie są skłonni poświęcać czasu. Starałbym się skrócić go tak, aby trwał najwyżej godzinę, ale jednocześnie wykazał zrozumienie dla kodowania i może wyznaczyłbym termin, np. “Proszę wypełnić do COB jutro” czy coś. Nadal mogą “skopiować i wkleić” coś w sieci, ale utrudniają to raczej bycie konkretnym niż czytanie online.

Jak zauważyli inni, niektórzy programiści mogą być odkładani na 1-2 godziny programowania, aby ubiegać się o pracę. To, co może zadziałać lepiej, to sesja białej tablicy, podczas której kandydat rozwiązuje problem na białej tablicy podczas rozmowy kwalifikacyjnej. Daje to możliwość odbycia osobistej rozmowy kwalifikacyjnej przy jednoczesnym upewnieniu się, że mają oni techniczne kotlety.

Problemy te nie powinny być niezwykle trudne, lub przeznaczone do potknięcia się dewelopera. Klasycznym przykładem jest FizzBuzz . Pozwala to zobaczyć, jak oni myślą, a także wiedzieć, że mogą przynajmniej programować i nie muszą google'ować jak zrobić pętlę.

Moim zdaniem, problem, jaki tu macie, niekoniecznie polega na teście programowania. Najpierw masz telefoniczną rozmowę techniczną, a następnie pracę z testu w domu przed rozmową twarzą w twarz. Wygląda na to, że trzymasz swoich kandydatów na dystans i zostawiasz ich na ostatnią chwilę przed spotkaniem z nimi. W którym momencie oczekujesz, że kandydaci zdecydują, że chcą pracować dla Ciebie ?

Zakładam, że Twoje ogłoszenie rekrutacyjne jest podobne do większości i dlatego skupia się na lokalizacji, wynagrodzeniu i liście (życzeń) umiejętności. Kandydaci tak naprawdę nie wiedzą nad czym pracowaliby, nad czymkolwiek o środowisku lub ludziach, z którymi musieliby współpracować. Nie sprzedałeś pracy do nich jeszcze tutaj jesteś prosząc ich, aby udowodnić swoje możliwości techniczne dwa razy, zanim dostaniesz zadać jedno pytanie na temat pracy.

Proponuję spróbować zmienić format technicznej rozmowy telefonicznej, aby być 30-45 minut czat o pracy, w tym wiele okazji do pytań od kandydatów, a następnie 15 minut pytań technicznych jako ekranu, więc nadal masz szansę wybrać lepszych kandydatów bez uczynienia go zbyt uciążliwe.

Rozważałbym również przeniesienie wyzwanie programowania do wykonania na miejscu przed rozmowami kwalifikacyjnymi. Wydawałoby się to bardziej osiągalne dla kandydatów, dałoby im motywację do pozostania na bieżąco z procesem, a Ty uzyskałbyś korzyść z obserwowania prawdziwego czasu spędzonego nad wyzwaniem (myślę, że możesz być zaskoczony).

Czy chcesz zatrudnić programistów którzy nie potrafią programować?

Zaryzykuję, że ty nie.

Zatrudnienie programistów, którzy nie potrafią rozwiązywać problemów i pisać kodu to dobry sposób na zrujnowanie firmy technologicznej. I nie będziesz skuteczny w eliminowaniu programistów, którzy nie potrafią programować (a jest ich tam _wielu), jeśli twój proces zatrudniania nie obejmuje jakiegoś testu programistycznego.

Czy jesteś skłonny obniżyć swoje standardy, ponieważ wszyscy starają się zatrudniać programistów?

Może i jesteś, ale nie sądzę, że powinieneś być. Jak zauważono w komentarzach i odpowiedziach, są na zewnątrz kandydaci, którzy nie będą przeszkadzać w robieniu ćwiczeń programistycznych w ramach rozmowy kwalifikacyjnej, ponieważ po prostu nie muszą tego robić, aby dostać pracę.

Ale czy to naprawdę są ludzie, których i tak chcesz zatrudnić? Ci, którzy podążają ścieżką najmniejszego oporu, robią to, co jest dla nich najkorzystniejsze w krótkiej perspektywie czasowej i naprawdę nie dbają wystarczająco o Twoją firmę, aby wykonać proste ćwiczenia programistyczne? Nie wydają się być to cechy pozytywne i nie dają dużej pewności siebie, jeśli chodzi o możliwość długoterminowego utrzymania tych kandydatów (co jest również ważne dla firmy technologicznej, ponieważ krzywe uczenia się są zazwyczaj strome, a koszt zastąpienia obecnych pracowników jest bardzo wysoki).

Więc niech te inne firmy mają programistów, którzy nie mogą być nawet kłopotliwe. I tak nie chcesz ich zatrudniać. W przeciwieństwie do nich, masz plan. Taki, który nie opiera się na błędzie “programista to programista”. Twój plan powinien koncentrować się na jakości i zrównoważonym rozwoju, a nie na cielesności.

Czy odstraszanie kandydatów jest problemem?

Generalnie nie, tak długo jak długo są przestraszeni z dobrego powodu. Nie chcesz zatrudniać ludzi, którzy nie są w stanie się podrapać. A niektórzy z tych, którzy mówią, że “nie mogą się przejmować” z powodu dużego zapotrzebowania, mogą użyć tego jako wymówki, aby ukryć sytuację, w której “nie są tak dobrzy w programowaniu, więc potrzebują całego tygodnia, aby wykonać jednogodzinne ćwiczenia”.

Dobrze jest odstraszyć tych kandydatów. Chcesz zatrudnić zdolnych, zmotywowanych kandydatów. Tak długo jak nie odstraszasz tych kandydatów, jesteś dobry.

Każdy kandydat, którego nie odstraszysz jest tym, którego musisz spróbować i ocenić. A to może być trudne do zrobienia, jeśli nie dajesz swoim kandydatom technicznym żadnych ćwiczeń technicznych do wykorzystania przy ocenie.

Jak mogę ulepszyć nasz proces zatrudniania?

Sprawdź zawartość swoich ćwiczeń z programowania. Czy jest to rozsądne i odpowiednie w kontekście rozmowy kwalifikacyjnej?

Nie chcesz, aby coś, co zajmie Ci kilka dni (lub nawet godzin), zostało ukończone. To, czego chcesz, to coś prostego do wyplenienia ludzi, którzy po prostu nie potrafią programować, najlepiej z wystarczającą ilością miejsca na niuanse, które ludzie, którzy potrafią programować really well, potrafią się odróżnić. Pamiętaj o tym, co starasz się osiągnąć (odchwaszczyć niewykwalifikowanych i niepoważnych kandydatów), i upewnij się, że twoje treści są dostosowane do tego celu. Nie przesadzaj.

Jeśli masz już jakiś personel techniczny, możesz go wykorzystać do sprawdzenia (i/lub pomocy przy projektowaniu) swojego ćwiczenia.

I zastanów się również nad tym, jak administrujesz ćwiczeniem. Jeśli po prostu dasz im jakąś dokumentację i powiesz “tutaj, zrób to w ciągu następnego tygodnia i wyślij mi to e-mailem”, prawdopodobnie będzie to tylko minimalnie skuteczne.

Lepiej będzie, jeśli będziesz mógł przeprowadzić ćwiczenie przez portal internetowy, na którym kandydaci będą mogli sprawdzić i rozpocząć ćwiczenie, a gdy już rozpoczną, zegar zacznie odliczać od 1 godziny. Następnie albo zgłaszają coś w ciągu tej godziny, albo nie. To jest mniej otwarte, lepiej zachować ostrość kandydata i zapewnić jasny termin/okólnik czasowy oba tak, że 1) nie jesteś w stanie czekać cały tydzień na wynik, który nigdy nie nadejdzie, i 2) niewykwalifikowani kandydaci nie wyrzucają tydzień swojego czasu próbując ukończyć twoje ćwiczenie programowania. Dostają 1 godzinę, albo rozwiązują problem, albo nie, a wynik znasz od razu.

I jeszcze lepiej byłoby sprowadzić ich na rozmowę kwalifikacyjną na miejscu. Przedstaw je członkowi swojego zespołu programistycznego. Zamknij je w pokoju razem z miejscem pracy. Niech Twój programista zacznie od kilku ogólnych/miękkich pytań do wywiadu, a następnie może sparować program z kandydatem, aby rozwiązać ćwiczenie programowania. To powie ci nie tylko czy kandydat potrafi kodować, ale także jak dobrze pracuje z twoim zespołem. Twój programista powinien być również w stanie uzyskać wiele dodatkowych informacji, których nie uzyskasz patrząc na kod napisany przez kandydata, a następnie wysłany do Ciebie e-mailem.

Dolinia

Nie, nie chcesz pozbyć się swojego ćwiczenia programistycznego. Ale może zechcesz przejrzeć go pod kątem odpowiedniej treści, upewnić się, że nie zajmie Ci to zbyt wiele czasu, a także przyjrzeć się, jak dopasowujesz go do swojego nadrzędnego procesu rozmowy kwalifikacyjnej.

Ćwiczenia w domu na wynos prawdopodobnie nie są najlepszym podejściem. Ale rozwiązanie tego problemu nie polega na tym, aby całkowicie zrezygnować z tego ćwiczenia. Nie, chyba że nie masz nic przeciwko zatrudnianiu gównianych programistów.

Lepiej odstraszyć wielu złych kandydatów i garstkę dobrych, niż otworzyć bramę i zatrudnić kilku złych.

Jedna rzecz, o której chyba nikt nie wspomniał; nawet jeśli test nie jest Twoim problemem, powinieneś szukać innych sposobów na przyciągnięcie talentów.

Jeśli polujesz na dobrych ludzi na podstawie ich dotychczas opublikowanych prac, nie musisz przeprowadzać testu na nich.

Jeśli tylko wysyłasz ludzi za pośrednictwem rekruterów i filtrowania, jesteś narażony na to, że Twoje potrzeby i potrzeby rekruterów nie współgrają idealnie. Chcą umieścić kogoś z Tobą. Chcesz mieć inżyniera najwyższego szczebla. Jeśli mogą znaleźć inżyniera najwyższego poziomu, który jest niesamowity, bo wrócisz do nich, ale jeśli nie mogą (a inżynierowie najwyższego poziomu mają tendencję do rzeczy dzieje się, że pozostawia mało czasu na rozmowę kwalifikacyjną), zadowolą się po prostu umieścić umiarkowany inżynier z ładnym garniturze. Strata dla nich jest trochę długoterminowa, ale to nieistotne w porównaniu z brakiem celów. Jeśli w twoim przypadku nie jest to prawdą, trzymaj się tego rekrutera i nigdy go nie puszczaj. Rekruterzy, którzy przedkładają długoterminową relację nad cele, to cenne diamenty w oceanie pyłu węglowego.

To, co chcesz robić, to znaleźć naprawdę interesujących kandydatów. Zapoluj przez StackOverflow i GitHub na najlepszych inżynierów (słyszę, że StackOverflow ma w tym narzędzie ), sprawdź, czy nie ma ciekawych technicznie firm, które produkują dobre oprogramowanie, ale które spieprzyły swoje finanse lub monetyzację, i po prostu zwolnij 10 inżynierów najwyższego szczebla. Spędzaj czas pracując na uniwersytetach pomagając przy projektach na ostatnim roku. Zidentyfikuj dobrych potencjalnych kandydatów i zaprzyjaźnij się z nimi, najlepiej osobiście, ewentualnie zdalnie; nawet jeśli mają oferty, dobrzy inżynierowie spędzają czas z dobrymi inżynierami. Mogą Ci również powiedzieć, jak się czujesz w procesie rekrutacji.

Czy to brzmi jak dużo pracy? To powinno… Jednym z powodów, dla których zatrudnianie wydaje się być tak “trudne” jest to, że starasz się robić to tak efektywnie jak to tylko możliwe. Im więcej czasu, mocy umysłowej i środków przeznaczasz na to, tym jest to łatwiejsze. To, czy te zasoby byłyby lepiej wydane na wysyłkę produktu, jest odwieczną kwestią zarządzania. Ale jeśli spędzasz dużo czasu na “gównianej filtracji programistów”, to jest to palenie pieniędzy. Przynajmniej opisane powyżej kroki mają nieodłączną wartość poza procesem zatrudniania.

(*): Hell, hire them.

Nie lubię testów take-home w ramach rozmów kwalifikacyjnych, z wielu powodów, o których już wspominano - wydłuża proces rekrutacji, dewaluuje czas kandydata, może i tak nie oddzwonić, itd.

Mój główny problem polega na tym, że nierealistyczne jest to, jak naprawdę działa zespół i sprawia, że proces rozmowy kwalifikacyjnej jest jednostronny. Aplikant chce, aby to miejsce dobrze do niego pasowało, w tym kultura, sposób podejścia zespołu i rozwiązywania problemów. Przede wszystkim szukasz również dopasowania, w tym, jak pracują i czy mają odpowiedni zestaw umiejętności. Egzamin zdawany w domu nie daje kandydatowi możliwości oceny miękkich cech miejsca pracy, a pracodawcy nie są w stanie dowiedzieć się, w jaki sposób kandydat podszedł do problemu.

Lepszym rozwiązaniem może być danie kandydatowi bardziej otwartego problemu, który może być rozwiązany w dowolny kreatywny sposób. Możesz nawet ograniczyć go do języka X. Zamiast wysyłać go pocztą elektroniczną, zaproś go z powrotem do przedstawienia go sobie i kierownictwu wyższego szczebla. To daje im autonomię i zachętę do zrobienia dobrze, ponieważ obiecuje kolejną rozmowę kwalifikacyjną i pokazuje, że zależy Ci na tym, aby wiedzieć, co myślą.

Jeśli musisz użyć testu, aby sprawdzić, którzy kandydaci robią to na rozmowę kwalifikacyjną z wyższą kadrą kierowniczą, włączyłbym ten test do rozmowy kwalifikacyjnej, abyście mogli wspólnie omówić ich proces myślowy.

Myślę, że sformułowałeś swoje pytanie trochę źle, ale sposób, w jaki je sformułowałeś, odzwierciedla powszechne błędne przekonanie o zatrudnianiu programistów. Czy kandydaci są “wystraszeni” przez zadanie programistyczne, czy też filtrują Twoją firmę z własnego punktu widzenia z powodu zadania?

Anegdota, która pokazuje mój punkt widzenia: podczas polowania na pracę nie tak dawno temu, widziałem stanowisko dla firmy, które wydawało mi się przeciętne. Sposób w jaki opisali swój proces programowania sprawił, że brzmiał on całkiem nieźle, ale było bardzo mało szczegółów, więc byłem sceptyczny. Może to było dobre miejsce do pracy, a może nie. Ale pomyślałem, że zobaczę, jak dostać się do ekranu telefonu, więc mogłem odgadnąć szczegóły i sprawdzić, czy są tak dobre, jak się wydawało.

Kliknąłem na ogłoszenie o pracy i natychmiast zostałem poproszony o napisanie listu motywacyjnego. Ugh. Myślę, że każdy kandydat nienawidzi listów motywacyjnych. Nie znałam tej firmy ani nie używałam ich produktów, więc co mogłam o nich powiedzieć? Wyszukiwałam je, czytałam ich strony internetowe i oferty produktów, zastanawiałam się, gdzie najprawdopodobniej zmieściłabym się w ich orggramie, jeśli zostałabym zatrudniona, i sama wymyśliłam kilka paragrafów “sprzedając”.

Następnie udostępniłam moje CV i dostęp do mojego LinkedIn - ale zaraz potem poprosiła mnie o wypełnienie moich istotnych doświadczeń zawodowych datami i opisami. Informacje te znajdują się zarówno w moim LinkedIn, jak i w moim życiorysie, absurdem było podanie tych samych informacji 3 razy. Zamknąłem zakładkę przeglądarki. 5 minut później aplikowałem do innej firmy, która oferowała kilka naprawdę fajnych korzyści, których pierwsza nie oferowała. Mogłem aplikować do innej firmy z lepszymi korzyściami szybciej niż mogłem skakać przez obręcze, które pierwsza firma chciała ode mnie.

Musisz być pewien, że Twoi kandydaci są inwestowani w swoją firmę w szczególności przed zaprezentowaniem im jakichkolwiek obręczy do skoku, w przeciwnym razie nie będą skakać. Czy robisz to?

Przykłady korzyści jakościowych, które często widzę w firmach technologicznych oferujących:

1. Praca zdalna.
2. Darmowe komputery/monitory jako bonus za podpisanie umowy.
3. Udział w szanowanych projektach open-source.
4. Zwrot kosztów profesjonalnych szkoleń i/lub konferencji.
5. Organizacja obiadów.
6. Elastyczne godziny pracy.
7. Możliwość pracy z nowymi lub nieznanymi technologiami.
8. “Kultura startupów” - czyli brak polityki/biurokracji.
9. Kapitał własny firmy.
10. Rozpoznanie nazwy: Twoja firma lub produkt jest dobrze znany. Kandydaci lubią wspominać, gdzie pracują i słyszeć, jak ludzie odpowiadają “Oh, schludnie! Podobają mi się ich produkty.”
11. Charytatywne lub rewolucyjne cele/wizja firmy. Ludzie lubią pisać kod, który czyni życie ludzi lepszym.
12. Ponadprzeciętna płaca. Pieniądze pokrywają wiele grzechów organizacyjnych.
13. Corocznie firma wycofuje się w chłodne miejsca.

Ta lista nie jest wyczerpująca, ale jeśli Twoja firma nie oferuje jednej lub więcej rzeczy, takich jak te z tej listy, to każda przeszkoda w procesie rekrutacji może wysłać kandydata szukającego takiego, który to zrobi.

Powiedzmy więc, że z jakiegokolwiek powodu nie oferujesz lub nie możesz zaoferować zachęt, takich jak powyższe, aby przekonać swoich kandydatów do spędzenia czasu na pisaniu kodu za darmo dla Ciebie. Więc co możesz zrobić? Mam dwie alternatywy, które większość kandydatów wolałaby od zadań programistycznych:

Alternatywa #1 - zapłacić im za godzinę pracy, aby wykonywali swoje zadania programistyczne tak, jakby byli wykonawcami. To zachęca ich do poważnego potraktowania tego zadania zarówno z powodów zawodowych jak i dlatego, że… otrzymują wynagrodzenie. To kosztuje Cię pieniądze, ale tak samo jak każda forma rekrutacji. Jeśli jesteś naprawdę dobry, możesz nawet znaleźć dla nich sposób, aby zdiagnozować i naprawić prawdziwy błąd w kodzie, w którym to przypadku dostajesz coś pożytecznego za swoje pieniądze.

Alternatywa #2 - Prawdopodobnie napisali już kod za darmo, który pokażą ci, jeśli tylko zapytasz. Większość programistów ma kod na stronach Github, Bitbucket, Q&A, takich jak Stack Overflow, lub może dostarczyć Ci jakiś kod, którego jeszcze nie opublikowali.

Po co kazać im pisać kod, który ich nie interesuje, skoro możesz pozwolić im dzielić się z Tobą projektem pasji? To na pewno mniej nudne niż przeczytanie po raz setny kolejnego rozwiązania tego samego ogólnego problemu. A ponieważ kod jest już napisany, oszczędza to zarówno Tobie jak i Twojemu kandydatowi czasu. Poza tym zobaczysz, jaki kod lubią pisać, co daje wgląd w ich osobowość i jak dobrze będą pasować do kultury Twojej firmy.

Jako bezpośrednia odpowiedź na odpowiedź Bobo (która jest odpowiedzią zaakceptowaną, ponieważ facet napisał ją i sam ją zaakceptował, co szczerze mówiąc uważam za nieco żałosne):

Pochodzisz z całkowicie błędnego założenia. Nie chcę _pracować dla ciebie. Skąd ten pomysł, że ktoś chce dla ciebie pracować? Jesteś tylko jedną z wielu firm oferujących pracę. Nie chcę dla ciebie pracować. Chcę ocenić twoją firmę, a jeśli wyjdziesz na prostą, to wtedy właśnie chcę dla ciebie pracować.

Jest tuzin firm, w których mogę pracować, jesteś po prostu gdzieś w kolejce. Najpierw sprawdzam jakie są firmy, wysyłam im moje CV, mogą je przeczytać i być pod odpowiednim wrażeniem lub nie, potem zazwyczaj prowadzę szybką rozmowę telefoniczną, gdzie pokazują mi, że mają ciekawą pracę, a ja pokazuję, że mam umiejętności, a każdy test z kodowaniem might przychodzi na sam koniec.

Twój test do domu stawia Cię na samym końcu kolejki. Żeby zrekompensować sobie to, musiałbyś postawić przedział płacowy, który jest o 10 tys. funtów wyższy od innych. Znalezienie pracy jest i tak czasochłonne; ktoś, kto zrobi to dziesięć razy bardziej czasochłonnie znajduje się na końcu listy. Jeśli mam wybór pomiędzy wysłaniem CV a przeprowadzeniem rozmowy telefonicznej z dziesięcioma firmami i odrobieniem pracy domowej dla Ciebie, zgadnij co zrobię.

Więc co się dzieje to znalezienie kandydatów, którzy chcą dla Ciebie pracować ponieważ nie dostaną pracy gdzie indziej.

Naprawdę uważam, że może to pomóc w ustaleniu, kto naprawdę zna języki wymienione w CV.

Jeśli to jest naprawdę twój cel, rozważałbym inne podejście. Jak wskazują inne odpowiedzi, TAK, zawsze powinieneś mieć pytanie kodowe, ale pytania kodowe rzadko wchodzą w szczegóły dotyczące języka. Niektóre pytania, które widziałem, są przydatne do testowania tego:

1. Porównaj i skontrastuj Java i C (lub dwa języki, które są istotne, znajdują się w życiorysie kandydata, itd.)
2. Jakie cechy, Twoim zdaniem, powinny zostać dodane do języka? (Albo jeszcze lepiej, co sądzisz o tej konkretnej proponowanej/odrzucanej zmianie języka?)

Inżynierowie, którzy widzieli już coś lub dwa, wiedzą jak odpowiedzieć na te pytania dość łatwo, i to w ciągu zaledwie kilku minut.

Jaki jest Twój problem biznesowy?

Pomijając wszystkie argumenty za lub przeciw poszczególnym testom, wszystko sprowadza się do kompromisu - więcej filtrów odstraszy dobrych kandydatów, mniej filtrów przepuści przez biednych kandydatów, których być może będziesz musiał wymienić wkrótce po zatrudnieniu.

Wszystko sprowadza się do przyjrzenia się sytuacji biznesowej zamiast ogólnych praktyk.

Czy obecnie masz problem, gdy brakuje Ci wykwalifikowanych kandydatów i nie jesteś w stanie zatrudnić ich tak szybko, jak potrzebujesz, aby osiągnąć swoje cele biznesowe? Musisz porzucić to początkowe zadanie związane z programowaniem.

Czy obecnie masz problem, w którym nie jesteś zadowolony z jakości swoich ostatnich zatrudnień? Następnie musisz wdrożyć więcej takich filtrów.

Czy masz _ oba te problemy, a oba są równie bolesne? Gratulacje, znalazłeś właściwą równowagę dla tego kompromisu.

IMHO ma prawie 0% szans, że świeżo upieczony absolwent szkoły wyższej będzie w stanie wykonać trudny kod programowania na poziomie podstawowym. Jeśli twój test z kodowaniem trwa tydzień, powinieneś wyraźnie zaznaczyć w swoim wymaganiu, że szukasz programistów z co najmniej 2+ letnim doświadczeniem, ponieważ uważam, że wiele doświadczenia powinno być wymagane do ukończenia pracy nad kodem, która wymaga jednego tygodnia. I myślę, że jeśli szukasz świeżo upieczonych absolwentów to zaprojektuj odpowiednio swój test i możesz znaleźć wiele pomysłów w Internecie lub możesz poprosić starszych programistów pracujących dla Ciebie o zaprojektowanie odpowiedniego testu dla świeżo upieczonych absolwentów.

Myślałem, że odpowiem na to pytanie, minął już rok od jego zamieszczenia, a my trzymamy się go.

ZNAJDANIA

Pozytywy podejścia

1) Weź do domu test chwastów zdemotywowanych kandydatów i zastąp ich kandydatami, którzy naprawdę chcą pracować dla Ciebie. Już samo to sprawia, że warto coś zrobić, ponieważ zmotywowani ludzie = produktywni pracownicy. Jeśli nie można im przeszkadzać w wykonaniu jednogodzinnego zadania, to wiele mówi o ich podejściu do zdobycia pracy.

2) Zgadzam się z innymi, że test zdawkowy nie powinien być dłuższy niż godzina - mój jest bardzo prosty. Mam następujące wyniki z dodania go do procesu rekrutacji -

a) Niektórzy kandydaci go nie kończą. Nie warto go zatrudniać.

b) Niektórzy kandydaci próbują, ale słabo go kończą. Nie warto zatrudniać.

c) Niektórzy kandydaci oszukują, w którym to momencie warto zadawać kolejne pytania dotyczące ich zadania. Zrobiliśmy to z niedawnym kandydatem, który wtedy nie zadał sobie trudu, by odpowiedzieć na nasz e-mail dotyczący zadania. Nie warto zatrudniać.

d) Niektórzy kandydaci po usłyszeniu zadania technicznego nagle wycofują swoją aplikację, gdzie wcześniej wykazywali duże zainteresowanie. Prawdopodobnie uniknęli pocisku.

e) Niektórzy kandydaci radzą sobie bardzo dobrze, komentują swój kod i w jednym lub dwóch przypadkach dostarczają dokumentację. Worth hiring.

Negatywy podejścia

1) Odrzucenie aplikacji od kandydatów odkładanych przez zadanie take home sprawia, że znalezienie kogoś odpowiedniego jest dłuższe. ALE po stronie flipów pozytywny dla firmy, ponieważ zmniejsza prawdopodobieństwo złego zatrudnienia, które jest niebezpieczne.

2) Nie zawsze można powiedzieć, czy ktoś oszukiwał, ale dlatego często jest to poparte technicznym wywiad telefoniczny.

Outcome of this approach

Jeden z naszych pracowników, których zatrudniłem przy użyciu tego podejścia okazało się być gwiazdą. Po ponad roku nadal pracuje dla nas. Jest niezawodny i utalentowany technicznie.

Nieznany układ myszki lub nieoczekiwany układ klawiatury (zwłaszcza Mac vs PC), lub różne IDE mogą drastycznie spowolnić wydajność bez różnicy w kompetencjach. Ponadto, kompletna aplikacja często wymaga dużej ilości kodu boilerplate'a, który deweloper może nie mieć wystarczająco dużo czasu na wpisanie lub nawet nie pamiętać. Uruchamianie nowej aplikacji całkowicie od zera jest właściwie bardzo rzadkim zadaniem; większość pracy koncentruje się na rozszerzaniu lub ulepszaniu istniejącego kodu.

Dlatego też sugeruję, aby podczas rozmowy kwalifikacyjnej podawać tylko bardzo krótkie i bardziej starannie przygotowane zadania. Najlepiej poprosić o napisanie funkcji, która musi wziąć pod uwagę dane parametry i zwrócić wyjaśniony wynik, a ja radziłbym zrobić to na papierze, unikając w ogóle komputera.

Wysłałbym ich na internetowy quiz, gdzie można odfiltrować ludzi, którzy nie mają pojęcia. Na początku mojej kariery headhunterzy powiedzieli mi, że “masz do czynienia z ludźmi, którzy przeczytali to pudełko i umieścili aplikację w swoim życiorysie”. Zakładam, że może się to jeszcze przydarzyć młodym i naiwnym, ale gdy już zdemolujesz się w kilku rozmowach kwalifikacyjnych, dowiesz się, że to zła rada…

Niedawno dostałem test do domu. Była to pełna aplikacja, która musiała się połączyć z serwerem gniazdek, który musiał symulować powolny przekaz. Klient miał dynamiczną aktualizację, mógł anulować kanał, pisać i czytać XML.

Tak jakby i tak chciałem nauczyć się obsługi gniazdek, ponieważ myślę o wykorzystaniu ich jako serwera pokerowego, który piszę.

Chciałem nauczyć się XMLreadera i XMLwritera.

Na początku myślałem, że o tym zapomnę. Ale potem zobaczyłem to jako szansę na udowodnienie tego, co mogę zrobić. Nie mam dyplomu CS, więc brakuje mi pewnych teoretycznych rzeczy. Zapytali, jakie są 3 filary OOP i chcieli powiedzieć, kogo to obchodzi.

Moim przesłaniem są ludzie, którzy chcą, aby ta praca zakończyła test.