Czy więcej etapów to lepsza decyzja? Jak skrócić proces rekrutacji IT bez utraty jakości
W rekrutacji IT zdarza się, że mnogość etapów staje się barierą w znalezieniu odpowiedniej osoby w optymalnym czasie. Najpierw odbywa się rozmowa z HR, potem techniczna, następnie kolejna techniczna „dla pewności”, a na końcu spotkanie z menedżerem projektu albo przedstawicielem biznesu.
Każde z tych spotkań może mieć swoje uzasadnienie. Problem pojawia się wtedy, gdy cały proces nie prowadzi do lepszej decyzji, tylko ją opóźnia. Gdy dwie rozmowy sprawdzają to samo, a feedback wraca po tygodniu, najlepsi kandydaci odpadają nie dlatego, że nie pasują, ale dlatego, że nie czekają.
Dlaczego liczba etapów rośnie, choć nikt tego nie planuje?
Zazwyczaj nie dzieje się tak dlatego, że firma źle rekrutuje. Częściej wynika to z faktu, że każda osoba zaangażowana w proces próbuje zabezpieczyć swój obszar odpowiedzialności.
CTO chce mieć pewność, że kandydat dowiezie projekt i nie będzie wymagał prowadzenia za rękę. HR dba o candidate experience i spójność procesu, ale nie zawsze ma techniczną wiedzę, aby ocenić niuanse kompetencji. Procurement potrzebuje dokumentacji, porównywalnych warunków i zgodności z procedurami.
Każda z tych perspektyw jest uzasadniona. Problem pojawia się wtedy, gdy zamiast jednego modelu decyzyjnego powstaje seria osobnych kontroli. Kandydat odpowiada na podobne pytania kilka razy, menedżerowie nie mają wspólnej karty oceny, a decyzja zapada dopiero wtedy, gdy wszyscy czują się komfortowo. W IT to zdecydowanie za wolno.
Co może zrobić agencja rekrutacyjna IT?
Dobra agencja rekrutacyjna IT nie dokłada kolejnego etapu do procesu. Jej rolą jest pomoc w wyeliminowaniu tych elementów, które są zbędne lub powtarzalne.
W praktyce oznacza to kilka konkretnych działań:
- szczegółowe doprecyzowanie profilu przed startem rekrutacji, a nie dopiero po trzech nietrafionych kandydatach,
- ustalenie kryteriów must-have i nice-to-have, które faktycznie wpływają na decyzję,
- weryfikację motywacji, dostępności i oczekiwań finansowych kandydata,
- przygotowanie rekomendacji zawierającej informację, dlaczego dana osoba pasuje do projektu, a nie tylko spełnia wymagania formalne.
To szczególnie istotne w rekrutacji technicznej. Kandydat może mieć pięć lat doświadczenia w Javie i jednocześnie nie pasować do zespołu utrzymującego system legacy. Może znać rozwiązania chmurowe, ale nigdy nie pracować w środowisku regulowanym. Agencja, która zna rynek IT, powinna wyłapać takie ryzyka przed rozmową z klientem, a nie dopiero po niej.
Model trzech bramek decyzyjnych
Zamiast mechanicznie usuwać etapy, warto spojrzeć na proces rekrutacji jak na trzy bramki decyzyjne. Każda z nich ma inny cel i innego właściciela.
Bramka 1: kwalifikacja
Na tym etapie nie trzeba jeszcze angażować zespołu technicznego. Kluczowe jest uzyskanie odpowiedzi na pytania, które zbyt często pojawiają się dopiero na końcu procesu.
- Czy kandydat rozumie charakter projektu?
- Czy odpowiada mu model współpracy: B2B, UoP lub hybryda?
- Czy jego dostępność pasuje do harmonogramu?
- Czy oczekiwania finansowe mieszczą się w budżecie?
- Czy nie ma oczywistych ryzyk komunikacyjnych?
To etap, który agencja może przejąć w całości. Dobra rekomendacja nie powinna ograniczać się do stwierdzenia, że „kandydat spełnia wymagania”. Powinna zawierać kontekst: dlaczego kandydat rozważa zmianę, czego oczekuje i jakie pytania warto zadać w kolejnym kroku.
Bramka 2: rozmowa techniczno-projektowa
To najważniejszy moment całego procesu. Jedna dobrze zaprojektowana rozmowa z tech leadem i hiring managerem może zastąpić dwa lub trzy osobne spotkania techniczne.
Rozmowa powinna sprawdzać nie tylko znajomość technologii, ale również sposób myślenia kandydata. Zamiast pytać: „Czy zna Pan Kubernetes?”, lepiej zapytać o konkretną sytuację: awarię produkcyjną, spór architektoniczny albo decyzję między szybkością a jakością. Taka odpowiedź mówi znacznie więcej niż lista technologii w CV.
Bramka 3: decyzja i domknięcie
Ostatni etap nie powinien być kolejną pełną rozmową rekrutacyjną. Powinien służyć domknięciu procesu: potwierdzeniu warunków, dostępności oraz formalności.
Warto wcześniej ustalić, jakie warunki muszą zostać zaakceptowane, aby uniknąć przeciągania decyzji i powrotu do tematów, które powinny być wyjaśnione wcześniej.
Ramy oceny: role techniczne a role biznesowe
Redukcja etapów ma sens tylko wtedy, gdy firma wie, co właściwie ocenia. W przeciwnym razie każdy skrócony proces będzie odbierany jako kompromis jakościowy.
Role techniczne
W przypadku ról technicznych zbyt często przecenia się listę technologii w CV, a zbyt mało uwagi poświęca się kontekstowi pracy. Dla senior developera, DevOpsa czy data engineera kluczowe pytania powinny dotyczyć nie tylko narzędzi, ale także sposobu działania w realnym środowisku projektowym.
Warto sprawdzić przede wszystkim:
- skalę systemów, z którymi kandydat pracował,
- poziom samodzielności,
- jakość decyzji technicznych,
- pracę pod presją i z niejasnymi wymaganiami,
- komunikację z zespołem i biznesem.
Role biznesowe
W rolach takich jak Project Manager, Business Analyst czy Product Owner ważna jest inna logika oceny. Kompetencje techniczne są istotne, ale równie ważne jest to, jak kandydat pracuje z interesariuszami, priorytetami i konfliktem.
W takich przypadkach dodatkowy etap bywa uzasadniony, ale tylko wtedy, gdy ma własny, jasno określony cel. Nie powinien być powtórzeniem wcześniejszej rozmowy.
Przykład z życia: jak pięć etapów zamienić w trzy
Firma technologiczna szukała senior backend developera do projektu migracyjnego. Proces wyglądał standardowo: rozmowa z HR, dwie rozmowy techniczne, spotkanie z menedżerem i domknięcie z HR.
Teoretycznie był to proces dokładny. W praktyce trwał za długo. Kandydaci czekali na feedback, a najlepsi w międzyczasie przyjmowali inne oferty.
Po przeprojektowaniu procesu agencja zaproponowała trzy zmiany:
- doprecyzowanie profilu — nie „senior Java developer”, ale osoba z doświadczeniem w migracji, pracy z legacy i gotowością do startu w ciągu 4 tygodni,
- przejęcie kwalifikacji, weryfikacji motywacji i oczekiwań finansowych,
- połączenie rozmów technicznych w jedno spotkanie z tech leadem i hiring managerem.
W efekcie pięć etapów zamieniło się w trzy. Nie usunięto oceny jakości. Usunięto powtórzenia. To zasadnicza różnica.
Najczęstsze obawy przy skracaniu procesu rekrutacji IT
„Stracimy kontrolę nad procesem”
W praktyce dobrze zaprojektowany krótszy proces daje więcej kontroli, ponieważ każdy etap ma jasny cel i właściciela. HR nie znika z procesu, ale staje się jego moderatorem.
„Menedżer musi sam ocenić kandydata”
Oczywiście, że musi. Skrócenie procesu nie oznacza rezygnacji z rozmowy technicznej. Oznacza, że menedżer rozmawia tylko z kandydatami, którzy przeszli sensowną kwalifikację. To oszczędza czas i poprawia jakość rozmowy.
„Szybciej znaczy drożej”
Niekoniecznie. Drogi jest również wakat, opóźniony projekt i utracony kandydat. Przy rolach projektowych koszt braku decyzji bywa mniej widoczny w Excelu, ale bardzo realny w delivery.
Jak zacząć skracanie procesu rekrutacji IT?
Nie trzeba przebudowywać całego procesu od razu. Wystarczy zacząć od audytu jednej roli i odpowiedzieć na kilka kluczowych pytań.
- Które etapy sprawdzają te same kompetencje?
- Kto naprawdę podejmuje decyzję?
- Jakie informacje musimy mieć przed rozmową z menedżerem?
- Ile czasu mija między rozmową a feedbackiem?
- Po czym poznamy, że kandydat jest wystarczająco dobry do oferty?
To proste pytania, ale odpowiedzi na nie często pokazują, gdzie proces traci tempo. Dobra agencja rekrutacyjna IT może pomóc przeprowadzić taki audyt szybciej, szczególnie jeśli zna realia ról technicznych, rozumie presję projektową i wie, jakie potrzeby stoją za prowadzonym projektem technologicznym.
Podsumowanie
Większa liczba etapów w rekrutacji IT nie zawsze oznacza lepszą decyzję. Często prowadzi jedynie do opóźnień, powtarzania tych samych pytań i utraty najlepszych kandydatów.
Skuteczny proces rekrutacyjny powinien być krótki, ale dobrze zaprojektowany. Kluczowe jest jasne określenie kryteriów, odpowiedzialności i celu każdego etapu. Dzięki temu firma nie rezygnuje z jakości, ale eliminuje chaos, powtórzenia i niepotrzebne opóźnienia.


 px).png)


