Spróbuję na przykładzie, bo wydaje mi się, że nasze opinie różnią się jedynie semantycznie.
W odniesieniu do juniora moje wymagania to podstawy wiedzy o języku programowania, ale przyswojone ze zrozumieniem. Chcę wiedzieć, że taka osoba coś już wie o programowaniu i faktycznie jest w stanie przyswajać wiedzę.
Zakładając, że chcę zatrudnić kogoś na poziomie seniorskim (kogo uważam za dobrego inżyniera) do projektu, chcę żeby taka osoba:
- Znała język programowania, w którym piszemy na przyzwoitym poziomie. Mogę rozważyć przyjęcie kogoś dobrego w innym języku programowania i jakiejś podstawowej wiedzy w tym, czego używamy (zakładając, że chce się tego nauczyć).
- Miała praktyczną umiejętność podziału kodu na funkcjonalne elementy (moduły, klasy).
- Znała od strony praktycznej wzorce projektowe. Nie ważne, czy potrafi nazwać jakiś wzorzec (chociaż wtedy komunikacja jest prostsza), ale chcę, żeby była w oparciu o tę wiedzę rozwiązywać praktyczne problemy. Czyli jeżeli poproszę ją np. o rozwiązanie problemu typu dorobienie listenerów reagujących na zmiany w kolekcji, to powie "zastosuję observer do powiadamiania o zmianach, a proxy do owinięcia istniejącej kolekcji". Oczywiście inne rozwiązania są możliwe.
- Umiejętność samodzielnego rozwiązywania problemów, które się pojawiają. Cos działa za wolno, coś czasami rzuca wyjątkiem, gdzieś konsumowane jest za dużo pamięci.
- Umiejętności wyrażenia swoich myśli słowami, oraz dyskusji popartej argumentami.
- Umiejętności naukowego rozwiązywania problemów. Postawienia hipotezy i jej potwierdzenia/odrzucenia.
Typowa rozmowa, to:
- Krótka dyskusja o tym co kandydat robił, czego dokonał, czego szuka w nowej pracy
- Trochę teoretycznych pytań o język programowania (niby śmieszne, ale nawet część seniorów ma problemy z podstawami typu "kiedy pamięć zaalokowana na jakiś obiekt zostanie zwolniona".
- Pytania praktyczne "jak rozwiązałbyś problem X" typu "masz aplikację serwerową, która w przypadkowych momentach zostaje zabijana w przypadkowych miejscach OOE, jak podszedłbyś do naprawy takiego błędu", "Masz środowisko podstawowe, środowisko zapasowe do którego replikowane są dane. Jak byś podszedł do problemu spójności danych w drodze, przy replikacji"
- Proste (moim zdaniem) live coding polegające na poprawie istniejącego kodu. Większość kandydatów radzi sobie z nim rozwiązując istniejący problem, ale rzadko kto faktycznie potrafi zastosować te wszystkie YAGNI, TDD, KISS i resztę dyrdymałów o miłości do których zapewniali w poprzednich częściach rozmowy.
Dzięki takiemu podejściu udało się zatrudnić bardzo dobrych programistów. Nie wiem oczywiście, czy nie odrzuciliśmy kogoś nadmiarowo, ale z mojego punktu widzenia znacznie większą szkodę dla projektu / zespołu robi się zatrudniając niewłaściwego kandydata, niż odrzucając potencjalnie dobrego.
Dla odmiany nie interesują mnie ludzie::
- których wiedza/umiejętności ograniczają się do wykucia odpowiedzi na top 100 interview questions
- Ich doświadczenie i ambicje ograniczają się do fragmentu wybranego frameworku, czyli po latach pracy w jakiejś technologii nie mają o niej pojęcia.
- Wiedzą jedynie jak coś należy zrobić, nie mając pojęcia dlaczego tak.
Nie pytamy o rzeczy, których nie wykorzystujemy w projekcie, nie dopytujemy o jakieś techniczne upierdliwostki typu "masz hierarchię dziedziczenia C>B>A, w jakiej kolejności zostaną wywołane konstruktory oraz bloki statyczne".