Joel on Software

Joel on Software   Joel o programowaniu

 

Inne artykuły serwisu "Joel on Software" po polsku

Inne artykuły serwisu "Joel on Software" po angielsku

Napisz do autora (tylko po angielsku)

 

Partyzancki poradnik rekrutacji


Joel Spolsky
Przełożył Andrzej Kocoń
Korekta Andrzej Swędrzyński
23 marca 2000

Krytyczną sprawą dla Fog Creek Software jest zatrudnianie właściwych ludzi. Osoby pracujące w naszej branży można podzielić na trzy kategorie. Na jednym końcu skali są niedoważone masy, którym brakuje nawet najbardziej podstawowych umiejętności zawodu programisty. Łatwo jest ich rozpoznać i wyeliminować na podstawie resumé, ewentualnie dwóch lub trzech krótkich pytań. Na przeciwległym końcu są wybitne supergwiazdy, które dla zabawy podczas weekendu piszą kompilatory Lispu w asemblerze na Palm Pilota. Pośrodku jest spora liczba „obiecujących”, którzy być może coś mogą wnieść do firmy. Sztuka polega na odróżnieniu supergwiazd od tych obiecujących, ponieważ w Fog Creek Software pracują tylko supergwiazdy. Oto techniki służące do tego celu.

Przede wszystkim kardynalne kryterium nr 1 przyjęcia do Fog Creek Software:

Bystry oraz
Realizujący Wyznaczone Cele

 

I tyle. To wszystko, czego szukamy. Warto to zapamiętać i powtarzać to sobie każdego wieczoru przed snem. Naszym celem jest zatrudnienie ludzi z nastawieniem, a nie z jakimiś specjalistycznymi umiejętnościami. Każda specjalistyczna  umiejętność, którą ludzie mogliby wnieść jako wkład w przedsięwzięcie, tak czy owak będzie za kilka lat technologicznie przestarzała, dlatego lepiej jest pozyskiwać pracowników zdolnych do nauczenia się dowolnej technologii, niż takich, którzy akurat w danym momencie znają SQL.

Znaczenie określenia bystry nie jest łatwe do zdefiniowania, lecz w miarę zapoznawania się z repertuarem pytań stawianych w trakcie rozmowy kwalifikacyjnej pokażę, jak zidentyfikować Bystrą osobę. Nie mniej ważną cechą jest Realizowanie Wyznaczonych Celów. Ci, którzy są Bystrzy, lecz nie Realizują Wyznaczonych Celów, często mają doktoraty i pracują w wielkich instytucjach, gdzie nikt ich nie słucha z powodu ich kompletnej niepraktyczności. Będą ślęczeć nad jakimś akademickim zagadnieniem, zamiast dotrzymać terminu. Ten gatunek ludzi łatwo rozpoznać po słabości do wskazywania na teoretyczne podobieństwa między całkowicie rozbieżnymi pojęciami. Powiedzą na przykład, że „arkusze kalkulacyjne są po prostu specjalnym przypadkiem języka programowania”, po czym poświęcą tydzień na napisanie niesamowitego, błyskotliwego artykułu o właściwościach arkuszy jako języków w ujęciu teoretycznej lingwistyki komputerowej. Imponujące, ale nieprzydatne.

Z drugiej strony ci, którzy Realizują Wyznaczone Cele, lecz brak im bystrości, narobią mnóstwo bezmyślnych głupstw, po czym ktoś inny będzie musiał zrobić porządek z tym bałaganem. Tacy stanowią obciążenie dla firmy, gdyż nie tylko nie wnoszą do niej niczego, ale jeszcze marnotrawią czas dobrych pracowników. Są to ludzie, którzy na przykład zamiast napisać procedurę, kopiują duże fragmenty kodu, ponieważ to też załatwia sprawę. Owszem, tyle że w „niezbyt” elegancki sposób.

Najważniejsza zasada w rozmowie kwalifikacyjnej:

Podejmij decyzję

 

Pod koniec rozmowy kwalifikacyjnej powinieneś być gotów do podjęcia jasnej decyzji co do kandydata. Są tylko dwa możliwe warianty takiej decyzji: Przyjąć lub Odrzucić. Od razu po rozmowie usiądź do komputera i prześlij informację o swojej decyzji do osoby odpowiedzialnej za rekrutację. Temat powinien zawierać nazwisko kandydata, a pierwsza linia wynik rozmowy: Przyjąć lub Odrzucić. Następnie poświęć ze dwa akapity na uzasadnienie decyzji.

Nie ma innej możliwej odpowiedzi. Nigdy nie mów „Przyjąć, ale nie do mojego zespołu”. Jest to niegrzeczne i zakłada, że kandydat nie jest na tyle bystry, aby pracować z tobą, lecz być może jest w sam raz dla tych nieudaczników z innych zespołów. Jeśli najdzie cię pokusa takiej odpowiedzi, po prostu zamień ją mechanicznie na Odrzucić i wszystko będzie w porządku. Jeśli kandydat mógłby się doskonale nadawać do pewnego szczególnego zadania, ale byłby mało przydatny w innych zespołach — Odrzucić. Wobec tak szybkich i częstych zmian w naszej branży potrzebujemy ludzi, którzy dadzą sobie radę ze wszystkim. Jeśli zdarzy ci się trafić na jakiegoś ograniczonego mędrca, który jest naprawdę, ale to naprawdę wspaniały w SQL, lecz całkowicie niezdolny do nauczenia się czegokolwiek innego — Odrzucić. Takie osoby nie mają przyszłości w Fog Creek.

Nigdy nie mów: „Być może, trudno powiedzieć”. „Trudno powiedzieć” oznacza Odrzucić. To jest łatwiejsze, niż myślisz. Trudno powiedzieć? Powiedz po prostu ”nie„! Podobnie, jeżeli nie możesz się zdecydować, to znaczy to Odrzucić. Nie mów nigdy „W zasadzie przyjąć, ale trochę mnie martwi...”. To również oznacza Odrzucić.

W rozmowie kwalifikacyjnej warto pamiętać, że jest znacznie lepiej odrzucić dobrego kandydata, niż przyjąć nieodpowiedniego. Zły kandydat oznacza marnotrawstwo pieniędzy, wysiłku i czasu pozostałych pracowników, naprawiających cudze błędy. W razie jakichkolwiek wątpliwości: Odrzucić.

Podczas rozmów kwalifikacyjnych nie myśl o tym, że jeśli odrzucisz znaczną liczbę ludzi, to Fog Creek nie będzie w stanie znaleźć nikogo do pracy. To nie jest twoje zmartwienie. Jest to zmartwienie personelu rekrutacyjnego, ludzi z działu zasobów ludzkich, Joela, ale nie twoje. Zadawaj sobie wciąż pytanie, co jest lepsze: czy to, że przekształcimy się w wielką, kiepską firmą pełną przeciętniaków, czy też to, że pozostaniemy firmą małą, za to o wysokiej jakości? Poszukiwanie dobrych kandydatów jest oczywiście ważne i każdy powinien traktować pozyskiwanie BystrychRealizujących Wyznaczone Cele jako jedno ze swoich zadań. Lecz w trakcie rozmowy kwalifikacyjnej należy założyć, że Fog Creek ma mnóstwo wspaniałych kandydatów. Nigdy nie należy obniżać standardów, niezależnie od tego, jak trudno jest znaleźć osoby, jakich szukamy.

Jak właściwie podejmować tę trudną decyzję? Podczas rozmowy musisz się po prostu stale pytać:  czy ta osoba jest Bystra? Czy potrafi Realizować Wyznaczone Cele?. Aby to rozstrzygnąć, będziesz musiał zadawać właściwe pytania.

Tak dla żartu przytoczę najgorsze pytanie pod słońcem w trakcie rozmowy kwalifikacyjnej: „Jaka jest różnica między varcharvarchar2 w Oracle 8i?”. Jest to okropne pytanie. Nie ma żadnej możliwej, wyobrażalnej korelacji pomiędzy grupą ludzi, znających odpowiedź na taką specjalistyczną, bezużyteczną błahostkę, a grupą ludzi poszukiwanych przez Fog Creek. Kogo obchodzi, jaka jest ta różnica? Można to znaleźć w sieci w ciągu 15 sekund!

W rzeczywistości bywają jeszcze gorsze pytania; wrócę do tego później.

Tak więc teraz przyjemniejsza część: pytania do postawienia w trakcie rozmowy kwalifikacyjnej. Moja lista takich pytań pochodzi z mojej pierwszej pracy w Microsofcie. W istocie są setki sławnych pytań rekrutacyjnych, związanych z tą firmą. Każdy posiada swój zestaw ulubionych pytań. Również i ty dopracujesz się swojego własnego zestawu, a także indywidualnego stylu przeprowadzania rozmowy, który pomoże ci w podejmowaniu decyzji Przyjąć czy Odrzucić. Oto pewne techniki, które stosowałem i które okazały się skuteczne.

Przed rozmową przeglądam resumé kandydata i na kawałku papieru szkicuję plan rozmowy. Jest to po prostu lista pytań, jakie chciałbym zadać. Typowy plan rozmowy z programistą wygląda mniej więcej tak:

  1. Wstęp
  2. Pytanie o ostatni projekt, w jakim kandydat brał udział
  3. Pytanie z gatunku niemożliwych
  4. Funkcja w C
  5. Czy jesteś zadowolony?
  6. Zadanie projektowe
  7. Wyzwanie
  8. Czy masz jakieś pytania?

Przed rozmową bardzo starannie unikam wszystkiego, co mogłoby mi dać jakiekolwiek wstępne pojęcie o kandydacie. Jeśli uznasz, że ktoś jest bystry, nim jeszcze wszedł do pokoju, tylko dlatego, że zrobił doktorat na MIT-cie1, to nic co usłyszysz podczas rozmowy, nie będzie w stanie tego nastawienia zmienić. Z kolei jeśli masz go za palanta, to nic, co powie, nie pokona twego uprzedzenia. Rozmowa jest jak bardzo czuły instrument — trudno ocenić kogoś na podstawie godzinnej rozmowy. Wynik może wydawać się wyważony. Jeśli jednak zawczasu dowiesz się czegoś o kandydacie, stanowi to spory ciężar na jednej szali, wobec czego rozmowa zda się na nic.

Pewnego razu, tuż przed rozmową, jeden z moich współpracowników odpowiedzialnych za rekrutację wszedł do mojego biura. „Spodoba ci się ten gość” — rzekł. Trudno opisać, jak mnie zdenerwował. Powinienem był odrzec: „cóż, jeżeli tak jesteś tego pewien, dlaczego po prostu sam go nie zatrudnisz, zamiast marnować mój czas na niepotrzebną rozmowę”. Byłem jednak młody i naiwny, więc odbyłem tę rozmowę. Kiedy kandydat mówił nie całkiem do rzeczy, pomyślałem sobie: „och, to musi być wyjątek potwierdzający regułę”. Na wszystko, co mówił, patrzyłem przez różowe okulary. W końcu orzekłem Przyjąć, chociaż w gruncie rzeczy był to mierny kandydat. I wiecie co? Wszyscy inni, którzy go przesłuchiwali, orzekli: Odrzucić. Zatem: nie słuchaj specjalistów od rekrutacji, nie rozpytuj wokoło o kandydata przed jego przesłuchaniem, a zwłaszcza nigdy, przenigdy nie rozmawiaj o nim z innym przesłuchującym, nim obaj nie poweźmiecie niezależnej decyzji. To metoda naukowa!

Wstępna faza rozmowy ma na celu wprowadzenie kandydata w swobodny nastrój. Poświęcam jakieś 30 sekund opowiadając o sobie i o tym, jak będzie przebiegać rozmowa. Zawsze zapewniam kandydata, że jesteśmy zainteresowani tym, jak sobie radzi z rozwiązywaniem problemów, a nie faktycznymi rezultatami. Przy okazji: powinieneś pamiętać o tym, aby nie oddzielać się od kandydata biurkiem. Wprowadza to formalną barierę, która nie rozluźni kandydata. Lepiej ustawić biurko pod ścianą, lub przejść się i usiąść z jednej strony z kandydatem. To pomaga wprowadzić swobodną atmosferę. Przyczynia się też do lepszych wyników, gdyż kandydatowi mniej przeszkadza nerwowość.

W drugiej części następuje pytanie o ostatnie przedsięwzięcie, w którym kandydat brał udział. W przypadku uczniów lub studentów warto spytać o pracę dyplomową, jeśli taką przygotowywali, lub o jeden z przedmiotów, którego częścią był interesujący ich projekt. Czasem na przykład pytam, jakie zajęcia w ostatnim semestrze, niekoniecznie związane z komputerami, najbardziej im się podobały? Zazwyczaj jestem zadowolony, kiedy opowiadają o przedmiocie nieinformatycznym. Niekiedy można spojrzeć na ich rozkład zajęć, z którego wynika, że uczęszczają tylko na absolutne minimum związane z informatyką, za to każdy przedmiot obieralny ma coś wspólnego z muzyką2. Po czym dowiadujemy się, że ich ulubionym przedmiotem są obiektowe bazy danych. I ja mam w to uwierzyć? Byłbym szczęśliwszy, gdyby po prostu przyznali, że wolą muzykę od komputerów, zamiast się przypochlebiać.

Podczas rozmowy z doświadczonymi kandydatami, można zapytać o ich poprzednią pracę.

Na tym etapie szukam jednej rzeczy: pasji. Podczas rozmowy o ostatnim przedsięwzięciu kandydatów, można zauważyć następujące dobre oznaki:

  • Kandydaci stają się bardzo podnieceni. Wykazują tendencję do szybszego mówienia i gestykulowania. Świadczy to o tym, że jeśli coś ich zajmie, oddadzą się temu z pasją. Zbyt wiele jest wokół nas osób, które potrafią coś robić bez żadnego zaangażowania emocjonalnego w jedną lub drugą stronę. Nawet negatywne emocje, byle okazane z pasją, mogą stanowić dobry sygnał. „Instalowałem Cud Program 2.0 u mojego poprzedniego szefa, ale to był idiota”. To są dobrzy kandydaci do przyjęcia. Złym kandydatom jest wszystko jedno i nie przejawiają żadnego entuzjazmu w trakcie rozmowy. Naprawdę dobrym znakiem rozpoznawczym kandydatów z pasją jest to, że gdy się rozpalą, potrafią zapomnieć choćby na chwilę o rozmowie kwalifikacyjnej. Czasami trafia się kandydat, którego ta sytuacja bardzo denerwuje. Jest to normalne, więc staram się tego nie dostrzegać. Kiedy jednak dojdzie do rozmowy na temat Monochromatycznej Sztuki Komputerowej, oznaki zdenerwowania znikają i dochodzi do głosu pasja. Lubię ludzi z pasją, którym naprawdę zależy na tym, co robią. (Aby zobaczyć przykład Monochromatycznej Sztuki Komputerowej spróbuj wyciągnąć wtyczkę monitora).

  • Starannie dobierają słowa. Zdarzało mi się odrzucać kandydatów dlatego, że kiedy opowiadali o swoim ostatnim projekcie, nie byli w stanie zrobić tego w sposób zrozumiały dla zwykłego człowieka. Adepci inżynierii zakładają po prostu, że każdy zna twierdzenie Batesa czy aksjomaty Peano. Jeśli zaczną w ten sposób, przerwij im na chwilę i poproś: „czy mógłbyś mi wyświadczyć przysługę i w ramach ćwiczenia objaśnić rzecz w sposób zrozumiały dla mojej babci”. Wiele osób w tym momencie nadal będzie operować żargonem, przez co wcale nie staną się zrozumiali. GONG!
  • Jeśli przedsięwzięcie było zespołowe, zwróć uwagę na to, czy kandydaci podejmowali rolę lidera. Kandydat może na przykład wspomnieć, że „pracowaliśmy nad X, ale szef powiedział Y, a klient Z”. Pytam wówczas: „a co ty zrobiłeś?”. Odpowiedź: „zebraliśmy się wraz z pozostałymi członkami zespołu i napisaliśmy oświadczenie...” jest jedną z tych dobrych. Do złych należy „Cóż, nic nie mogłem zrobić. To była sytuacja bez wyjścia”. Pamiętaj: BystryRealizujący Wyznaczone Cele. Dobrym sposobem na stwierdzenie, czy dana osoba Realizuje Wyznaczone Cele jest zbadanie, czy osoba ta przejawiała takie cechy w przeszłości. W rzeczy samej, możesz nawet wprost poprosić o podanie takiej sytuacji z nieodległej przeszłości, w której osoba podjęła się roli  przywódczej i zrealizowała wyznaczone cele — dajmy na to przezwyciężyła pewien instytucjonalny bezwład. 

Przejdźmy zatem do kolejnego pytania. Trzeci punkt na liście, to pytanie z gatunku niemożliwych. Tu jest zabawnie. Idea polega na zadaniu pytania, na które trudno jest dać odpowiedź, po to, aby zobaczyć, jak kandydaci sobie z tym radzą. „Ilu jest optyków w Seattle?” „Ile ton waży pomnik Waszyngtona?” „Ile stacji benzynowych ma Los Angeles?” „Ilu stroicieli fortepianów jest w Nowym Jorku?”

  • Bystrzy kandydaci zauważą, że nie przepytujesz ich z wiadomości, i z zapałem oddadzą się próbom znalezienia choćby zgrubnego oszacowania. „No cóż, pomyślmy. LA liczy około 7 milionów mieszkańców, z czego każdy ma jakieś 2,5 samochodu...”. Nic nie szkodzi, jeśli całkowicie się pomylą. Ważny jest entuzjazm, z jakim przystąpili do zadania. Mogą próbować oszacować pojemność stacji benzynowej. „Ha, tankowanie zajmuje 4 minuty, stacja ma około 10 pomp i jest otwarta jakieś 18 godzin...”. Mogą do zadania zabierać się na podstawie powierzchni. Nieraz zadziwią cię swoją pomysłowością lub poproszą o książkę telefoniczną miasta. Wszystko to są dobre oznaki.
  • Mniej bystrzy wpadną w konfuzję i zły humor. Będą się na ciebie patrzeć jakbyś spadł z księżyca. Musisz ich poprowadzić. „Przykładowo, jeśli miałbyś zbudować miasto wielkości Los Angeles, ile stacji benzynowych byś przewidział?” Możesz im dać drobne wskazówki. „Jak długo trwa napełnienie zbiornika paliwa?” Mimo to będziesz musiał ich ciągnąć za uszy, podczas gdy ci będą tępo siedzieć i czekać na wybawienie. Tacy nie należą do rozwiązujących problemy i nie chcemy, żeby dla nas pracowali. 

Jeżeli chodzi o zadania z programowania, to proszę kandydatów, aby napisali małą funkcję w C. Poniżej są typowe przykłady funkcji, o jakie zwykłem prosić:

  1. Odwrócić tekst w miejscu
  2. Odwrócić listę łączoną
  3. Zliczyć jedynki w bajcie
  4. Przeszukiwanie binarne 
  5. Znaleźć najdłuższy podciąg w słowie 
  6. atoi 
  7. itoa (niezłe, ponieważ wymaga stosu lub użycia strrev())

Nie zadawaj problemów, których rozwiązanie wymaga więcej niż około 5 linii kodu, czas ci na to nie pozwoli.

Przyjrzyjmy się bardziej szczegółowo niektórym zadaniom. Numer 1, odwrócenie tekstu w miejscu. Żaden z kiedykolwiek przeze mnie przesłuchiwanych kandydatów nie zrobił tego dobrze za pierwszym razem. Wszyscy, bez wyjątku, próbowali utworzyć bufor roboczy i wpisać odwrócony tekst do tego bufora. Kłopot w tym, kto ma przydzielić bufor i kto ma go zwolnić? Po zadaniu tego pytania tuzinom kandydatów odkryłem interesujący fakt. Większość osób uważających, że znają C, tak naprawdę nie rozumie kwestii przydziału pamięci ani wskaźników. Po prostu nie chwytają tego. Jest zadziwiające, że osoby te pracują jako programiści, ale tak jest. Przedstawione zadanie tak pozwala ocenić kandydatów:

  • Czy zaproponowana funkcja jest szybka? Policz, ile razy wywołuje strlen. Mimo że strrev() jest zadaniem o złożoności O(n), widziałem już algorytmy o złożoności O(n^2), gdyż wciąż wywoływały w pętli funkcję strlen.
  • Czy wykorzystywane są wskaźniki? Jest to dobry znak. Wielu „programistów w C” po prostu nie wie, jak używać tej arytmetyki. Normalnie nie odrzuciłbym kandydata z powodu braku jakiejś szczególnej wiedzy. Odkryłem jednak, że rozumienie wskaźników w C nie jest kwestią wiedzy, lecz nastawienia. Na początku semestru każdego wstępnego kursu informatyki zawsze jest około 200 dzieci, z których każde w wieku 4 lat pisało skomplikowane gry przygodowe w Basic-u na swoje Atari 800. Podczas nauki Pascala w szkole przypominają im się stare, dobre czasy, aż któregoś dnia nauczyciel wprowadza wskaźniki i nagle nie wiedzą, o co chodzi. Po prostu przestają cokolwiek rozumieć. 90% klasy rezygnuje i zostaje studentami nauk społecznych, a znajomym opowiada, że na informatyce nie dość było pociągających osobników odpowiedniej płci, dlatego się przenieśli. Z jakiegoś powodu większość ludzi zdaje się rodzić bez tej części mózgu, która jest potrzebna do rozumienia wskaźników. Jest to sprawa podejścia, a nie umiejętności — wymaga ono pewnej złożonej formy podwójnie upośrednionego myślenia, czego niektórzy ludzie po prostu nie potrafią.

Jeśli chodzi o zadanie 3, to pokazuje ono stopień opanowania przez kandydatów operacji na bitach w C... ale to jest wiedza, a nie podejście, dlatego trzeba z analizą pójść dalej. Interesująco jest popatrzeć, jak piszą funkcję zliczającą jedynki w bajcie, po czym poprosić, aby napisali wariant znacznie szybszy. Naprawdę Bystrzy kandydaci zbudują tablicę indeksowaną (zawiera przecież tylko 256 pozycji), której elementy wystarczy policzyć raz. Z dobrymi kandydatami można odbyć interesującą rozmowę na temat różnych ograniczeń czasowo-przestrzennych. Warto naciskać dalej: powiedz, że nie chcesz tracić czasu na wypełnianie tablicy w trakcie inicjalizacji. Błyskotliwi mogą więc zaproponować schemat zapamiętywania, w którym bity zlicza się tylko za pierwszym razem, gdy zachodzi potrzeba, a wynik zapamiętuje w tablicy, aby nie trzeba go było obliczać w przyszłości. Wyjątkowo wybitni podejmą próbę skrócenia czasu wypełniania tablicy przy wykorzystaniu powtarzających się wzorców.

Podczas przyglądania się, jak kandydaci piszą programy, pomocne są następujące techniki:

  • Zawsze zapewnij, że rozumiesz, jak trudno jest pisać kod bez edytora i że nie będziesz miał za złe, jeśli kartka stanie się zabazgrana. Rozumiesz także, że trudno zachować poprawną składnię bez kompilatora i weźmiesz to pod uwagę. 
  • Oznaki dobrego programisty: dobrzy programiści miewają zwyczaj pisania „{” i od razu „}” z zachowaniem odstępu, po czym dopiero wypełniają wolne miejsce. Mają także skłonność do stosowania pewnej konwencji nazewnictwa, jakkolwiek by ona nie była prymitywna. Dobrzy programiści stosują raczej krótkie nazwy wskaźników pętli. Jeśli ktoś nazwie taką zmienną LicznikWskaznikaBiezacejPozycjiStrony, jasne jest, że w swoim życiu nie napisał zbyt wielu programów. Czasami możesz spotkać programistę w C piszącego coś w rodzaju if (0==strlen(x)), to znaczy stawiającego stałą z lewej strony znaku ==. To bardzo dobrze świadczy, oznacza bowiem, że zbyt wiele razy zdarzyło mu się pomylić = z ==, wobec czego wyrobił sobie nowy nawyk, pozwalający uniknąć tej pułapki. 
  • Dobrzy programiści robią plan, nim wezmą się do pisania, zwłaszcza kiedy w grę wchodzą wskaźniki. Jeśli każesz im, na przykład, odwrócić listę łączoną, to dobrzy kandydaci zawsze sporządzą mały rysunek ze wskaźnikami przed zamianą i po niej. Powinni. Jest po prostu niemożliwą dla człowieka rzeczą napisać fragment programu, odwracający listę wskaźnikową, bez namalowania prostokątów połączonych strzałkami. Źli programiści od razu wezmą się do pisania. 

Jest nieuniknione, że stwierdzisz błąd w takiej funkcji. W ten sposób dochodzimy do punktu 5: Czy jesteś zadowolony z programu? Mogłbyś na przykład zapytać, „Dobra, więc gdzie jest błąd?”. Czysty ekstrakt nieokreślonego pytania rodem z piekła. Wszyscy programiści robią błędy i nic w tym złego, powinni tylko umieć je znaleźć. W przypadku funkcji operujących na tekście, prawie zawsze zapominają o kończącym nowy tekst zerze. W przypadku prawie każdego rodzaju funkcji z dużym prawdopodobieństwem popełnią błędy typu „plus minus 1”. Czasem zapomną o średniku. Funkcja nie będzie działać poprawnie na pustych tekstach lub spowoduje błąd ochrony, kiedy zawiedzie malloc... Rzadko, bardzo rzadko trafi się kandydat, który nie popełni żadnego błędu za pierwszym razem. W tym przypadku pytanie jest jeszcze ciekawsze. Kiedy powiesz, że „W tym programie jest błąd”, takie osoby starannie przejrzą kod, po czym dadzą ci okazję sprawdzić, czy są zdolni dyplomatycznie acz stanowczo obstawać przy swoim. Ogólnie rzecz biorąc, pytanie kandydatów o to, czy są usatysfakcjonowani swoim rozwiązaniem, jest zawsze dobrym pomysłem. Bądź tym, który panuje.

Część 6: zadanie projektowe. Poproś kandydata, aby coś zaprojektował. Jabe Blumenthal, pierwotny projektant Excela, lubił prosić kandydatów o zaprojektowanie domu. Bywali według niego kandydaci, którzy podchodzili do tablicy i od razu rysowali prostokąt. Prostokąt! Tacy natychmiast kwalifikowali się, żeby ich Odrzucić. Czego się spodziewamy po pytaniach projektowych?

  • Dobrzy kandydaci będą próbowali wydobyć od ciebie więcej informacji na zadany temat. Dla kogo jest ten dom? Z zasady nie przyjmę nikogo, kto od razu bierze się do projektowania, nie wypytawszy o to, komu dom ma służyć. Często bywam tak rozdrażniony, że dokuczam im przerywając w połowie i mówiąc, „zapomniałeś chyba zapytać, ale to dom dla rodziny ślepych, 15-metrowych żyraf”
  • Mniej bystrzy kandydaci sądzą, że projektowanie jest jak malowanie: bierzesz czystą kartkę i możesz robić, co chcesz. Bystrzy rozumieją, że projekt to szereg trudnych kompromisów. Doskonałe zadanie: zaprojektować uliczny kosz na śmieci. Pomyśl o tych wszystkich sprzecznych wymaganiach! Kosz musi być łatwy do opróżnienia, lecz odporny na próby kradzieży. Odpadki powinno się łatwo wrzucać, ale nie powinny ulatywać przy byle wietrzyku. Kosz powinien być trwały, ale niezbyt kosztowny. W niektórych miastach powinien być specjalnie zaprojektowany, żeby terroryści nie mogli w nim ukryć bomby.
  • Twórczy kandydaci często zaskoczą cię interesującym, mało oczywistym rozwiązaniem. Do moich ulubionych zadań należy Zaprojektować Regał na Przyprawy dla Niewidomych. Nieuchronnie kandydaci podpiszą gdzieś pojemniki brajlem. Z różnych powodów, które odkryjesz zadawszy to pytanie 100 razy, zwykle będzie to na wieczku. Raz zdarzył mi się kandydat, który orzekł, że lepiej będzie umieścić przyprawy w szufladce, ponieważ wygodniej jest odczytywać napisy brajlem, gdy palce są poziomo, a nie pionowo. (Spróbuj!) Było to tak pomysłowe, że aż mnie zaskoczyło — podczas dziesiątek rozmów nigdy nikt nie zaproponował takiego rozwiązania. Naprawdę wymagało to znacznego „skoku” twórczego, aby wyjść poza granice problemu. Na podstawie tego tylko rozwiązania i braku przeciwwskazań zatrudniłem kandydata, który stał się jednym z lepszych menedżerów projektowych w zespole Excela.
  • Zwróć uwagę na zamknięcie. Stanowi ono część Realizowania Wyznaczonych Celów. Niekiedy kandydaci błąkają się, nie mogąc podjąć decyzji, lub próbując uniknąć trudnych kwestii. Czasami zostawią trudniejsze decyzje bez rozstrzygnięcia i próbują iść dalej. Niedobrze. Dobrzy kandydaci mają tendencję, żeby w naturalny sposób posuwać rzeczy do przodu, nawet jeśli będziesz próbował ich powstrzymywać. Jeśli w rozmowie zaczniecie się kręcić w kółko i kandydat powie coś w tym rodzaju: „dobra, możemy tak gadać cały dzień, ale trzeba coś przecież postanowić, więc niech będzie, że X”, to jest to bardzo dobry znak.

I tak dochodzimy do punktu 7, Wyzwanie. Tu jest dosyć zabawnie. W trakcie rozmowy starasz się wychwycić moment, w którym kandydat powie coś absolutnie i bezsprzecznie prawdziwego. Wtedy mówisz: „zaraz, zaraz” i przez 2 minuty odgrywasz rolę adwokata diabła. Próbuj zaoponować w chwili, gdy wiesz, że mają rację.

  • Słabi kandydaci ulegną. Odrzucić.
  • Mocni kandydaci znajdą sposób, aby cię przekonać. Zastosują cały repertuar technik erystycznych w celu pozyskania twojej przychylności. Powiedzą: „Być może niezbyt dobrze cię zrozumiałem”. Jednak twardo będą obstawać przy swoim. Przyjąć.

Zgoda, w sytuacji rozmowy kwalifikacyjnej strony nie są równe. Istnieje więc ryzyko, że kandydat nie będzie się chciał przeciwstawić z uwagi na twoją pozycję decydującego. Niemniej dobrzy kandydaci raczej dadzą się ponieść argumentacji i zapominając na chwilę, że są w trakcie rozmowy kwalifikacyjnej, zaangażują się mocno w próbę przekonania. To są właśnie ludzie, których chcemy wynająć.

Na koniec powinieneś zapytać kandydata, czy sam chciałby się czegoś dowiedzieć. Niektórzy rozmówcy zdają się w tym momencie oczekiwać inteligentnych pytań, co jest standardowym zaleceniem książek na temat rozmów kwalifikacyjnych. Osobiście jest mi wszystko jedno, jakie pytanie padnie. Na tym etapie rozmowy podjąłem już decyzję. Kłopot polega na tym, że kandydaci zobaczą się w tym dniu z 5-6-ma osobami i trudno im będzie zadać tylu osobom kolejne błyskotliwe pytanie, jeśli więc nie mają żadnych — w porządku.

Zawsze, w każdym przypadku, zostawiam około 5 minut na „sprzedanie” Fog Creek. Jest to bardzo ważne, choćbyś nie zamierzał właśnie przesłuchiwanego kandydata zatrudnić. Jeśli miałeś dość szczęścia, aby znaleźć naprawdę dobrego kandydata, zrobisz w tej chwili wszystko, aby zapewnić, że kandydat zechce przyjść do Fog Creek. Natomiast gdy masz do czynienia z nieodpowiednimi kandydatami, zależy ci, aby wyszli z firmy pod wrażeniem. Pomyśl o tym w ten sposób: to są nie tylko potencjalni pracownicy, lecz również klienci. Mogą też spełnić rolę akwizytora w wysiłku rekrutacyjnym: jeśli uznają Fog Creek za wspaniałe miejsce pracy, zachęcą znajomych, aby się zgłosili.

Aha, właśnie sobie przypomniałem, że obiecałem dać kilka przykładów nieodpowiednich pytań, których należy unikać.

Przede wszystkim unikaj pytań niezgodnych z prawem. Wszystko, co się tyczy rasy, religii, płci, pochodzenia, wieku, obowiązku wojskowego, statusu weterana, orientacji seksualnej czy fizycznego upośledzenia jest po prostu nielegalne. Jeśli z CV wynika, że w 1990 roku ktoś służył w armii, nie próbuj pytać, choćby dla miłej pogawędki, czy brał udział w wojnie w Zatoce. Jest to wbrew prawu. Jeśli ktoś podaje w CV, że był słuchaczem Technion w Hajfie, nie napomykaj nawet, czy jest Izraelczykiem. Jest to wbrew prawu. Rozsądne rozważania na temat tego, co jest nielegalne, znajdziesz pod tym adresem. (Jednak pozostałe pytania do postawienia w trakcie rozmowy kwalifikacyjnej, jakie proponuje ta strona, są zwyczajnie głupie).

Dalej, unikaj wszelkich pytań, które mogłyby sugerować, że mile lub niechętnie widzimy sprawy, które w rzeczywistości są nam obojętne. Najlepszym przykładem, jaki mi przychodzi do głowy, jest pytanie o dzieci lub stan cywilny. Może to spowodować mylne wrażenie obawy, że kandydaci posiadający dzieci nie będą w stanie poświęcić dość czasu na pracę, albo że zamierzają pójść na urlop macierzyński.

Wreszcie, unikaj pytań-łamigłówek, jak to, w którym należy ułożyć 6 zapałek jednakowej długości, tak aby otrzymać dokładnie 4 jednakowe trójkąty równoboczne. Jest to zadanie typu „aha!” i z tego, czy kandydat był w stanie wykonać potrzebny skok myślowy, nie otrzymasz żadnej wskazówki w sprawie Bystry/Realizujący Wyznaczone Cele.

Rozmowa kwalifikacyjna jest bardziej sztuką niż nauką, lecz pamiętając o zasadzie Bystry/Realizujący Wyznaczone Cele, będziesz na dobrej drodze. Wykorzystaj sposobność i wypytaj współpracowników o ich ulubione zadania oraz oczekiwane odpowiedzi. Jest to odwieczny, popularny przedmiot rozmów podczas przerwy w kawiarni Budynku 16 w Redmond.

1MIT (skrót od: Massachusetts Institute of Technology) — jedna z najbardziej prestiżowych uczelni technicznych w USA. (przyp. redaktora)

2Na większości uczelni w USA panuje o wiele większa swoboda w wyborze przedmiotów przez studentów niż w Polsce. (przyp. redaktora).



Oryginał ukazał się w wersji angielskiej pod nazwą The Guerrilla Guide to Interviewing  

Joel Spolsky jest założycielem Fog Creek Software, małej firmy programistycznej w Nowym Jorku. Ukończył Uniwersytet Yale i  pracował jako programista i menedżer w Microsofcie, Viacom i Juno.


Zawartość tych stron wyraża opinie jednej osoby.
Cała zawartość prawnie chroniona. Copyright ©1999-2005 by Joel Spolsky. Wszelkie prawa zastrzeżone.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky