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

131

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.

gius
źródło
3
<żart> Aby rozpoznać dobrego programistę, zawsze używam The Dress Programmers jako miernika. ;-) </joke>
Galwegian
7
Mam około 6 stóp, 185 funtów., Ogoloną głowę i kozią bródkę. Mam na sobie Chucka Taylorsa i niebieską koszulkę na białym ocieplaczu. Proszę, głosujcie na mnie łagodnie - odpowiedziałem na pytanie. :)
MusiGenesis,
6
Powiązane lub powielone: programmers.stackexchange.com/questions/4614/…
Maniero
1
oto inne spojrzenie na temat - Jak przeprowadzić wywiad z programistą
2
To pytanie dobrze pasowało do tej witryny w 2008 roku, kiedy zostało zadane. Pięć lat. Pięć lat później Prog.SE zmieniło się w SO2, duplikat.
Warren P

Odpowiedzi:

157

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.

Jon Skeet
źródło
3
Świetne pomysły - szczególnie projekty hobby i problemy z ich ulubionym językiem wydają mi się naprawdę dobre. Powinno ujawnić więcej na temat ich związku z programowaniem. Blog jest również dobrym pomysłem. Niestety zwykle nie mają bloga :-(. Dziękuję ...
25
Pasja niekoniecznie przekłada się na profesjonalizm lub pracę zespołową. Mogą po prostu chcieć kodować to, co jest fajne / zabawne, a nie to, co wymaga kodowania.
22
@Preston: Chociaż z pewnością jest to prawdą w teorii, nie spotkałem nikogo, kto byłby pasjonatem, który nie byłby szczęśliwy z powodu chrząkania. Poznałem koderów prima donna, którzy myślą, że są ponad to, ale generalnie nie są pasjonatami. Testowanie profesjonalizmu i tak jest dość trudne ...
Jon Skeet
36
SPRAWDŹ ICH
83

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.

Hamish Smith
źródło
2
Zatrudnianie dobrych ludzi jest trudne. :)
ostateczna przyczyna
7
Pytania na ekranie telefonu zaczynają się dobrze, ale potem coraz więcej pytań staje się śmiesznych. Nie sądzę, żeby dobry programista musiał wiedzieć 2^16na pamięć. A wersja szybkiej ścieżki na dole jest po prostu kiepską parodią.
Peter
Linki SO wydają się uszkodzone (brak wyników lub 404).
Stijn Geukens,
@StijnGeukens, wygląda na to, że ten tag został przeniesiony do inżynierii oprogramowania. Zaktualizowałem link.
Hamish Smith,
47

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. :-)

Adam Liss
źródło
4
Pamiętam mój pierwszy wywiad programowy, w którym poproszono mnie o przejrzenie wydrukowanego kodu. Na górze były komentarze wyjaśniające, co zrobił kod. Sprawdziłem to, czytając kod, a następnie w zasadzie czytałem komentarze dosłownie i powiedzieli „Bardzo dobrze!” Powiedziałem: „tak, to prawie tak mówi tutaj, w bloku komentarza”. Byli dość zawstydzeni.
Dustin
@Dustin IMO zostawienie komentarzy w kodzie, który kandydat powinien sprawdzić, było dość nieostrożne (?) Z ich strony. To w zasadzie daje im darmową odpowiedź lub zamieszanie, w zależności od tego, co zawiera komentarz.
cst1992
39

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 .

rev Eigir
źródło
3
Masz całkowitą rację co do googlowania - dobry programista nie musi wiedzieć wszystkiego, ale powinien być w stanie szybko się dowiedzieć.
2
„ktoś, kto zna się na programowaniu i ma dobre umiejętności ludzi”… i to jest problem - nie jest łatwo go znaleźć. Zwykle mają tylko jedną z nich. Dlatego staram się poprawić obie gałęzie :-).
7
Posiadanie umiejętności wielkich ludzi zwykle stoi w sprzeczności z byciem abstrakcyjnym myślicielem. Bycie abstrakcyjnym myślicielem zwykle stoi w sprzeczności z byciem dobrym programistą.
Tomalak,
7
Gius: Jeśli masz szczęście, znajdziesz programistów, którzy rozumieją, że ludzie są komputerami biologicznymi i dlatego są zainteresowani tym, jak pracujemy / myślimy. Ci często rozwijali także umiejętności dobrych ludzi, ponieważ są zainteresowani doskonaleniem się także w tym obszarze.
Eigir: Zgadzam się. Ale jak ktoś już tu wspomniał - jeśli kogoś znajdziesz, trafiłeś w dziesiątkę ;-). Mam nadzieję, że będziemy mieli szczęście.
23

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.

Doktor Jones
źródło
1
Jeśli nie znoszą pracy z innymi ludźmi, to jak nazwać ich „najlepszym programistą na świecie”? Programowanie z pewnością nie polega tylko na rozmowie z kompilatorem i wycinaniu kodu, większość zadań programisty / programisty wymaga pewnej współpracy.
Christopher Creutzig
Rozumiem twój punkt widzenia, ale w tym kontekście „programowanie” polega tylko na kodowaniu, w przeciwnym razie użyłbym terminu „programista”. Terminy „programista” i „programista” nie są synonimami.
Doktor Jones
6
Nie, w rzeczywistości wiele osób nie może nauczyć się być lepszymi programistami. I szczerze mówiąc, jeśli mają 5-10 lat doświadczenia, oczekiwałbym, że już wiedzą, jak wykonywać swoją pracę . To NIE jest odpowiedź na pytanie; mówisz tylko: „identyfikujesz dobrych programistów, nie dbając o to, czy są dobrymi programistami”
Benubird,
1
@Benubird miałem na myśli, że umiejętności interpersonalne mogą być ważniejsze niż surowy talent programistyczny, szczególnie jeśli chodzi o pracę w zespole. Nie opowiadam się za zatrudnianiem ludzi, którzy nie mogą wykonywać swojej pracy. Nie warto zatrudniać programisty „gwiazdy rocka”, jeśli nie będą dobrze pracować w twoim zespole. To nie jest warte tarcia i kłopotów.
Doktor Jones
@DoctorJones i ja zgadzamy się z tobą; wcale się nie mylisz. Po prostu odpowiedź, której udzieliłeś, nie jest odpowiedzią na pytanie „Jak rozpoznać dobrego programistę?”
Benubird,
16

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.

Manoj
źródło
Podoba mi się pomysł, aby faktycznie zlecić im kodowanie (można to zrobić przed rozmową kwalifikacyjną), a następnie użyć kodu jako tematu podczas rozmowy kwalifikacyjnej. Niech wyjaśnią, dlaczego wybierają różne rozwiązania i tak dalej ...
Ogólnie pomysł na temat kodowania jest bardzo dobry. Obawiam się jednak, że stworzenie zadania, które naprawdę pokaże, co jest w nich, jest dość trudne - i dobry temat na kolejną dość długą (ale bardzo mizerną!) Dyskusję. ... czy powinniśmy tutaj zadawać pytanie? ;-)
Lista ich ulubionych blogów byłaby świetnym wskaźnikiem!
6
Miałem wywiad z programistą. Ankieter nalegał, żebym rozmawiał z nim przez moje rozwiązanie. Przedstawiłbym pomysł, on zasugerowałby, w jaki sposób może zawieść. W ten sposób nauczył się, jak radzę sobie z problemem. To był najtrudniejszy i najbardziej uczciwy wywiad, jaki kiedykolwiek miałem.
@gius - Myślę, że powinieneś zadać to pytanie.
Manoj,
16

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.

Wolf5
źródło
2
Inspirujące pytanie - „Dlaczego kształciłeś się jako programista?”
5
Prędzej czy później tracimy wszystkie zasoby. Tylko skały są wieczne.
Carl Manaster,
1
Trochę krótkowzroczny. „Schlubladendenken”
6
Głosowałbym za tym, gdyby nie „Prawdopodobnie nie chcesz programisty, który ma ambicje lidera”. Pracownicy, którzy chcą wziąć na siebie obowiązki, są niezbędni i powinieneś znaleźć sposoby na ich awans w swojej organizacji.
Danny Varod
5
Masz inną definicję „hakera” niż ja. „Hakerem” jest dla mnie ktoś, kto „hakuje” rzeczy tak szybko, jak to możliwe, dopóki nie osiągną rezultatu (swego rodzaju), ale pozostawił po sobie ślad zniszczenia i przerażenia, ponieważ nie zastosował jednej najlepszej praktyki. „Haker” jest nieprofesjonalny.
David Masters
7

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ć.

Svante
źródło
To świetny pomysł i chciałbym, aby to była standardowa praktyka. Jako osoba, która została zwolniona z kilku prac z powodu niedostosowania się do kultury firmy lub z powodu niewłaściwej oceny poziomu umiejętności, chciałbym najpierw przetestować wodę.
DarenW,
20
Problem polega na tym, że jeśli ktoś już ma pracę, nie może oderwać nawet tygodnia, aby przejść do pracy w innej firmie, aby dowiedzieć się, czy naprawdę ją dostał.
Cercerilla,
@Cercerilla Right! wystarczająco trudno jest nawet znaleźć czas na rozmowę kwalifikacyjną, a co dopiero mieć tydzień pracy dla nich.
eaglei22,
6

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.
Memento
źródło
3

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.

Silvercode
źródło
Podoba mi się pomysł patrzenia nie tylko na pracownika, ale także na własną organizację i procesy wewnątrz niej.
3

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…

Baba Smith
źródło
2

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ść).

Vinko Vrsalovic
źródło
1
Masz całkowitą rację, ale jeśli on nie jest dla ciebie dobry, nadal tracisz jedną lub dwie ćmy, jego pensję i pracę ludzi, którzy angażują go w twój projekt. Dobrze byłoby więc uniknąć takiej sytuacji.
3
Problem polega na tym, że dobrzy programiści mają prawdopodobnie inne oferty pracy i jeśli zaoferujesz im tylko pracę tymczasową na początku, mogą wybrać kogoś innego ...
@ Rexxar: Nadal odejdą, jeśli im się nie spodoba. Jest to po prostu bardziej uczciwe i szczere, że oferuje to w ten sposób, IMO. Przynajmniej dla mnie byłby to plus, a nie minus (biorąc pod uwagę, że jest to umowa krótkoterminowa i że na jej koniec staje się na stałe lub pożegnanie).
Vinko Vrsalovic,
3
Muszę nadal płacić rachunki, nigdy nie powinienem rozważać podjęcia pracy tylko za miesiąc i rezygnacji z stałej pracy. Jeśli jesteś bezrobotny lub masz bogatego małżonka, może to zadziałać. Innymi słowy, tracisz wiele dobrych kandydatów, ponieważ nie mogą sobie pozwolić na to, że nie okłamujesz ich, że zostali na stałe.
HLGEM
4
„Jeśli dana osoba jest warta swojej soli, nie sprzeciwi się” - cóż, ten programista powiedziałby „pieprzyć to” i znaleźć lepszą pracę.
gnasher729