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.
Odpowiedzi:
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.
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”.
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.
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ę :)
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:
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.
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).
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ś.