Z mojego doświadczenia, zanim zaczniesz pracować dla firmy, nie masz okazji przyjrzeć się bazie kodu (poprosiłem i ze względu na poufność wszyscy zawsze mówili „nie”, myślę, że to jest sprawiedliwe), więc podczas rozmowy kwalifikacyjnej czy uważasz, że są najważniejsze pytania, które należy zadać, aby dowiedzieć się, w jakim stanie jest kod (w końcu, jeśli jest to pies, to będziesz miał do czynienia z biednymi nieszczęśnikami, którzy muszą go chodzić codziennie)?
AKTUALIZACJA:
Lista kontrolna: Zapytaj;
- Co oni myślą o kodzie. A kiedy to zrobisz, zwróć szczególną uwagę na mimikę twarzy i czas potrzebny na reakcję. [Zaraz]
- Jaki jest poziom CMM firmy [DPD] (i jeśli słyszysz, że poziom 5 działa w drugą stronę [Doug T])
- W jakim cyklu życia używają [DPD] (A jeśli słyszysz „Agile”, wtedy zaczynasz zadawać kilka wnikliwych pytań, aby spróbować dowiedzieć się, czy przez „Agile” mają na myśli „Agile” lub „kodowanie kowboja” [Carson63000])
- Jakich narzędzi używają do oceny jakości kodu? [DPD]
- Jakich narzędzi używają do programowania? [DPD] (poszukaj narzędzi do refaktoryzacji i serwerów ciągłej kompilacji)
- Jakiego systemu kodu źródłowego (kontroli wersji) używają, i dobrą odpowiedzią jest pytanie, dlaczego go używają. [Zachary K].
- Jakie są ich procedury testowe? [Karl Bielefeldt] (Zwróć szczególną uwagę na zespoły, które używają fałszywych frameworków i kładą nacisk na dokładne zautomatyzowane testowanie jednostek za pomocą ustalonych frameworków, takich jak NUnit / JUnit; nie zniechęcaj się zespołami, które nie używają testowego rozwoju TDD, ale bądź uważaj, jeśli nie uznają testowania za integralną i solidną podstawę do tworzenia oprogramowania. Poszukaj zespołów z oddanymi testerami).
- Jakie zadania są przydzielane nowym programistom? Do doświadczonych programistów? [Karl Bielefeldt]
- Ile osób pracuje nad projektem? [Karl Bielefeldt]
- Czy refaktoryzacja jest dozwolona? Zachęcony? [Karl Bielefeldt]
- Jakie zmiany w procesie lub architekturze związane z jakością są rozważane lub zostały wprowadzone niedawno? [Karl Bielefeldt]
- Ile autonomii mają poszczególne moduły? [Karl Bielefeldt]
- Czy będziesz opracowywać nowsze projekty (rozwój terenów zielonych) czy starsze projekty (rozwój terenów poprzemysłowych)? (Rozwój Greenfield jest ogólnie przyjemniejszy i ma mniej problemów, ponieważ nie czyścisz błędów innych).
- Czy wskaźnik rotacji pracowników jest wysoki w organizacji czy zespole? (Często oznacza to niższą jakość kodu) [M.Sameer]
- Niektóre twoje własne problemy programistyczne; ale unikaj wydawania się palantem. [Iskrzący]
- Jak współpracują programiści i jak dzielą się wiedzą w zespole? (To powinno pasować do twojej osobowości; powiedziałbym, że najlepiej jest mieszać pracę solo i parę, przy proporcji odpowiadającej twoim potrzebom społecznym)
- Jak blisko jest ich baza danych do trzeciej postaci normalnej (3NF), a jeśli odbiega ona gdzie i dlaczego? (Jeśli powiedzą „3NF ???”, wyjdź. Jeśli nie, a powody mogą być inne, dowiedz się, jakie są).
UWAGA: Zaakceptowałem odpowiedź Anona, ponieważ po około tygodniu społeczność myśli, że jest najlepsza - myślę, że to sugeruje, że jest to po prostu coś, dla czego musisz rozwinąć szósty zmysł. Ale myślę, że każdy miał coś cennego do powiedzenia.
Odpowiedzi:
Zamiast pytać o kod, zapytaj, co myślą o bazie kodu. A kiedy to zrobisz, zwróć szczególną uwagę na mimikę twarzy i czas potrzebny na reakcję.
Następnie wykorzystaj swoją wiedzę na temat niewerbalnych gestów kultury, aby zinterpretować to, co naprawdę mówią. W przypadku firmy z Ameryki Północnej następujące informacje powinny być dokładne:
Oczywiście, jeśli masz problemy z komunikacją międzyludzką, może to nie działać.
źródło
Dziwię się, że nawet zapytałeś. Żadna firma nigdy nie pokaże Ci kodu, zanim dołączysz. Nawet konsultanci wezwani do procesu, chyba że podpisali umowę o zachowaniu poufności.
Oto, o co możesz poprosić, aby się dowiedzieć.
źródło
To byłoby z czubka mojej głowy. Zauważysz, że niektóre z moich pytań dotyczą procesu tworzenia oprogramowania, a nie tylko kodowania. Jakość tego drugiego jest bezpośrednią funkcją jakości tego pierwszego.
Powiedziawszy to, zadając te pytania, postępuj ostrożnie. Przestudiuj je i wybierz kilka podczas wywiadu.
Kilka rzeczy, o których powinieneś pamiętać. Dobry zespół programistów z przyjemnością usłyszy, jak osoba, z którą przeprowadzono wywiad, zadaje te pytania ... pod warunkiem, że zostanie zapytany z taktem. Zrób to źle, a dasz ankieterowi wrażenie arogancji i perfekcjonizmu. Bez względu na to, jak dobry jest zespół deweloperów, żadna grupa nie jest idealna i wszyscy mają problemy do rozwiązania, kompromisy w zakresie jakości i tym podobne. Chcą drużyny z zamiłowaniem do jakości, a nie destrukcyjnego perfekcjonisty. Więc uważaj.
Mogą się również zdarzyć przypadki, w których masz zespół dobrych ludzi, którzy z przyczyn zewnętrznych muszą pracować w kodzie o niskiej jakości (mogą to być programiści młodsi, lub po prostu odziedziczyli kupę bzdur, nad którymi muszą teraz pracować z ograniczonymi możliwościami) zasoby przeznaczone na poprawę jakości.) Możesz pracować z gównianym kodem i nadal mieć dobre doświadczenia zawodowe, jeśli ludzie wokół ciebie są również dobrymi ludźmi (zarówno osobiście, jak i zawodowo). Zadawaj im złe wrażenie, gdy zadajesz pytania, a oni mogą po prostu uniknąć całkowitego zatrudnienia cię (pozbawiając cię możliwości pracy z dobrymi ludźmi w bardzo trudnej i trudnej sytuacji).
Możesz także spotkać gównianą grupę programistów z gównianymi ludźmi. Oczywiście ich kod będzie gówniany i obleją się każdym z tych pytań. Mogą gardzić tobą za zadawanie im trudnych pytań (a zatem mogą wyświadczyć ci przysługę), lub zatrudnią cię, ponieważ cię potrzebują (nawet jeśli nie są / będą w stanie z tobą pracować).
Kiedy tak się dzieje, musisz zadać sobie pytanie, czy potrzebujesz tej pracy tak bardzo. Czasami to robisz i musisz zanurzyć się w kupie spaghetti. Czasami nie (to znaczy, możesz sobie pozwolić na nie.)
Są to rzeczy, które należy wziąć pod uwagę, gdy / jeśli zdecydujesz się zapytać ankietera o jakość jego kodu i procesów oprogramowania.
źródło
Zamiast rzeczywistej jakości kodu wolałbym raczej szukać firmy, w której znaczenie jakości kodu jest dobrze zrozumiane.
Na przykład powiedzmy, że firma A ma menedżerów, którzy uważają, że „planowanie to strata czasu” i „możemy później naprawić problemy projektowe (np. Gdy piekło zamarznie. Będziemy wtedy mieli czas)”. Nawet jeśli ta firma ma teraz dobrą bazę kodów, nie będzie miała jej długo. A ty będziesz tym, który będzie (zmuszony) pogorszyć sytuację.
Z drugiej strony, powiedzmy, że firma B ma złą bazę kodu, ale kierownictwo rozumie, że jakość kodu powoduje wszystkie te błędy i opóźnienia, widzą potrzebę zmian i są gotowi coś z tym zrobić (np. Na dużą skalę refaktoryzacja lub nawet przepisanie). Ta firma ulepszy swoją bazę kodu i możesz pomóc im to zrobić.
Wiem, gdzie chciałbym pracować.
źródło
Istnieje 99,9% szans, że nie będziesz mógł zobaczyć kodu przed rozpoczęciem. (O ile oczywiście nie wypuszczą wolnego oprogramowania)
Więc co możesz zrobić, zapytałbym o proces, ogólnie dobry proces wytworzy dobry kod. Zacznę od testu Joela i zapytam o metodę programowania. Wyjdź także poza podstawy. Na przykład zawsze pytam, jakiego systemu kodu źródłowego używają, więc dobrym rozwiązaniem jest pytanie, dlaczego go używają.
źródło
Miejsce, w którym pracowałem z kodem o bardzo wysokiej jakości, w zasadzie nie pozwalało dwóm trzecim programistów dotknąć kodu. Inni napisali zamiast tego automatyczne skrypty testowe czarnej skrzynki. Jeśli udowodniłeś, że jesteś godny zmiany faktycznego kodu, wymagania były tak bardzo zawyżone, że w zasadzie była to tylko transkrypcja na kod źródłowy. Skrypty testowe były tak naprawdę przyjemniejsze w pisaniu.
Miejsca, w których widziałem kod o najniższej jakości, były dokładnie odwrotne: tylko względnie niedoświadczeni lub niezaangażowani programiści kiedykolwiek dotknęli kodu, zwykle dlatego, że było to narzędzie niezwiązane bezpośrednio z produktem firmy lub uważane za eksperymentalne.
Najbardziej przyjemne miejsca pracy mają równowagę. Nowi programiści otrzymują prawdziwe zadania, ale są mentorami. Istnieje dobry dział kontroli jakości i proces wzajemnej oceny w celu wykrycia błędów. Nie jesteś karany za popełnianie błędów, ale musisz je naprawić i uczyć się od nich. Czasem źle napisany moduł wpada przez szczeliny, ale nie jesteś krytykowany za poświęcanie czasu na poprawę jakości kodu. Firma jako całość nieustannie poszukuje nowych sposobów na ulepszenie kodu.
Dlatego pytania, które zadałbym w celu oceny jakości kodu, to:
źródło
Jak powiedział @DPD i @Zachary, proces i SDLC są bardzo ważnymi czynnikami, ale chcę dodać kilka innych czynników, które zgodnie z moim doświadczeniem mają znaczący wpływ na jakość kodu:
Pamiętaj, że proces bardzo pomaga, ale nie daje całkowitej odporności na powyższe czynniki. Kiedy wielu programistów przekazuje projekt, każdy ma inny sposób myślenia. Architekt i deweloper nie będą postępować dokładnie tak, jak zrobili to ich poprzednicy, co doprowadzi do pewnych niespójności.
źródło
Moje podejście jest takie, kod jest kodem, jeśli jest zły, to jest wyzwanie, aby go ulepszyć. Jeśli jest dobry, to jest jeszcze trudniejsze wyzwanie, aby go ulepszyć!
Najważniejsze dla mnie jest to, czy chcę pracować dla firmy i ludzi, z którymi mam okazję współpracować. Kod można zmienić, ludzie nie mogą ...
źródło
Nieco żartobliwie mówię, przeprowadzam ze mną wywiad .
Zwykle używam rzeczywistego błędu (już naprawionego) w naszej bazie kodu jako testu wywiadu, więc widzisz trochę rzeczywistego kodu. Zasadniczo nieco skomplikowany kod i zawiera błąd.
Zachęcam wszystkich do korzystania z tej techniki, ponieważ już wiesz, że błąd jest prawdziwy, problem jest prawdziwy i wiesz, ile czasu zajęło znalezienie i naprawienie.
Świetną rzeczą jest to, że możesz mieć mierzalnie trudny problem.
Użyłem bardzo trudnego problemu jako pytania z ostatniego wywiadu, aby oddzielić ekspertów od całkiem dobrych.
Znaczenie pytania PO polega na tym, że każdy, kto przejdzie wywiad fizyczny, zobaczy kod. (Nic z poufnymi treściami firmy)
Jeśli nie możesz użyć tej techniki, powiedzmy, wulgaryzmów w bazie kodu, test działa, ponieważ potencjalni pracownicy zapytają „czy mogę zobaczyć kod”, a odpowiedź brzmi „och, nie możesz pełne wulgaryzmów ".
Oczywiście standardową odpowiedzią „to wszystko tajemnica firmy” jest całkowity chytry koń.
Mój dowód: u mojego poprzedniego pracodawcy część niepoufna produktu wojskowego była próbka kodu do pytania na rozmowę kwalifikacyjną. [Na szczęście niesklasyfikowane]
Problem z określeniem jakości sklasyfikowanych projektów pozostawiam przed kimś mądrzejszym ode mnie. Sugeruję, że może być powszechne, że klasyfikacja jest synonimem wolnego od nadzoru.
źródło
Wątpliwe jest, aby pozwolili ci zobaczyć ich kod, ale możesz być w stanie dowiedzieć się, jak to może być, jeśli powierzysz im zadanie domowe z programowania. Wiele miejsc daje rozmówcom zadanie programowania na wynos, którego mogą użyć do oceny ciebie. Oddaj przysługę - spodziewaj się jednego z nich, aby lepiej ocenić, w co możesz się wpakować.
źródło
Zapytaj, co jest wymagane, aby kod mógł znaleźć się w kompilacji produkcyjnej. Jeśli dostaniesz „hmm ... twórca to popełni ...”, to prawie na pewno śmieci.
Istnieje wiele rzeczy, które mają tendencję do podnoszenia jakości kodu (oczywiście nie ma gwarancji).
Mogą one pomóc poprawić nie tylko siłę kodu, ale także jego jakość.
źródło
Zapytaj ich o testy jednostkowe. Jeśli wezmą to na poważnie, wówczas osoba przeprowadzająca wywiad prawdopodobnie będzie miała pewne określone opinie na ten temat i chętnie się z nimi podzieli. Jeśli odpowiedzi są niejasne, to duży znak ostrzegawczy.
Jeśli jest to sklep Java, zapytaj ich, jakiej biblioteki ORM używają. Jeśli wyrzuciły własne, może pójść w obie strony - może ssać lub może być w porządku. Jeśli nie używają żadnego, biegnij od razu do drzwi.
To trudne zadanie, ponieważ istnieje tak wiele różnych złych praktyk kodowania, że nigdy nie będziesz w stanie przewidzieć wszystkich.
źródło
Niestety nie możesz. Żadna firma nie pozwoli ci zobaczyć ich kodu (ale poprosi o obejrzenie TWOJEGO kodu ...), a są szanse, jeśli zadasz im pytania dotyczące środowiska, w którym albo zostaniesz okłamany („Kontrola wersji? Jasne .. używamy ... uhh .. myśląc Sub .. Sub-coś ”) lub wprowadziliśmy w błąd co do jakości („ Używamy najnowszego i najlepszego .NET 4 ”tylko po to, aby dowiedzieć się, że podczas korzystania z .NET 4„ piszę go jak .NET 1.1).
W przeszłości byłem przez niego palony wiele razy i jeszcze nie znalazłem dobrego sposobu na ocenę jakości. Zwykle najlepszym sposobem jest skorzystanie z własnego osądu, a jeśli sprowadza się do tego, opuść natychmiast, jeśli jest gorzej, niż ci się wydawało; możesz skończyć z pracy, ale zachowasz rozsądek.
źródło