Wywiad techniczny i umiejętność programisty [zamknięte]

To, co powiem, może być nieco kontrowersyjne z natury, ale dzisiaj jestem bardzo przygnębiony - i dlatego zapytam o to.

Właśnie odbyłem wywiad z dużą firmą technologiczną na staż, gdzie zadano mi wiele typowych pytań do wywiadu zorientowanych na algorytm. Teraz, biorąc pod uwagę moje pochodzenie, uważam się za silnego w algorytmach (mam również dobre stopnie w algorytmach na poziomie magisterskim - rzeczy obejmujące kompletność NP i więcej (algorytmy aproksymacyjne i losowe), ale niestety nie zaliczyłem wywiadu. Nie mogłem pomyśl o bardzo skutecznej metodzie rozwiązania problemu strun w około ~ 10 minut. Po zakończeniu wywiadu wypiłem szklankę wody, zjadłem banana i zrelaksowałem się na chwilę i spróbowałem ponownie. I vola! odpowiedź, którą mogłem przybyć w niecałe 5 minut. A co najgorsze - byłem na tym torze, a ankieter powiedział mi o tym, ale zbyt mocno naciskało na mnie. Całe moje doświadczenie sprawiło, że pomyślałem o wywiadach technicznych. Miałem kilka pytań i chciałem zadać je na tym forum -

1. Czy naprawdę można ocenić czyjąś zdolność techniczną w ciągu pół godziny? Szczerze? A może to tylko rzut kostką?

2. Czy pytania podczas wywiadu technicznego mierzą zdolność rozwiązywania problemów? Ten punkt jest bardzo dyskusyjny? Jako doktorant wiem, że matematyczne rozwiązywanie problemów polega na rozwiązywaniu problemów, o których nigdy wcześniej nie słyszałeś. Z drugiej strony pytania takie jak - scalanie dwóch połączonych list w posortowanej kolejności lub drukowanie wszystkich elementów drzewa binarnego na poziomie k-tego stają się „zwykłymi ćwiczeniami”, gdy ktoś już zobaczy rozwiązanie lub rozwiąże problem?

3. Czy ludzie, którzy wychodzą w tych rozmowach z latającymi kolorami, stają się świetnymi programistami? Czy nadal projektują eleganckie silniki gier, biblioteki graficzne, piszą szybkie ramy do łączenia widelców? Czy istnieją dowody wskazujące na pozytywną korelację między dobrym działaniem w wywiadach technicznych a faktyczną umiejętnością programowania? Czy te wywiady są bardziej nastawione na znalezienie osoby typu „załatwianie spraw” (Spolsky)?

Mogę się założyć, że wielu naukowców publikujących przełomowe pomysły w - ICML, VLDB, Mobicom - obleje te wywiady. Ale zapewniam cię, że są jednymi z najmądrzejszych ludzi, których znajdziesz na tej planecie.

Jestem głównie w środowisku akademickim (student) - dlatego bardzo docenię spostrzegawczość kogoś po drugiej stronie ogrodzenia. Ktoś, kto faktycznie przeprowadza te wywiady?

[Ok wszyscy. Dzięki za wszystkie miłe i przemyślane odpowiedzi. Ponieważ nie chcę zadawać innego pytania, poproszę o odpowiedź na to pytanie.

Załóżmy, że kandydat X ma dobre publiczne portfolio prac, w których wniósł wkład w jakiś znany projekt open source, w którym - możesz faktycznie przejść i zweryfikować jego łatki, zweryfikować błędy, które zamknął i spojrzeć na projekty, które stworzył. W takim przypadku pytaniem jest, ile wagi chcesz poświęcić jego publicznie dostępnej / weryfikowalnej pracy w porównaniu do tego, jak dobrze radzi sobie z odpowiedzią na bardzo wymyślne pytanie z drzewa binarnego w czasie krótszym niż 15 minut?]

Weź pod uwagę, że...

1. Głównym celem procesu rozmowy kwalifikacyjnej nie jest ustalenie absolutnej prawdy o osobistej zdolności każdego z rozmówców, ale wybranie kilku kandydatów z wielu.
2. Zatrudnianie złego programisty jest DUŻO, DUŻO droższe niż przekazywanie dobrego.

Często zdarza się, że podczas rozmowy kwalifikacyjnej podejmowane są niedoskonałe skróty (takie jak quizy techniczne), ponieważ, jak wspomniałeś, nie ma idealnego procesu oceny osoby w ciągu 30 minut. Ale ponieważ większość nie ma luksusu, aby pracować z tobą ramię w ramię, powinieneś po prostu zaakceptować, że to jest to, gra w szanse, w którą wszyscy grają.

Czy naprawdę można ocenić czyjąś zdolność techniczną w ciągu pół godziny?

Nie dokładnie. Możliwe jest wyeliminowanie ludzi, którzy nie mogą w ogóle programować, i tych, którzy nie potrafią wyjaśnić tego w swoim CV. Poza tym zwykle staram się po prostu ocenić ogólną inteligencję i zainteresowanie w tej dziedzinie. Trudno jest dalej komentować swoją sytuację, nie wiedząc o problemie, który zostałeś poproszony o rozwiązanie.

Czy pytania podczas wywiadu technicznego mierzą zdolność rozwiązywania problemów?

To nie jest cel moich pytań technicznych. Zamiast tego próbuję odkryć, czy kandydat rozumie podstawy informatyki. Aby ocenić zdolność rozwiązywania problemów, proszę kandydata, aby opowiedział o interesującym problemie, nad którym pracowali.

Czy ludzie, którzy wychodzą w tych rozmowach z latającymi kolorami, stają się świetnymi programistami? Czy te wywiady są bardziej nastawione na znalezienie osoby typu „załatwianie spraw” (Spolsky)?

O to chodzi. Wielkość jest rzadka. Cieszę się, że znalazłem kogoś kompetentnego.

1. Tak. Tak szczerze Nie oznacza to, że 30 minut to wystarczający czas, aby uzyskać pełny obraz możliwości danej osoby. Zadaniem ankietera jest zrobienie tego, aby dowiedzieć się, kim jest i co może zrobić. Znalezienie ludzi, którzy włożyli w swoje CV coś, czego tak naprawdę nie wiedzieli, jest proste. Dowiedzenie się dokładnie, co potrafi rozmówca, w tym wszystkich jego umiejętności i mocnych stron, nie jest.

2. Tak. Pozwalają ci zobaczyć, jak myśli rozmówca. Uzyskanie poprawnej odpowiedzi nie zawsze jest konieczne. Patrzenie, jak ktoś zmaga się z problemem, z którym się boryka, jest tak samo korzystne, jak patrzenie, jak ktoś poprawnie rozwiązuje problem bez większych problemów. Zawsze zadaję pytanie, które moim zdaniem rozmówca może nie być w stanie udzielić odpowiedzi.

3. Nie znam żadnego empirycznego dowodu, który mówi, że wywiady techniczne znajdują najlepszych kandydatów, ale to najlepsza rzecz, jakiej próbowałem. Różni ludzie są dobrzy w różnych sprawach, a uzyskanie poprawnych odpowiedzi technicznych nie jest jedyną rzeczą, która decyduje o tym, czy ktoś zostanie zatrudniony. Bardzo ważne jest również dobre dopasowanie do firmy.

W oparciu o twoje pytanie, myślę, że najważniejszą rzeczą, którą musisz zrozumieć, jest to, że dni jasno określone informacje zwrotne, takie jak ocena listowa, już minęły. Uzyskanie właściwej odpowiedzi to tylko część wyniku. Równie ważne jest pisanie dobrego kodu, przekazywanie pomysłów i słuchanie innych. Te obszary są jednak bardziej subiektywne i należy je traktować jako takie.

Podobnie jak w przypadku rozwiązania problemu, cofnij się o krok i oczyść głowę. Dużo się dzieje w wywiadzie i ankieter wie, że nie jest to idealny system. Starają się robić wszystko, co w ich mocy, dla firmy, tak jak Ty starasz się zrobić dla siebie najlepiej.

W ciągu pół godziny możesz ocenić, że zdolność techniczna danej osoby jest co najmniej tak dobra, jak x. Oznacza to, że ich zdolność może być wyższa, niż wykazali, ale możesz być całkiem pewien, że nie jest gorzej. Jeśli x jest wyższy niż twoje wymagania, zatrudniasz je. Tak, niesprawiedliwe jest wykazanie poniżej swoich umiejętności. Wszystko, co mogę powiedzieć, to być lepszym w demonstracji.

Gdyby ktoś zgrzeszył praktycznie zapamiętaną odpowiedzią, dałbym mu trudniejszy problem. W środowisku akademickim zapamiętywanie jest ważną umiejętnością. W pracy jest to najczęściej zbędne, gdy masz tam Google.

Widząc, jak zatrudniani są najlepsi programiści, można bezpiecznie założyć, że w pewnym momencie przeszli rozmowę o pracę. Nie, nie wiesz, czy ktoś będzie świetnym programistą po półgodzinnym wywiadzie. Na szczęście większość firm nie potrzebuje świetnych programistów. Dobrze sobie radzą z solidnymi, niezawodnymi programistami, którzy nie boją się wykonywać zadań poza swoją strefą komfortu.

Powodem, dla którego przełomowi myśliciele mogą oblać rozmowy kwalifikacyjne, jest to, że okazje do rozwiązywania krzykliwych, przełomowych problemów są bardzo rzadkie, a ty zaufasz, że rozwiążesz je dopiero po tym, jak udowodnisz, że potrafisz rozwiązać przyziemne, ale trudne problemy koledzy nie może, na przykład dlaczego oprogramowanie ulega awarii, gdy osiąga ponad 16% obciążenia.

Bardzo niewiele osób wie, czy ich techniki wywiadów naprawdę działają, ponieważ nigdy nie dowiadują się więcej o tych, którzy zawiedli. Ale kiedy nic nie obala ich hipotezy, przyjmują to za potwierdzenie, że są prawdziwe. Jest więc określony element rzucania kostkami.

Gdyby teorie ekonomiczne, według których rynki były racjonalne i wydajne, byłyby prawdziwe, wówczas firmy szukałyby osób, które były kiepskie podczas rozmowy kwalifikacyjnej w sposób, który nie pogorszyłby ich w ich pracy. Tak więc ktoś, kto nosił źle dopasowany garnitur, spocony, wyglądał na bardzo zdenerwowanego i miał problemy z robieniem problemów technicznych pod presją rozmowy kwalifikacyjnej - jeśli istniałyby dowody z zewnątrz, mogłyby sprawić problemy techniczne, a presja w pracy nie była podobna do tych rozmowy kwalifikacyjnej (jak zwykle nie są) - stanowiłaby najlepszą szansę firmy na pozyskanie kandydata lepiej niż mogłaby przyciągnąć i działałaby odpowiednio. (Think Money-ball dla świata korporacji). Ostatecznie tendencyjność wywiadu zniknie.

W praktyce jest to sprzeczne z ludzką naturą. Ankieterzy lubią pewnych siebie ekstrawertów, bez względu na stanowisko, a nawet jeśli wywiad techniczny dostarcza gorszych informacji niż CV i referencje (jak być może w twoim przypadku), wezmą to pod uwagę.

Co do twoich pytań:

1. Nieco. Testy mają słaby stosunek sygnału do szumu, ale można je dostroić, aby wyeliminować całkowicie niewykwalifikowane kosztem wywiadów wykwalifikowanych, ale złych w sprawach technicznych.

2. Zobacz nr 1. Część hałasu wynika z różnic w tym, czy ludzie widzieli problem wcześniej.

3. Zobacz nr 1. Prawdopodobnie istnieje niewielka dodatnia korelacja między tymi testami a byciem świetnym programistą.

Moja rada - zapoznaj się z przykładowymi pytaniami technicznymi, aby uzyskać podstawową znajomość. Pamiętaj, że to trochę rzut kostką, więc podczas rozmowy staraj się być pewny siebie. Jeśli potrafisz wyjaśnić, co myślisz, nie odrywając się od myślenia, zrób to. Jeśli to naprawdę idzie źle, przyznaj, że denerwujesz się podczas wywiadów i daj im znać, że wydaje się, że to coś, z czym normalnie nie miałbyś problemów - prawdopodobnie podając przykład podobnego, ale trudniejszego problemu, który rozwiązałeś.