Jakich technik używasz podczas wywiadów z programistami? [Zamknięte]

28

Zdaję sobie sprawę z tego, że odbyło się wiele dyskusji na temat tego rodzaju rzeczy i często zmieniają się one w dogmaty wokół tego, czy zadajesz pytania typu „100 logicznych piratów”, czy też zachęcasz ich do napisania „fizycznego szumu”.

Interesuje mnie, jakie techniki i pytania były dla Ciebie skuteczne podczas przeprowadzania wywiadów z potencjalnymi programistami.

Jedna technika na odpowiedź, abyśmy mogli głosować na nie.

Paddyslacker
źródło

Odpowiedzi:

21

Oprócz prawdziwych pytań technicznych i zazwyczaj na końcu wywiadu staram się poznać ich poziom zainteresowania branżą i jej kulturą, zadając pytania takie jak:

  • Czy widziałeś ostatnio coś, co uważasz za interesujące i które chciałbyś polecić innym programistom? Nowy język, narzędzie, platforma, technika, strona internetowa?

  • Czy możesz wymienić jakąś znaną osobę w naszej branży, której prace lubisz lub która jest dla Ciebie inspirująca i dlaczego? (programista, założyciel witryny, autor, mówca itp.)

  • Co teraz czytasz lub jaka była ostatnio czytana książka związana z oprogramowaniem?

  • Jakie strony związane z programowaniem często odwiedzasz?

Chociaż w ogóle brak odpowiedzi na te pytania (niestety zdarza się to bardzo często) nie oznacza dla mnie „braku zatrudnienia”, ale wiele mówią o tym, jak dana osoba podchodzi do zawodu programisty.

Sergio Acosta
źródło
4
Prawdopodobnie posunąłbym się nawet do stwierdzenia, że ​​jest to najważniejsza rzecz do oceny w każdym wywiadzie dotyczącym oprogramowania. Można argumentować, że pisanie kodu jest ważniejsze, ale ludzie, którzy opisywali coś podobnego niedawno lub na uniwersytecie, mogą zgadnąć, jak to zrobić, podczas gdy bardzo trudno jest udawać prawdziwe, prawdziwe zainteresowanie.
Mike B,
5
Nie dziwię się, że to popularna odpowiedź na tej stronie. Publiczność tutaj z definicji ceni sobie „kulturę programisty”. (Zgadzam się z odpowiedzią, ale spotkałem kilku doskonałych programistów, którzy nie zdadzą tego testu, zwłaszcza tych w ponad 40
osobowym
2
@AShelly: Tak, zgadzam się. Dlatego nie uważam tego pytania za niezbędne do odrzucenia lub zaakceptowania programisty. To tylko kolejna technika, której możesz użyć podczas rozmowy kwalifikacyjnej.
Sergio Acosta,
16

Niech piszą kod, prawdziwy kod.

Ankieter może pozwolić ci wybrać język programowania, w którym czujesz się najbardziej komfortowo, czy to C ++, Java, C # lub cokolwiek innego, i poprosić cię o rozwiązanie prostego problemu, np. Wykonanie pracy z łańcuchem lub podwójnie połączoną listą lub czymkolwiek. Jeśli masz problem z użyciem najlepszego języka do rozwiązania prostego problemu, oznacza to, że występuje problem. Zapoznaj się z postem na blogu Steve'a Yegge, a zwłaszcza z sekcją „Przygotowanie mentalne”.

grokus
źródło
6
Tak, ale nie za dużo.
Damovisa,
Pisanie prawdziwego kodu pomoże ci wejść do drzwi elitarnych firm produkujących oprogramowanie (Google, Amazon, Microsoft, ...) i możesz wybrać resztę.
grokus
3
Proszę wyjaśnić swoją odpowiedź. Co rozumiesz przez „prawdziwy” kod? Jaki kod nie jest „prawdziwy”?
MAK
+1 @MAK: Uzgodniony, jaki jest prawdziwy kod? Jeśli jest to kod, który zamierzasz wykorzystać w oprogramowaniu produkcyjnym ...
Steven Evers,
1
Zastanawiałbym się nad „prawdziwym kodem” jak proszeniem rozmówcy o napisanie funkcji „strdup ()”. Ma prawdziwe zastosowanie i ujawnia ich doświadczenie i podejście do takich rzeczy, jak zarządzanie pamięcią i obsługa błędów.
JBRWilkinson,
11

Niech kilka osób z twojego zespołu przeprowadzi z nimi wywiad osobno. Podziel się swoimi przemyśleniami później, nie rozmawiaj pomiędzy nimi, zanim je przesłuchasz. Rozmowa między nimi wpłynie na twój osąd i nie będziesz mieć niezależnych ocen.

Osoby techniczne, które przeprowadzają z nimi wywiad, zmuszają je do pisania kodu. W przypadku nietechnicznych nie próbuj zadawać pytań, z którymi nie masz doświadczenia. Upewnij się jednak, że masz co najmniej kilka osób przeprowadzających rozmowy kwalifikacyjne.

Wywiady nie powinny być prowadzone wyłącznie przez kierowników, powinny być niezwykle ważne dla każdego pracownika, z którym będą pracować w przyszłości.

Brian R. Bondy
źródło
2
+1 za „wywiady nie powinny być przeprowadzane tylko przez menedżerów”. Jeśli nowy najemnik nie będzie w stanie wyciąć kodu tak dobrze, jak ich koledzy, zespół będzie niepokojony.
JBRWilkinson,
7

Chciałbym, aby rozmówca wyjaśnił ich poprzednie projekty i to, co zrobili. Na podstawie tej odpowiedzi mogę zadać dalsze pytania: dlaczego zrobili coś w określony sposób, jak rozwiązali określony problem, jeśli wspomnieli o jednym, ale co najważniejsze, jaki był cel projektu i jaki problem biznesowy rozwiązał.

Robię to, aby sprawdzić, czy potrafią wyrazić w sposób, który pozwala mi zrozumieć, co robili, i sprawdzić, czy rozumieli, co robili.

Zaskakujące jest to, że ostatnie pytanie o cel projektu i rozwiązany problem biznesowy poruszyło wiele osób. Nie mają pojęcia DLACZEGO projekt, nad którym pracowali, został w ogóle zrealizowany. Jeśli nie wiesz, dlaczego Twój projekt istnieje, zastanawiam się, czy wnosisz rozwiązania, czy po prostu postępujesz zgodnie z instrukcjami.

(Pomyślałem, że wrzucam tę odpowiedź, ponieważ wszystkie pozostałe odpowiedzi mają charakter techniczny. Chcę, aby ludzie, którzy wiedzą, dlaczego rozwiązują problemy, które rozwiązują, w przeciwnym razie mają tendencję do rozwiązywania niewłaściwych problemów, których nie robi użytkownik końcowy ”. t obchodzi się :)

Sójka
źródło
6

Zapytaj ich o ważną decyzję architektoniczną

Na przykład. Oto program x, który wykonuje jednocześnie liczbę podzadań. Który byś wybrał, struktura wieloprocesowa lub wątkowa.

Jakie są zalety / wady obu. Jak dobrze by działały i jak można je wykorzystać do wykorzystania wielordzeniowej, wieloprocesorowej platformy, jakie są twoje osobiste preferencje? Osobiste uprzedzenia mogą pomóc w stwierdzeniu, czy kiedykolwiek musieli faktycznie zastosować tę wiedzę i dać im punkt wyjścia do podzielenia się swoimi doświadczeniami?

Istnieje wiele pytań, na które może odpowiedzieć ankieter:

  • TCP czy UDP?
  • Język dynamiczny czy statyczny?
  • Aplikacja monolityczna czy wiele mniejszych aplikacji?
  • Czego byś użył do komunikacji międzyprocesowej?
  • Procedury przechowywane lub ORM?

Większość z tych tematów obejmuje typy, które wymagają dogłębnej wiedzy o tym, jak / dlaczego system komputerowy działa tak, jak działa. Wszystkie są problemami / rozwiązaniami problemów, na które nie ma jednoznacznej odpowiedzi, więc dają wyobrażenie o tym, jak dobrze dana osoba jest w stanie dostosować się lub pokonać stojące przed nią wyzwania. Nie jest to rodzaj koncepcji, które można łatwo wybrać bez faktycznego doświadczenia.

Uwaga: Konieczne jest także, aby wnioskodawca napisał kod pesudo, ale ta odpowiedź jest już zajęta.

Evan Plaice
źródło
Jedynym zastrzeżeniem, które dodam do tego, jest upewnienie się, że pytanie nie jest związane z domeną firmy przeprowadzającej wywiad.
JBRWilkinson
1

Po prostu daj im trochę podstawowego kodu do zrobienia na tablicy - np. Implementacja listy powiązanej, sortowanie lub coś podobnego.

Możesz ocenić ich wygodę w posługiwaniu się językiem bez pomocy kompilatora i możesz ocenić ich proces myślowy (szczególnie jeśli nigdy nie wdrożyli czegoś takiego - większość „nowych” programistów nigdy tego nie zrobiła).

Josip Medved
źródło
8
Nie zgadzam się. Powiązane listy i sortowanie są dość dobrze znanymi problemami z typowym problemem. Każdy, kto go napisał, wie, jak działa, ale większość ludzi nie zawraca sobie głowy pisaniem własnego, ponieważ większość języków już dobrze sobie z tym radzi.
Evan Plaice,
Zgadzam się z Evanem. W praktyce często wystarczy zdawać sobie sprawę z wydajności różnych algorytmów sortowania / wyszukiwania i podstawowych struktur danych. Umiejętność ich implementacji jest zgrabna, ale ostatecznie bezużyteczna. Ponadto w większości zadań programistycznych ważniejsze jest, aby wiedzieć, jak wybrać odpowiedni szkielet / bibliotekę dla zadania, niż jak zaimplementować QuickSort w trzech liniach.
Alan Plum
0

Porozmawiaj, pozwól mu dryfować i meandrować techniczną i profesjonalną drogą, a po drodze szukaj wnikliwych lub głupich komentarzy. Dzięki temu uzyskasz 3/4 potrzebnych informacji z wywiadu, oceny: umiejętności i osobowości ludzi, ogólnej inteligencji oraz zgrubnej oceny umiejętności technicznych.

Używaj „pytań” z wywiadu jako elementów rozpoczynających temat i utrzymywania konwersacji związanych z tematami technicznymi - konieczne może być od czasu do czasu resetowanie konwersacji (np. Ćwiczenie kodowania) w celu odpowiedniego zbadania obszarów zainteresowania / zainteresowania.

Prawdziwą sztuczką w tej technice jest upewnienie się, że wszystko mówią, w przeciwnym razie ryzykujesz pozytywną ocenę, ponieważ sprawili, że czujesz się mądry, słuchając / zgadzając się ze wszystkim, co powiedziałeś.

Mark Brackett
źródło