Ostatnio zastanawiałem się nad pytaniami do wywiadu i zastanawiałem się nad złymi doświadczeniami z wywiadu, które miałem w przeszłości. Jedną ze szczególnych uwag jest to, że zapytałem ankietera, dlaczego zespół zdecydował się zastosować EJB 3 nad Spring w swoim produkcie. Ankieter niemal oderwał mi twarz, krzycząc „Ponieważ wiosna to nie wszystko i koniec rozwoju oprogramowania Java, chcesz tę pracę, czy nie?”. W odpowiedzi powiedziałem mu, że prawdopodobnie nie jest to dla mnie praca i natychmiast wyszedłem z rozmowy.
Zostałem poinformowany na początku wywiadu, że firma ma dużą rotację pracowników, produkt, nad którym pracowali, został początkowo stworzony w Modula-3, następnie przeniesiony do Perla, a na końcu do Javy. Dostałem 10-stronicową broszurę z pytaniami technicznymi obejmującymi Java, EJB, SQL i JDBC i zadano mi pytania dotyczące stosów technologicznych, z którymi pracowałem. Kiedy poproszono mnie o zadawanie pytań, uznałem, że rozsądnie jest zapytać ich o stos technologii i uzyskać rozsądne odpowiedzi z powrotem, nie wysyłając ankietera do ognia.
Pytanie: Czy dobrym pomysłem jest zbadanie wyborów architektonicznych podjętych podczas wywiadu? Jeśli nie to dlaczego?
Z mojego punktu widzenia wywiad jest procesem dwukierunkowym. Jeśli ankieterzy sprawdzają moje umiejętności techniczne, mam pełne prawo zadać im te same pytania, aby:
1) Dowiedz się, jaki jest ich sposób myślenia i stosunek do tworzenia oprogramowania. 2) Ustal, czy ich podejście jest zgodne z tym, jak podejdę do tego rodzaju problemów.
Możliwe, że osoba przeprowadzająca wywiad, która się zdenerwowała, miała słabe umiejętności przeprowadzania wywiadów i zapomniała, że rozmowa jest dwustronna. Gdybym mnie o to zapytał, udzieliłbym rozsądnej odpowiedzi, ale z pewnością nie próbowałbym wprowadzić rozmówcy w stan łagodnej kapitulacji, w którym głowa tylko trzęsie się w górę i w dół bez rozmowy.