Mock Interview · Frontend / Fullstack

Przygotuję Cię do rozmowy technicznej.

Taka sama rozmowa, jaką przeprowadziłbym z kandydatem do mojego zespołu. Po niej pisemny raport: co zrobił_ś dobrze, czego zabrakło i co dalej.

Junior, mid i senior. Pytania pod Ciebie.

Obecnie cały proces jest bezpłatny w zamian za zgodę na publikację relacji z rozmowy. Nie nagrywam spotkań.

Jak wygląda publikacja?

Umów „Poznajmy się” →

Bezpłatne 30 minut o Twoim doświadczeniu i celu. Termin właściwego Mock Interview ustalimy osobno.

Wolisz napisać?

Poznajmy się - 30 minut

Doświadczenie, stack, projekty, dotychczasowe rekrutacje. Zaglądam w Twoje repo, jeśli je masz. Z tego układam rozmowę pod Ciebie i ustalamy termin właściwego Mock Interview.

„Dobrze się rozmawiało - nie czułem się jak na przesłuchaniu.”

Czy moja rozmowa trafi na bloga? Tak - nie nagrywam, relację piszę z notatek. Relacja jest anonimowa - jedyne, co w niej nieanonimowe to Twoje imię. Uwzględniam wyłącznie przebieg rozmowy, bez prywatnych rzeczy, które mi powiesz. Zasady publikacji

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.

Drążę, drążę, aż wydrążę. Chodzi o wydobycie z kandydata jak najwięcej wartości.

„Nie wiem” też jest odpowiedzią. Pięć minut udawania, że wiesz - nie.

Rozmowa rekrutacyjna do konkretnej firmy to droga opcja na odkrywanie własnych braków. Możesz je znaleźć tutaj - zanim zrobisz to na żywym organizmie.

Bart Wasilew

Kto Cię pyta

Pięć lat prowadzę rozmowy techniczne, zrekrutowałem cztery zespoły frontend/fullstack. Niemal 10 lat pracy inżynierskiej i doświadczenie liderskie - dzięki temu oceniam nie tylko odpowiedź, ale rozumienie technologii, decyzji i kompromisów, które za nią stoją.

Wiesz więc, skąd bierze się feedback, który dostajesz - nie ze smutnej checklisty 400 generycznych pytań - tylko z rozmów, które prowadziłem po obu stronach stołu.

Jak to wygląda

  1. 1. Przygotowanie

    CV, repo, portfolio albo zadanie rekrutacyjne, jeśli je masz. Z tego craftuję całą rozmowę - nie wyciągam pliku frontend-interview-final-v7-REAL.pdf i nie lecimy po kolei.

  2. 2. Mock Interview - około 90 minut

    Pytania techniczne, sytuacyjne i produktowe - jak dla kandydata do mojego zespołu. Jeśli udostępnisz repo, robimy też code review.

    • 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?

  3. 3. Pisemny feedback

    Szczegółowy pisemny raport: co poszło dobrze, gdzie brakowało wiedzy albo argumentacji, co dalej rozwijać oraz moja rekomendacja pt. „co dalej”.

Raport, który faktycznie dostajesz

Moim celem nie jest wystawienie Ci oceny 7.3/10 FRONTEND DEVELOPER. Raport rozbiera pytanie po pytaniu: co było trafne, czego zabrakło, dlaczego i co poprawić. Poniżej prawdziwy, anonimowy fragment:

Fragment prawdziwego raportu

Pytanie

Masz wyszukiwarkę. Użytkownik szybko wpisuje kolejne litery i za każdym razem leci request do API. Jak to zoptymalizować?

Feedback

Pierwsza odpowiedź o tym, że wołałbyś API dopiero od X znaków jest okej, ale jako dodatek do głównego rozwiązania problemu. Pomysł z zatwierdzaniem Enterem to też jest jakieś wyjście, ale raczej ostateczne. Miałeś dobrą intuicję "wiem, że nie o to tu chodzi". Natomiast pomysł ze strzałem do API po 3 znakach i znowu strzał do API po kolejnych 3 znakach - jest mocno randomowy i nie rozwiązuje nam głównego problemu, bo po 1. Zrobimy strzał do API zarówno jak szukana fraza to "asd" i "lis" - oba mają 3 znaki, a pierwszy nie ma kompletnie sensu. Po 2. zoptymalizujemy wtedy liczbę requestów z "ilość znaków" na "ilość znaków / 3" - to i tak często i niepotrzebnie zawsze. Najlepszym rozwiązaniem będzie debounce - użytkownik wpisuje, wpisuje, wpisuje, …, aż nie przestanie wpisywać na X milisekund/sekund - wtedy wołamy API. Wisienką na torcie byłby tu distinctUntilChanged, żeby nie wołać API dla tych samych fraz.

Anonimowy fragment raportu po Mock Interview

Zobacz końcową ocenę i dalsze kroki

Na teraz polecam

Na dziś widzę Cię jako mocnego juniora+ z wyraźnymi sygnałami mida. Rozbijanie konkretnych problemów, argumentowanie i reagowanie na konkretny kod są już momentami midowe. Techniczne podstawy nie są jeszcze równie stabilne w każdym obszarze - przede wszystkim w testach, auth, performance i pracy ze stanem. Aplikuj na role junior+ / early mid, nie dyskwalifikuj się sam, ale świadomie domknij te luki. Masz z czym iść dalej. Powodzenia, Bart.

Anonimowy fragment raportu po Mock Interview

Raport Matiego miał np. 10 stron konkretnego feedbacku (więcej w relacji) - to przykład, nie gwarantowany standard.

Bezpłatne, 30 minut. Zakres dogramy przed rozmową.

Umów „Poznajmy się” →

Wolisz napisać?

Co mówią uczestnicy

5osób, które zaufały

Poczytaj pełne relacje

Masz pytania przed pytaniami?

Zapis, przygotowanie, zasady relacji. Krótko, bez regulaminu.

Przeczytaj FAQ →

Bezpłatne, 30 minut. Zakres dogramy przed rozmową.

Umów „Poznajmy się” →

Wolisz napisać?