Dlaczego ankieterzy nie proszą wnioskodawcy o przeczytanie kodu? [Zamknięte]

Miałem w życiu kilkanaście wywiadów (mam zamiar ukończyć studia) i zastanawiam się, dlaczego tylko raz poproszono mnie o przeczytanie i wyjaśnienie jakiegoś kodu. Z grubsza 90% miejsc pracy dotyczy głównie utrzymania istniejących systemów. Ważna jest umiejętność IMO do czytania kodu innej osoby.

Dlaczego ankieterzy tego nie sprawdzają? *

* _{Wśród moich znajomych jestem jedynym, który został poproszony o przejrzenie jakiegoś kodu.}

Kiedy zadawałem pytania na rozmowę kwalifikacyjną, najpierw to robiłem, ale powoli ją wycofywałem. Wszyscy kandydaci, którzy potrafili dobrze pisać kod podczas wywiadu, mogli dobrze czytać kod podczas wywiadu. Wnioskodawcy, którzy nie potrafili odczytać kodu, również nie mogli go napisać. Pytania związane z czytaniem kodu tak naprawdę nie różnicowały żadnego kandydata.

Krótka wersja

Jeśli praca polega na utrzymaniu aplikacji, umiejętności, które musisz sprawdzić podczas rozmów kwalifikacyjnych to:

• Zdolność do zrozumienia dużej bazy kodu z jej dokumentacją, testami jednostkowymi itp.

• Umiejętność byłaby kod i przynieść zmiany bez zerwania wszystko.

Poproszenie ludzi o przeczytanie kodu nie pomoże ci ocenić tych umiejętności.

Długa wersja

Czy zostałeś poproszony o napisanie kodu? Jeśli tak, jak zauważył w swojej odpowiedzi Sign , to wystarczy. Jeśli trochę uogólnimy, osoba, która napisze jasny, łatwy do zrozumienia kod źródłowy, będzie w stanie odczytać kod źródłowy napisany przez inne osoby.

Jeśli nie zostałeś poproszony o napisanie kodu, to prawdopodobnie byłeś przesłuchiwany przez osobę z działu zasobów ludzkich. Takie rozmowy nie mogą być zbyt techniczne i są w większości bezwartościowe, ponieważ nie doceniają twoich umiejętności i zdolności do dobrej pracy, ale raczej liczbę lat spędzonych na studiach i innych rzeczy, które nie mają nic wspólnego z pracą.

Jest jeszcze kilka powodów, dla których nie należy prosić o odczytanie kodu dla zadania konserwacji:

1. Trudno to zrobić niezawodnie

A konkretnie, co byś zrobił, gdybyś był ankieterem? Niech twoi kandydaci przeczytają jakiś kod. Jaki kod? W jakim języku? Jak dobrze lub źle napisane? Z komentarzami czy bez? Z dokumentacją czy bez?

Co ważniejsze, co mówi o kandydacie? Jak dobrze koreluje z samą bazą kodu?

Załóżmy, że masz starszą aplikację VB.NET do utrzymania. Wiesz, że kod źródłowy jest w większości brzydki i nieprzetestowany, a kilka komentarzy jest nieaktualnych lub wprowadzających w błąd. Przez ostatnie trzy miesiące miałeś bardzo zręcznego programistę pracującego nad rozwiązaniem; przebudował i przetestował najbardziej krytyczne części aplikacji, dodał komentarze tam, gdzie były potrzebne komentarze, i, co najważniejsze, napisał szczegółową dokumentację na temat ogólnej architektury, części krytycznych i pułapek.

Zatrudniasz teraz programistę do obsługi tej bazy kodu. Czy podczas wywiadu podałbyś fragment kodu (brzydki, nieprzetestowany), czy fragment kodu, który został ponownie opracowany przez poprzedniego programistę?

Czy dostarczyłbyś dokumentację? Aby przeczytać dokumentację, kandydat musi spędzić co najmniej kilka godzin. To uniemożliwia to podczas rozmowy kwalifikacyjnej.

2. Czytanie krótkiego kodu nie jest tym samym, co czytanie kodu znanego projektu

Pamiętaj, że zadaniem jest utrzymanie projektu. Trudno jest utrzymać dużą bazę kodu w pierwszych dniach lub tygodniach, gdy nie znasz projektu. O wiele łatwiej jest to zrobić po kilku miesiącach, kiedy napisałeś całą dokumentację i masz jasny obraz ogólnej bazy kodu.

Najważniejszą rzeczą do przetestowania jest to, czy dana osoba będzie skuteczna w tych miesiącach . Nie obchodzi cię, czy dana osoba nie będzie w stanie nic zrozumieć przez pierwsze dwa dni.

Prosząc osobę o przeczytanie krótkiego fragmentu kodu od zera, nie testujesz, w jaki sposób ta osoba byłaby w stanie poradzić sobie ze znanym, udokumentowanym kodem tysięcy LOC .

3. Utrzymanie kodu źródłowego to nie tylko jego czytanie

Kiedy utrzymujesz bazę kodu, modyfikujesz ją. Deweloper, który po prostu czyta kod, nie wnosi nic użytecznego dla jego firmy.

Przydatne umiejętności to zdolność do refaktoryzowania kodu , dodawania testów jednostkowych , przewidywania wpływu zmiany itp. Nie testujesz tych umiejętności, prosząc osobę o przeczytanie kodu podczas rozmowy.

Czytanie jest założeniem opartym na tym, że umiejętność pisania jest obecna. Rozważ tę koncepcję w dowolnym języku. Programowanie to tylko język komunikacji między człowiekiem a maszyną. Zastanów się nad komunikacją między ludźmi. Gdybyś zatrudniał kogoś, kto byłby tłumaczem japońskiego, czy nie miałoby to uzasadnienia, że ​​gdyby mógł napisać esej na 1000 słów na konkretny temat, byłby w stanie go przeczytać?

Jako programiści naszą podstawową działalnością jest tworzenie kodu i tłumaczenie abstrakcyjnych pomysłów na konkretne implementacje. Ogólnie oznacza to pisanie. Zgadzam się, że czytanie jest równie ważne, ale w zdecydowanej większości przypadków, w których umiejętność pisania jest obecna, zdolność czytania jest również obecna. Jedynym prawdziwym przypadkiem, w którym dostrzegłem zauważalną różnicę, byłoby środowisko, w którym istnieje wiele bardzo złożonych przypadków, które ewoluowały w czasie. Nawet biorąc pod uwagę te, nie można oczekiwać, że ktoś będzie w stanie je przeczytać i zrozumieć bez przynajmniej odrobiny nauki.

Ponadto czytanie kodu i wyjaśnianie, co według niego nie działa, tak naprawdę nie mówi ankieterowi, jak wykorzystujesz swoje umiejętności krytycznego myślenia. Pokazuje trochę analizy, ale większość pracodawców chce sprawdzić, czy możesz myśleć bez umieszczania w pudełku. Chcą wiedzieć, czy potrafisz uchwycić pojęcia bez korzyści (lub nawet kruszenia) istniejącego kodu, aby powiedzieć ci, co lub jak zrobić.

W przeszłości uważałem, że czytanie kodu powinno być czymś zademonstrowanym w wywiadach, ale z czasem zdałem sobie sprawę, że jest to strata czasu zarówno dla ankietera, jak i ankietera. Dlaczego? Ponieważ nawet źli koderzy potrafią odczytać fragment kodu.

Możliwość oceny czyjejś umiejętności czytania kodu staje się istotna tylko wtedy, gdy spojrzysz na coś złożonego lub kodu obejmującego wiele klas i plików. Możliwość śledzenia kodu w celu ustalenia, co robi, jest pożądaną cechą, ale po prostu nie ma wystarczająco dużo czasu, aby ktoś wymyślił dobry przykład (nie kod produkcyjny), ani też nie ma czasu na wywiad, aby zadać takie pytanie .

Źli koderzy potrafią czytać kod, ale nie potrafią dobrze pisać kodu. Proszenie o obejrzenie przykładów pracy kandydata lub poproszenie kandydata o napisanie kodu podczas rozmowy kwalifikacyjnej to zdecydowanie lepsze wskaźniki ich umiejętności. Jeśli potrafią napisać czysty zwięzły kod, są szanse, że potrafią odczytać kod.

Pytam każdego kandydata, z którym przeprowadzam wywiad, o odmianie problemu FizzBuzz . Jest szybki, prosty i zwykle potrafi wykryć złe kodery znacznie szybciej niż cokolwiek innego, co znalazłem. Dobry programista zdobędzie go bardzo szybko i łatwo i pozwoli ci szybko zapoznać się z ich stylem kodowania i procesem myślowym.