Rozmowa pair programming: czego się spodziewać i jak się przygotować

Jeśli przygotowywałeś się głównie zagadkami algorytmicznymi, runda pair programming może wydawać się obca. Ta sekcja wyjaśnia, na czym polega różnica i dlaczego zmienia to sposób przygotowania. Krótka odpowiedź brzmi: jesteś oceniany jako przyszły członek zespołu, a nie jako osoba rozwiązująca łamigłówki.

Sesja przebiega zwykle na jeden z trzech sposobów: we wspólnym edytorze w przeglądarce, we własnym IDE podczas udostępniania ekranu, albo jako rozszerzenie projektu take-home, który już wykonałeś. Zadanie zwykle przypomina codzienną pracę, na przykład dodanie reguły walidacji, naprawienie niedziałającego testu albo refaktoryzację funkcji. Niektóre firmy zamieniają role, więc część sesji spędzasz jako driver, który pisze, a część jako navigator, który kieruje.

• Pytania doprecyzowujące. Czy przed napisaniem kodu potwierdzasz wymaganie i to, co oznacza 'gotowe'.
• Myślenie na głos. Czy Twój partner potrafi śledzić Twój plan bez konieczności pytania.
• Postęp przyrostowy. Małe, działające kroki zamiast jednej dużej zmiany na koniec.
• Testowanie. Czy piszesz lub uruchamiasz test, aby udowodnić, że zmiana działa.
• Czytanie kodu. Jak szybko odnajdujesz się w kodzie, którego sam nie napisałeś.
• Przyjmowanie informacji zwrotnej. Jak reagujesz na wskazówkę lub inny pomysł swojego partnera.

Inne formaty kodowania, w tym whiteboard, take-home i rundy algorytmiczne na żywo, są porównane w interview types hub.

Inżynier backendu ubiegający się o stanowisko mid-level w startupie logistycznym został poproszony o dodanie reguły rabatowej do istniejącego modułu checkout. Zanim zaczął pisać, zapytał, czy rabaty mogą się sumować i co powinno się stać z zamówieniami już w trakcie realizacji. Przeczytał istniejące testy, napisał jeden niedziałający test dla nowej reguły, sprawił, że zaczął działać dzięki najprostszej możliwej zmianie, a następnie zapytał partnera, czy reguła powinna należeć do klasy pricing, czy do osobnego obiektu policy. Gdy rekruter zaproponował inne podejście, wypróbował je i wyjaśnił związany z nim kompromis. Nie ukończył rozszerzonego wymagania, a mimo to informacja zwrotna nadal skupiała się na tym, jak łatwo się z nim współpracowało.

Ten przebieg — doprecyzowanie, najpierw testowanie, małe zmiany i dyskusja o projekcie — jest właśnie tym, co większość rund pair programming ma na celu zaobserwować.

Poćwicz z przyjacielem małe zadanie w nieznanym repozytorium i trenuj opowiadanie na głos w trakcie pracy. Jeśli będziesz używać własnego IDE, przygotuj wcześniej środowisko: projekt powinien się budować, a testy powinny przechodzić, zanim zacznie się rozmowa. Mock interview tool pomaga w częściach konwersacyjnych, takich jak wyjaśnianie wyboru projektowego czy opisywanie wcześniejszego projektu.

Bądź realistą co do narzędzi live w tym kontekście. Pair programming w dużej mierze opiera się na udostępnianiu ekranu, a wszystko, co udostępniasz, widzi Twój partner; Twój rekruter również obserwuje na żywo, jak piszesz kod. SubcueAI transkrybuje rekrutera i przygotowuje szkice punktów odpowiedzi podczas części dyskusyjnych rozmowy wideo, z aplikacji desktopowej lub rozszerzenia przeglądarki, bez żadnego bota w rozmowie. Samo kodowanie należy do Ciebie, a środowiska nadzorowane (proctored) i urządzenia zarządzane przez firmę są poza zakresem. Szczegóły konfiguracji znajdziesz na stronie tutorial.