Jak ocenić umiejętności inżyniera AI/ML?

Czego szukamy w Senior inżynierze AI/ML

Rekrutacja inżyniera AI/ML w 2026 roku to zadanie inne niż rekrutacja klasycznego backend developera. Rynek przesunął się od „kogoś kto zna scikit-learn” do specjalisty, który rozumie zarówno fundamenty matematyczne (algebra liniowa, statystyka, optymalizacja), jak i pełny pipeline produkcyjny — od preprocessing’u danych, przez fine-tuning modeli foundation, aż po MLOps i monitorowanie modelu w produkcji. W ARDURA Consulting weryfikujemy kandydatów na role Senior AI/ML Engineer dla projektów obejmujących systemy rekomendacyjne, RAG (Retrieval-Augmented Generation), klasyfikację dokumentów, computer vision oraz wdrażanie LLM-ów w środowiskach enterprise.

Dobry Senior AI/ML Engineer powinien czuć się swobodnie w warstwie języka (Python z NumPy, pandas, scikit-learn), frameworków deep learning (TensorFlow, PyTorch, opcjonalnie JAX), ekosystemu LLM (Hugging Face Transformers, LangChain, ColBERT do retrievalu), narzędzi eksperymentacyjnych (MLflow, Weights & Biases) oraz infrastruktury MLOps (Kubeflow, Seldon Core, BentoML). Ważna jest umiejętność dobrania właściwego podejścia do problemu — kandydat, który na każde pytanie odpowiada „użyję GPT-4”, jest tak samo problematyczny jak ten, który na każde pytanie chce trenować model od zera.

W tym przewodniku znajdziesz konkretne pytania rekrutacyjne, scenariusze zadań technicznych oraz red flags, które wyłapujemy w procesie weryfikacji w ARDURA Consulting.

Top 15 pytań rekrutacyjnych (z odpowiedziami)

1. Czym różni się fine-tuning od RAG i kiedy wybrać które podejście? Fine-tuning modyfikuje wagi modelu na podstawie zbioru treningowego — sprawdza się, gdy potrzebujemy zmienić styl odpowiedzi, format wyjścia lub nauczyć model specyficznej domeny zamkniętej. RAG dodaje kontekst w czasie inferencji przez wyszukanie istotnych dokumentów w bazie wektorowej — sprawdza się, gdy wiedza często się zmienia, gdy zależy nam na cytowalności źródeł i gdy nie chcemy retreningować modelu przy każdej aktualizacji bazy wiedzy. Senior wskaże też hybrydę: fine-tuning na strukturę odpowiedzi + RAG na świeże dane.

2. Wyjaśnij architekturę transformera. Co to attention, multi-head attention, positional encoding? Self-attention pozwala każdemu tokenowi zwracać uwagę na inne tokeny w sekwencji z różną wagą. Multi-head attention uruchamia kilka równoległych warstw attention, by model uchwycił różne typy zależności. Positional encoding (sinusoidalny lub RoPE) wprowadza informację o pozycji, bo czyste attention jest permutacyjnie niezmiennicze. Senior powinien narysować architekturę encoder-decoder i wskazać różnicę między BERT (encoder-only), GPT (decoder-only) i T5 (encoder-decoder).

3. Jak debugujesz model, który dobrze działa na zbiorze treningowym, a źle na walidacyjnym? Klasyczny overfitting. Strategie: regularyzacja (dropout, weight decay), early stopping, augmentacja danych, redukcja pojemności modelu, cross-validation, sprawdzenie czy nie ma data leakage między train/val. Senior wspomni o sprawdzeniu distribution shift między zbiorami i o tym, że czasem problemem nie jest overfitting, a różnica rozkładów.

4. Jakich metryk używasz do oceny modelu klasyfikacyjnego i kiedy? Accuracy ma sens przy zbalansowanych klasach. Przy niezbalansowanych: precision, recall, F1, PR-AUC, ROC-AUC. Senior wskaże, że w problemach kosztowo asymetrycznych (np. wykrywanie fraudów) wybór threshold’u jest decyzją biznesową, nie matematyczną — pokaże confusion matrix i wykres precision-recall.

5. Jak ewaluujesz model generatywny (LLM)? Metryki automatyczne: BLEU, ROUGE, METEOR — przydatne dla zadań z referencjami, ograniczone dla otwartego generowania. Coraz częściej: LLM-as-a-judge (GPT-4 ocenia odpowiedzi), embeddingowe podobieństwo do referencji, ewaluacja faktyczności (czy odpowiedź zawiera halucynacje). Senior wspomni o human evaluation jako gold standard i o frameworkach typu RAGAS dla systemów RAG (faithfulness, answer relevancy, context precision).

6. Jak budujesz pipeline RAG? Etapy: (1) chunkowanie dokumentów (rozmiar 256-1024 tokenów, overlap 10-20%), (2) embedding (np. text-embedding-3-large lub e5-mistral-7b), (3) indeksowanie w bazie wektorowej (Pinecone, Weaviate, Qdrant, pgvector), (4) retrieval (najczęściej kombinacja semantic search + BM25, opcjonalnie ColBERT dla late-interaction), (5) reranking (cross-encoder), (6) generation z context window’em. Senior doda monitoring jakości retrievalu osobno od jakości generacji.

7. Co to halucynacje i jak je redukujesz? Halucynacje to generowanie informacji nieobecnych w kontekście. Redukcja: lepszy retrieval, instrukcja w prompcie “odpowiadaj tylko na podstawie kontekstu, jeśli nie wiesz — powiedz nie wiem”, grounded generation, citation enforcement, post-hoc verification (drugi model sprawdza faktyczność). Senior wspomni o constrained decoding i o tym, że temperature=0 nie eliminuje halucynacji.

8. Jak skalujesz training na wielu GPU? Data parallelism (DDP w PyTorch) replikuje model na każdym GPU i synchronizuje gradienty (NCCL). Model parallelism dzieli sam model (pipeline parallelism, tensor parallelism — używane w FSDP, DeepSpeed ZeRO). Senior wskaże, że dla większości projektów wystarczy DDP, a FSDP/DeepSpeed potrzebne dopiero gdy model nie mieści się na jednym GPU. Wspomni o mixed precision (fp16/bf16) i gradient accumulation.

9. Co to CUDA i jak diagnozujesz problemy z pamięcią GPU? CUDA to API NVIDIA do obliczeń na GPU. Problemy z pamięcią: torch.cuda.OutOfMemoryError. Diagnostyka: nvidia-smi, torch.cuda.memory_summary(), profiler PyTorch. Rozwiązania: zmniejszenie batch size, gradient checkpointing, mixed precision, czyszczenie cache (torch.cuda.empty_cache()), usunięcie nieużywanych tensorów.

10. Czym jest MLOps i jakich narzędzi używasz? MLOps to praktyki łączące ML z DevOps: wersjonowanie danych (DVC, LakeFS), wersjonowanie eksperymentów (MLflow, Weights & Biases), orkiestracja pipeline’ów (Kubeflow, Airflow, Dagster), serving (BentoML, Seldon Core, KServe, TorchServe), monitoring driftu (Evidently, Arize, Fiddler). Senior opowie o swojej ulubionej kombinacji i uzasadni wybór trade-offami.

11. Jak monitorujesz model w produkcji? Trzy warstwy: (1) infrastrukturalna — latency, throughput, error rate, (2) jakościowa — metryki business KPI, (3) ML-specific — data drift (PSI, KS test), concept drift, prediction drift, feature drift. Senior wspomni o A/B testach, shadow deployment i o tym, że metryka offline (np. accuracy) nie zawsze koreluje z metryką business.

12. Wyjaśnij prompt engineering. Jakie techniki znasz? Zero-shot, few-shot, chain-of-thought, self-consistency, ReAct, tree-of-thoughts, prompt chaining. Senior pokaże, że dobre prompty to: (1) jasna instrukcja, (2) format wyjścia (najlepiej JSON ze schematem), (3) przykłady, (4) constraints, (5) role definition. Wspomni o tym, że prompt engineering to iteracja, nie magia — i o wersjonowaniu promptów w git.

13. Jak wybierasz model — open source vs proprietary API? Trade-offy: koszty (API per-token vs infrastruktura), latency (lokalny vs sieć), prywatność danych (GDPR, dane wrażliwe = lokalnie), customization (open source = pełna kontrola), jakość (GPT-4 / Claude wciąż lepsze dla wielu zadań), vendor lock-in. Senior nie ma dogmatu — analizuje przypadek.

14. Co to jest evaluation harness i dlaczego jest ważny? Evaluation harness to zestaw testów uruchamianych regresyjnie na każdej zmianie modelu/promptu. Bez tego rozwój LLM-owy to jazda po omacku. Powinien zawierać: golden set (przykłady eksperckie), edge cases, adversarial examples, fairness/bias tests. Senior wspomni, że budowa harness’a to często więcej pracy niż sam model.

15. Opowiedz o najtrudniejszym problemie ML, jaki rozwiązałeś. Pytanie behawioralne. Słuchamy: czy kandydat rozumie problem biznesowy, czy potrafi przedstawić alternatywne podejścia i uzasadnić wybór, czy zna ograniczenia swojego rozwiązania, czy mierzył impact, czy potrafi mówić o porażkach.

Zadania techniczne — 3 scenariusze

Scenariusz 1: Live coding (60 min) — klasyfikator z scikit-learn + PyTorch Kandydat dostaje dataset (np. tabularny, 50k wierszy, 30 cech, target binary, lekko niezbalansowany). Zadanie: zbudować baseline w scikit-learn (LogisticRegression / RandomForest / XGBoost), policzyć metryki na hold-out (ROC-AUC, PR-AUC, F1), zaproponować strategię dla niezbalansowania (class_weight, SMOTE, threshold tuning). Następnie: zaimplementować prosty MLP w PyTorch (forward pass, training loop, validation loop, early stopping). Patrzymy na: znajomość API, czytelność kodu, używanie cross-validation, świadomość overfittingu, debugging mindset. Red flag: kopiowanie kodu z pamięci bez zrozumienia, brak walidacji.

Scenariusz 2: System design (45 min) — RAG dla bazy 500k dokumentów prawnych Kandydat ma zaprojektować system RAG dla kancelarii prawnej: 500k dokumentów PDF, codziennie 100 nowych, użytkownicy zadają pytania w języku naturalnym, wymagane cytowanie źródeł, latency p95 < 3s. Oczekujemy diagramu: ingestion pipeline (OCR, chunking, embedding, indeks), retrieval (hybrid search BM25 + dense, reranker), generation (LLM z grounding), evaluation, monitoring. Pytamy o: wybór bazy wektorowej (Pinecone vs Weaviate vs Qdrant — argumenty), strategie chunkowania pod dokumenty prawne (po sekcjach), obsługa updates (incremental indexing), kontrola kosztów (caching, semantic cache), bezpieczeństwo (PII, access control). Patrzymy na rozumowanie trade-offów.

Scenariusz 3: Code review (30 min) — pipeline z bugiem Pokazujemy kod treningowy ~150 linii z 4-6 ukrytymi problemami: (1) data leakage (StandardScaler.fit na całym zbiorze przed splitem), (2) brak model.eval() przed walidacją (dropout aktywny), (3) niepoprawne użycie optimizer.zero_grad() (po loss.backward()), (4) brak with torch.no_grad() w walidacji (pamięć GPU rośnie), (5) metryka liczona na batchach a uśredniana niepoprawnie, (6) random seed nieustawiony. Senior znajduje wszystkie w 30 minut i wyjaśnia konsekwencje. Mid-level znajduje 2-3.

Red flags i deal-breakers

Kandydat nie pisze testów dla kodu ML — to nie jest „specyfika ML”, to brak dojrzałości inżynierskiej. Modele można i trzeba testować: unit testy dla preprocessing’u, integration testy dla pipeline’u, regression testy na golden set. Brak znajomości Pythona na poziomie idiomów (list/dict comprehensions, generators, context managers) przy deklarowanym 5+ lat — alarm. Brak zrozumienia podstaw matematycznych (gradient descent, backprop, entropy) przy roli Senior — alarm. Mówienie wyłącznie o frameworkach bez rozumienia co dzieje się pod spodem — alarm. Brak doświadczenia produkcyjnego (tylko notebooki, brak deploy’u) — nie disqualifier, ale wymaga doprecyzowania roli. Brak pytań kandydata o projekt, zespół, stack — sygnał słabego zaangażowania. Wreszcie: deklarowanie „znam GPT, Claude i Gemini” bez umiejętności porównania ich pod kątem konkretnego zadania = powierzchowność.

Jak ARDURA Consulting weryfikuje kandydatów

W ARDURA Consulting prowadzimy 3-etapowy proces weryfikacji Senior AI/ML Engineerów w 5 dni roboczych. Etap 1 (dzień 1) — screening CV + 30-minutowa rozmowa techniczna z naszym lead engineerem, podczas której zadajemy 8-10 pytań z listy powyżej i weryfikujemy znajomość stacku zgodnego z wymaganiami klienta. Etap 2 (dni 2-3) — zadanie techniczne live (90 minut): live coding z PyTorch/scikit-learn + system design RAG/recommendation/classification + code review. Etap 3 (dzień 4) — rozmowa z naszym CTO o doświadczeniu projektowym, dopasowaniu kulturowym, oczekiwaniach finansowych i dostępności. Dzień 5 — finalna decyzja i przekazanie kandydata klientowi z pełnym raportem (mocne strony, ryzyka, rekomendacja seniority). Korzystamy z bazy 500+ zweryfikowanych seniorów, 99% retencji i średnio 2 tygodnie do wdrożenia kandydata w projekt klienta. Sprawdź dostępnych ekspertów →