Jak opisujecie projekty na rozmowie o pracę

Witajcie. Jak opisujecie projekty przygotowywane w poprzedniej pracy podczas rozmów rekrutacyjnych? Zakładam, że taki temat pojawia się zawsze. Czy szczegółowo omawiacie architekturę, wykorzystane algorytmy, biblioteki i wyniki, czy raczej ogólnie i odpowiadacie na pytania, które się pojawią? Czy dostajecie zwykle bardzo szczegółowe pytania dotyczące tych projektów?

waska_gaska napisał(a):

Witajcie. Jak opisujecie projekty przygotowywane w poprzedniej pracy podczas rozmów rekrutacyjnych? Zakładam, że taki temat pojawia się zawsze. Czy szczegółowo omawiacie architekturę, wykorzystane algorytmy, biblioteki i wyniki, czy raczej ogólnie i odpowiadacie na pytania, które się pojawią? Czy dostajecie zwykle bardzo szczegółowe pytania dotyczące tych projektów?

Zwróć uwagę, komu o tym mówisz i dopasować odpowiednio sposób mówienia.

HR są tępe, więc jedyne, na co zwrócą uwagę, czy projekt był komercyjny. Więc jeśli mówić o czymkolwiek, to warto mówić, że to było robione komercyjnie, dla jakiejś firmy. To jedyne kryterium, które potrafią przeanalizować w swoich niewielkich rekruterskich móżdżkach

Programistom natomiast możesz powiedzieć o szczegółach technicznych. Możesz ich zaciekawić. Również warto wspomnieć o rozwiązaniach, które mają jakiś związek z tym, co będziesz robić w pracy. Tutaj możesz zaplusować, jak będziesz ze szczegółami opowiadać.

Jeszcze są menedżerkowie, ale to inna bajka. Niektórzy mają background techniczny i coś kminią, ale i tak raczej nie powinno się ich zbytnio zarzucać szczegółami, bo ich zanudzisz albo spowodujesz, że będzie to zbyt trudne dla nich. A wtedy mogą uznać, że nie umiesz się komunikować. Albo że jesteś overqualified i że w ich firmie byś się nie odnalazł (prawdziwa sytuacja - kiedyś dostałem odmowę właśnie dlatego, że gadałem menedżerkowi o swoim projekcie; napisali w mejlu odmownym, że jestem zbyt ambitny i bym się nie odnalazł w ich rutynowej pracy).

Opisuje nie zdradzając szczegółów które są know-how firmy. Więcej mogę się rozgadać o projektach które co prawda były komercyjnie, ale w pewnym sensie open source, np. dla administracji publicznej. No i oczywiście HRówa na mnie naciska chamsko "ale masz podpisane non-disclosure?" bo juleczka nie rozumie że człowiek jest lojalny niezależnie od podpisanych papierków. Współczucie dla jej chłopaka ;)
Ale pewne rzeczy techniczne ogólnie opisuję, właśnie zastosowane zewnętrznej biblioteki, zrobienie dla nich wrappera.... HRówę szlak trafia bo nie rozumie o czym mówię, a ludzie techniczni ze mną dyskutują z entuzjazmem. Oczywiście wtedy jeżeli HRówa ma coś do powiedzenia to mnie odrzuci

Tak w ogóle to źle zrozumiałem pytanie i zrozumiałem, że chodzi o swoje prywatne projekty, a teraz widzę: Jak opisujecie projekty przygotowywane w poprzedniej pracy. Jednak mój poprzedni post i tak ma sens - HRowi podkreślać komercyjność, programistom można mówić szczegóły, w rozmowie z menedżerkami badać sytuację, bo różnie bywa.

Jednak kontekście projektów, które były komercyjne raczej mówię ogólnie, rzucam buzzwordami technologii czy patternów albo jaki problem biznesowy to rozwiązywało. Tak, żeby nie mówić szczegółów, wiadomka NDA itp. No i też jest taki problem, że wiadomo jak to bywa w firmach - legacy kod, bezsensowne rozwiązania, więc dzielenie się tego typu szczegółami to w zasadzie mówienie źle o swoim byłych pracodawcach, co nie musi być dobrze widziane. Plus raczej zależy nam na tym, żeby zrobić wrażenie, że projekty, w których braliśmy udział, były dobrze napisane, że się nauczyliśmy dobrych praktyk, a nie że babraliśmy się w kodzie spaghetti.

Więc i tak, projekty prywatne są bezpieczniejsze do mówienia na rozmowie.

W tym poście miałem na myśli właśnie projekty komercyjne (wydaje mi się, że są one dużo ważniejsze podczas rekrutacji niż prywatne). Zastanawiam się gdzie jest granica między tym, co można i wypada powiedzieć, a co już jest tajemnicą firmy. Na ile można opisywać szczegóły techniczne (typu architektura, wykorzystane algorytmy, wyniki eksperymentów, osiągnięte metryki itp.)

Mówię ogólniki a jak czegoś nie pamiętam albo nie jestem pewny albo nie chcę przyznać że używamy do tego jakiegoś g#$na jak pytają to mówię że NDA mi nie pozwala.
Powołanie się na NDA pozwala dodać nutę tajemniczości i zajebistości nawet do prostych projektów i daje pozytywne plusy dodatnie do oceny odpowiedzialności i lojalności wobec firmy.

Czyli polecalibyście pisać tylko to, co publicznie dostępne i jakie technologie były używane jeśli są typowe dla tego typu projektów? W rekomendacjach odnośnie opisywania CV widziałem dużo o “języku korzyści” i o tym, że trzeba podawać metryki jak bardzo rozwijany projekt poprawia cokolwiek. W przypadku, gdy nie ma publicznie podanych tego typu informacji podajecie informacje typu “poprawa dokładności o x%”?

Mówię chatugpt co zrobiłem, on mi to ubiera w słowa jakbym stworzył silnik rakietowy od zera i wynalazł napęd WARP a potem powtarzam jak katarynka. Oczywiście przygotowuje się na followupy. Historie muszą mieć ręce i nogi. Jak są prawdziwe to jest znacznie łatwiej. Potem i tak nikt nigdy tego nie sprawdzi. Sprawdza się conawjyżej historie zatrudnienia. Niemniej jednak w PL i tak na szczęście rzadko.

waska_gaska napisał(a):

W rekomendacjach odnośnie opisywania CV widziałem dużo o “języku korzyści” i o tym, że trzeba podawać metryki jak bardzo rozwijany projekt poprawia cokolwiek. W przypadku, gdy nie ma publicznie podanych tego typu informacji podajecie informacje typu “poprawa dokładności o x%”?

no na ostatniej akcji rekrutacyjnej u nas większość cv miało tak wpisane, dla mnie to trochę głupawe, zwłaszcza że nie ma szans że ktoś to tak dokładnie mierzył, a ludzie wpisują rzeczy niemierzalne typu "poprawa wyglądu aplikacji o 60%" (przesadzam).
Dodatkowo kandydaci zadają te same pytania, najpopularniejsze: "czego firma ode mnie oczekuje w ciągu pierwszych 90 dni od zatrudnienia" - wydaje się spoko pytanie, gorzej jak to piąta z rzędu osoba która słowo w słowo pyta o to samo, wtedy jest żałosne.

Nie wiem jakie tiktoki ludzie oglądają przed rekrutacją, ale wydaje mi się że najlepiej być sobą i nie oglądać takich treści bo potem chcąc się wybić jest się ostatecznie jednym z wielu który leci według schematu.
Trzeba pamiętać że te poradniki są z d**y wyjęte i że wszystkim kandydatom pokazują się te same porady, a cv oceniają zwykli, losowi ludzie, całkowicie od siebie różni. Nie ma uniwersalnego klucza na wszystkich; to co podziała na jednego rekrutera nie zrobi wrażenia na drugim albo może zadziałać nawet na niekorzyść. Pisz cv tak żeby zrobiło wrażenie na tobie samym.

Ja tam zawsze chcę usłyszeć od kandydatów jak najwięcej o (1) business value i (2) konkretnym impakcie na projekt. Konkrety, od ogółu do szczegółu. Przydaje się STAR framework, żeby nadać strukturę. Etapy: manager phone screen i behavioral interviews.

ja zawsze mowie ze mam NDC (zgodne z prawda) i ew. opowiadam o jakichs malych fraghmentach ktore sa dla mnie wygodne.

Ja często przeprowadzam rozmowy czysto techniczne na stanowiska IC. Nie interesuję się managerskimi sprawami.

Jak ktoś zaczyna nawijać o impakcie i business value, to nawet mówię wprost, że chcę rozmawiać wyłącznie o aspektach technicznym. Jak ktoś nadal nie łapie, to wiadomo - albo ściemniacz, albo rola niedopasowana.

Wstępna rozmowa o poprzednim projekcie ma na celu:

• ocenić ile nakłamałeś w CV. AI CV są bezużyteczne - każdy był leadem technicznym i wprowadzał innowacyjne rozwiązania.
• stwierdzić, co tak naprawdę robiłeś - poziom doświadczenia.
• stwierdzić, czy umiesz się wypowiadać na odpowiednim poziomie detali, i czy ja rozumiem, co mówisz (z tym tradycyjnie programiści wszelkich nacji mają problem).
• czy używasz odpowiedniej terminologii. To dobry marker na doświadczenie i dokształcanie się. Kandydaci, którzy znają tylko własną pracę, mówią o architekturze używając wewnętrznego żargonu.
• stwierdzić, czy rozumiesz drogę na produkcję tego, co tworzyliście w zespole. Wykrywa to archetypy: non-coding-manager i ticket-monkey.

Nie ma znaczenia, czy architektura poprzedniego projektu była dobra. Rozumiem, że to nie ty ją projektowałeś.