Podstępne łamigłówki logiczne - czy są naprawdę przydatne w ocenie umiejętności programowania? [Zamknięte]

W ostatnim wywiadzie, w którym uczestniczyłem, poproszono mnie o rozwiązanie zagadki, w której miałem zmierzyć dokładnie bla litry wody, biorąc pod uwagę dwa wiadra o pojemności - odpowiednio bla i bla litry. Nie byłem w stanie rozwiązać zagadki w określonym czasie (~ 5 minut).

Ankieter był nieco rozczarowany i powiedział, że programista musi mieć „te” umiejętności. Nie rozumiałem, o jakich umiejętnościach mówił.

Zawsze czułem się dziwnie z tego rodzaju łamigłówkami, które zwykle są zadawane podczas programowania rozmów kwalifikacyjnych. Nie rozumiem, jaki jest związek między takimi zagadkami a programowaniem, jeśli w ogóle. Dokładnie jakie umiejętności ankieterzy zamierzają ocenić za pomocą takich zagadek?

Niektóre osoby pytają ich, próbując ocenić twoje umiejętności i podejście do rozwiązywania problemów. Osobiście nie sądzę, że takie łamigłówki zapewniają dokładny wskaźnik. W „prawdziwym świecie” masz więcej niż pięć minut, aby dowiedzieć się, czy na przykład radzisz sobie z pakowaniem pojemników, czy z problemami z plecakiem . Początkowo czasami łatwo jest źle zrozumieć dany problem, dopóki nie znajdziesz się w środku stosowania niewłaściwego rozwiązania. Tak dzieje się w przypadku osób z 1, 5, 10, a nawet 20-letnim doświadczeniem.

Najlepsze „zagadki” podczas wywiadu to te, w których siedzisz przy komputerze, aby rozwiązać problem w dziedzinie, w której zdobywasz wiedzę. Nie podoba mi się również myślenie „Cóż, programista powinien ...”, ponieważ nie bierze pod uwagę, że ludzie stają się niespokojni, gdy uderza ich coś nieoczekiwanego w stresującym otoczeniu. Jasne, możesz to rozwiązać, jeśli będziesz miał czas, aby o tym pomyśleć ... a może możesz rozwiązać to szybciej, jeśli zdasz sobie sprawę, że twoje życie się skończy, jeśli tego nie zrobisz. Czy chcesz pracować gdzieś, gdzie skończy się twoje życie, jeśli nie rozwiążesz problemów w ciągu pięciu minut ? Zostaniesz zwolniony, jeśli nie możesz ?

Czy wszyscy wielcy programiści powinni być również mistrzami rozwiązywania sudoku? Jestem pewien, że jest ich mnóstwo, ale nie jest to jakiś warunek wstępny do kompetencji.

Nie mówię, że powinien nie być testowane, w jaki sposób podejść do problemów, ale testy powinny być zabawa i zaprosić „najlepsze”, że wnioskodawca musi podać, ze względu na ich obszar wiedzy. Udowadniając, że jesteś tak mądry jak znak, że Bruce Willis wciela się wydaje rodzaju bezcelowe, biorąc pod uwagę, że producenci spędził ładną sumę dostać tę scenę po prostu prawo.

Innymi słowy, jeśli wykryjesz, że przesłuchuje Cię ktoś, kto nie rozumie, co właściwie robisz , przepraszam, aby pójść do toalety i nigdy nie wracać.

Microsoft zaczął używać tych pytań na początku lat osiemdziesiątych. Gdy Microsoft odniósł duży sukces, inne firmy zaczęły je kopiować, ale kilka kluczowych punktów zaginęło w tłumaczeniu.

W tym czasie Microsoft próbował obsadzić wiele technicznych, ale nieprogramowych stanowisk: pisarzy technicznych, testerów, wsparcia telefonicznego itp. W tamtych czasach nie były to typowe zadania, a ludzie z faktycznym doświadczeniem w tych obszarach byli trudni odnaleźć. Alternatywnie Microsoft pomyślał, że mogą zatrudnić naprawdę inteligentnych, sprytnych, elastycznych ludzi i przeszkolić ich w pracy. Ponieważ ci ludzie nie mieli doświadczenia programistycznego, zadawanie im pytań programowych podczas wywiadu było bezcelowe. Zagadki zostały wybrane, aby spróbować wskazać ludzi, którzy byli sprytni i mieli wyjątkowo dobre umiejętności analityczne. Programiści generalnie mieli problemy z programowaniem na tablicy, choć mogą być też zadawane zagadki podczas lunchu lub kolacji.

Te pytania nigdy nie były pomyślane jako pass-fail. Miały one być początkiem rozmowy o tym, jak poradzisz sobie z tym problemem i jak myślałeś o problemach, których nigdy wcześniej nie widziałeś. Jedynym pewnym sposobem na „niepowodzenie” było odmowa próby rozwiązania problemu. W tym czasie była to nowatorska strategia i nie można było po prostu wyszukać pytań w Google.

Edytować:

Jakiś czas po napisaniu tej odpowiedzi przeczytałem The Computer Boys Takeover , historię komputerów instytucjonalnych w latach 50. i 60. XX wieku. Najwyraźniej praktyka zadawania łamigłówek i zagadek dotyczących kandydatów do pracy programistycznej sięga lat pięćdziesiątych. USA próbowały skomputeryzować swój system obrony przeciwlotniczej, a IBM oszacował, że do wykonania pracy potrzebowałoby kilku tysięcy programistów. Reakcja była szokiem i konsternacją: na całym świecie było tylko kilkudziesięciu „profesjonalnych programistów”. Wypróbowano kilka podejść: abstrakcyjne testy umiejętności programowania, rekrutację matematyków jako programistów, rekrutację szachistów i rozwiązywanie krzyżówek oraz sprawdzanie kandydatów za pomocą zagadek i łamigłówek.

W końcu udało im się zrekrutować wystarczającą liczbę programistów, aby ukończyć projekt, ale doszło do wniosku, że żadna z metod badań nie była lepsza niż szansa na zidentyfikowanie rekrutów, którzy odnieśli sukces jako programiści.

Czy są przydatne? Nie, nie bardzo. Kiedyś były tak powszechne w Microsoft, że nawet nazwano je „pytaniami Microsoft”, a napisano o nich książki, ta jest naprawdę całkiem dobra.

Są z nimi 2 problemy. Po pierwsze, jeśli wnioskodawca przeprowadzi badania (i przeczyta książkę), i tak je pozna, a po drugie, nawet jeśli potrafią je rozwiązać, jak to pokazuje, że będzie to dobry program / test / PM.

Z tych powodów rzadko są już pytani w Microsoft. Zdecydowanie lepiej jest zadawać pytania dotyczące kodowania lub rozwiązywania problemów, które nie wymagają odpowiedzi „trickowej”. Innymi słowy, musisz zadawać pytania, które pozwolą ci poznać umiejętności i zachowanie wnioskodawcy, gdy ten próbuje rozwiązać problem - jako ankieter chcę, aby zadawał pytania, wymyślał rozwiązania, a następnie cofał się, gdy się zorientują. problem, może nawet nie znajdzie rozwiązania w swoim czasie, ale przynajmniej podejmie go rozsądnie. To odzwierciedla rzeczywistą pracę. Nigdy nie musiałem mierzyć 3 kufli za pomocą 2 wiader i kurczaka (lub cokolwiek innego było to pytanie).

To powiedziawszy, zadano mi kilka podstępnych pytań w swoim czasie i teraz uważam się za eksperta w transporcie kurczaków i lisów na małych łodziach i obliczaniu życia muchy, która mieszka w pociągu. Nigdy nie musiałem korzystać z tych informacji, ale kto wie, może kiedyś ...

Może chcesz przeczytać książkę How You You Move Mount Fuji? . Wchodzi w rozumowanie, że wielu ludzi używa zagadek podczas wywiadów, a moim zdaniem jest to kombinacja kultowego zachowania ( „Microsoft to robi, a jeśli chcemy odnieść taki sukces jak oni, to lepiej zrobimy to, co oni” robić ” ) i braterskie leniuchowanie ( „ Boże !, musiałem odpowiedzieć na te pytania i lepiej wierzyć, że następny facet będzie musiał na nie odpowiedzieć! ” ).

Historia tych pytań jako praktyki wywiadu rozpoczęła się u Williama Shockleya w latach 50. XX wieku. Były dość popularnym rodzajem pytania do wywiadu w Dolinie Krzemowej, które zadawali ankieterzy, ponieważ robili to inni ankieterzy (a może wiedzieli coś, czego ten ankieter nie wiedział?). Shockley zamierzał je jako test inteligencji, a pytanie z 2 łyżkami dotyczyło jednego z oryginalnych testów Stanford Binet IQ w 1916 roku.

Całkiem możliwe, że osoby przeprowadzające wywiad naprawdę chcą zobaczyć, jak szukasz odpowiedzi, więc nie będą w stanie obliczyć pytań, takich jak liczba pomp gazu w twoim mieście. Tego rodzaju problemy to problemy Fermiego . Dwa interesujące posty na blogu Jeffa na ten temat to najtrudniejsze pytanie w historii wywiadu i jak dobry jesteś estymatorem? Część III .

Osobiście mam niską opinię na temat tego rodzaju pytań, ponieważ na ogół są one używane przez ankieterów, którzy nie wiedzą, co robią, ani jak szukać programistów. O ile nie zamierzasz pracować dla firmy, która tworzy łamigłówki / zagadki, należą one do prochu historii wraz z „jaka jest twoja największa słabość” (odpowiedz na to prawdę i źle skończysz wywiad) lub „dlaczego” są okrągłe pokrywy włazów ”(nie wszystkie są).

Innego dostarczyły odpowiedzi, które mam upvoted jako przedmiot moszczu . Powodem, dla którego piszę inną odpowiedź, jest to, że to, co chcę powiedzieć, prawdopodobnie nie zmieści się w komentarzu, a także dlatego, że trzeba coś powiedzieć o tym, jak może wyglądać dobra rozmowa programistyczna.

W pierwszym dobrym wywiadzie, który pamiętam, dużo rozmawialiśmy bez pośpiechu. Najpierw przez godzinę, przez telefon, na temat projektowania obiektowego oraz zalet i wad wdrażania go w C ++. Następnie na miejscu rozmawiałem z kilkoma osobami o ich praktykach tworzenia oprogramowania, integracji, testowaniu, kontroli wersji i zarządzaniu konfiguracją, o zespołach i obowiązkach, o technologii i projektowaniu. To był całodniowy wywiad obejmujący lunch z ludźmi, którzy przeprowadzili ze mną wywiad. Z perspektywy czasu chodziło o to, czy produktywnie pasowałbym do tego, co już robili.

Od tego czasu wszystkie dobre rozmowy były długie, trwające od jednej do dwóch godzin na temat tworzenia oprogramowania. Nie było pytań dotyczących rozwiązywania problemów, łamigłówek i problemów z kodowaniem.

Gdybym miał dzisiaj przesłuchać kogoś w sprawie pracy programistycznej, postąpiłbym podobnie. Poprosiłbym o opinie na temat szerokiego zakresu tematów i odłożyłem na bok głębokość:

1. Jakie są twoje preferencje języka programowania? Dlaczego?
2. Jak podejść do obsługi wyjątków?
3. Czy korzyści płynące z projektowania warstwowego nie są mitem?
4. Czy ciągła integracja nie jest obciążeniem dla wydajności?
5. Ktokolwiek napisał fragment kodu, powinien go posiadać, prawda?
6. Co robisz, aby dostać się do „przepływu”.
7. Jak zgłaszane usterki należy uwzględnić w planie projektu?
8. ...

Są to pytania z więcej niż jedną odpowiedzią, a wszystkie dotyczą tematów, na które twórca oprogramowania powinien mieć świadomą opinię. Z całego serca zgadzam się z odpowiedziami, które wspominają poprzednie prawdziwe problemy występujące jako temat rozmowy (nie jako pytania).

Bardziej naukowe badania na temat skutecznego tworzenia oprogramowania od czasu Peopleware mówią, że najlepszymi programistami są ci, którzy rozumieją dynamikę rozwoju oprogramowania, nawet jeśli nie mają najwyższych IQ. Wolę wziąć nowicjusza, który chętnie się uczy, niż kogoś z nwieloletnim doświadczeniem, który sprowadza się do 1powtarzanego roku doświadczenia n. Moje osobiste nastawienie dotyczy kandydatów, którzy mają tendencję do myślenia nieszablonowego, a jednocześnie wiedzą, jak dopasować się do obecnego (mojego) pudełka.

Mogą być przydatne w ocenie umiejętności rozwiązywania problemów , co jest oczywiście jednym z kluczowych aspektów programowania.

Jako ankieter wielu osób na przestrzeni lat zwykle nie zadaję pytań typu gotcha, takich jak te, które zdajesz się opisywać, ale mogę o coś zapytać i zapytać „jak byś rozwiązał ...”.

W tym przypadku oczekuję, że wyartykułujesz swoje podejście do problemu. Jakie inne dane chciałbyś zgromadzić? Jak przetestowałbyś swoje hipotezy itp.

To tylko praktyki zatrudniania voodoo. Inni ludzie zadają te pytania, aby czuli się tak, jak powinni. Wiedzą, że brak odpowiedzi na pytanie jest „zły”, a odpowiedź „dobra”, ale nie potrafią wyjaśnić, dlaczego poza brakiem odpowiedzi, np. „Programista potrzebuje tych umiejętności”. Są stratą czasu i wskaźnikiem, że ankieter nie jest kompetentnym ankiecie.

To racjonalne staro-skool, że musisz mieć podstawowe umiejętności logiczne; czegokolwiek innego można nauczyć. Ale to nie do końca prawda. Czytanie logiki logicznej , warunków i pętli nie jest tym samym, co umiejętność rozwiązywania zagadki logicznej .

To powiedziawszy, w czasach języków proceduralnych prawdopodobnie prawdą było, że ktoś, kto byłby w stanie rozwiązać te problemy, miałby większą skłonność do zastosowania dowolnego problemu pod względem zamiany. Ale moim zdaniem programowanie OO / funkcjonalne wymaga myślenia inżynieryjnego, które jest zupełnie inne (choć nie sprzeczne).

Osobiście nie jestem pewien, czy chciałbym pracy w firmie, która nadal uważała, że ​​logika jest ważniejsza niż praktyczne umiejętności programowania.

Oświadczenie: Jestem bardzo dobry w łamigłówkach logicznych i prawdopodobnie nie zacząłbym w tej pracy bez tego uzasadnienia.

Ankieter musiał mieć na myśli rozwiązywanie problemów i umiejętności logiczne, które są częścią codziennej pracy programisty. Gdy pojawia się problem, musisz być w stanie go przeanalizować, podzielić na części i napisać rozwiązanie, stosując najbardziej optymalne podejście.

Można spierać się o to, jak dobrze taka układanka reprezentuje twoją zdolność do tego. Nie widzę zalet zadawania zagadek logicznych zamiast zadawania prawdziwych problemów programistycznych.

Programowanie nie polega na pisaniu wierszy kodu, ale na rozwiązywaniu problemów dla i od innych osób (klientów, użytkowników itp.).

Zdarza się, że dla programistów rozwiązanie ma postać programu.

Dlatego ważne jest, aby mieć możliwości rozwiązywania problemów i dlaczego jest on testowany.

Biorąc to pod uwagę, nie jestem pewien, czy rozwiązanie podstępnej łamigłówki jest najlepszym sposobem na ocenę kogoś.

Zagadki w wywiadach dzielą się na dwie kategorie: „zagadki logiczne” (jak ta, o którą cię pytano) i kategorię „myśl inaczej”. Kategoria myślenia inaczej (nie jestem pewien, czy są one również nazywane łamigłówkami bocznymi?) To zwykle ten typ: Ile liści jest w tym drzewie? lub Ilu krawców jest obecnych w twoim mieście?

Nie mam nic przeciwko „łamigłówkom logicznym”, ponieważ mają one co najmniej jedno lub dwa rozwiązania i można je uzyskać za pomocą prostej logiki. I wierzę, że logiczne łamigłówki są do pewnego stopnia dobre, ponieważ proces potrzebny do ich rozwiązania jest bardzo podobny do sposobu, w jaki koder musi myśleć w prawdziwym życiu.

„Myśl inaczej” nie wkurza mnie bez końca, ponieważ zmuszają cię do poczynienia założeń, a następnie do dokonania pewnych obliczeń w oparciu o założenia. Mówiąc najprościej, jeśli twój ankieter zgadza się z twoją logiką, ale nie z twoimi założeniami lub odwrotnie, przegrałeś. Jest zbyt dużo miejsca dla ankietera, aby nie zgodzić się z twoim rozwiązaniem.

Podczas wywiadów nie zadaję zagadek logicznych. Powód: większość kandydatów, nawet tych z 3-4 letnim doświadczeniem, nie zdaje egzaminu lub poddaje się, gdy proszę o kodowanie prostych problemów z podręcznikiem, takich jak seria Fibonacciego lub palindromy.

Problem z łamigłówkami, tak czy inaczej, polega na tym, że niezbyt dobrzy programiści wiedzą, że po prostu szukając rozwiązań tak typowych łamigłówek w sieci, mogą zaimponować ankieterom. Bardzo niewiele osób będzie na tyle uczciwych, by powiedzieć, że znają już rozwiązanie.

Dwa punkty:

1. Programowanie różni się głównie od rozwiązywania zagadek. Jest to dokładnie wyjaśnione przez Steve'a McConnella w „Code Complete”:

   Co? Nie musisz być superinteligentny? Nie, ty nie. Nikt nie jest wystarczająco inteligentny, aby programować komputery. Pełne zrozumienie przeciętnego programu wymaga niemal nieograniczonej zdolności do wchłaniania szczegółów i równej zdolności do ich zrozumienia w tym samym czasie. Sposób, w jaki skupiasz swoją inteligencję, jest ważniejszy niż to, ile masz inteligencji. Jak wspomniano w rozdziale 5, podczas wykładu Turinga z 1972 r. Edsger Dijkstra opublikował artykuł zatytułowany „The Humble Programmer”. Twierdził, że większość programowania jest próbą zrekompensowania ściśle ograniczonego rozmiaru naszych czaszek. Najlepszymi programistami są ludzie, którzy zdają sobie sprawę, jak mały jest ich mózg. Są pokorni. Ludzie, którzy najgorzej programują, to ludzie, którzy nie akceptują faktu, że ich mózgi nie są równe zadaniu. Ich ego powstrzymują ich przed byciem świetnymi programistami. Tym bardziejnaucz się kompensować swój mały mózg, tym lepiej będziesz programistą . Im bardziej jesteś pokorny, tym szybciej się poprawisz.

2. Takie łamigłówki mogą być przydatne podczas wywiadu, ale tylko jeśli ankieter patrzy na Proces , a nie sam wynik.

Ale idealnie, moim zdaniem, układanki powinny być bardziej skomplikowane i związane z programowaniem (jak mały 2-godzinny projekt). Chodzi o to, że ankieterzy to ludzie i nie mają doskonałych „umiejętności prowadzenia wywiadów”.

Istnieje kilka różnych sposobów badania takich problemów:

1. Znając poprzednie rozwiązanie. W filmie ... Die Hard with a Vengeance ... wytłumacz mi to ...? będący przykładem poznania rozwiązania przypadku, w którym blaszki wynoszą odpowiednio 4,3 i 5. Niektóre osoby będą w stanie szybko wykorzystać swoją wiedzę na temat wcześniejszych rozwiązań i dostosować je w razie potrzeby. Sądzę, że zwykle tego oczekuje ankieter, co może, ale nie musi być dobrym pomysłem.

2. Twórcze umiejętności improwizacji. Tak byłoby w przypadku, gdy nie znasz wcześniejszego rozwiązania lub nawet nie rozpoznałeś problemu jako czegoś, co można by modelować jako równanie diofantyczne. Pytanie brzmi zatem, jak szybko można wykorzystać to, co zostało podane, i znaleźć twórcze rozwiązanie problemu wraz z wyjaśnieniem, dlaczego to, co masz, jest prawidłowym rozwiązaniem problemu.

Oba pytania mogą zadowalająco przejść obok pytania, ale w każdym przypadku jest też test umiejętności komunikacyjnych, ponieważ można również spróbować odpowiedzieć: „Czy to naprawdę pasuje do stanowiska, w którym jestem zastosowanie? Kiedy te umiejętności były ostatnio używane? ” może to prowadzić do interesującego dialogu, jeśli ankieter otworzy się na temat tego, co dokładnie chce zobaczyć, że być może alternatywne podejście może być tutaj postrzegane jako bardziej skuteczne.

To nie jest szczególnie trudny problem. Wymagane są tylko trzy kroki, a na każdym kroku są tylko dwie opcje. Byłbym zaskoczony, gdyby któryś z moich kolegów nie był w stanie rozwiązać go w bardzo krótkim czasie. Nie przedstawiamy takich problemów w wywiadach, ale myślę, że rozsądne jest zadawanie takich pytań. Są one z pewnością bardziej przydatne niż szczegółowe pytania na temat składni lub bibliotek.

OTOH, myślę, że problemy z programowaniem są bardziej przydatne.

Musisz pamiętać, że nie ma sposobu, aby wiedzieć z absolutną pewnością, że ktoś będzie dobry w pracy. Zwłaszcza praca z CS, ponieważ nie można przewidzieć wielu wyzwań, jakie może ona przynieść.

Potencjalny pracodawca musi więc zgadywać twoje przyszłe wyniki.

Stopnie, rekomendacje i GPA można uzyskać z czasem / wysiłkiem i inżynierią społeczną, doświadczenie zawodowe można upiększyć i / lub fałszywe, a znormalizowane testy są szczerze mówiąc zbyt podstawowe, aby nadmiernie wskazywać na umiejętności. Wznowienie może więc wskazywać poziom wysiłku / zaangażowania w twojej historii, ale żaden z nich nie będzie mówił o twojej rzeczywistej zdolności do rozwiązywania trudnych problemów, które pojawiają się w świecie informatyki. Nie mogę wymyślić lepszego sposobu na przewidzenie tego rodzaju umiejętności niż kilka dobrych łamigłówek logicznych / math / CSy.

Pamiętaj, że jest to gra polegająca na zgadywaniu, a rzeczywistość jest taka, że ​​wszystkie rzeczy równe każdemu z nas wolą zatrudnić kogoś, kto jest w stanie rozwiązać te zagadki, niż tę, która nie może.

Tak, możesz uczyć się zagadek z wywiadem, ale myślę, że zostaniesz spalony, jeśli dana łamigłówka nie pasuje do tych, które studiujesz ... i dopóki nie zapamiętasz zagadek i ich rozwiązań, być może studiujesz puzzle sami uczynią cię mądrzejszą osobą w realny sposób, jak każda prawdziwa edukacja.