Jak poradzić sobie z wywiadem „zły kod”? [Zamknięte]

Wywiad z „złym kodem” to taki, w którym osoba udzielająca wywiadu pokazuje fragment „złego kodu” i jest proszona o poprawienie go lub wskazanie, co jest z nim nie tak. Mam problem z tymi wywiadami, ponieważ zajmuje mi trochę czasu, aby przeczytać kod, dowiedzieć się, co on robi i wskazać wady. W sytuacji, w której występuje presja czasu, mam tendencję do zamrażania i widzę, że kod „powinien” działać, nawet jeśli nie.

Jaki jest dobry sposób na przeprowadzenie tego rodzaju wywiadu i, bardziej ogólnie, jakie są dobre techniki szybkiego czytania i rozumienia kodu ?

Wywiady z błędnym kodem (jeśli są poprawnie wykonane) powinny pokazywać kod z następującymi informacjami:

• Zła technika językowa ( usingw razie potrzeby nie używać instrukcji w języku C # lub ArrayListzamiast niej List<T>)
• Zła decyzja projektowa (dlaczego do cholery jesteśmy przechodząc ciągi wszędzie, albo używając refi outparametry tak dużo?)
• Błędy składniowe (nie powinno się nawet kompilować!)
• Błędy w czasie wykonywania (takie jak przepełnienie stosu spowodowane właściwością odwołującą się do siebie w języku C #)

Istnieje mentalna lista kontrolna, którą należy przejść, trafiając do każdego z powyższych punktów. Jeśli nie możesz spojrzeć na kod i to zrobić, to jest punkt do poprawy. Niezależnie od tego, w jakim języku jesteś uznany za „biegły”, powinieneś być w stanie spojrzeć na blok kodu i wskazać te cztery rodzaje błędów.

Niedawno napisałem na blogu o kodzie, który wykazywał wszystkie te problemy , powinien pomóc ci przejść przez ten sam proces umysłowy.

Ayende zagłębia się w serię Wages of Sin .

Nie próbuj szybko tego zrozumieć. Celem tutaj nie jest sprawdzenie, czy potrafisz zrozumieć kod jak guru, ale raczej zobaczenie, jak myślisz.

Kluczowym IMO jest po prostu głośne myślenie. Więc nawet jeśli się zamrozisz - po prostu powiedz: „Stresuję się tutaj, ale pozwól mi przejść przez to powoli na głos”.

Zakładając, że masz umiejętność głośnego myślenia, spowolni Cię na tyle, abyś mógł dobrze myśleć. Jeśli wywiady są wystarczająco bystre, zobaczą twoją sytuację i pomogą ci, dopóki nie pomyślisz jasno. Nie chcą cię oszukać, żebyś wyglądał głupio - to po prostu potężna technika, by zobaczyć, jak myślisz.

Szanse są takie, że „presja czasu”, którą odczuwasz, jest całkowicie narzucona samemu sobie. Ma to więcej wspólnego z poczuciem niepewności i zmartwieniem o to, jak dobrze sobie poradzisz.

Najlepszą radą, jaką można udzielić, jest: Relaks. Nie spiesz się, spójrz na kod i po prostu mów o tym, co widzisz tak, jak to widzisz. Nie krępuj się mówić o dobrych i złych stronach; Pomoże to zmniejszyć nerwowość i wewnętrzne obawy, że upłynie zbyt wiele czasu.

Ponadto przejście przez różne „przejścia” może nieco ułatwić dostrzeżenie konkretnych szczegółów. Weź jedną przepustkę w poszukiwaniu niedopasowanych aparatów ortograficznych lub literówek. Wybierz inną przepustkę, szukając zaciemnionych linii. Weź kolejny, szukając semantycznych precli. Skupienie się na jednym rodzaju „niewłaściwej rzeczy” może ułatwić dostrzeżenie tych szczegółów i (ponownie) zredukować wewnętrzne pytanie, czy robisz to szybko / wystarczająco dobrze.

Przede wszystkim mów przez to, co robisz i myślisz - pomoże to tobie i ankieterowi.

Nigdy nie brałem udziału w takim wywiadzie, ale kiedy próbuję opracować skomplikowany fragment kodu, który mógłbym podejrzewać, że jest zły, czasami rozmawiam cicho ze sobą. Czasem wokalizowanie pomaga mi w rozwiązywaniu problemów. Również w wywiadzie możesz spróbować prześledzić etapy wykonania jako diagram lub coś ołówkiem i papierem. To kiedyś działało dla mnie w szkole, wciąż robię to czasem w pracy. YMMV, oczywiście ...

Sądzę, że dobrym miejscem do rozpoczęcia (jeśli nie widzisz nic oczywistego) byłoby „debugowanie”. Jeśli nie widzisz możliwych problemów od samego początku, dobrym miejscem na początek jest sporządzenie małej listy wartości testowych. Dobre wartości to „szczęśliwa ścieżka” (normalna) wartość, „zero” lub „pusta” wartość, wartości null, bardzo mała wartość (ciąg 1 znaków, int 1 itd.), Bardzo duża lub bardzo długa wartość i „dziwne” wartości specyficzne dla typu (np. znaki Unicode dla ciągów, liczby ujemne dla liczb całkowitych itp.). Nie zaszkodzi tu wspomnieć, że normalnie piszesz testy jednostkowe przy użyciu tych wartości do testowania kodu, a po prostu uruchamiasz je w celu weryfikacji funkcji.

Zacznij od przejścia z wartościami szczęśliwej ścieżki. W przypadku funkcji dodatkowej możesz zacząć od 3 lub 4. Zbadaj każdą linię pod kątem literówek i błędów logicznych, śledząc wartości zmiennych lokalnych w miarę upływu czasu. Mam nadzieję, że znajdziesz kilka błędów. Kiedy skończysz ze szczęśliwą ścieżką, będziesz lepiej wyczuwał kod i mam nadzieję, że poczujesz się mniej przytłoczony - powiedz więc coś w stylu: „Teraz, gdy lepiej rozumiem, co robi ten kod, jestem cofając się i przyglądając się temu, „to po prostu rób to - szukając rzeczy, które wyróżniają się jako rzeczy, które zrobiłbyś inaczej (złe decyzje projektowe, źle nazwane zmienne, badaj możliwe błędy itp.).

Jeśli to cię nigdzie nie prowadzi lub masz wrażenie, że zabrakło Ci rzeczy do powiedzenia, wróć do listy wartości testowych i przejrzyj ją ponownie z nową, która Twoim zdaniem może powodować problemy.

To cię przynajmniej uruchomi.

Jak powiedział Stephen Bailey, myślenie na głos jest doskonałą techniką w tej sytuacji, ponieważ pozwala ankieterom zobaczyć proces myślenia. W pewnym sensie wyjaśnij, co próbujesz rozgryźć. Inną rzeczą, którą możesz zrobić, to poinformować ankieterów, że będziesz czytał kod poprawnie przed postawieniem diagnozy na temat złego kodu. Byłem po obu stronach stołu i wiem, że w tych sytuacjach może to być frustrujące dla obu stron.

Jeśli odczuwasz mniejszą presję podczas wykonywania testu pisemnego, wyciągnij notatnik i zacznij robić notatki. Wyciągnąłem notatnik i zacząłem szkicować notatki w ramach mojego procesu myślenia w wywiadzie. Posiadanie notesu i pióra sprawia, że ​​wyglądasz na uporządkowanego. Możesz zapisać kilka wypunktowanych rzeczy, których należy szukać, składnię, błędy logiczne, niedopasowania typu danych, wartości zmiennych lokalnych (lista może się różnić w zależności od rodzaju otrzymanego kodu, moja lista złożonego fragmentu SQL być innym niż ktoś, kto dostał kawałek kodu, który nie był skoncentrowany na danych) podczas przechodzenia przez proces itp. Po napisaniu kilku z nich, zacznij ich szukać. W ten sposób, nawet jeśli nie znajdziesz wszystkich problemów, zanim ankieter nie będzie chciał przejść dalej, będzie mógł zobaczyć listę rzeczy, które chciałbyś sprawdzić. Jeśli wcześniej utworzysz listę kontrolną rzeczy, których możesz chcieć szukać, poczujesz się pewniej, rozpoczynając proces, wiedząc, które rzeczy planujesz obejrzeć. Zazwyczaj te pytania dotyczą raczej sposobu znalezienia błędów niż faktycznego znalezienia ich wszystkich.

Jestem trochę spóźniony na tę imprezę, ale jedną z technik, której można użyć, byłoby napisanie testów jednostkowych dla danego kodu. Następnie możesz mniej skoncentrować się na tym, co subtelnie źle działa z kodem, a więcej na oczekiwanych oczekiwanych wynikach. Wolę zatrudnić kogoś, kto może napisać dobre testy, niż kogoś, kto może natychmiast dostrzec, co jest nie tak z fragmentem kodu.

Mogą występować dwa problemy:

Może to być „wywiad stresowy” http://en.wikipedia.org/wiki/Job_interview#Stress . Ankieter stara się zobaczyć, jak radzisz sobie ze stresem, ponieważ takie jest środowisko pracy.

LUB

Możesz się stresować. W takim przypadku będziesz musiał poradzić sobie ze stresem, np. Introspekcją i zobaczyć, jak możesz zachować spokój.