Python jest najczęściej używany jako język interpretowany (dokładniej: uruchamiany przez interpreter/VM), co daje szybki development kosztem części wydajności runtime.

Na rozmowie dobrze powiedzieć praktycznie: Python zwykle wygrywa produktywnością i czytelnością, a C/C++ częściej wydajnością i kontrolą nad pamięcią.

list jest mutowalna, a tuple niemutowalna.

W praktyce lista służy do danych, które zmieniasz, a tuple do danych, które traktujesz bardziej jak stały rekord.

Na rozmowie warto dodać, że tuple może być użyte jako klucz w słowniku (jeśli jego elementy też są hashowalne), a list nie.

== porównuje wartości, a is sprawdza, czy to ten sam obiekt w pamięci.

To klasyczne pytanie rekrutacyjne. Najważniejszy przykład praktyczny: porównanie z None robi się zwykle przez is None, a nie == None.

List comprehension to skrócony, czytelny sposób tworzenia list na podstawie iteracji i warunku.

squares = [x * x for x in numbers if x > 0]

Na rozmowie warto podkreślić, że są świetne dla prostych transformacji, ale przy złożonej logice lepiej wrócić do zwykłej pętli dla czytelności.

Mutowalne obiekty można zmieniać „w miejscu” (np. lista, dict), a niemutowalne nie (np. int, str, tuple).

To ważne na rozmowie, bo wpływa na kopiowanie, przekazywanie argumentów i potencjalne bugi przy współdzielonych referencjach.

*args zbiera dodatkowe argumenty pozycyjne, a **kwargs zbiera dodatkowe argumenty nazwane.

To przydatne, gdy piszesz elastyczne funkcje lub wrappery/dekoratory.

Na rozmowie warto odpowiedzieć prosto i praktycznie, bez komplikowania: jedno zbiera tuple argumentów, drugie dict parametrów nazwanych.

Ten warunek pozwala rozróżnić, czy plik został uruchomiony bezpośrednio, czy zaimportowany jako moduł.

Dzięki temu możesz mieć w jednym pliku zarówno definicje funkcji/klas, jak i kod uruchamiany tylko przy bezpośrednim starcie skryptu.

Na rozmowie to prosty temat, ale dobrze pokazuje, że rozumiesz podstawy pracy z modułami w Pythonie.

lambda pozwala zdefiniować małą anonimową funkcję w jednej linii.

Sprawdza się np. w prostych callbackach czy kluczach sortowania, ale przy bardziej złożonej logice lepiej użyć normalnej funkcji z def dla czytelności.

Na rozmowie dobra odpowiedź to właśnie rozsądne użycie, a nie „wszystko da się zrobić lambdą”.

Moduł to pojedynczy plik Python z kodem, a pakiet to katalog (namespace) grupujący moduły.

Na rozmowie warto odpowiedzieć praktycznie: moduły i pakiety pomagają organizować kod i unikać chaosu w większych projektach.

enumerate() zwraca pary indeks + wartość podczas iteracji, dzięki czemu kod jest czytelniejszy niż ręczne zwiększanie licznika.

To prosty temat, ale na rozmowie pokazuje znajomość idiomatycznego Pythona.

append() dodaje jeden element na koniec listy, a extend() dodaje wiele elementów z iterowalnego obiektu.

Na rozmowie warto odpowiedzieć z prostym przykładem, bo to częsta pułapka przy pracy z listami.

List comprehension tworzy listę od razu, a generator expression zwraca generator i generuje wartości leniwie.

Na rozmowie warto podkreślić aspekt pamięci i zastosowania: przy dużych danych generator często jest lepszym wyborem.

zip() łączy elementy z kilku iterowalnych obiektów w pary/tuples iterowane równolegle.

To bardzo praktyczne przy pracy na dwóch listach naraz i często daje czytelniejszy kod niż ręczne indeksowanie.

Na rozmowie warto wspomnieć, że długość wyniku zależy od najkrótszej sekwencji (w standardowym użyciu).

any() zwraca True, jeśli przynajmniej jeden element jest truthy, a all() tylko gdy wszystkie są truthy.

Na rozmowie warto podać prosty przykład walidacji warunków, bo to pokazuje idiomatyczny styl Pythona i czytelne operowanie na iterowalnych danych.

list.sort() sortuje listę w miejscu, a sorted() zwraca nową posortowaną sekwencję i działa też na innych iterowalnych obiektach.

Na rozmowie to częsta pułapka podobna do innych pytań o mutację vs niemutowanie.

W Pythonie porównanie do None zwykle robi się przez is None, bo sprawdza tożsamość singletona None i jest idiomatyczne.

Na rozmowie to prosty, ale dobry sygnał, że znasz styl i praktyki języka.

Oba rozwiązania służą do transformacji danych, ale list comprehension często bywa czytelniejsze dla prostych przypadków.

Na rozmowie dobra odpowiedź to nie wojna narzędzi, tylko pragmatyzm: wybieram to, co jest bardziej czytelne w danym kontekście.

pass nic nie robi (placeholder), continue przechodzi do następnej iteracji, a break kończy pętlę.

To podstawowy temat, ale na rozmowie często sprawdza uważność i zrozumienie flow sterowania.

dict przechowuje pary klucz-wartość i daje bardzo szybki dostęp po kluczu.

W praktyce to jedna z najważniejszych struktur danych w Pythonie.

Na rozmowie dobrze wspomnieć, że klucze muszą być hashowalne (np. string, int, tuple z hashowalnych elementów).

Shallow copy kopiuje tylko pierwszy poziom, więc zagnieżdżone obiekty nadal są współdzielone. Deep copy kopiuje całą strukturę.

Na rozmowie warto pokazać świadomość problemu przy listach/dictach zagnieżdżonych oraz wspomnieć o module copy (copy() vs deepcopy()).

set to kolekcja unikalnych elementów, bardzo przydatna do usuwania duplikatów i szybkiego sprawdzania przynależności.

Na rozmowie warto powiedzieć praktycznie: gdy potrzebuję unikalności albo szybkiego in, często set jest lepszy niż lista.

copy.copy() robi płytką kopię, a copy.deepcopy() próbuje skopiować całą zagnieżdżoną strukturę.

Na rozmowie warto podać praktyczny scenariusz z listą słowników, gdzie shallow copy prowadzi do nieoczekiwanych modyfikacji współdzielonych danych.

Zwykły tuple jest prosty i lekki, ale mniej czytelny semantycznie przy większej liczbie pól. namedtuple i dataclass poprawiają czytelność przez nazwy pól.

Na rozmowie warto pokazać, że dobierasz strukturę do potrzeb: prostota vs czytelność modelu danych.

dict[key] rzuci błąd, jeśli klucz nie istnieje, a dict.get() pozwala bezpiecznie pobrać wartość (lub domyślną).

Na rozmowie warto powiedzieć, że wybór zależy od semantyki: czasem brak klucza to błąd, a czasem normalny przypadek biznesowy.

Counter upraszcza zliczanie wystąpień elementów bez ręcznego pisania pętli i warunków.

Na rozmowie to dobry przykład znajomości standardowej biblioteki i idiomatycznego podejścia zamiast wynajdywania koła na nowo.

collections.defaultdict pozwala automatycznie tworzyć wartości domyślne dla brakujących kluczy (np. listy, liczniki), dzięki czemu kod jest krótszy i czytelniejszy.

Na rozmowie warto podać przykład grupowania elementów bez ciągłego sprawdzania, czy klucz już istnieje.

list to sekwencja (kolejność), set to unikalność i szybkie membership check, a dict to mapowanie klucz-wartość.

Na rozmowie warto odpowiedzieć przez use case zamiast samych definicji struktur danych.

deepcopy służy do kopiowania struktur obiektów w pamięci, a serializacja/deserializacja to inny mechanizm, zwykle używany do zapisu/przesyłania danych.

Na rozmowie warto powiedzieć pragmatycznie: czasem serializacja „działa” jako obejście, ale to nie zawsze dobre ani wydajne rozwiązanie do kopiowania.

Python wspiera klasy, dziedziczenie, polimorfizm i enkapsulację, ale robi to w dość elastyczny sposób.

Na rozmowie warto pokazać praktyczne rozumienie: kiedy użyć klasy, kiedy zwykłej funkcji/modułu, oraz że Python preferuje czytelność ponad „przeinżynierowane” hierarchie.

@property pozwala udostępnić metodę jak atrybut, co daje czytelne API obiektu przy zachowaniu kontroli nad logiką odczytu/zapisu.

Na rozmowie warto powiedzieć, że to dobre narzędzie do enkapsulacji i walidacji bez psucia wygodnej składni.

@staticmethod nie dostaje ani self, ani cls - to po prostu funkcja umieszczona w klasie dla organizacji.

@classmethod dostaje cls i może pracować na klasie (np. alternate constructors).

Na rozmowie warto podać właśnie przykład metody fabrykującej obiekt jako typowego użycia @classmethod.

__str__ to bardziej „czytelna” reprezentacja dla użytkownika, a __repr__ to reprezentacja bardziej techniczna/developerska.

Na rozmowie to prosty, ale dobry temat pokazujący znajomość idiomów Pythona i pracy z debugowaniem/logowaniem.

Dekorator to funkcja, która opakowuje inną funkcję (lub klasę), dodając jej zachowanie bez zmiany kodu wewnątrz.

Typowe użycia: logging, cache, autoryzacja, walidacja.

Na rozmowie warto zaznaczyć, że dekoratory bazują na closure i funkcjach wyższego rzędu.

Generator zwraca wartości po kolei przez yield, zamiast tworzyć całą kolekcję od razu.

To przydatne przy dużych danych i streamowaniu, bo oszczędza pamięć.

Na rozmowie dobrze podać prosty przykład i powiedzieć, że generator jest iterowalny i „leniwy” (lazy).

Iterable to obiekt, po którym można iterować (np. lista, tuple, string). Iterator to obiekt, który zwraca kolejne elementy i pamięta stan iteracji.

Na rozmowie warto powiedzieć to prostym językiem: iterable to „coś po czym da się przejść”, iterator to „mechanizm, który to przejście wykonuje”.

Context manager automatyzuje setup/cleanup zasobów (np. plików, połączeń, locków), dzięki czemu kod jest bezpieczniejszy i czytelniejszy.

with open(\"file.txt\") as f:
    data = f.read()

Na rozmowie warto powiedzieć, że with pomaga gwarantować cleanup nawet przy wyjątku.

Poza użyciem gotowych context managerów możesz tworzyć własne, implementując odpowiedni protokół lub używając narzędzi ułatwiających ten wzorzec.

Na rozmowie warto pokazać rozumienie idei: kontrolowany setup/cleanup zasobów i czytelny lifecycle operacji.

Niektóre obiekty (np. generatory) zużywają się podczas iteracji, a kolekcje jak lista można iterować wielokrotnie.

Na rozmowie warto podkreślić praktyczny skutek: po przejściu iteratora możesz nie mieć już danych, jeśli nie zapisałeś ich wcześniej.

W Pythonie używasz try/except/finally (i opcjonalnie else).

Na rozmowie warto podkreślić dwie rzeczy:

• łap konkretne wyjątki zamiast gołego except,
• nie ukrywaj błędów bez logowania / sensownej reakcji.

Dobra odpowiedź pokazuje, że myślisz o niezawodności i debugowalności kodu.

Dobra praktyka to łapać konkretne wyjątki, logować kontekst i nie używać gołego except bez powodu.

Na rozmowie warto podkreślić, że wyjątek to informacja diagnostyczna, więc „połknięcie” go bez logowania utrudnia utrzymanie systemu.

venv (virtual environment) izoluje zależności projektu od globalnej instalacji Pythona.

Dzięki temu różne projekty mogą mieć różne wersje bibliotek bez konfliktów.

Na rozmowie to jest podstawowy temat praktyczny - warto wspomnieć też o requirements.txt lub odpowiedniku narzędzia używanego w projekcie.

pip służy do instalacji pakietów Pythona. requirements.txt to prosty sposób zapisania zależności projektu (często z wersjami).

Na rozmowie warto dodać, że przypinanie wersji pomaga w powtarzalności środowiska i wdrożeń.

venv rozwiązuje izolację środowiska, a narzędzia typu Poetry/Pipenv próbują dodatkowo uporządkować zarządzanie zależnościami i lockfile.

Na rozmowie warto powiedzieć pragmatycznie: ważna jest powtarzalność środowiska i jasny workflow w zespole, nie „religijna wojna narzędzi”.

pip instaluje pakiety, ale w praktyce ważne jest też pinowanie wersji i kontrola kompatybilności zależności.

Na rozmowie dobra odpowiedź: używam izolacji środowiska, pinuję wersje tam gdzie trzeba i dbam o reprodukowalne środowisko, zamiast instalować „na żywo” globalnie.

pathlib daje wygodniejsze i czytelniejsze API do pracy ze ścieżkami niż ręczne składanie stringów.

Na rozmowie warto podkreślić praktykę: mniej błędów, lepsza czytelność i wygodniejsze operacje na plikach/katalogach.

W kodzie aplikacyjnym lepiej używać modułu logging, bo daje poziomy logów, formatowanie, handlery i kontrolę nad miejscem zapisu.

Na rozmowie dobra odpowiedź: print() bywa OK do szybkiego debugowania, ale w realnym systemie potrzebujesz sensownego logowania i kontekstu.

GIL (Global Interpreter Lock) w CPython ogranicza wykonywanie kodu Pythona do jednego wątku naraz w obrębie procesu.

Na rozmowie ważne jest rozróżnienie:

• wątki nadal mają sens dla I/O (np. sieć),
• dla CPU-bound zadań często lepszy jest multiprocessing.

To pokazuje, że rozumiesz praktyczne konsekwencje, a nie tylko znasz skrót.

Najpierw mierz, potem optymalizuj. To najważniejsza odpowiedź rekrutacyjna.

W praktyce warto zacząć od profilowania, sprawdzenia bottlenecków, algorytmów, I/O i dopiero potem mikrooptymalizacji składni.

Na rozmowie dobrze brzmi pragmatyczne podejście: poprawiam to, co naprawdę boli w produkcji, a nie zgaduję.

Warto przetwarzać dane strumieniowo/iteracyjnie zamiast wczytywać cały plik do pamięci naraz.

Na rozmowie dobra odpowiedź pokazuje zrozumienie generatorów, iteratorów i praktycznego podejścia do I/O oraz pamięci.

Multithreading uruchamia wiele wątków w jednym procesie i dobrze sprawdza się głównie przy I/O-bound zadaniach. Multiprocessing uruchamia osobne procesy i omija ograniczenia GIL dla CPU-bound pracy.

Na rozmowie dobra odpowiedź to: wybór zależy od typu problemu (I/O vs CPU), a nie od „co jest szybsze ogólnie”.

asyncio to framework do asynchronicznego I/O w Pythonie oparty o event loop, async i await.

Najlepiej sprawdza się przy dużej liczbie operacji I/O (np. sieć), a nie jako uniwersalny lek na wszystko.

Na rozmowie dobra odpowiedź to rozróżnienie: I/O-bound -> asyncio może pomóc, CPU-bound -> często lepiej multiprocessing.

dataclass to wygodny sposób definiowania klas przechowujących dane bez pisania dużej ilości boilerplate (np. __init__, __repr__).

Na rozmowie warto powiedzieć, że to świetne narzędzie do modeli danych, DTO i prostych struktur, gdy nie potrzebujesz rozbudowanej logiki obiektowej.

Type hints w Pythonie poprawiają czytelność kodu, wspierają IDE i narzędzia statycznej analizy (np. mypy), ale nie są pełnym systemem typów runtime jak w językach statycznych.

Na rozmowie warto powiedzieć, że pomagają w większych projektach i współpracy w zespole, szczególnie przy API funkcji i strukturach danych.

unittest jest w standardowej bibliotece, a pytest często daje wygodniejszą składnię i bogaty ekosystem pluginów.

Na rozmowie warto powiedzieć pragmatycznie: narzędzie jest ważne, ale ważniejsze jest co testujesz (logika biznesowa, edge casey, integracje) i jak utrzymujesz testy czytelne.

Takie funkcje warto projektować tak, żeby dało się wstrzyknąć źródło czasu albo zamockować je w testach.

Na rozmowie to pokazuje dojrzałość projektową: zamiast walczyć z trudnym testem, projektujesz kod bardziej testowalny.

Warto testować kluczowe integracje i przepływy, ale świadomie ograniczać zakres danych/scenariuszy i dbać o izolację środowiska testowego.

Na rozmowie dobra odpowiedź to balans: nie same unit testy, ale też nie tysiące ciężkich integracji odpalanych bez strategii.

Najważniejsze jest sensowne rozdzielenie odpowiedzialności: logika biznesowa, warstwa wejścia/CLI/API, konfiguracja, testy.

Na rozmowie dobra odpowiedź to myślenie o czytelności i skalowaniu projektu, a nie tylko o pojedynczym pliku, który „działa”.

W większym projekcie warto mieć spójne miejsce i zasady walidacji zamiast rozrzucać przypadkowe ify po całym kodzie.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o czytelności, testowalności i jednolitych komunikatach błędów, a nie tylko o pojedynczej funkcji.

Lepsze podejście to grupowanie kodu według odpowiedzialności/domeny zamiast wrzucania wszystkiego do jednego worka.

Na rozmowie taka odpowiedź pokazuje, że myślisz o utrzymaniu projektu i czytelności modułów wraz z jego rozrostem.

Najczęściej pomaga lepszy podział odpowiedzialności i ograniczenie wzajemnych zależności między modułami.

Na rozmowie dobra odpowiedź pokazuje, że widzisz problem architektoniczny, a nie tylko próbujesz „obejść import” sztuczką w jednej linijce.

Warto rozdzielać konfigurację od kodu, unikać trzymania sekretów w repo i jasno definiować źródła konfiguracji dla różnych środowisk.

Na rozmowie taka odpowiedź pokazuje myślenie produkcyjne, a nie tylko uruchamianie skryptu lokalnie.

Samo zparsowanie JSON-a to dopiero początek - potem trzeba jeszcze sprawdzić strukturę i typy danych zgodnie z oczekiwanym kontraktem.

Na rozmowie dobra odpowiedź pokazuje, że nie zakładasz „JSON się zparsował = dane są poprawne”.