Na rozmowie pada pytanie o różnicę między listą a krotką, a chwilę później trzeba wyjaśnić, czemu funkcja dopisuje dane do wyniku z poprzedniego wywołania. W pytaniach rekrutacyjnych z Pythona najczęściej liczy się rozumienie działania kodu, choć zakres rozmowy mocno zależy od stanowiska i poziomu doświadczenia.
Dobra odpowiedź pokazuje rozumowanie, nie recytację definicji
- Podstawy: mutowalność, argumenty domyślne, wyjątki i kolekcje.
- Praktyka: wyjaśniaj, co kod zwróci, gdzie może zawieść i jak to sprawdzić.
- Stanowisko: backend, data i automatyzacja wymagają innych przykładów.
- GIL: odpowiedź „w Pythonie wątki nie działają równolegle” jest zbyt uproszczona.
- Przygotowanie: ćwicz krótkie zadania z testami i mów na głos o kompromisach.
Najpierw sprawdź, czy rozumiesz obiekty i przepływ danych
Przy pytaniu o listę i krotkę nie wystarczy powiedzieć, że pierwsza jest mutowalna, a druga nie. Rekruter może dopytać, co stanie się po przekazaniu listy do funkcji, przypisaniu jej do kolejnej zmiennej albo użyciu jako wartości domyślnej. Liczy się wyjaśnienie skutku w konkretnym kodzie.
Przykładowe pytanie brzmi: „Co wypisze ta funkcja po dwóch wywołaniach?”
def add_item(item, items=[]):
items.append(item)
return items
print(add_item("a"))
print(add_item("b"))Wynikiem będą kolejno ["a"] i ["a", "b"], bo domyślna lista powstaje raz, przy definiowaniu funkcji, a potem jest współdzielona przez wywołania. Bezpieczniejszy wzorzec to wartość None i utworzenie nowej listy wewnątrz funkcji, jeśli argument jej nie przekazano. Takie zachowanie opisuje oficjalny samouczek Pythona.
Podobne pytania obejmują różnicę między is a ==, kopię płytką i głęboką, zakres zmiennych oraz wyjątki. Uważam, że przy każdym z nich najlepiej podać mały przykład i od razu nazwać pułapkę: odpowiedź brzmi wtedy jak wiedza z pracy z kodem, a nie wyuczona fiszka.
Jedno zadanie kodowe może ujawnić więcej niż definicje
Gdy dostajesz krótkie zadanie, nie zaczynaj od pośpiesznego pisania. Najpierw ustal zachowanie dla pustego wejścia, duplikatów i nietypowych wartości, a potem opowiedz, jaki wynik ma zwracać funkcja. To porządkuje rozwiązanie i daje rekruterowi szansę ocenić tok myślenia, nawet jeśli nie zdążysz dopracować każdej linijki.
Przykład: napisz funkcję, która zwraca najczęściej występujący element listy. Zanim wybierzesz słownik z licznikami, dopytaj, co zrobić przy remisie i pustej liście. To dwa warunki, które łatwo przeoczyć, gdy od razu skupiasz się na „głównym” algorytmie.
| Sytuacja na rozmowie | Co może ujawnić | Jak zareagować |
|---|---|---|
| Niejasne wymaganie dotyczące remisu | Brak ustalonej reguły może zmienić wynik funkcji. | Zapytaj, czy zwrócić pierwszy element, wszystkie remisy czy dowolny z nich. |
| Lista jest pusta | Nie istnieje element, który można wskazać jako najczęstszy. | Ustal, czy funkcja ma zwracać None, pusty wynik czy zgłaszać wyjątek. |
| Kod działa na przykładzie, ale nie na powtórzeniach | Rozwiązanie może pomijać aktualizację licznika lub błędnie rozstrzygać remis. | Dodaj przypadek z duplikatami i prześledź wartości krok po kroku. |
| Rozwiązanie jest poprawne, ale wolne | Możliwa niepotrzebna wielokrotna iteracja po danych. | Omów złożoność i pokaż, czy da się policzyć elementy w jednym przejściu. |
Po napisaniu kodu sprawdź go na małym przykładzie i nazwij jego złożoność, czyli sposób, w jaki rośnie koszt wraz z rozmiarem danych. W zadaniach juniorskich wystarczy zwykle solidna obsługa przypadków brzegowych; przy wyższych poziomach rozmówca może oczekiwać także uzasadnienia wyboru struktury danych.
GIL nie daje już odpowiedzi w jednym zdaniu
Pytanie o GIL często prowadzi do zbyt kategorycznej odpowiedzi: „wątki nie wykorzystują wielu rdzeni”. Dla typowego buildu CPythona ograniczenie to nadal jest ważne przy kodzie intensywnie obliczeniowym, ale od wersji 3.13 istnieje opcjonalny build free-threaded, w którym GIL może być wyłączony. Oficjalne FAQ Pythona zaznacza też, że nie jest to domyślna konfiguracja, a zgodność rozszerzeń może mieć znaczenie.
Na rozmowie rozdziel trzy przypadki. Przy operacjach wejścia-wyjścia wątki mogą pozwolić zadaniom postępować naprzemiennie, gdy jedno czeka na sieć lub dysk; przy intensywnych obliczeniach CPU typowym wyborem bywa wieloprocesowość; asyncio pasuje do współbieżnego I/O, gdy biblioteki i architektura aplikacji wspierają asynchroniczność. Najlepsza odpowiedź zależy od rodzaju pracy, nie od samej nazwy mechanizmu.
Jeśli pojawia się pytanie „czy GIL sprawia, że kod wielowątkowy jest bezpieczny?”, odpowiedz ostrożnie: nie należy traktować go jako zamiennika synchronizacji. Dokumentacja wskazuje, że nawet operacja wyglądająca prosto, jak zwiększenie licznika, nie musi być atomowa. Warto nazwać blokady lub inne mechanizmy synchronizacji i wyjaśnić, jaki wspólny stan trzeba chronić.
Poziom stanowiska zmienia zestaw pytań
Ten sam kandydat może dostać pytanie o dekorator na jednej rozmowie, a o projektowanie API na drugiej. Zakres przygotowań dobierz do zadań z ogłoszenia: backend zwykle kieruje uwagę ku HTTP, bazie danych i współbieżności, a rola data ku przetwarzaniu danych, walidacji i pracy z bibliotekami analitycznymi.
- Junior: przećwicz typy wbudowane, funkcje, wyjątki, pętle, testy jednostkowe i podstawowe zadania algorytmiczne.
- Mid: przygotuj przykłady pracy z API lub bazą, generatorami, dekoratorami, typowaniem i debugowaniem.
- Senior: spodziewaj się rozmowy o kompromisach architektonicznych, wydajności, obserwowalności, niezawodności i decyzjach zespołowych.
W każdym przypadku przygotuj jeden przykład z własnego projektu: problem, ograniczenia, rozważane rozwiązania i powód wyboru. Nie wystarczy wymienić technologii. Dobra opowieść pokazuje, co zadziałało, co było kosztem decyzji i czego nie dało się rozstrzygnąć bez dodatkowych danych.
Przy pytaniu o czytelność kodu możesz odwołać się do PEP 8, ale z ważnym zastrzeżeniem: zasady projektu mają pierwszeństwo przed stylem ogólnym. To dobry przykład odpowiedzi, która nie kończy się na nazwie standardu, tylko pokazuje umiejętność dostosowania go do zespołu.
Przygotowanie ma przypominać rozmowę, nie zakuwanie
Lista stu pytań może dać poczucie postępu, ale łatwo wtedy zapamiętać gotowe formułki bez umiejętności obrony odpowiedzi. Skuteczniejsza sesja to wybranie kilku tematów, napisanie krótkiego kodu, uruchomienie testów i głośne wyjaśnienie decyzji.
Przygotowując się do rozmowy, wybór padłby na trzy ćwiczenia: analizę błędnego fragmentu, małe zadanie na kolekcjach oraz omówienie projektu z CV. Taki zestaw sprawdza teorię, praktyczne kodowanie i umiejętność tłumaczenia decyzji, czyli trzy różne tryby rozmowy.
Gdy trafisz na pytanie, którego odpowiedzi nie znasz, nie zgaduj z pewnością. Powiedz, co wiesz, zaznacz założenie i zaproponuj sposób weryfikacji, na przykład test albo sprawdzenie zachowania biblioteki w dokumentacji. Uczciwe rozumowanie daje rozmówcy więcej informacji niż pewnie wypowiedziana, lecz błędna definicja.
Najlepsza odpowiedź łączy kod z uzasadnieniem
Przed rozmową dopracuj podstawy, ale nie ucz się ich w oderwaniu od przykładów. Pytanie o mutowalność może przejść w analizę działania funkcji, a pytanie o współbieżność w wybór architektury dla konkretnego obciążenia. Ćwicz przejście od pojęcia do konsekwencji, bo właśnie tam widać, czy potrafisz użyć Pythona w pracy.
Przy każdym rozwiązaniu zatrzymaj się na chwilę i dopowiedz, jakie przypadki testujesz oraz dlaczego wybrana metoda pasuje do zadania. Nawet krótka odpowiedź staje się mocniejsza, gdy słychać w niej jasne założenia, ograniczenia i decyzje.
