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

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?”

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.

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.

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ę.

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.

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)

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.

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.

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.

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.

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.

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.

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.

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.