Jeśli chodzi o przygotowanie się do rozmów kwalifikacyjnych, najlepiej jest samodzielnie zbadać te tematy i pracować nad własnymi projektami, w których są one wykorzystywane.

Na przykład moja pierwsza praca związana z oprogramowaniem była podobna, nie angażowaliśmy się w żadne dobre praktyki i były one trudne do wdrożenia. Pracowałem więc nad prywatnymi projektami, w których mogłem robić, co chcę i miałem czas. W tych projektach bym właściwie zaplanował wszystko, poprawnie skonfigurowałbym kontrolę src, przetestowałbym cały swój kod, skomentowałbym kod i postarał się, aby był zrozumiały, wielokrotnego użytku i skalowalny itp. Kiedy więc nadszedł czas, aby porozmawiać o tych najlepszych praktykach podczas rozmów kwalifikacyjnych, miałem w nich przyzwoitą wiedzę i doświadczenie, nawet jeśli nie miałem z nimi kontaktu w mojej rzeczywistej pracy.

Zwykle znajduję że ankieterzy nie chcą konkretnych przykładów tych praktyk z twojej obecnej pracy, chcą tylko wiedzieć, że jesteś ich świadomy i czego one dotyczą. Możesz mieć trudności z narażeniem się na ich działanie w pracy, ale nic nie stoi na przeszkodzie, abyś szukał ich i używał ich poza tymi godzinami. Na pewno będzie to warte czasu, jeśli chodzi o karierę. Osobiste projekty, które przedstawiają te najlepsze praktyki, świetnie nadają się do Twojego portfolio, nawet jeśli są małe.

Jeśli absolutnie naciskają bardzo mocno na aktualne przykłady pracy, to osobiście powiedziałbym, że twoja obecna praca tak naprawdę tego nie robi, więc podjąłeś wysiłek, aby się ich nauczyć / ćwiczyć samodzielnie. To pokazuje inicjatywę i może dostarczyć im dodatkowego kontekstu, dlaczego szukasz gdzie indziej.

Ostatnio byłem w takiej sytuacji. Podczas mojego poprzedniego występu pracowaliśmy na bardzo starej bazie kodu (część kodu zgodnego z Javą 1.2 / 1.3); kod był pełen magicznych liczb i magicznych ciągów używanych do uzyskania dostępu do referencji Object z Vector , które zostały następnie rzucone; żadnych testów jednostkowych, prawie żadnych testów integracyjnych, żaden z nich nie jest zautomatyzowany; mało czasu przeznaczonego na refaktoryzację starego kodu; brak przeglądu kodu; komentarze z natury ezoteryczne ...

Kiedy poczułem, że nadszedł czas, aby udać się na bardziej zielone pastwiska, zadano mi to samo pytanie, kontynuowałem o tym, jak chcę pracować i jak ten brak satysfakcji z mojej osobistej etyki pracy była jednym z powodów, dla których szukałem gdzie indziej.

Wyjaśniłem, jakie cechy mają dla mnie znaczenie dla jakości kodu (solidność dzięki dokładnym testom automatycznym, czytelność nazw zmiennych i funkcji, dzielenie kodu na tak małe, jak to możliwe funkcje zamiast bloków składających się z tysięcy wierszy powtarzającego się kodu itp.) i wylądowałem na moim obecnym koncercie.

Jak @Sascha wskazał w swojej odpowiedzi, nie ma potrzeby obwiniania twojego obecnego /Poprzedni pracodawca. Chodzi o sprzeczne postrzeganie najlepszych praktyk, które uniemożliwiają czerpanie satysfakcji z wykonywanej pracy.

Wrobisz to w niewłaściwy sposób i podchodzisz do tego w niewłaściwy sposób.

Fakt, że masz rzeczywiste doświadczenie ze złymi praktykami i szkodami, jakie wyrządzają, jest dobrą rzeczą . Widzieliście to, nauczyliście się na tym i wiecie, że lepiej nie pomijać tych wszystkich praktyk, które „ spowalniają Cię ” i „ powstrzymują Cię przed załatwianiem spraw ” .

Co więcej, w swoim czasie wyciągnąłeś rękę i przeczytałeś wszystko, co możesz o tych praktykach, wdrożyłeś je w pobocznych projektach i możesz rozmawiać, dopóki ludzie się nie znudzą, słuchając wszystkiego o korzyściach z nich wnosić do dowolnego projektu i czy wnosić do konkretnego projektu obecnego miejsca pracy - prawda?

Obecność wystawiona na złe praktyki (ważne - nie przestrzeganie ich - ponieważ nie jest to Twój wybór) jako doświadczenie oraz Twoja wiedza na temat lepszych praktyk i ich wartości jako czegoś, co dowiedziałem się z tego doświadczenia.

Nie tylko nie spowoduje to żadnych ostrzeżeń dla ankietera, ale prawdopodobnie będzie lepsze niż ktoś, kto miał tylko doświadczenie z dobrymi praktykami, ale po prostu wziął je za pewnik i może nie mieć nic szczególnie interesującego do powiedz o nich (Co, to? Jasne, tak właśnie robią wszyscy, prawda?).

Byłem w takiej sytuacji i sformułowałem ją tak, że zasugerowałem wiele lepszych praktyk, ale nie pozwolono mi ich wdrożyć, co jest jednym z powodów, dla których chcę iść dalej.

To pokazuje zarówno świadomość problemu, jak i sposób jego rozwiązania, a także chęć pracy na wyższym poziomie.

Niech odpowiedź brzmi „dlaczego uważam, że firma, z którą rozmawiam, jest świetna i lepsza niż moje obecne miejsce pracy?”.

Ilekroć rozmawiam w innym miejscu, zwykle pytany o to, jak pracuję i jak podchodzę do testowania lub weryfikacji / walidacji.

Zamiast „jak idę” odpowiedz „jak mam zamiar iść”. Stwierdź, że oczywiście tworzenie oprogramowania o rozsądnej jakości jest inwestycją w czas i szkolenia, które czasami nie są uważane za rozsądne ze względu na doświadczenie firmy i typy projektów, ale wolisz pracować w środowisku i nad projektami, w których wykonywane są rzeczy związane z profesjonalnym SW . Jeśli to prawda, powiedz, że taka jest reputacja firmy, z którą rozmawiasz.

Czuję, że gdybym był ankieterą i kandydatem wychowanym, że nic takiego się nie dzieje, byłaby to wielka czerwona flaga i po prostu wyrzuciłbym ich podanie. Jak mam się zabrać do omawiania tego podczas wywiadów?

• Bez obwiniania poprzedniego pracodawcy lub współpracowników za coś, co poszło nie tak
• Przedstaw oczekiwanie, że firma, do której aplikujesz, zajmuje się profesjonalnie rozwojem oprogramowania.
• Gdy zostaniesz o to bezpośrednio poproszony, powiedz wprost i powiedz, że kierownik projektu uznał za rozsądne, aby nie wdrażać takich środków i że wykonałeś przydzielone zadania zgodnie z zapytaniem. Jeśli tak, możesz również powiedzieć, że poinformowałeś o tym PM.

Nie wspominaj o swoim obecnym środowisku pracy. Nie ma to nic wspólnego z tym, że pracujesz w miejscu, w którym przeprowadzasz rozmowę kwalifikacyjną.

Kiedy ankieter zadaje te pytania, pyta o proces myślowy, że rozumiesz koncepcje i ćwiczyłeś to wcześniej . Powiedziałbym: „Normalnie lubię robić X, Y i Z” i NIE wspominać, że twoje obecne środowisko pracy nie robi tych rzeczy.

Jeśli osoba przeprowadzająca rozmowę NAPRAWDĘ naciska na to, jak działa Twoja praca, powiedziałbym: „Cóż, lubię to robić w ten sposób, ale moje obecne środowisko pracy nie korzysta z najlepszych praktyk. główne powody, dla których szukam nowej pracy. ”

Zwykle jestem pytany o to, jak pracuję i jak podchodzę do testowania lub weryfikacji / walidacji

Opisanie twoich obecnych praktyk pracy rzeczywiście podniesie czerwoną flagę. Chodzi o to, że naprawdę brakuje ci umiejętności, których poszukuje większość firm. Czytanie o TDD / Git / Cokolwiek i budowanie projektu zabawki w wolnym czasie przy jego użyciu to jedno. Korzystanie z TDD / Git / Cokolwiek w twojej pracy przez ostatnie X lat to coś innego.

Realistycznie powinieneś spróbować znaleźć nową pracę w firmie z rozsądnymi praktykami pracy, która chciałaby, żebyś na pokładzie, zdobądź tam kilka lat doświadczenia, a następnie aplikuj do firmy, w której chciałbyś pracować .

Możesz spróbować rozwinąć pewne umiejętności w samodzielnie, wykonując projekty OSS w wolnym czasie, ale pamiętaj, że muszą one być naprawdę dobre. Wielu programistów stosuje w pracy dobre praktyki kodowania i ma teraz coś na Githubie, więc będziesz musiał konkurować z tymi ludźmi, kiedy aplikujesz.

Spróbuj wyrazić zanim pojawi się takie pytanie, że chciałbyś przejść z ryzykownej sytuacji do firmy, która stosuje bardziej efektywne praktyki.

Jeśli chcesz przećwiczyć zasady, które uważasz za lepsze, aby zdobyć z nimi doświadczenie, zdecydowanie polecam znalezienie interesującego Cię projektu Open Source i wniesienie wkładu. Nie tylko będziesz mógł ćwiczyć lepsze praktyki inżynierskie i na własne oczy być świadkiem ich wyższości, ale także będziesz mieć na coś do powiedzenia podczas rozmowy kwalifikacyjnej.

Oczywiście projekty prywatne również działają dobrze, ale brak korzyści z przebywania w zespole innych inżynierów, którzy przekazują opinie i przedstawiają różne perspektywy.

Szczera odpowiedź od faceta, który spędził 20 lat na projektowaniu i wdrażaniu przemysłowych systemów oprogramowania VLS z setkami tysięcy do milionów linii kodu, tysiącami stóp kwadratowych diagramów UML i dziesiątkami tysięcy stron dokumentacji, w tym przypadków testowych zgodnie ze ścisłymi wytycznymi FDA dla przemysłu farmaceutycznego dotyczącymi tworzenia systemu oprogramowania UHA (Ultra-High-Availability) 9 na 9 (oczekiwany niezawodny czas działania 99,9999999%)?

Chyba że ubiegasz się o zarządzanie projektem oprogramowania stanowisko - nic z tego nie ma znaczenia. Po prostu pokaż mi, że jesteś dobrym inżynierem oprogramowania, który potrafi napisać dobry działający kod i wystarczająco inteligentny, aby szybko nauczyć się NASZYCH „najlepszych praktyk” - i jesteś gotowy.

Prawdziwy talent do projektowania i pisania oprogramowania to coś naprawdę wyjątkowy - biurokracja i struktura korporacyjna (w tym standardy komunikacji i dokumentacji) różnią się w zależności od firmy i nie są tak trudne do nauczenia. Zwłaszcza, że ​​nie jesteś zatrudniony do implementacji lub kierowania tą strukturą, tylko po to, by ją śledzić.

Post Scriptum

Komentarze w nowoczesnym kodzie SĄ stratą czasu. Powinieneś napisać samokomentujący kod, taki jak

public CapsuleOrder GetOrderByPoNumber (String PoNumber) {}

Cała reszta powinna znajdować się w systemie dokumentacji ACTUAL.