Wymagania
Często wymieszane. Mało istotne na początku, istotne w środku lub na końcu. Np. punkt z wykształceniem na pierwszym miejscu, tak jakby było najistotniejsze, a nie kompetencje czy doświadczenie.
Również wymienianie wszystkich technologii w projekcie niekoniecznie jest najlepszym pomysłem. Warto skupić się tylko na tych kluczowych, a nie pobocznych bibliotekach.
Często jest to również błąd rekruterów w sytuacji, gdy projekt wymaga znajomości kilku technologii (np. kolejność wymagań jest taka: MVC, WCF, T-SQL). W efekcie możemy dostać CV osób znających WCF, nie mających pojęcia o MVC i SQL albo administratorów baz danych.
Co oznacza dużo technologii w ogłoszeniu?
Może oznaczać kilka różnych rzeczy - najczęściej, że projekt to legacy code, długo rozwijany i trudny w utrzymaniu. Lepiej trzymać się z daleka. Rzadziej, że faktycznie projekt jest złożony i jest kilka teamów - przydział może zależeć od kompetencji. Czasami również oznacza, że ktoś wypisał wszystko co się dało lub co przekazał manager, niekoniecznie poświęcając chwile na przemyślenie.
Mieszanie terminologii
Bardzo często pomieszane są terminy techniczne np Knowledge of Web technologies: HTML, CSS, JavaScript, HTTP. HTTP nie jest technologią tylko protokołem.
Kolejną wtopą (rekruterów) jest brak znajomości terminologii - dukają nazwy, powtarzają to co było wspomniane wcześniej itd.
Pytania z różnych technologii
Jeśli na rozmowie trafi się duży rozstrzał technologiczny lub wypisano w opisie projektu mase różnych rzeczy to warto zadać pytanie - "czy faktycznie korzystacie z tego wszystkiego o czym rozmawialiśmy/jest w ogłoszeniu?"
Kontrola wersji (Git, TFS, SVN, ...) i code review
Warto o to zapytać. Dużo mówi o "kulturze" firmy i tym jak się będzie pracowało. Np. brak dobrej (jakiejkolwiek nawet w niektóych przypadkach!) strategii branchowania świadczy o absolutnym braku gotowości do rozwoju projektu w trybie feature'ów. Bardziej przypominam development w szopie/garażu niż profesjonalny rozwój systemów.
Skróty
- Często w ofertach pojawia się masa mniej lub bardziej zrozumiałych skrótów. Jeśli ktoś z Was trafi na pojęcie SOX - niech ucieka. Procesy SOX'owe dotyczą spółek notowanych na giełdzie amerykańskiej i są związane z aplikacjami finansowymi. Strasznie to utrudnia życie programistów (i proces release'a), którzy robią również wsparcie produkcji.
- Kolejnym istotnym pojęciem jest ITIL. Krótko mówiąc chodzi o zarządzanie przez procesy (czyli wchodzimy "w buty" dużych korporacji). Im większe korpo tym więcej niejasnych, zagmatwanych procesów, gdzie nie ma czynnika ludzkiego, a tylko system. Nie da się do kogoś "uderzyć", żeby rozwiązał problem tylko trzeba grzecznie czekać. Najbardziej strict implementacje widziałem w IBMie.
Podchwytliwe stwierdzenia
- Zdolność do pracy na zmieniających się wymaganiach i priorytetach. To jest chyba jedna z gorszych rzeczy jakie może człowieka w IT spotkać. Oznacza to, że jest mało ludzi do wykonywania zadań i do tego management nie wie czego chce albo często zmienia zdanie. Albo jeszcze gorzej - jest kilka osób, które wrzucają zadania i każdy uważa, że jego jest ważniejsze i do tego na wczoraj.
- Dobre umiejętności organizacyjne.Będzie trzeba samemu ogarnąć chaos. No może z pomocą jakiegoś narzędzia, jeśli dobrze pójdzie. Ale i tak nie uchroni to Cię przed różnymi wrzutkami i rozjazdami planów.
