Rozmowa techniczna - frontend/fullstack

Pięć lat prowadzę rozmowy techniczne. W tym czasie zrekrutowałem cztery zespoły frontend/fullstack naprawdę zajebistych ludzi. I oczywiście dużo "osobnych osób". To, co robię tutaj, to mock interview - próbna rozmowa techniczna frontend i fullstack, która wygląda i czuje się jak prawdziwa rekrutacja.

Wiem, jak wygląda dobra odpowiedź. Wiem też, jak wygląda odpowiedź człowieka, który nie wie, ale bardzo chciałby, żebyśmy obaj przez pięć minut udawali, że wie.

I właśnie dlatego robię te rozmowy.

Nie po to, żeby Cię złapać na tym, że nie pamiętasz trzeciego parametru jakiejś funkcji. Chcę zobaczyć jak myślisz, jak podejmujesz decyzje, jak reagujesz, kiedy czegoś nie wiesz i co właściwie umiesz - również wtedy, kiedy nie umiesz tego od razu dobrze sprzedać.

Drążę, drążę, aż wydrążę.

Jak to wygląda?

Dwie rozmowy. Nie jedna, bo wtedy pierwsze pół godziny technicznej spędzilibyśmy na ustalaniu, kim jesteś. A szkoda pół godziny.

1. Poznajmy się - około 45 minut

Spotykamy się osobno, wcześniej. Gadamy o Tobie, doświadczeniu, projektach, stacku, rozmowach, które już przeszedłeś i o tym, gdzie właściwie jesteś zawodowo.

Zaglądam też w Twoje projekty, jeśli je masz.

A potem na tej podstawie układam rozmowę pod Ciebie. Nie wyciągam pliku frontend-interview-final-v7-REAL.pdfi nie lecimy po kolei.

2. Rozmowa techniczna - około 90 minut

Robimy rozmowę podobną do tej, którą przeprowadziłbym kandydatowi do swojego zespołu.

• SytuacyjnyKolega z zespołu uważa, że jego rozwiązanie jest lepsze. Niestety ma też głos i może tego rozwiązania bronić. Co robisz?
• TechnicznyTechniczne problemy i pytania, przy których bardziej interesuje mnie Twój tok myślenia niż definicja przepisana z dokumentacji.
• ProduktowyUser płacze, że aplikacja jest wolna. Dlaczego? Oczywiście pierwsza odpowiedź brzmi: backend. Ale co dalej?
• Code ReviewOtwieramy Twój kod i rozmawiamy o decyzjach. Dlaczego tak? Dlaczego tutaj? Co byś zmienił? I dlaczego masz 37 typów w jednym pliku?

Czego tutaj nie będzie?

Raczej nie zapytam Cię, co robi trzeci parametr:doSomething(p1, p2, p3).

Nie będę też sprawdzał, czy pamiętasz, co dokładnie zmieniło się między Angularemv.21.2.3.4.5.6.6.2.2a wersją wydaną czternaście minut później.

Takie rzeczy można sprawdzić.

Dużo trudniej sprawdzić po fakcie, czy potrafisz dobrze rozłożyć problem, zakwestionować własne rozwiązanie, powiedzieć "nie wiem" albo zauważyć, że właśnie próbujesz naprawić coś, czego jeszcze nawet nie zdiagnozowałeś.

A jak czegoś nie wiem?

To mówisz:

Nie wiem.

Serio.

Jedną z najlepszych odpowiedzi, jakie usłyszałem podczas takiej rozmowy, było:

Nie. I nie będę się wypowiadał w temacie, bo nie ma sensu zmyślać.

Piękne.

Wolę to sto razy bardziej niż pięć minut odpowiedzi, podczas której oboje wiemy, że nie wiesz, ale jeszcze przez chwilę sprawdzamy, czy może wydarzy się cud.

Nie wydarzy się.

Potem dostajesz feedback

Nie:

Dziękujemy za udział w procesie. Tym razem zdecydowaliśmy się kontynuować z innym kandydatem.

Tylko normalny, konkretny feedback do rozmowy.

Dostajesz ode mnie:

• komentarz do pytań i Twoich odpowiedzi,
• co zrobiłeś dobrze,
• gdzie brakowało mi wiedzy albo argumentacji,
• co warto dalej rozwijać,
• co warto przestać robić,
• materiały i kierunki do uzupełnienia braków,
• moją rekomendację: co dalej.

I zwracam uwagę nie tylko na rzeczy, które poszły źle.

Jeżeli robisz coś dobrze, też chcę Ci o tym powiedzieć. Bo całkiem możliwe, że robisz to dobrze od dawna, tylko żadna firma nie raczyła Ci tego wcześniej powiedzieć.

Po co?

Bo prawdziwa rozmowa rekrutacyjna jest dość drogim miejscem na odkrywanie swoich braków.

Możesz dowiedzieć się ich tutaj - to solidne przygotowanie do rozmowy technicznej, zanim zrobisz to na żywym organizmie.

Bez utraty oferty pracy, bo żadnej oferty pracy tutaj nie ma. Sprytne.

Moim celem nie jest wystawienie Ci oceny7.3/10 FRONTEND DEVELOPER.

Chcę znaleźć Twoją wartość jako kandydata, pokazać Ci, gdzie ją już masz i gdzie jeszcze jej brakuje.

Czasem wystarczy coś doczytać. Czasem trzeba przestać pierdolić przez pięć minut i powiedzieć "nie wiem".

Obie rzeczy da się poprawić.

Jak to wygląda w praktyce?

Pierwsze Mock Interview zrobiłem z Kacprem. Opisałem to później na blogu - razem z pytaniami, odpowiedziami, tym, co zrobił dobrze i miejscami, w których trochę go pomęczyłem.

Mock Interview #1: Kacper, czyli „nie wiem” jest lepsze niż pięć minut pierdolenia

2osoby już mi zaufały