Jak rozpoznać dobrego programistę? [Zamknięte]

Nasza firma szuka nowych programistów. I tu pojawia się problem - jest wielu programistów, którzy świetnie wyglądają na rozmowie kwalifikacyjnej, wydają się znać technologię, której potrzebujesz, i mają dobre przygotowanie do pracy, ale po dwóch miesiącach pracy okazuje się, że nie są w stanie pracować zespół, napisanie kodu zajmuje im bardzo dużo czasu, a ponadto wynik nie jest tak dobry, jak powinien.

Czy stosujesz jakieś sformalizowane testy (czy są jakieś?)? Jak rozpoznajesz dobrego programistę - i dobrą osobę? Czy są jakieś proste „dobre” pytania, które mogą ujawnić przyszłe problemy? ... czy chodzi tylko o twoje „odczucia” wobec osoby (tj. głównie twoje doświadczenie) i wypróbowanie jej / jej?

Edycja: Zgodnie z odpowiedzią Manoj, oto pytanie związane z zadaniem kodowania podczas rozmowy kwalifikacyjnej.

Poproś ich, aby porozmawiali o tym, co ich interesuje. Nie spotkałem się jeszcze z programistą, który jest naprawdę pasjonatem, gdy mówi o programowaniu, ale nie potrafi właściwie kodować. Oczywiście mogą istnieć - i twój wywiad powinien również sprawdzić kompetencje - ale pasja jest dobrym wskaźnikiem w moim doświadczeniu. (Pamiętaj, że to nie to samo, co możliwość „mówienia” w kontekście modnych słów).

Zapytaj ich, co im się nie podoba w ich ulubionym języku lub platformie. Jak mieliby to naprawić? Co chcieliby zobaczyć w następnej wersji? Czy mają projekty hobby? Jeśli mają blog, przeczytaj go. Sprawdź ich ogólną obecność online.

Zatrudnianie dobrych ludzi jest trudne .

Naprawdę popełniłem kilka błędów. Zaczynasz dużo bardziej ufać swojemu jelitowi po kilku pierwszych chwilach, kiedy nie ufasz mu i żałujesz.

Mam wielki szacunek dla pytań zadawanych przez Steve'a Yegge'a na ekranie telefonu i wykorzystałem to jako podstawę do przeprowadzania wywiadów z niektórymi osobami.
Myślę też, że stałem się lepszy w przeprowadzaniu wywiadów z ludźmi po przeczytaniu przewodnika Joela po wywiadach partyzanckich (teraz w wersji 3.0, która wyprzedza wersję internetową i wszystko inne, po prostu musi być dobra).

Istnieje również 57 innych pytań (na dzień 20.11.2008) na temat Inżynierii oprogramowania Stackexchange oznaczonych wywiadem, a niektóre z nich wyglądają bardzo trafnie, więc sprawdź je.

Jakieś pomysły:

• Zadaj kilka otwartych pytań z kilku różnych punktów widzenia:

  • Przejrzyj kod. Co zidentyfikowano? Błędy techniczne, niespójności stylu, komentarze, algorytmy, łatwość konserwacji itp.
  • Napisz kod. Szukaj procesu, kuloodporności, czytelności itp.
  • Utwórz projekt wysokiego poziomu dla małego systemu. Poszukaj zrozumienia problemu, podejścia, komunikacji, kompletności, szczegółów.
  • Opisz proces tworzenia oprogramowania. Szukaj projektu, współpracy, przeglądu, testowania, dobrych / złych nawyków i ogólnego doświadczenia.

• Wybierz coś - cokolwiek - kandydat twierdzi, że dobrze zna. Zadaj proste pytanie, a następnie, w oparciu o odpowiedź, zadaj kolejne, nieco bardziej szczegółowe i kontynuuj „kopanie”, aż osiągniesz limit wiedzy kandydata. To daje wyobrażenie o:

  • Uczciwość: czy on / ona wie tyle, ile twierdzi?
  • Głębokość wiedzy: jak dobrze się uczy?
  • Komunikacja: jak dobrze wyjaśnia ci coś nieznanego? Czy proces myślowy jest logiczny?
  • Reakcja na stresujące sytuacje: jak ciężko pracuje, aby odpowiedzieć? Czy on / ona to fałszuje? Czy nieuniknione „nie wiem” jest łatwe czy trudne?

• Zapytaj, jak kandydat radził sobie z różnymi sytuacjami z poprzednich prac: praca zespołowa, zaległe projekty, debugowanie itp . Czy odpowiedzi są pozytywne czy negatywne? Namiętny? Inteligentny? Arogancki?

Uważam, że najlepsi kandydaci są entuzjastyczni, doświadczeni, pewni siebie, ale uprzejmi i, co najważniejsze, obecni . Musisz wiedzieć, że ktoś jest w środku. :-)

Aby rozpoznać dobrego programistę, musisz być dobrym programistą. Oznacza to, że musisz bardzo dobrze znać programowanie, aby przejrzeć to, co zostało powiedziane i zrobione podczas wywiadu, i musisz wiedzieć, jakie pytania zadać.

Widziałem kandydatów, którzy udzielili złej odpowiedzi podczas rozmowy kwalifikacyjnej, ale ich wyjaśnienie pokazało, że znali temat (a zatem mogli łatwo uzyskać prawidłową odpowiedź, przeszukując sieć). Aby to zobaczyć, musisz bardzo dobrze znać temat, o który pytasz.

Inną rzeczą jest unikanie pytań o szczegóły, które można łatwo znaleźć w Google. To pytanie pokazuje tylko, jak dobry jest kandydat, aby pamiętać rzeczy, a nie, jeśli naprawdę ma wiedzę i zrozumienie, których szukasz.

Radzę uzyskać pomoc od kogoś, kto zna się na programowaniu i ma dobre umiejętności, aby pomóc w rozmowach kwalifikacyjnych.

Edycja: Tutaj też napisałem komentarz na temat wywiadów .

Pamiętaj, że umiejętność programowania to nie wszystko. Możesz mieć najlepszego programistę na świecie pracującego dla ciebie, ale jeśli nie znoszą pracy z innymi ludźmi, nie okażą się bardzo przydatni.

Osobowość programistów powinna znajdować się wyżej na liście, niż wydaje się, że większość pracodawców ją ocenia. W moim obecnym miejscu pracy bardzo ostrożnie podchodzą do zatrudniania właściwego rodzaju osób.

Ludzie na ogół mogą nauczyć się być lepszymi programistami, ludzie na ogół nie mogą nauczyć się być lepszymi ludźmi.

Zmodyfikuj je. Podaj problem, który można rozwiązać na przykład za 4 lub 5 godzin, i sprawdź kod pod kątem dokumentacji, stylu kodowania, tego, jak zaplanował rozwiązanie, zanim zacznie kodować itp. Nie musi tak naprawdę rozwiązywać problemu. I jak wspomniał Jon Skeet, niech rozmawiają o programowaniu, wybranym języku i podobnych rzeczach. Możesz rozpoznać pasję u dobrego programisty. Zapytaj, ile stron związanych z programowaniem śledzą, na przykład przepływ zasobów. Blogi, które obserwują, mogą być dobrym wskaźnikiem.

Podoba mi się pasja. Uważam, że musisz być pasjonatem tego, z czym pracujesz, aby być w tym bardzo dobrym.

Dobry programator z boku oprócz pracy (przynajmniej raz na jakiś czas). Lubi rozwiązywać problemy programistyczne. A kiedy nie może znaleźć programu, który zaspokoi określoną potrzebę w domu, zazwyczaj sam spróbuje ją rozwiązać.

Ale istnieje kilka rodzajów programistów.

• Masz te, które uwielbiają dokumentować. Osobiście nie lubię dokumentować. Ale dokumentowanie tego, co jest zrobione, może być ważne.
• Masz „hakerów”. Te, które są bardzo zainteresowane rozwiązywaniem złożonej układanki, w której gdybyś szukał go w Google, prawdopodobnie nie znalazłby rozwiązania. Mogą rozwiązać „każdy” problem, o ile dysponują narzędziami, których potrzebują.
• Masz tych, którzy kształcą się na programistów tylko dlatego, że rynek był dobry na zatrudnienie do programowania. Są one zwykle mierne, ponieważ brakuje im pasji.
• Masz tych, którzy świetnie się komunikują i „potrafią rozwiązać wszystko”, ale kiedy dostaną pracę, powieszą się na wszystkich, aby uzyskać pomoc w rozwiązaniu problemu.

Jeśli znajdziesz „hakera”, który również bardzo dobrze dokumentuje i ma doskonałe umiejętności komunikacyjne, uwierzyłbym, że trafiłeś w dziesiątkę.

Aha, i ostatnia rzecz. Prawdopodobnie nie chcesz programisty, który ma ambicje lidera, ponieważ użyje programowania tylko do uruchomienia. Oznacza to, że wcześniej czy później stracisz ten zasób.

Pytanie, które zadałbym przy zatrudnianiu programisty, brzmiałoby: „Dlaczego kształciłeś się jako programista?”. Byłoby to gratisowe rozdanie, gdyby się tam zawahali.

To jest moja opinia.

Mój przyjaciel pracuje w firmie, w której ma dodatkowy krok w procesie rekrutacji: po wstępnej selekcji i rozmowie kwalifikacyjnej kandydat musi „przetestować pracę” przez kilka dni. Powiedział mi, że chociaż jeden kandydat miał każdy umiejętności i talent potrzebne, nie zatrudnić go, ponieważ był typu A nie jest to miła osoba pracować.

Bardzo trudno jest rozpoznać programistę na podstawie samej rozmowy kwalifikacyjnej.

Niektóre rzeczy, które decydują o tym, że ktoś jest dobrym programistą, to:

• zdolny do pracy w zespole
• pisze dobry kod, który jest zrozumiały i łatwy w utrzymaniu
• jest w stanie poznać nowe technologie

Masz więc kilka wskazówek, o których możesz dowiedzieć się w wywiadzie:

• Czy kandydat zna jeden język technologii / programowania, czy zna wiele? Jeśli zna różne języki, wydaje się, że jest w stanie uczyć się nowych rzeczy i prawdopodobnie wie o wadach swojej preferowanej technologii / języka. Poproś o wiedzę oprócz technologii, z której korzystasz w swojej firmie.
• Zapytaj o projekty, w których już pracował, szczególnie projekty hobbystyczne i open source. Projekty hobby pokazują, że lubi programować i robi to nawet w wolnym czasie (i w ten sposób podnosi swoje umiejętności). W projekcie typu open source możesz wyszukać kod, który napisał. Jeśli w projekcie uczestniczy więcej niż jedna osoba, możesz uzyskać wskazówki na temat jego umiejętności zespołu. W projekcie systemu operacyjnego możesz przejrzeć archiwa listy mailingowej, aby dowiedzieć się więcej.

Możesz przeprowadzić test w wywiadzie.

Ale wiele razy występuje również problem z samym środowiskiem pracy. Z pewnością może nie być tak w twojej organizacji, ale w branży oprogramowania dość często zdarza się, że dług technologiczny staje się zbyt duży. Kiedy zatrudniasz nowych ludzi, nie ma wielkiego znaczenia, czy są dobrzy, czy nie, z powodu długu. Maksymalizacja czytelności i zrozumiałości kodu programu pomaga początkującym w pracy.

Również wiele osób jest zdolnych do współpracy, ale czasami nie ma możliwości współpracy. Na przykład, jeśli wszyscy ludzie są programistami, powinni wykonywać swoją pracę. Cóż, robią. Ale czy masz architekta, który kieruje projektem deweloperskim i organizuje spotkania itp.? Normalni programiści mogą czuć, że nie mają niezbędnego mandatu do rozpoczęcia spotkań i mogą myśleć, że przerywanie innym od czasu do czasu nie jest właściwą drogą.

Komunikacja ze sobą nie powinna być celem końcowym. Im mniej potrzeba komunikacji, tym lepiej, ale tylko wtedy, gdy jest to możliwe. Mniej staje się możliwe, jeśli masz architekta. Całkowita ilość komunikacji może pozostać na dobrym poziomie, ale uzyskasz więcej wyników dla tej samej ilości komunikacji.

najpierw zaczynam od zwykłych wywiadów, uważam za bardzo ważne, aby sprawdzić, czy osoba przede mną jest czegoś warta, a także określić jej umiejętności i wiedzę.

Następnie używam kilku technik w dziedzinie Java, takich jak omawianie niektórych zasad, głównie zaczerpniętych z Effective Java.

Na tym etapie, kiedy myślę, że mogę mieć dobrego programistę przede mną, daję mu kawałek kodu, aby go przejrzał. Chcę zobaczyć, że może wskazać niebezpieczne części kodu, podać pewne wskazówki dotyczące ulepszeń, znaleźć pułapki w wydajności na wiele wątków ORAZ że może odróżnić ważne uwagi od „uwag smakowych”. Wszystko to pomaga mi znaleźć bardziej sprawnego pracownika.

ale w końcu zawsze pamiętam, że zatrudnianie jest rodzajem hazardu… bardzo, bardzo trudnym do przewidzenia…

Wiem, że to nie odpowiada na to, o co pytasz, ale zalecam, jeśli pozwalają na to przepisy, zawsze najpierw zatrudnij tymczasowo (dwa tygodnie lub miesiąc, w zależności od pracy). Jeśli dana osoba jest warta swojej soli, nie sprzeciwi się, poza tym jest to zabezpieczenie dla was obojga (możesz pozwolić mu odejść, a może nie polubić pracy i odejść).