Przez ostatnią dekadę przygotowanie do rozmowy technicznej wyglądało prosto: otwierasz listę Blind 75 albo LeetCode 150, zamykasz się sam w pokoju na miesiąc, w ciszy rozwiązujesz zadania na czas, a potem dostajesz ofertę.
W 2026 roku ten przepis stał się niebezpieczną pułapką dla programistów.
Jak podsumowuje przegląd Tech Interviews in the AI Era: The Rules Are Being Rewritten, rekrutacja w IT mocno się zmieniła. Asystenci AI (Cursor, Claude Code, GitHub Copilot) piszą podstawowe algorytmy i typowe komponenty w kilka sekund, więc sprawdzanie, czy kandydat umie w ciszy pisać kod z pamięci, straciło sens.
Budujemy Skill Rally z myślą o tym nowym formacie, a nasza główna teza jest prosta: dobrzy inżynierowie z ponad 5-letnim doświadczeniem oblewają rozmowy nie dlatego, że nie znają technologii, ale dlatego, że przygotowali się do egzaminu z 2021 roku, a przyszli na egzamin z 2026.
Poniżej na danych z branży pokazujemy, jak firmy prowadzą dziś rozmowy, dlaczego doświadczeni inżynierowie „zamierają” w nowych rundach i jak próbne rozmowy P2P pomagają się do nich przygotować.
Raporty Google DORA i Karat oraz blogi inżynierskie firm produktowych pokazują jedno: firmy sprawdzają dziś kandydatów na dwa różne sposoby. Żaden z nich nie sprzyja tym, którzy przywykli przygotowywać się w pojedynkę.
Australijski jednorożec Canva powiedział to wprost już w czerwcu 2025 roku: „Yes, You Can Use AI in Our Interviews. In fact, we insist”. Argument jest praktyczny: prawie połowa inżynierów frontendu i backendu w Canva codziennie korzysta z narzędzi AI, więc zakaz na rozmowie oznaczałby sprawdzanie umiejętności w sztucznych warunkach. W Coinbase AI pisało na początku 2025 roku tylko 5,7% scalanego kodu, a pod koniec roku już ponad połowę. Dziś prawie cały nowy kod w tej firmie generuje AI, a ludzie go sprawdzają, więc Coinbase przebudował rozmowy rekrutacyjne pod tę rzeczywistość.
Na takich rozmowach oczekuje się, że otworzysz IDE z asystentem AI. W zamian zadanie jest dużo trudniejsze:
Google działa ostrożniej. CEO Sundar Pichai zapowiedział, że firma zachowa co najmniej jedną rundę na żywo, w której sprawdza podstawy bez żadnej pomocy. AI jest dozwolone tylko w ograniczonym pilotażu z 2026 roku w wybranych zespołach w USA: kandydaci dostają Gemini w nowej rundzie code comprehension (rozumienie kodu), w której czytają, debugują i wyjaśniają istniejący kod zamiast pisać go od zera. Ogólnie ciężar rozmów przesuwa się w stronę Live Debugging i System Design.
Tutaj wyjaśniasz na głos każdą linię, szukasz luki w gotowym pull requeście albo projektujesz system odporny na awarie, a osoba prowadząca rozmowę cały czas zadaje dodatkowe pytania.
Jak zmieniła się ocena:
Dlaczego więc doświadczeni programiści oblewają nowe rundy?
W artykule Karat o luce kompetencyjnej w erze AI (styczeń 2026) jako jedną z oznak inżyniera, któremu brakuje umiejętności ery AI, wymieniono: „Freeze when AI-generated solutions break” (zamiera, gdy rozwiązanie wygenerowane przez AI się psuje).
Według raportu Google DORA 2025 około 90% specjalistów IT już używa AI w pracy. Naszym zdaniem tu właśnie jest pułapka: AI przyspiesza pisanie szablonowego kodu, ale daje złudzenie kompetencji. Gdy programista miesiącami działa w schemacie „napisz prompt → przyjmij podpowiedź → uruchom”, słabnie jego umiejętność debugowania na żywo pod presją.
Wyobraź sobie typową rundę dla inżyniera Frontend albo Fullstack w 2026 roku. Dostajesz komponent wyszukiwania z autouzupełnianiem (według scenariusza zadania wygenerował go junior za pomocą LLM) i słyszysz: „Użytkownicy skarżą się, że gdy szybko piszą, w wynikach czasem zostają dane ze starego zapytania. Znajdź problem i napraw go”.
Oto fragment kodu, który widzi kandydat:
// Przykład zadania na rundę Code Review / Debugging
import { useState, useEffect } from 'react';
export function UserSearch({ query }: { query: string }) {
const [results, setResults] = useState<string[]>([]);
const [loading, setLoading] = useState(false);
useEffect(() => {
if (!query.trim()) {
setResults([]);
return;
}
setLoading(true);
fetch(`/api/users?q=${encodeURIComponent(query)}`)
.then((res) => res.json())
.then((data) => {
// Tu jest błąd: co się stanie, jeśli zapytanie dla "re" odpowie PO zapytaniu dla "react"?
setResults(data.users);
setLoading(false);
});
}, [query]);
return (
<div>
{loading && <span>Ładowanie...</span>}
<ul>
{results.map((user, idx) => (
<li key={idx}>{user}</li> // Druga czerwona flaga: key={idx} dla dynamicznej listy
))}
</ul>
</div>
);
}
AI w kilka sekund „naprawi” ten kod, jeśli o to poprosisz. Ale osoby prowadzącej rozmowę nie interesuje poprawiony plik, tylko to, jak znajdujesz i wyjaśniasz problemy. Dobry kandydat nazywa je na głos, jeden po drugim:
loading na zawsze zostanie true, a res.json() może rzucić wyjątek, którego nikt nie łapie.loading. Jeśli użytkownik wyczyści pole, gdy zapytanie jeszcze trwa, wskaźnik ładowania nie zniknie.key={idx}. Gdy lista się zmienia, React porównuje elementy po indeksie. W dynamicznej liście powoduje to zbędne re-rendery i błędy stanu wewnątrz elementów. Potrzebny jest stabilny klucz, na przykład id użytkownika.Jeden ze sposobów naprawy:
useEffect(() => {
if (!query.trim()) {
setResults([]);
setLoading(false);
return;
}
const controller = new AbortController();
setLoading(true);
fetch(`/api/users?q=${encodeURIComponent(query)}`, { signal: controller.signal })
.then((res) => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
})
.then((data: { users: string[] }) => setResults(data.users))
.catch((error) => {
if (error.name !== 'AbortError') setResults([]);
})
.finally(() => {
if (!controller.signal.aborted) setLoading(false);
});
// Anulujemy stare zapytanie, gdy tylko zmieni się query albo komponent zostanie odmontowany.
return () => controller.abort();
}, [query]);
A potem przychodzi najcenniejsza część odpowiedzi, której AI za ciebie nie powie: „W prawdziwym projekcie dodałbym debounce na 200–300 ms, żeby nie wysyłać zapytania przy każdej literze, i użyłbym SWR albo TanStack Query, bo one już rozwiązują wyścig zapytań, cache i ponowne próby”. To właśnie takie kompromisy, wypowiedziane na głos, wyróżniają dobrego kandydata.
Takie zadanie da się rozwiązać samemu. Ale rozmowa sprawdza coś innego:
null?”. Prawdziwy rozmówca przerwie.Tego wszystkiego można się nauczyć tylko z drugim człowiekiem.
Próbna rozmowa P2P (peer-to-peer) to treningowa rozmowa dwóch programistów, którzy na zmianę są kandydatem i osobą prowadzącą rozmowę. Tak właśnie zbudowaliśmy Skill Rally:
Więcej o tym, jak wyglądają nowe rundy w Meta, Google i Coinbase, przeczytasz w artykule „Rozmowy Frontend i Backend w 2026: nowa runda z AI”.
W 2026 roku rozmowa sprawdza bardziej to, jak myślisz, niż to, jak szybko piszesz kod: jak czytasz cudzy kod, jak znajdujesz błędy, jak wyjaśniasz kompromisy i jak krytykujesz odpowiedź AI. Tych umiejętności nie rozwiniesz w ciszy, sam na sam z LeetCode. Rozwiniesz je tylko w żywej rozmowie z innym inżynierem.
Skill Rally wkrótce startuje. Zapisz się na listę oczekujących, aby jako jeden z pierwszych ćwiczyć z prawdziwymi programistami.