Czy „White-Board-Coding” jest nieodpowiednie podczas wywiadów? [Zamknięte]

30

Jest to dość subiektywne pytanie, ale chciałbym usłyszeć opinie / opinie ankieterów / rozmówców na ten temat.

Nasz wywiad techniczny podzieliliśmy na 4 części. Napisz kod, odczytaj i przeanalizuj kod, sesję projektowania i kod na białej tablicy.

W końcowej części pytamy rozmówców o napisanie małego fragmentu kodu (4-5 wierszy) na tablicy i wyjaśnienie, kiedy go przechodzą. Powiem jasno, że celem nie jest złapanie ludzi. Nie szukamy idealnej składni. Do diabła może to być nawet pseudo-kod. ale chodzi o to, aby dać im bardzo prosty problem i sprawdzić, czy ich mózg może nam przekazać rozwiązanie. Przez proste problemy rozumiem „Odwróć ciąg”, „FizzBuzz” itp.

Pamiętaj, że zawsze najpierw prosimy o wyraźny język. Jesteśmy domem .NET C #. powiedzieliśmy tylko „pseudo-kod”, w którym ktoś wygasał / naprawdę zmagał się z kodem.

Moje pytanie brzmi: „Czy niewłaściwe / nierozsądne jest oczekiwanie od programisty napisania fragmentu kodu na tablicy podczas wywiadu?”

Eoin Campbell
źródło
13
Całkiem rozsądny IMHO (i zapobiegłby niektórym bardzo złym zatrudnieniu u mojego byłego pracodawcy, gdyby tylko został wdrożony).
Piskvor,
3
Z perspektywy ankietera jest to naprawdę przygnębiające. W jaki sposób ludzie, którzy twierdzą, że 5-letnie doświadczenie w programowaniu może nie mieć tych podstawowych umiejętności? i 90% nie. (czyli 90% po natychmiastowym usunięciu 70% CV i 70% wskaźnika niepowodzeń w wywiadzie telefonicznym)
Michael Shaw
18
We're not looking for perfect syntax.to uzasadnione, w rzeczywistości powiedziałbym, że polecam! Jest to nierozsądne , aby krytykować błędy składniowe na tablicy kodowania.
Qwerky, 11.11.11
16
nie oczekuj też idealnego pisma. Pisanie na tablicy to umiejętność, której większość ludzi nie ma, a większość programistów z mojego doświadczenia ma okropne pismo odręczne, delikatnie mówiąc, pisanie w pionie tylko to pogarsza.
jwenting 11.11.11
3
Odpowiedni tak. Skuteczne, nie. Jedyny słaby programista, którego osobiście zatrudniłem, znakomicie spisał się na tablicy.
pdr

Odpowiedzi:

47

Moim zdaniem jest to bardzo właściwe. Jeśli chcesz, aby praca polegała na wykonaniu określonej umiejętności, to całkowicie słuszne jest, abyś zademonstrował tę umiejętność podczas rozmowy kwalifikacyjnej.

Wpływ tej techniki na proces rekrutacji jest bardzo zauważalny. 90% kandydatów nie spełnia tego zadania. ale rekrutowani programiści są dobrzy, a programiści będą szanowani w firmie.

Jeśli jako kandydat w obliczu tej techniki, przede wszystkim się zrelaksuj. Chodzi o ocenę ciebie jako programisty i twoich procesów myślowych. Nie chodzi o twoją idealną składnię. Jeśli popełnisz błąd składniowy, mógłbym odegrać rolę kompilatora i powiedzieć ci, że kod nie kompiluje się w określonym wierszu, i dać ci komunikat o błędzie i zobaczyć, jak zareagujesz. Podobnie jeśli dodasz; na pętlę lub instrukcję if, która by się skompilowała, zagrałbym w debuggerze i przeprowadziłbym cię przez jeden krok przez kod. Ponownie, nie chodzi o błąd, chodzi o to, jak poradzisz sobie z błędem i czy twoje procesy myślowe są dobre.

Michael Shaw
źródło
1
dzięki za opinie ptolemy. bardzo mile widziane. odpowiadasz dokładnie opisuję to, czego szukam, a także sposób, w jaki podchodzę do pomocy kandydatowi w rozwiązywaniu problemów. Ale jak już wskazałeś, jestem oszołomiony liczbą osób ubiegających się o role w wieku 5+ lat, które nie mogą tego zrobić.
Eoin Campbell
1
Największym niebezpieczeństwem jest to, że pojawia się frustracja, a ty oferujesz pracę komuś, kto nie wykonał zadania programistycznego, ale dobrze poradził sobie z innymi aspektami rozmowy, jak test techniczny. W rzeczywistości ci kandydaci przeczytali książkę i mają dobrą pamięć. Czy zachęcasz ludzi do czytania książek? lub pisać programy?
Michael Shaw
@EoinCampbell, jeśli umiejętności komunikacyjne są dla Ciebie ważne, jest to całkowicie właściwe.
1
więc jako kandydat popełniasz błąd, a następnie nieco później (nie od razu) zwracam uwagę na ten błąd. W tym momencie poczujesz presję. To jest kluczowa część wywiadu, widząc, jak reagujesz? Czy poradzisz sobie z presją literówki podczas wywiadu? Jeśli stopisz się pod tą presją, co zamierzasz zrobić, gdy my jako zespół jesteśmy pod presją dostarczania oprogramowania w wyznaczonym terminie?
Michael Shaw
1
Użyłem kodowania tablicy, pozytywne jest to, że znajduje naprawdę dobrych młodszych programistów. Minusem kodowania tablicy jest wysoki wskaźnik awaryjności, ale ci ludzie nie są zbyt dobrzy na początek. Poprosiłem ludzi o napisanie na tablicy zaledwie jednego wiersza kodu i nadal miałem bardzo wysokie wskaźniki awarii. Z drugiej strony zadawano mi pytania na tablicy jako rozmówcy i zawsze uważałem, że pytania są uzasadnione. Zdecydowanie wolę kodowanie tablicy niż wyświetlanie ulubionych algorytmów dla konkretnych problemów.
Michael Shopsin
15

Moje pytanie brzmi: „Czy niewłaściwe / nierozsądne jest oczekiwanie od programisty napisania fragmentu kodu na tablicy podczas wywiadu?”

To bardzo rozsądne. Alternatywą dla tablicy może być laptop i rzutnik, ponieważ programiści są bardziej przyzwyczajeni do pisania kodu na klawiaturze niż na tablicy. Po prostu upewnij się, że środowisko programistyczne, takie jak Eclipse, VS lub Idle, jest już uruchomione z pustym projektem podczas uruchamiania kandydata, aby nie musiała tracić czasu na wyszukiwanie zainstalowanych aplikacji.

nikie
źródło
Celowo nie używam komputera w wywiadach ze względu na efekt inteligencji. Niedoświadczone programy kandydujące, naciskając. i wybranie czegoś z listy. Tablica czyni to bardzo oczywistym ...
Michael Shaw
5
@Ptolemy: Naprawdę tak uważasz? W przypadku typowego ćwiczenia na tablicy, takiego jak „zaprogramuj najpierw głębokość przeszukiwania drzewa”, jakie zastosowanie miałoby Intellisense?
nikie
2
Tablice / dokumenty nie ulegają awarii i każdy wie, jak na nich pisać. Jeśli dasz mi bezczynność do rozwiązania problemu, zakładam, że jesteś idiotą, a jeśli dasz mi Eclipse, spędzę połowę czasu na walce z domyślnymi skrótami klawiszowymi.
6
Intellisense (i inne funkcje autouzupełniania innych IDE, jestem pewien) można wyłączyć. Możesz też dać im Notatnik (lub ciekawszą alternatywę, taką jak Notepad ++, która wyróżnia składnię, ale nie ma autouzupełniania itp.) Jasne, może ulec awarii, ale realistycznie: ile błędów showstopper napotkałeś w Notatniku?
CVn
3
Nawet jeśli jest to tylko notepad.exe, o wiele łatwiej jest pracować z papierem lub tablicą. Możesz wstawiać lub usuwać linie, co jest ogromnym problemem dla fizycznych nośników.
CodesInChaos
10

Nie jest to niewłaściwe, ale wiedz, że NIE zawsze może ujawnić prawdziwy wgląd w umiejętności programowania lub rozwiązywania problemów przez osobę, z którą przeprowadzasz wywiad. I chyba właśnie tego szukasz.

Po drugie, zwróć uwagę, że zawsze istnieje strach przed porażką, stale zasłaniający mózg osoby. „Co jeśli spieprzę?”, „Co jeśli popełnię głupi błąd”. Większa część mózgu tej osoby jest zajęta ciągłym sprawdzaniem, jak się schodzi - tylko nieliczni potrafią powstrzymać nerwy.

Zatem w takiej sytuacji nawet najlepsi mogą się chwiać.

Ostatnią częścią , o którą pytamy rozmówców, jest napisanie małego fragmentu kodu (4–5 wierszy) na tablicy i wyjaśnienie podczas jego przeglądania

W porządku. Ale znowu to, że ktoś nie potrafił poprawnie wyjaśnić czegoś, nie oznacza, że ​​nie zna tego dobrze. (Wyjaśnienie to sztuka mowy).

Gdybym był tobą, zrobiłbym to dla ostatniej części ...

Zatrudnij ich do bardzo małego (ale realistycznego) projektu. Zobacz, jak kodują, podejmują decyzje, asymilują warunki pracy i członków zespołu itp., A następnie na tej podstawie podejmują ostateczną decyzję.

treecoder
źródło
6
Jeśli częścią twojego procesu rekrutacji jest zaoferowanie standardowej umowy na czas określony na 3 miesiące, to ile osób naprawdę zrezygnuje z roli permu, aby przyjąć twoją ofertę?
Michael Shaw
1
Miałem na myśli ostatni w tym sensie, że był to ostatni element na mojej liście. Zmieszam kolejność rzeczy w wywiadzie w zależności od tego, jak postępowała część konwersacji i gdzie, moim zdaniem, są ich mocne i słabe strony. Co do oferowania im krótkoterminowej umowy ... to po prostu nierealne w prawdziwej małej firmie. Nie mam czasu / środków, aby podejmować 3-miesięczne ryzykowne wykopaliska na ludziach, którzy mogą nie ćwiczyć, a jak zauważył Ptolemeusz, wątpię, by kandydaci też byli zbyt bystrzy.
Eoin Campbell
„Większa część mózgu tej osoby jest zajęta ciągłym sprawdzaniem, jak się schodzi - tylko nieliczni potrafią powstrzymać nerwy”. Zawsze uważałem, że należy to odnotować, szczególnie w przypadku niektórych nowych osób, które właśnie kończyły studia. Wiem, że byłem wrakiem w pierwszych kilku wywiadach, martwiąc się o to do tego stopnia, że ​​pomyliłem niektóre z najłatwiejszych pytań tylko dlatego, że byłem tak zdenerwowany. To prawda, że ​​niewiele możesz zrobić. Wszystko, co mogłem zrobić, to przejść do następnego wywiadu, by w końcu poczuć się komfortowo z tym procesem.
Dzbanek
1
@ TheJug całkowicie się zgadza i będziemy o wiele łagodniejsi z Juniors & Grads, aby upewnić się, że nie zostaną przytłoczeni tym procesem, ale mieliśmy starszych deweloperów (7-8 lat), którzy borykają się z tym.
Eoin Campbell,
1
„Zatrudnij ich do bardzo małego (ale realistycznego) projektu ...” - czy sugerujesz, że powinieneś „zatrudnić” np. Trzech kandydatów, którzy ubiegali się o stanowisko, nawet jeśli planujesz go utrzymać? To wydaje mi się bardzo niesprawiedliwe! Prawdopodobnie nie poprawi też ducha zespołu.
nikie
8

Nie nieodpowiednie, ale pamiętaj, że niektóre osoby (a może większa część tłumu programistów) mogą być bardzo zestresowane w wywiadzie. Myślę, że większość z nas zna faceta z biura, który jest genialnym programistą i osobą godną zaufania, ale w takiej sytuacji stopiłby się. Jego wyników nie można było zmierzyć w takim teście, więc nie rób z tego testu go / no go.

Tamás Szelei
źródło
7
Nie znam tego faceta, ponieważ nie został zatrudniony.
kevin cline
4
@kevincline ze szkodą dla firmy, chyba że zarabiasz pieniądze, gdy ludzie mają nerwy.
JayPea
1
@JayPea: skąd mam wiedzieć, że osoba jest genialnym programistą, jeśli nie wydaje mi się, żeby była kodem? Jedyną alternatywą byłoby zalecenie kogoś już zatrudnionego. Wszyscy uwielbiają zatrudniać na zaufanych rekomendacjach, ale to dość mała grupa.
kevin cline
1
@kevincline Przeczytaj moją odpowiedź, nie mówię, że nie powinieneś pisać kodu na tablicy podczas wywiadu z programistą.
Tamás Szelei
@JayPea Jestem pewien, że posiadanie pracowników, którzy nie denerwują się w sytuacjach stresowych, jest ważnym czynnikiem sukcesu finansowego wielu firm.
Kyle Strand,
4

Osobiście uważam, że jest to jedna z najlepszych rzeczy, które możesz zrobić. Jak powiedziałeś, nie szukasz poprawnej składni lub czegoś podobnego, najważniejszą częścią jest tutaj sprawdzenie, czy ktoś może się komunikować ... Widziałem tylu dobrych programistów, którzy mogą pracować samotnie we własnej przestrzeni ... Niestety to nie jest możliwe w ogromnej liczbie przypadków, więc posiadanie wykwalifikowanego faceta, który jest w stanie POWIEDZIEĆ, co myśli w jasny i zwięzły sposób, jest bardziej wartościowym członkiem zespołu niż ktoś, kto myśli: „Nie zrozumieją tego w każdym razie po prostu zrobię to sam i pokażę później ”.

Komunikacja, komunikacja, komunikacja, która jest podstawą każdego średniego i dużego projektu (nawet mniejszego, gdy jest to potrzebne)

Ivan Crojach Karačić
źródło
cóż, to coś więcej niż komunikacja. muszą mieć możliwość komunikowania się, jasne, ale muszą też być w stanie powiedzieć mi swoje rozwiązanie prostego problemu.
Eoin Campbell
4

Myślę, że to nie jest rozsądne. Staramy się znaleźć kandydatów, którzy są dobrzy w zadaniu, które chcemy im wykonać. Pisanie kodu na tablicy nie jest jednym z nich i nie sądzę, że jest to prawidłowy filtr do wyszukiwania dobrych kandydatów.

  • Dobry kod nie zostaje napisany, zostaje przepisany. Tablica jest prawie niezmienna, ponieważ po jej napisaniu trudno ją zmienić. Zmiana zdania powinna być jak najłatwiejsza, gdy tylko lepiej zrozumiesz problem.
  • Przebywanie w rozmowie kwalifikacyjnej jest stresującą sytuacją, dlatego nie ma potrzeby wywierania dodatkowej presji na kandydata. Wielu informatyków nie ma dobrego pisma. Nowoczesne środowiska IDE zapewniają wiele narzędzi, do których jesteś przyzwyczajony. Możliwość wyszukiwania w Google w jednej chwili jest także częścią stylu pracy większości programistów. Po co zabierać te wszystkie rzeczy i tworzyć sztuczne środowisko, w którym nigdy nie będą musieli pracować, jeśli złożysz im ofertę?
  • Jesteśmy również bardzo zainteresowani umiejętnością pisania dobrych testów, może nawet TDD. Nie można tego zobaczyć podczas kodowania tablicy.

Większość wskazówek, które możesz wyciągnąć z sesji kodowania tablicy, możesz także wyciągnąć z sesji parowania - i uważam, że parowanie jest znacznie lepszym narzędziem do zrozumienia, w jaki sposób kandydat rozwiązuje problem i jak działa. Może zabrać własny komputer i pracować w środowisku, w którym czuje się dobrze. Znacznie łatwiej jest zastosować się do zadania, które chcesz, aby dołączyli. Mamy na przykład dużą bazę kodu starszego typu, dlatego prosimy o ponowne przetworzenie wyodrębnionego kodu dla prawdziwego projektu. W naszej codziennej pracy łączymy tak dużo, jak to możliwe, więc dobrze pasuje.

Chociaż sesja tablicy prawdopodobnie pomaga odfiltrować złych kandydatów, prawdopodobnie również odfiltrowuje wielu dobrych programistów.

iGEL
źródło
1
Tablice są niezmienne? Po prostu wycierasz coś i przepisujesz to na kaprys, co czyni je przydatnymi, zwłaszcza do nauczania. Musisz żyć w alternatywnym wszechświecie.
whatsisname
Może niezmienne jest niewłaściwe słowo (wziąłem je z medium.com/dima-korolev/… - kto uważa, że ​​to zaleta). Mimo to, w porównaniu do edytora, trudno jest dodać coś, na co nie masz miejsca.
iGEL,
3

Osobiście chodziłbym na każdego ankietera proszącego mnie o zrobienie FizzBuzz. Nie wiem, kiedy to stało się nowym standardem branżowym, ale to naprawdę strata czasu. FizzBuzz jest filtrem, którego można użyć przed rozmową kwalifikacyjną, chociaż osobiście uważam, że gdybym musiał wybrać spośród N kandydatów, z których wystarczająco dużo kodu lub bloga, na który mogę spojrzeć, zdecydowanie wolałbym to jako filtr .

Mówiąc najprościej, myślę, że w wywiadzie na stanowisko programistyczne (z wyjątkiem może dla juniorów lub staży) powinno już być ustalone / ustalone, że rozmówca może programować.

Ale tak, tablica jest idealna, chociaż myślę, że powinieneś podjąć inny zestaw problemów. Rzuć im prawdziwy problem i niech narysują kilka sprzeczek w języku UML, aby wyjaśnić swoją ogólną strategię rozwiązania tego problemu. Daj im komputer z Internetem, aby mogli szukać bibliotek innych firm, których mogliby użyć jako czarnych skrzynek w swoim squibblescape.
W ciągu kilku minut naprawdę zobaczysz, jak radzą sobie z problemami. Możesz sprawić, że będzie to bardzo interesująca rzecz, wybierając problemy, które niekoniecznie masz na uwadze, i próbuj je razem rozwiązać, aby zobaczyć, jak dobrze się komunikują i jak dobrze mogą wnieść wkład (jednak nie naciskaj ich zbyt mocno - niektórzy ludzie mogą po prostu zamarznąć, jeśli to zrobisz). A potem dodaj kilka wymagań w locie. To trochę jak tworzenie oprogramowania bez implementacji i - co najważniejsze - bez debugowania, więc 15 minut to dużo czasu.

back2dos
źródło
„powinno być już ustalone / ustalone, że rozmówca może programować” - jak? Albo masz wstępną rozmowę kwalifikacyjną, w którym to przypadku OP stawia pytanie, czy kodowanie tablicy jest właściwe w trakcie wstępnej rozmowy kwalifikacyjnej, lub skutecznie wierzysz na słowo kandydata, co zapowiada katastrofę. Osoby rekrutujące i CV mogą (i robią) kłamać, blogi i repozytoria github mogą być plagiatowane.
Julia Hayward
@JuliaHayward: Ustalenie podstawowych umiejętności kodowania kandydata podczas wywiadu wstępnego to inna sprawa. Tak naprawdę nie musisz zapraszać kogoś na stronie . Możesz wysłać im mały problem, który mogą rozwiązać. Ewentualnie omów to rozwiązanie (lub kod github) osobiście. Co najważniejsze: jest bardzo mało prawdopodobne, że znajdziesz kandydata, który z wdziękiem poradzi sobie z typem problemu, który sugeruję, nie będąc w stanie rozwiązać problemów typu fizzbuzz. Rozmowa kwalifikacyjna powinna być wykorzystana do ustalenia, jak kandydat jest w stanie poradzić sobie ze złożonością typową dla rzeczywistych problemów.
back2dos
Być może nie będziesz musiał mieć kogoś na miejscu, ale przynajmniej powinieneś rozmawiać przez telefon z kandydatem rozmawiającym przez programowanie, niezależnie od tego, czego używasz. Samo zadawanie pytań i czekanie na przesłanie pliku zip nadal wiąże się z ryzykiem podszywania się; jako ekstremalny przykład zrobiłem kiedyś test dla FooCorp, a potem po prostu nie interesowałem się w wyszukiwarce „Test kodowania FooCorp” - i znalazłem, że ktoś opublikował całkiem dobre rozwiązanie.
Julia Hayward
@JuliaHayward: Jeśli dasz każdemu wnioskodawcy ten sam problem, wtedy odpowiedź stanie się Google. Nic dziwnego, prawda? Ale znowu moja odpowiedź pozostaje: nie rób kodowania tablicy na poziomie fizzbuzz w wywiadzie. To po prostu pokazuje, że nie zadałeś sobie trudu przygotowania dobrego i interesującego problemu. Jak sam powiedziałeś, istnieją sposoby na ustalenie podstawowych umiejętności programistycznych na długo przed zaproszeniem kandydatów do tablicy.
back2dos
3

Pozwól, że odpowiem innym pytaniem:

Czy pisanie kodu na białej tablicy ma jakąkolwiek rzeczywistą przewagę w ocenie umiejętności programowania, w porównaniu do pisania i wykonywania kodu na komputerze?

Myślę, że absolutnie właściwe jest poproszenie kandydata o napisanie kodu podczas rozmowy kwalifikacyjnej. Jednak dla mnie możliwość wykonania kodu jest kluczową częścią pętli sprzężenia zwrotnego, która składa się na programowanie. Na białej tablicy wiążesz jedną rękę za moimi plecami i nie masz pełnego obrazu tego, jak pracuję nad problemem.

Kevin C.
źródło
czy to tylko Twoja opinia, czy możesz jakoś to zrobić?
komar
2
@gnat Po prostu zadaję pytanie. Druga połowa odpowiedzi to moja opinia, tak, ale powinno to być dość jasne w zależności od użytego języka. Co więcej, samo pytanie zaczyna się od uznania, że ​​jest subiektywne, i w szczególności wymaga opinii w tej sprawie. Nie sądzę, by głosowanie było uzasadnione.
Kevin C.
@Kevin C. Myślę, że niezależnie od twojego sformułowania, robisz tu bardzo dobry punkt. Kodowanie na tablicy różni się od kodowania komputerowego. Czy to opinia? Z pewnością nie, o ile tablice nie są w stanie uruchomić kodu.
Leandro Caniglia
2

Nie, ale IMO lepszym rozwiązaniem byłoby użycie tablicy zgodnie z jej przeznaczeniem i użycie UML / szkiców / notatek do jakiegoś fikcyjnego projektu, zamiast starego „napisz do mnie zapytanie SQL, aby uzyskać wszystkie rekordy” lub „napisz metodę, która odwraca ciąg ".

Jednym z najlepszych wywiadów, jakie przeprowadziłem, było około 20 minut na omówienie z głównym deweloperem architektury (nie oprogramowania) rezydencji szalonego naukowca (wraz z tajną kryjówką, promieniem śmierci i budą dla psów). Zobaczył moje podejście do rozwiązywania problemów, a problem polegał na czymś zabawnym, a nie na typowym programowaniu na pamięć 101 rzeczy, które tysiące współczesnych języków rozwiązało. Nawiasem mówiąc, wcześniej napisałem taki fragment kodu, ale czułem się znacznie bardziej „pod presją” niż z częścią architektury.

Wayne Molina
źródło
2

W dzisiejszych czasach dużo programowania odbywa się w zespołach. Aby zespoły działały, ludzie muszą mieć możliwość komunikowania się. Duża część tego jest w stanie komunikować się przed tablicą (burza mózgów, mentoring, poprawki kodu proponowane poprawki itp.)

Chciałbym sprawdzić, czy kandydat wyjaśnił, jak przejść do rozwiązania problemu programistycznego, używając do tego kodu tablicy. Jeśli wyjaśnienie jest wystarczająco dobre, inni dobrzy programiści w pokoju automatycznie poprawią wszelkie literówki / błędy na tablicy.

W przypadku większości typów pozycji w zespole nierozsądne byłoby NIE oczekiwać, że kandydat będzie w stanie wyjaśnić i zapisać swoją próbę rozwiązania.

hotpaw2
źródło
0

Nie, dobrze jest napisać kod na rozmowę kwalifikacyjną, ale powinieneś zezwolić na kod w dowolnym rozsądnym języku, ponieważ zwykle łatwiej jest wyszkolić programistę w innym języku niż uzyskać tak bardzo kodera w wybranym przez siebie języku do poziomu konkurencji.

Paddy3118
źródło
0

Powiedziałbym, że jest to właściwe, ale w większości przypadków nie jest to skuteczny sposób, aby dowiedzieć się, kto jest dobry w programowaniu, a kto nie. Jeśli chcesz wykonać pracę (= zatrudnić kogoś, kto jest w stanie), rozmowa kwalifikacyjna powinna koncentrować się na mierzeniu umiejętności z życia wziętych. Jak dotąd najlepszy wywiad, w którym pracowałem w ten sposób:

  • Pozdrowienia, powitanie przez HR.
  • Kilka słów o mnie, o firmie itp. ... i wyjaśniła resztę wywiadu.
  • Dała mi laptopa z programem, w którym brakowało kilku części, z tego powodu nie przeszła testów jednostkowych. Brakujące części zostały tam skomentowane jako teksty, chodziło o wdrożenie podstawowego zadania, takiego jak stworzenie połączenia między kilkoma klasami i wprowadzenie prostej logiki biznesowej.
  • Jeśli wszystko poszło dobrze, testy jednostkowe stały się zielone.
  • Pożegnanie i zgoda na powrót za kilka dni.
  • Tego dnia lider spotkał się ze mną i zapytał o ukończony program, co zrobiłem i dlaczego.
  • Również ten lider zapytał o moje wcześniejsze doświadczenia i kilka innych pytań.

Podsumowując: jeśli szukasz siły roboczej do kodu produkcyjnego, sprawdź ich umiejętności w prawdziwym środowisku. Jeśli jesteś ciekawy ich wiedzy teoretycznej, lepiej zapytaj ich o te rzeczy. Jeśli jesteś pozbawiony IDE lub denerwujesz się, ponieważ musisz programować na białej tablicy przed kimś, rozumiem, szczególnie, że w IT ludzie są czasami zamknięci w sobie i wielu z nas nie radzi sobie dobrze z tymi sytuacjami, więc na białym nasza wydajność będzie wyglądać gorzej niż w rzeczywistości.

CsBalazsHungary
źródło
-1

Nie uważam tego za nierozsądne, chyba że rozmówca źle pisał (lub powinienem powiedzieć pisanie na tablicy) :-). Poza tym jedyną różnicą w twoim podejściu jest użycie planszy i znacznika. W niektórych przypadkach ankieterzy robią to, ale zamiast tego dają kartkę i długopis. W przypadku przeprowadzania wywiadu przez 3-4 osoby, powiedziałbym, że twoje podejście będzie znacznie lepsze i odpowiednie.

Pankaj Upadhyay
źródło
1
„Przeważnie lub wszyscy ankieterzy to robią” to dość rzadka IMO.
Kirk Broadhurst,
Chyba wszyscy to robią. Rzadko spotykają się z komputerem lub laptopem, aby sprawdzić, czy rozwiązujesz konkretny problem z kodowaniem. Ale może rzeczy są inne w twoim miejscu. Jeśli chcesz, mogę edytować to w odpowiedzi?
Pankaj Upadhyay
zobacz, zgodzę się, że to dość rzadkie ... W ciągu ostatnich 9 lat miałem 4 prace i nigdy nie zostałem poproszony o napisanie kodu na papierze / wb. Wszelkie kodowanie odbywało się w IDE. dlatego zastanawiam się, czy to niewłaściwe. Spodziewałbym się, że deweloper będzie w stanie rozbić kod „Odwróć ciąg” w ciągu najwyżej kilku minut bez pomocy IDE / Intellisense.
Eoin Campbell
Dokonałem edycji w oparciu o twoje doświadczenia. Podczas dwóch wywiadów, w których również byłem, dali mi długopis i papier do napisania, jak wydrukować serię Fibonacciego i algorytm do łączenia. Tak więc myślałem, że większość rzeczy idzie w ten sposób :-)
Pankaj Upadhyay
Powinienem zaznaczyć, że nigdy nie musiałem pisać kodu na komputerze; Miałem do kodu pisania na papierze dwukrotnie (zarówno gdy byłem młodszy) i musiałem narysować schemat architektury na tablicy raz . To około 20 wywiadów ...
Kirk Broadhurst,