Trudna rola IT nie zaczyna się od magicznego zapytania. Zaczyna się od odpowiedzi na pytanie: co ta osoba ma samodzielnie zmienić, w jakim środowisku i po czym poznamy, że naprawdę to robiła?
Krótka odpowiedź
Najlepszy workflow łączy cztery warstwy: precyzyjny brief techniczny, kilka wariantów języka wyszukiwania, ręczną kalibrację dowodów oraz kontakt, który nie udaje pewności. AI pomaga rozszerzyć mapę i uporządkować profile. Nie zastępuje eksperta, rozmowy ani decyzji kandydata.
To ważne w Polsce, gdzie ten sam tytuł może oznaczać zupełnie inną pracę. „Senior Backend Engineer” bywa właścicielem krytycznej usługi, osobą dowożącą zadania w zespole albo technicznym liderem małego produktu. Narzędzie wyszukiwawcze może znaleźć podobne profile, ale nie rozstrzygnie tej różnicy za rekrutera.
Ten tekst dotyczy wąskiego problemu: aktywnego sourcingu ról IT, których nie da się rozsądnie opisać jednym tytułem. Szerszy proces planowania kanałów, kontaktu i talent poolu opisuje przewodnik po sourcingu kandydatów. Tutaj skupiam się na pracy między dobrym briefem a pierwszą, ręcznie skalibrowaną shortlistą.
1. Zamień opis stanowiska na hipotezę techniczną
Właściciel roli powinien odpowiedzieć na pięć pytań: jaki produkt lub system rozwija zespół, jakie decyzje należą do tej osoby, z jakimi ograniczeniami się mierzy, jakie artefakty może pokazać oraz czego można nauczyć się po dołączeniu. „Znajomość chmury” jest za ogólna. „Projektowanie granic usług, obserwowalność i reakcja na awarie w środowisku Kubernetes” daje rekruterowi coś, co można sprawdzać.
Przykład hipotetyczny: firma szuka osoby do SRE dla platformy obsługującej płatności. Warunkiem nie musi być konkretny pracodawca ani identyczny tytuł. Istotne mogą być decyzje dotyczące niezawodności, automatyzacja wdrożeń, praca z incydentami, metryki i współpraca z zespołami produktowymi. W briefie oznacz osobno:
- warunki konieczne: np. odpowiedzialność za produkcyjną usługę i gotowość do pracy z incydentami;
- sygnały wspierające: Kubernetes, Terraform, monitoring, platform engineering, ale bez traktowania słów jako dowodu;
- pytania otwarte: skala, zakres samodzielności, udział w decyzjach i aktualność doświadczenia.
Przydatna jest prosta matryca briefu. Nie ma oceniać ludzi automatycznie; ma ułatwić wspólny język między klientem, rekruterem i ekspertem.
| Obszar | Pytanie do briefu | Przykład dowodu |
|---|---|---|
| Środowisko | Co działa dziś i co jest krytyczne? | Opis usługi, ograniczeń i dyżurów |
| Decyzja | Za co osoba odpowiadała samodzielnie? | Zmiana architektury, procesu lub narzędzia |
| Rezultat | Co się poprawiło i skąd to wiadomo? | Mierzalny opis incydentu, wdrożenia lub operacji |
| Luka | Czego nie da się potwierdzić publicznie? | Skala, udział własny, aktualność doświadczenia |
2. Szukaj także po rolach sąsiednich
Dobrze zdefiniowana mapa nie ogranicza się do jednego tytułu. Dla wspomnianej roli SRE sprawdź platform engineer, DevOps engineer, production engineer, cloud infrastructure engineer oraz osoby, które opisują się przez niezawodność, automatyzację lub operacje. Dla backendu dodaj service owner, software engineer z odpowiedzialnością za API oraz technicznego lidera, który nadal pracuje blisko kodu.
Każdy sąsiedni segment potrzebuje własnej hipotezy przejścia. Osoba z platform engineering może mieć właściwy kontekst, ale nie pracować z wymaganiami dostępności. Backend developer może rozumieć system rozproszony, lecz nie mieć doświadczenia on-call. Zapisz tę różnicę przy profilu. Nie zamieniaj podobieństwa w twierdzenie.
AI może tu pomóc na dwa sposoby: rozszerzyć słownik o warianty językowe oraz uporządkować większy zbiór profili. To nadal etap discovery. Shortlistę kalibruje człowiek znający rolę, najlepiej na małej próbce. Jeśli ekspert odrzuca kolejne osoby z tego samego powodu, popraw brief albo segment — nie tylko prompt.
Warianty zapytań zamiast jednego Boolean
Boolean nadal jest użyteczny, o ile traktujesz go jak serię hipotez. Zacznij od wariantu tytułowego: (SRE OR "site reliability" OR "platform engineer") AND (Kubernetes OR K8s) AND (Terraform OR "infrastructure as code"). Następnie przygotuj wariant oparty na odpowiedzialności: (incident OR on-call OR observability OR reliability) AND (Kubernetes OR cloud) AND (production OR platform). Trzeci wariant może szukać języka projektowego: (service mesh OR ArgoCD OR Prometheus OR Grafana) AND (AWS OR GCP OR Azure).
Te zapytania nie są równoważne. Pierwsze znajdzie osoby, które używają znanych nazw ról. Drugie może odkryć profile opisujące pracę, ale bez tytułu SRE. Trzecie daje tropy narzędziowe i wymaga szczególnie ostrożnej oceny kontekstu. Porównaj wyniki, usuń powtarzające się profile i zapisz, które słowa dały szum. Wyszukiwanie po polsku, angielsku i skrótach technicznych może odsłonić różne części rynku, ale żaden wariant nie gwarantuje kompletności. To ilustracyjne hipotezy, nie przenośna składnia: przed użyciem sprawdź operatory i limity pól w dokumentacji konkretnego narzędzia.
3. Traktuj GitHub jak źródło tropów, nie certyfikat
GitHub bywa przydatny przy rolach programistycznych, platformowych i data, ale łatwo przecenić jego znaczenie. Publiczne repozytorium może być ćwiczeniem, pracą zespołową, forkiem albo śladem dawnej aktywności. Brak profilu nie oznacza braku kompetencji. Dokumentacja GitHub opisuje możliwości wyszukiwania użytkowników, ale nie potwierdza autorstwa, poziomu ani gotowości do zmiany pracy — sprawdź oficjalną składnię wyszukiwania użytkowników.
Przy każdym publicznym sygnale zapisz: co dokładnie widzisz, kiedy to widzisz i czego nadal nie wiesz. „Kontrybucja do repozytorium” jest faktem. „Zaprojektował architekturę” jest hipotezą, dopóki kandydat lub referencja nie potwierdzi zakresu. Nie kopiuj wrażliwych danych z kodu ani nie proś o szczegóły projektów objętych poufnością.
4. Łącz nowe źródła z własnym CRM
Najbardziej pomijanym kanałem bywa własna historia relacji. Kandydat odrzucony przy innym mandacie może dziś pasować do roli, której wtedy nie było. Przed kolejnym wyszukiwaniem sprawdź duplikaty, datę ostatniego kontaktu, preferencje, powód odmowy i to, czy zapis opiera się na aktualnym źródle. CRM ma pomóc odtworzyć kontekst, nie uruchamiać automatycznej kampanii.
Połącz tę rediscovery z nowymi źródłami: LinkedIn, strony firm, społeczności techniczne, konferencje i publiczne profile projektowe. Każdy kanał ma luki. Nie obiecuj pełnego rynku i nie zakładaj, że profil publiczny jest świeży. Zespół powinien umieć powiedzieć, które segmenty sprawdził, a których nie mógł potwierdzić.
5. Kalibruj shortlistę przed kontaktem
Weź niewielką próbkę i przejdź ją wspólnie z ekspertem. Dla każdej osoby oznacz dowody, luki, pytanie weryfikacyjne i powód ewentualnego odrzucenia. Szukasz powtarzalności: czy rekruter i ekspert podobnie rozumieją „samodzielność”, „produkcję” albo „ownership”? Jeżeli nie, wróć do briefu.
Dopiero po tej kalibracji przygotuj kontakt. Wiadomość powinna nazwać konkretny problem, zakres odpowiedzialności i jeden sprawdzony powód, dla którego rozmowa może być interesująca. Nie udawaj pewności co do motywacji kandydata. Daj łatwą możliwość odmowy i nie powtarzaj tej samej wiadomości bez nowego, uzasadnionego kontekstu.
Przykładowa wiadomość do hipotetycznej osoby z doświadczeniem platformowym może brzmieć: „Dzień dobry, piszę w sprawie zespołu, który porządkuje niezawodność platformy płatniczej i rozwija obserwowalność. W publicznym opisie Pani/Pana pracy widzę wątek Kubernetes i automatyzacji wdrożeń; nie zakładam jednak zakresu odpowiedzialności. Czy rozmowa o roli z wpływem na incydenty, standardy platformy i decyzje operacyjne byłaby w ogóle interesująca? Jeśli nie, wystarczy krótka odmowa — nie będę wracać bez nowego kontekstu.” To szkic do weryfikacji, nie automatyczna sekwencja.
Po pierwszych rozmowach wróć do kalibracji. Jeżeli kandydaci rozumieją „SRE” jako pracę stricte operacyjną, a klient oczekuje projektowania platformy, rozbieżność jest informacją o briefie. Jeżeli odpowiadają osoby z dobrym kontekstem, ale odrzucają dyżury, problemem może być model pracy, nie jakość sourcingu. Taki feedback powinien zostać zapisany jako decyzja i hipoteza do kolejnej iteracji.
6. Mierz proces bez wymyślonych benchmarków
Nie potrzebujesz uniwersalnej liczby, która rzekomo dowodzi skuteczności. Ustal miary dla konkretnego mandatu: pokrycie segmentów, liczba profili z konkretnym dowodem, odsetek korekt po review, odpowiedzi, powody odmów i czas potrzebny na kolejną iterację briefu. Zestawiaj kanały ostrożnie — różnią się trudnością roli i jakością danych.
Po kilku iteracjach widać, czy problemem jest język wyszukiwania, zbyt wąski mandat, lokalizacja, model pracy czy sama propozycja. To właśnie jest wartość AI sourcingu: szybsza praca z hipotezami i większa pamięć procesu. Decyzja o dopasowaniu, kontakcie i dalszym przetwarzaniu danych nadal należy do ludzi.
W raporcie dla klienta pokaż nie tylko nazwiska. Wymień segmenty, które sprawdzono, warianty zapytań, liczbę profili wymagających ręcznej korekty oraz najczęstsze pytania bez odpowiedzi. Przy profilu oznacz dowód, źródło i datę, a obok napisz, czego nie wolno z niego wywnioskować. Taki zapis chroni zespół przed efektem pozornej precyzji: ranking może wyglądać dokładnie, choć opiera się na niepełnych danych.
Przy zmianie briefu zachowaj poprzednią wersję i powód korekty. Dzięki temu po kilku tygodniach wiadomo, czy rynek był zbyt mały, czy definicja roli była po prostu niejasna. Własny CRM staje się wtedy pamięcią decyzji: przechowuje rozmowę, korektę i preferencję kandydata, ale nie udaje, że publiczny sygnał jest zgodą na kontakt.
W praktyce ta dyscyplina oszczędza także czas eksperta. Zamiast kolejny raz czytać przypadkowe profile, widzi, które dowody już sprawdzono, jakie pytanie pozostało otwarte i jaki kompromis zaakceptował klient. To czyni kolejną sesję wyszukiwania bardziej celową, nawet jeśli odpowiedzi rynku nie są wygodne.
FAQ: AI sourcing ról IT w Polsce
Od czego zacząć sourcing trudnej roli IT?
Od krótkiego briefu z rezultatem, środowiskiem, decyzjami i dowodami pracy. Dopiero potem dobieraj tytuły, kanały i zapytania.
Czy GitHub potwierdza poziom techniczny kandydata?
Nie. Publiczne repozytorium pokazuje tylko dostępny ślad aktywności, nie autorstwo, aktualność ani odpowiedzialność za cały system. Wymaga ręcznej weryfikacji.
Czy AI zastępuje Boolean search i rozmowę eksperta?
Nie. Może pomóc rozszerzyć język zapytania i uporządkować profile, ale rekruter oraz ekspert kalibrują shortlistę i oddzielają fakt od hipotezy.
Co mierzyć w sourcingu IT bez arbitralnych benchmarków?
Pokrycie zdefiniowanych segmentów, odsetek profili z konkretnym dowodem, korekty po review, odpowiedzi, powody odmów i jakość kolejnej iteracji briefu.
Yena może wspierać warstwę discovery, a następnie zachować kontekst w ATS i recruiting CRM. Zakres i aktualne plany najlepiej omówić na demo; szczegóły oferty znajdziesz na stronie cennika. Jeśli potrzebujesz tylko prostego ogłoszenia i obsługi aplikacji, platforma do aktywnego sourcingu może nie być potrzebna.