Pytanie o wzorce ma sens dla juniora, bo pozwala określić, jak dużo "suchej" wiedzy kandydat posiada, ile czasu zajmie mu wdrożenie się w projekt (oczywiście to ciągle strzelanie w ciemno, ale w wielu przypadkach wystarczy) i czy będzie musiał odkrywać każde koło na nowo, czy może raczej da się z nim pogadać jakimś lingua franca.
Rekrutacja na pozycję powyżej juniora to w większości przypadków bzdura. Dla ludzi z doświadczeniem takie pytania mogą mieć sens, o ile będziemy pytali o wzorce architektury, wdrożeń, jakieś najlepsze praktyki z robienia post mortem itp, ale to i tak sprowadza się do doświadczenia, bo na wyższym poziomie rozwiązania "wymyśla" się rzadziej i nie ma jednego przepisu na sukces. Osobiście czekam, aż branża dorośnie na tyle, że będzie można ufać doświadczeniu kandydatów patrząc na CV, bo jeżeli ktoś pracuje 5+ lat, to pewnie daje sobie radę z inżynierią oprogramowania. Oczywiście zawsze można się do czegoś dowalić ("bo on klepie repozytorium generyczne, jak zwierzę!" albo "gość mockuje w testach, jak w XX wieku"), ale rozsądni ludzie raczej zdają sobie sprawę, że to nie o to chodzi.
Wszelkiej maści algorytmy, klepanie na tablicy czy codility uznaję za mało sensowne. Każda firma mówi, że nie trzeba rozwiązać zadania, liczy się sposób podejścia do problemu, rozbicie na kawałki i myślenie na każdym kroku, ale ja w to nie wierzę — zbyt dużo razy byłem po drugiej stronie i widziałem, co ludzie robią, żeby się na to nabrać. Jak nie rozwiążesz zadania wystarczająco dobrze (co w 90% przypadków oznacza rozwiązanie poprawne i w dobrej złożoności), to choćbyś naprawdę kapitalnie myślał, to odpadniesz. O ile jeszcze rozumiem Codility jako etap wstępny (bo "masa amatorów pcha się do zabawy"), to ręce mi opadły, gdy kiedyś miałem "onsite" przez Internet i druga strona chciała to robić właśnie przez tę platformę. Kompiluję kod, autocompletion nie ma, nie pamiętam, czy tablica ma Length, Size, Count czy coś innego, kompilator krzyczy, rekruter też nie pamięta i mówi, że sprawdzi w dokumentacji, a ja siedzę i marnuję czas na wszystkie permutacje znanych mi nazw.
Jak chodzi o wiedzę informatyczną, to też jest kiepsko. Jeszcze nie pamiętam rozmowy, żeby jakaś wiedza "naukowa" mi się przydała, kiedyś nawet byłem podjarany, bo rekruter pytał mnie, dlaczego reference counting w GC nie zwolni cykli i jak to się ma do problemu stopu, ale potem zorientowałem się, że gość myśli, że Java stosuje RC i w jego mniemaniu powiedziałem, że "Java nie zwolni cykli", więc drążył. Ja produkowałem się z maszyny Turinga, optymalizacji kompilatora, sposobów na rozwiązanie problemu a gość myślał, że "gość klepie tyle lat, a nie wie, że GC sobie radzi z cyklami bez problemu, no po prostu debil". Osobiście zadaję takie "jednostrzałowe" pytania w stylu "co to jest anomalia Belady'ego" albo "ile wynosi kwant czasu w Windowsie", ale to na zasadzie szybkiego sprawdzenia, czy kandydat ma gdzieś coś ciekawego do powiedzenia, a jak nie ma pojęcia, o co chodzi, to nic się nie dzieje.
Osobiście całe te rekrutacje traktuję jako grę. Reguły są takie, że trzeba coś tam umieć w Codility, w miarę szybko i sprawnie odpowiadać, być pewnym siebie, jak to się opanuje, to potem już w miarę z górki. Tylko rekrutacja nie powinna być czymś, co robi się raz na kilka lat przy zmianie pracy, tylko coś, na co chodzi się raz w miesiącu dla rozrywki (czy to jako kandydat, czy jako rekruter z drugiej strony). Wtedy bardzo łatwo jest trzymać wiedzę na świeżo.