Jak przejść przez live coding?

Live coding interview to etap rekrutacyjny polegający na pisaniu kodu “na żywo” – podczas spotkania kwalifikacyjnego dostajemy zadanie do napisania i musimy je przekształcić w kod. Zadanie tego typu nie występuje w każdym procesie rekrutacyjnym, ponieważ wiedza o programowaniu może być weryfikowana w inny sposób, na przykład przez hometask lub serię pytań teoretycznych, ale jak już ma to miejsce, to jest to bez wątpienia jeden z najbardziej stresujących etapów jaki możemy spotkać podczas szukiwania pracy.

Samo pisanie kodu nie jest prostą czynnością i wymaga dużego skupienia, a jeżeli dochodzi do tego jeszcze stres związany z rekrutacją i faktem, że ktoś nam dosłownie patrzy na ręce, to nie ma co ukrywać… live coding jest po prostu trudnym doświadczeniem. I to nie tylko dla osób początkujących, dosłownie nie znam nikogo, kto jest fanem tego procesu. Jednakże tak jak to ma miejsce z rekrutacją, uważam, że jest to kolejna rzecz, do której jednak da się odpowiednio przygotować.

Poniższe porady przydadzą się nie tylko na live codingu, czyli pisaniu kodu na spotkaniu na którym jest obecna osoba techniczna, ale także gdy zadanie polega na napisaniu kodu w formie zdalnej w ograniczonym czasie.

Aby przejść przez live coding przede wszystkim musimy zrozumieć:

1. czemu służy live coding i jakie umiejętności sprawdza
2. kiedy się wypada lepiej na live codingu
3. jak się do niego przygotować

Powszechnym błędem jest myślenie, że live coding służy tylko i wyłącznie sprawdzeniu, czy umiemy pisać kod, a naszym jedynym zadaniem jest skupenie na napisaniu poprawnego kodu. Tak nie jest. Live coding sprawdza wiele umiejętności – nie tylko znajomość syntaksu języka programowania, ale także umiejętność rozkładania zadania na czynniki pierwsze, czy umiejętność komunikacji w sytuacji silnego stresu. 

Absolutnie najgorszym zachowaniem podczas takiego spotkania jest zamknięcie się w sobie i próba samodzielnego wpadnięcia na rozwiązanie zadania w sytuacji, gdy nie potrafimy go rozwiązać, i w konsekwencji milczenie przez kilka minut. Rekruter w takiej sytuacji nie wie o czym myślimy – czy zastanawiamy się nad kolejnym krokiem, próbujemy przypomnieć sobie nazwę funkcji, czy stres nas zjadł kompletnie i nie myślimy absolutnie o niczym. Dlatego tak ważna jest komunikacja z drugą osobą – przedstawienie jak rozumiemy problem, jak chcemy do niego podejść, co zamierzamy napisać czy z jakim problemem się aktualnie mierzymy. Tylko podczas rozmowy rekruter jest w stanie zrozumieć na jakim etapie utknęliśmy, przez co także nam pomóc w znalezieniu prawidłowego rozwiązania tego problemu.

Zacznijmy jednak od początku – poniżej 6 porad jak przejść przez live coding:

1. Praktyka czyni mistrza

Sukces przejścia przez ten etap kwalifikacyjny zaczyna się znacznie wcześniej niż samo spotkanie. Mimo iż mówimy o niesamowicie stresującym doświadczeniu to… praktyka czyni mistrza, a live coding można po prostu wyćwiczyć. Aby to zrobić potrzebujemy regularnie zacząć pisać kod pod presją – najlepiej pod presją czasu i osoby nas oceniającej, ale jeżeli nie macie zaprzyjaźnionej osoby, która może poudawać rekrutera, to samo ćwiczenie z presją czasu już was dużo nauczy.

Ucząc się kodować często fundujemy sobie komfortowe warunki pracy – przygotowujemy ciepłą herbatkę, siadamy na spokojnie do kodu i ćwiczymy jego pisanie bez żadnych stresujących bodźców w otoczeniu. Napotykając bug robimy sobie przerwę na odświeżenie umysłu i wracamy do kodu dopiero, gdy nasz umysł jest już wypoczęty.

Niestety podczas live codingu warunki wyglądają zgoła inaczej, i to właśnie te warunki chcemy odwzorować przy ćwiczeniach. Musimy nabyć umiejętność kodowania w bardziej stresujących warunkach, przynajmniej pod presją czasu. W internecie znajdziecie masę darmowych portali do ćwiczenia zadań programistycznych – najbardziej polecam hackerrank oraz leetcode. Otwieramy zadanie, dajemy sobie na jego zrobienie 10 minut i próbujemy je rozwiązać w tym czasie. Praktykowanie pisania kodu w takich warunkach spowoduje, że będzie szło nam dużo lepiej na rekrutacjach – i jasne, dalej będą one stresujące, ponieważ dalej będzie dodatkowy czynnik stresu w postaci osoby nas oceniającej, ale obiecuje, że stres będzie mniejszy, niż gdybyśmy w ogóle nie ćwiczyli w ten sposób.

2. Poświęć czas na zrozumienie zadania

Dobra, zaczynamy spotkanie, dostajemy zadanie i… prawdopodobnie zaczynamy je za szybko pisać. Brzmi absurdalnie, ale nie pisałabym tego punktu, gdyby nie zdarzał się tak często. Normą jest, że będąc ocenianym myślimy, że wypada jak najszybciej zacząć coś robić, przez co rozpoczynamy pisanie często nie do końca rozumiejąc jeszcze na czym dokładnie polega zadanie. Daj sobie czas na przeczytanie i zrozumienie problemu. Opanuj nerwy. Dobrym patentem może być posiadanie kartki oraz długopisu, które możesz wykorzystać do notatek. Po zapoznaniu się z wymaganiami możesz powiedzieć rekruterowi, że chciałabyś je sobie na spokojnie rozpisać w zeszycie – możesz napisać wszystkie kroki jakie musisz wykonać lub rozpisać warunki, które ma spełniać kod. Po dokładnym zapoznaniu się z kryteriami zadania dobrym pomysłem będzie sparafrazowanie je rekruterowi, na przykład posługując się przykładem z wymyślonym inputem – jeżeli okaże się, że źle zrozumiałaś zadanie, rekruter na pewno zareaguje w jakiś sposób. 

Dlaczego to jest tak istotne? Złe zrozumienie zadania powoduje, że zaczynamy pisać zły kod, i nawet jeżeli domyślimy się po chwili, że nie o to w nim chodzi to marnujemy czas, dodajemy sobie stresu i wypadamy na osobę chaotyczną. Spokojne rozpoczęcie nie powoduje, że wyglądamy na osoby wolne – wręcz przeciwne, wypadamy jako osoby opanowane, uporządkowane i rzetelnie podchodzące do zadania.

3. Pisz kod krok po kroku

Możesz się spotkać z dwoma rodzajami live codingu: 1) polegający na napisaniu kodu, który się kompiluje, 2) polegający na pisaniu pseudokodu.

W tym pierwszym przypadku kod musi być napisany całkowicie poprawnie, czyli musi się uruchamiać i zwracać poprawne wyniki. Zazwyczaj jest on pisany w edytorze kodu, który jest podłączony do środowiska języka programowania lub do bazy danych (w przypadku SQL). W tym przypadku nie możemy mieć literówek, użyć niepoprawnych nazw funkcji czy zrobić jakiegokolwiek błędu, aby poprawnie zakończyć zadanie. W drugim przypadku, przy pisaniu pseudokodu, możemy zostać poproszeni o napisanie kodu gdziekolwiek, nawet w edytorze tekstu worda. Zadanie to polega bardziej na umiejętności rozłożenia zadania na czynniki pierwsze, czy wiedzę o złożoności obliczeniowej, ale do tego zagadnienia jeszcze wrócimy. W takim przypadku nie są istotne możliwe literówki, czy nawet użycie dokładnych nazw funkcji.

Jeżeli jednak piszemy „prawdziwy” kod, to istotne jest upewnienie się, że kod działa i zwraca poprawne wyniki. A w tym temacie… możemy mieć błędne wyobrażenie jak wygląda „profesjonalne” pisanie kodu. Osoby początkujące myślą, że napisanie całego kodu od początku do końca jest PRO i to właśnie tak powinno wyglądać, kiedy w rzeczywistości powinniśmy pisać kod krok po kroku, tym bardziej pisząc go na stresującym spotkaniu. Osoby początkujące tak często popełniają ten błąd, że nawet specjalnie popełniłam artykuł na ten temat. W skrócie: jeżeli mamy do napisania query w SQL wymagającą filtrów, JOINów i agregacji, to nie piszemy jej od razu od początku do końca! Piszemy najpierw query wyciągającą wiersze z jednej tabeli, sprawdzamy czy działa, dodajemy WHERE, sprawdzamy czy działa, później dokładamy JOIN itd. Pisanie zbyt dużych fragmentów kodu powoduje, że bardzo ciężko się szuka błędów w takim kodzie, co w przypadku stresu przy live codingu może nas całkowicie zgubić.

4. Komunikuj się z rekruterem

Upewnij się, że rekruter jest na bieżąco z twoim tokiem rozumowania. W większości przypadków są to osoby, które chcą ci pomóc, zatem jeżeli utkniesz na jakimś kroku, to są w stanie podpowiedzieć rozwiązanie czy naprowadzić na właściwy kierunek. Nawet jeżeli osoba po drugiej stronie nie jest zbyt skłonna do podpowiedzi, to często możemy wyczytać z jej reakcji czy idziemy w dobrym kierunku np. przez potakiwanie lub mimikę twarzy. Prowadzenie komunikacji jest kluczem do sukcesu, zresztą sam live coding także służy sprawdzaniu umiejętności komunikacji – odzwierciedla to sytuację w pracy, gdzie jeżeli mamy jakiś problem techniczny to przecież możemy doradzić się współpracowników w jaki sposób warto do niego podejść. Sprawdzana jest także umiejętność słuchania, zatem gdy rekruter do nas mówi, to warto go słuchać i reagować na wskazówki!

A teraz historia z życia wzięta – mój pierwszy live coding był… całkowitą porażką. Miałam do napisania trzy zadania z SQL w przeciągu pół godziny. Kompletnie się zestresowałam i popełniłam wszelkie możliwe błędy jakie się dało, łącznie z klasycznym pomyleniem WHERE z HAVING. Do trzeciego zadania nawet nie doszłam. Byłam pewna, że oblałam ten etap, a się okazało, że… go przeszłam! Dlaczego? Bo mimo wielu (naprawdę wielu) błędów reagowałam na feedback rekrutera – jak mi podpowiadał, że coś nie jest tak, jak powinno, to od razu poprawiałam na właściwe rozwiązanie.

5. Szukanie rozwiązań

Jeżeli nie potrafisz napisać kodu, bo np. zapomniałaś jakiejś funkcji, to sprawdzane jest także jak wybrniesz z tej sytuacji. Moją poradą jest poinformowanie rekrutera z czym się mierzymy i otwarte zapytanie, czy możesz poszukać rozwiązania w internecie. Sama uważam, że nie ma nic złego w zapomnieniu jakiejś funkcji – tak wygląda codzienna praca z kodem, przecież nie musimy zapamiętywać wszystkiego na pamięć. Oczywiście firmy mogą mieć na ten temat różne zdanie, dlatego warto zadać to pytanie zanim sami postanowimy otworzyć przeglądarkę. Jeśli zaczniecie poszukiwania, to zwróćcie także uwagę w jaki sposób je wykonujecie – najlepszą opcją będzie zawsze skorzystanie z oficjalnej dokumentacji. Jeśli sięgamy po stackoverflow lub chatGPT, to ja bym głośno podkreśliła, że zdaje sobie sprawę, iż nie jest to dokumentacja, ale mimo wszystko te platformy często podpowiadają właściwe rozwiązanie – dlatego zaryzykuję, ale dokładnie sprawdzę kod, aby upewnić się, czy kod jest poprawny. Zresztą w każdym przypadku po znalezieniu odpowiedniego fragmentu kodu czy funkcji upewnijmy się dokładnie, że kod działa tak, jak tego potrzebowaliśmy.

6. Nie poddawaj się

Powróćmy na chwilę do mojego pierwszego live codingu – z racji masy popełnionych błędów w trakcie spotkania byłam praktycznie pewna, że go nie zdałam, jednak po jego zakończeniu miałam od razu kolejny etap kwalifikacyjny z inną osobą, więc… odziałam uśmiech numer dwa i udawałam, że live coding świetnie mi poszedł. I naprawdę, była to najlepsza decyzja ever, bo finalnie okazało się, że jednak przeszłam ten live coding, a koniec końców przeszłam też kolejne rozmowy i dostałam tę pracę! A przecież gdybym się wtedy poddała i odpuściła to na pewno nie wypadłabym dobrze na następnym spotkaniu – skupienie się, aby pokazać się z jak najlepszej strony to najlepsze, co mogłam wtedy zrobić. 

Sama kiedyś rekrutowałam analityków danych do jednej firmy i najgorsze co się mogło wydarzyć to właśnie jak komuś siadała motywacja, bo myślał, że źle zrobił pierwsze zadanie i nie ma co się starać przy kolejnym. Miałam nawet raz sytuację, gdy pewnej osobie wcale nie poszło tak źle przy pierwszym zadaniu, ale była pewna, że go nie przeszła, i całkowicie sobie odpuściła kolejne… przez co rzeczywiście nie zdała.

Sednem sprawy jest to, że nie jest ważne jak wy (myślicie, że) wypadacie na rozmowie, ale jak wypadacie na tle reszty. Etapy techniczne nie polegają na tym, że musicie poprawnie odpowiedzieć na każde zadane pytanie i rozwiązać każdy możliwy problem, liczy się całokształt: ile już potraficie technicznie, jaki macie potencjał i jak kształtują się wasze umiejętności miękkie. 

Dlatego nigdy, przenigdy nie poddawajcie się w trakcie rozmów, ponieważ to tylko i wyłącznie może zadziałać na waszą niekorzyść. Nawet jak nie potraficie czegoś rozwiązać to podchodźcie do każdego kolejnego zadania dając z siebie wszystko, bo jeżeli się poddacie, to na pewno nie zdobędziecie tej pracy, a w przeciwnym przypadku może jeszcze nie wszystko stracone.

Jak powinien wyglądać kod

1. Pomyłki są normalne, ale są jakieś podstawy podstaw, które jednak dobrze jest mieć opanowane. Gdybym zobaczyła kandydata, który ma problem z kolejnością klauzul w SQL (np. używa WHERE przed JOIN), lub nie potrafi napisać składni pętli IF w Pythonie, to stwierdziłabym, że ta osoba napisała mało kodu w SQL czy w Pythonie w swoim życiu. Błędy są normalne, ale są jakieś podstawy, które jednak powinniśmy mieć opanowane, nawet przy dużym stresie przy live codingu.
2. Próbujemy nie wynajdować koła na nowo, czyli jeżeli istnieje jakaś gotowa funkcja, która robi to, czego potrzebujemy, to ją używamy. Jeżeli całe zadanie polega na tym, że mamy napisać coś, co robi dokładnie jakaś funkcja, to wtedy możemy się spytać czy możemy jej użyć czy sami powinniśmy napisać kod od zera, bo może to być akurat test sprawdzający algorytmikę – przykładem będzie policzenie ile razy powtarzają się elementy w liście (można to zrobić za pomocą funkcji Counter z biblioteki colletions).
3. W większości przypadków wystarczający będzie kod, który działa – czyli tzw. brute force approach. Jeżeli aplikujesz do bardziej wymagającej firmy lub na stanowisko wymagające lepszej znajomości kodu może pojawić się temat tzw. złożoności obliczeniowej i prośba o napisanie bardziej optymalnego rozwiązania – podrzucam ściągę o tym temacie: https://github.com/TSiege/Tech-Interview-Cheat-Sheet#asymptotic-notation. Przy okazji pora na autoreklamę: czasem zdarza mi się napisać krótki newsletter techniczny i właśnie kiedyś opisywałam prostymi słowami o co chodzi w złożoności obliczeniowej – jeżeli chcesz dostawać takie materiały to zapraszam do zapisu do listy subskrybentów.
4. W miarę możliwości warto też postawić na czytelność kodu, chociażby zapewnić minimum jak używanie znaczących nazw zmiennych – gdy coś pójdzie nie tak łatwiej nam będzie się odnaleźć w czytelnym kodzie. O zasadach czytelności w SQL poczytasz na tym wpisie na blogu. 
5. Po napisaniu kodu w miarę możliwości przetestuj go sprawdzając wyniki na kilku przykładach, jeżeli to możliwe także uwzględniając przypadki brzegowe.

Podsumujmy sobie zatem jak powinien wyglądać live coding:

• Przećwicz wcześniej pisanie kodu pod presją czasu.
• W miarę możliwości spróbuj opanować nerwy i podejść do zadania na spokojnie.
• Gdy otrzymujesz zadanie, upewnij się, że je dokładnie rozumiesz
• Sparafrazuj zadanie rekruterowi i przedstaw twoją propozycję rozłożenia go na poszczególne kroki (jeżeli zadanie tego wymaga).
• Zacznij pisać kod, powoli krok po kroku sprawdzając, czy działa tak jak powinien.
• Prowadź komunikację z rekruterem. Gdy napotykasz problem nie zamykaj się w sobie, wręcz przeciwnie, wytłumacz z czym się borykasz i spróbuj uzgodnić możliwe rozwiązanie, np. sprawdzenie problemu w internecie.
• W miarę możliwości pisz czysty kod i przetestuj go przed zgłoszeniem jego ukończenia.

Dajcie znać w komentarzu czy macie doświadczenia z live codingiem na rekrutacji i czy macie jakieś swoje własne sposoby na jego przejście.

keywords: SQL, nauka SQL, analityk danych, jak zostać analitykiem danych, kursy SQL, jak się nauczyć SQL, SQL co oznacza, SQL dla początkujących, SQL czy python, python analityk danych, python data science, python data scientist, python jak się nauczyć, nauka pythona, python analiza danych, rekrutacja analityk danych, jak zostać data scientistem, data science jak zacząć, jak znaleźć pracę jako data scientist, rekrutacja, rekrutacja techniczna, programowanie, jak przejść przez live coding, jak przejsc przez live coding, live coding co to, live coding questions, live coding exercises, nauka programowania, programista, branża IT, branża it, branza it, live coding zadania, life coding, live coding tips, live coding ćwiczenia, live coding cwiczenia, live coding w rekrutacji, live coding to co znaczy, live coding co to oznacza, rekrutacja analityk danych, rekrutacja data scientist, analityk danych co trzeba umieć, data scientist co trzeba umieć, zadania rekrutacyjne analityk danych, zadania rekrutacyjne data scientist, zadania rekrutacyjne data science, zadania kwalifikacyjne analityk danych, zadania kwalifikacyjne data scientist, zadania kwalifikacyjne data science