Głupie pytania na rozmowach o pracę

Jest to kontynuacja / rozwinięcie poprzedniego postu.


Co jeśli jesteś na rozmowie o pracę i usłyszysz głupie pytanie?

Nie odpowiadaj na nie. To znaczy: odpowiadaj (musisz przecież coś powiedzieć, a nie zamilczeć jak grób), ale odpowiadaj na inne pytanie, niż ci zadali. Zwykle głupie pytania są symptomem, że pytający chce o coś zapytać, ale nie wie dokładnie o co i to ty musisz się domyślić o co on chce zapytać, być może poprosić o doprecyzowanie pytania. Ew. też odbić całkowicie piłeczkę i polać wodę na inny temat ale jednak tak ciekawie opowiadać, że rekruter zapomni o co pytał wcześniej. Można też asertywnie odmówić odpowiedzi na pytanie i zmienić temat. Różne są taktyki.

Czasem również da się (i trzeba) odpowiedzieć wprost na pytanie, ale to dalej nie oznacza wcale, że dane pytanie jest mądre.

Ale przejdźmy do konkretów - jakie to są głupie pytania na rozmowach?

1. pytania tak ogólne, że nie da się na nie opowiedzieć krótko i konkretnie.

Np. "opowiedz coś o swoich doświadczeniach związanych z programowaniem".

Czyli o czym? O doświadczeniach ostatnich tygodni? Miesięcy? Lat? Wypracowanie mam też napisać? Elaborat na 5 stron?

Samo pytanie sugeruje, że rekruter nie odrobił pracy domowej. Nie czytał CV, nie przejrzał Twittera, nie zajrzał na konto na Githubie. I nie ma pojęcia z kim rozmawia.

Przeglądając czyjegoś Twittera/bloga/Githuba/wpisy na forum, można mieć bardziej namacalny obraz tego, kim dana osoba jest, z czym walczy i co ją jara, niż mielenie doświadczeń typu "w firmie X robiłem Y, i pracowałem z technologiami A, B, C oraz D"

Z drugiej strony ciężko powiedzieć rekruterowi "przejrzyj sobie mojego Twittera i bloga". Co więc odpowiedzieć?

Na pewno nie to, o co pytają. Oni nie chcą znać wcale twoich doświadczeń zawodowych. Chcą tylko mieć ogólny obraz kandydata. Najlepiej więc odbić trochę piłeczkę i zamiast się spowiadać z historii zawodowej, lepiej powiedzieć o swoich własnych projektach. Powiedzmy sobie szczerze: to czym dany programista zajmuje się w czasie wolnym i jego prywatne projekty robione "na boku" mówią o nim często więcej niż fakt, że pracował czysto w firmie X i robił Y.

Szczególnie, że i tak często ciężko powiedzieć cokolwiek o projektach komercyjnych, skoro wiążą nas lojalki. Z drugiej strony jeśli sam dla siebie robiłeś tylko nędzne HelloWorldy, za to robiłeś coś ciekawego komercyjnie i możesz o tym opowiedzieć, też pewnie nie zaszkodzi.

Ogólna zasada jest taka - żeby mówić interesująco i pewnie o ciekawych rzeczach. O czym dokładnie, nie jest aż tak ważne.

2. pytania wchodzące w prywatność bądź twoją (pytania zbyt osobiste) bądź twoich poprzednich pracodawców (a przecież są umowy poufności etc.).

Jak dla mnie jest to potężnym faux pas ze strony rekruterów namolne zadawanie pytań, na które widać, że kandydat nie chce bądź nie może po prostu odpowiedzieć.

Tutaj sprawdza się asertywność i ucinanie sprawy. Zmiana tematu.

3. pytania techniczne testujące wiedzę z rzeczy banalnych bądź łatwych do nauczenia

Kiedyś na jednej z rozmów miałem pytania o to czy pracowałem z Redmine, i jak powiedziałem, że nie, to rekruterzy byli bardzo zasmuceni.

Na takie proste i konkretne pytania akurat trzeba wprost odpowiadać: tak albo nie.

Dziwi mnie jednak fakt, że znajomość/nieznajomość Redmine ma być jakimś wyznacznikiem tego, czy ktoś się nadaje. Równie dobrze można pytać o umiejętność obsługi Skype'a czy Gmaila...

Z drugiej strony banalne pytania mogą być też mniej konkretne. Np. "Co to jest AJAX?", "Jak działa funkcja dolara w jQuery?".

Jednak i na nie trzeba odpowiedzieć jak najkrócej. Kiedyś chciałem się pokazać od jak najlepszej strony na rozmowach i zawsze odpowiadałem szczegółowo na takie banalne pytania (np. mówiąc o AJAXie wspominałem o obiekcie XMLHttpRequest i o protokole HTTP. Prawda jest taka, że nikogo to nie interesuje.

Więc prosta, krótka odpowiedź:
- AJAX to metoda komunikacji strony z serwerem bez przeładowania strony.
- funkcja dolara w jQuery służy do różnych rzeczy (ciężko krócej i mądrzej na to odpowiedzieć xD)

4. pytania typu "wymień 5 rzeczy", "wymień 10 rzeczy". 

Np. kontynuując: wymień 5 rzeczy, do których można użyć funkcji dolara w jQuery.

Jest to pytanie o tyle ciężkie do odpowiadania, że można korzystać z czegoś codziennie i nie robić sobie w głowie takich list "n rzeczy, które mogę zrobić za pomocą x". Po prostu się używa danej rzeczy.

Dopiero jak ci zadają gdzieś to pytanie, to się zastanawiasz nad tym na ile n sposobów można użyć rzeczy x.

Tylko, że to akurat jest dość proste, wystarczy zrobić w głowie listę. Gorzej jeśli tego typu pytanie będzie dotyczyć totalnych szczegółów, np. "wymień 10 rzeczy, którymi różni się IE9 od IE8"

Ja pierdolę, nie wiem. Zawsze mówię, że w realnej sytuacji bym wszedł na jakieś Can I use albo Kangaxa i posprawdzał, czy dana rzecz jest obsługiwana przez daną przeglądarkę.

I wydaje mi się, że to jest dobra praktyka. 

5. pytania typu "gdzie się nauczyłeś programować"? albo "skąd zainteresowanie programowaniem?"

Takie pytanie zadawano mi w czasach zanim jeszcze pracowałem jako zawodowy programista. Geneza tego pytania jest dość oczywista - nie mam wykształcenia informatycznego (studiowałem antropologię kulturową), nie pracowałem (wtedy) jako programista, więc rekruter był ciekawy skąd to programowanie.

Cóż, rozumiem ciekawość, co nie zmienia faktu, że takie pytania przystają raczej osobom, które nie miały nic do czynienia z programowaniem (np. osobom z działu HR). jeśli programista drugiemu programiście zadaje takie pytanie, to znaczy, że nie przemyślał tego dobrze i zadaje pytanie, na które odpowiedź już zna.

A odpowiedź jest banalna: programować uczy się człowiek programując. Przez praktykę. Nie ma innego wyjścia raczej. Jeśli rekruter-programista tego nie wie, to wiedz, że coś się dzieje.

I tym optymistycznym akcentem zakończymy. W następnym odcinku opowiemy sobie o żenujących zachowaniach na rozmowach o pracę, oraz opowiemy sobie też wkrótce o tym, jak powinna wyglądać pozytywna, kulturalna rozmowa rekrutacyjna (z punktu widzenia potencjalnego pracownika).