W 2025 roku miałem okazję uczestniczyć jako ekspert techniczny w ponad 60 rozmowach rekrutacyjnych w ING. Moja rola była dość prosta: sprawdzić, czy kandydat faktycznie posiada wiedzę potrzebną na stanowisku, czy tylko dobrze opanował sztukę mówienia rzeczy brzmiących sensownie.
Rozmowy techniczne zwykle zaczynałem od SQL-a. Nie od konkretnej bazy, nie od dialektów, nie od „jak to jest w Oracle albo Postgresie”, tylko od fundamentów. Interesowała mnie koncepcja, sposób myślenia, rozumienie tego, co się dzieje pod spodem. Składni każdy może się nauczyć, dokumentacja jest publiczna. Myślenia już niekoniecznie.
Jednym z pierwszych pytań, takich typowo na rozgrzewkę, było pytanie o klucz główny. Czym jest, do czego służy, dlaczego się go stosuje. Na tym etapie zwykle było spokojnie. Kandydaci poprawnie tłumaczyli, że identyfikuje rekord, że zapewnia unikalność, że pomaga w relacjach. Wszystko się zgadza, notatnik w głowie mówił: „okej, jedziemy dalej”.
Jeśli rozmowa szła płynnie, zadawałem pytanie, które bardzo lubię, bo jest proste tylko z pozoru: czy klucz główny w relacyjnej bazie danych jest wymagany?
I tu zaczynało się robić ciekawie.
Część kandydatów reagowała z autentycznym zdziwieniem. Padały odpowiedzi w stylu: „nie spotkałem się z bazą bez klucza głównego”, „przecież musi być”, „jak to w ogóle możliwe?”. Ton często sugerował, że pytanie jest trochę podchwytliwe, a trochę absurdalne. Bo przecież zawsze jest primary key. Zawsze był. Zawsze będzie.
I właśnie w tym momencie zapalała mi się lampka.
To pytanie jest banalne, ale świetnie waliduje realną wiedzę o SQL-u i relacyjnych bazach danych. Odpowiedź twierdząca bardzo często wynika z jednego źródła: wieloletniej pracy z ORM-ami, najczęściej z Entity Frameworkiem lub jego odpowiednikami. A że ORM wymaga klucza głównego, to w głowie powstaje skrót myślowy: baza danych = primary key. Koniec dyskusji.
Tylko że to nieprawda.
Odpowiadając krótko i konkretnie: klucz podstawowy nie jest absolutnie obowiązkowy w każdej relacyjnej bazie danych. Standard SQL nie wymaga, aby każda tabela miała zdefiniowany primary key. Silniki bazodanowe również tego nie wymuszają. Można stworzyć tabelę bez klucza głównego i będzie ona działać. Da się do niej wstawiać dane, da się je odczytywać, da się nawet budować zapytania, które mają sens.
Czy to dobry pomysł? Najczęściej nie. Czy są przypadki, gdzie to ma uzasadnienie? Jak najbardziej. Tabele techniczne, stagingowe, logi, dane tymczasowe, snapshoty, integracje z systemami zewnętrznymi, gdzie struktura nie jest pod pełną kontrolą. Życie, nie podręcznik.
Dla mnie ważne nie było to, czy kandydat od razu odpowie „tak” albo „nie”. Ważne było dlaczego. Czy potrafi oddzielić ograniczenia narzędzia od zasad samej bazy danych. Czy rozumie, gdzie kończy się SQL, a zaczyna framework, który akurat używa. Czy potrafi powiedzieć: „w teorii nie jest wymagany, w praktyce zwykle warto go mieć”.
Bo właśnie tak wygląda dojrzałość techniczna.
Po tych kilkudziesięciu rozmowach jedno jest dla mnie jasne: dobre pytania rekrutacyjne nie muszą być trudne. Muszą być celne. A odpowiedzi nie muszą być perfekcyjne — muszą być świadome. I tego, szczerze mówiąc, szukałem najczęściej.