„Testowanie” tablicy podczas wywiadu: uzasadniony sposób na wykonanie kopii zapasowej kodu (tablicy)? [Zamknięte]

Jak rozumiem, błąd (nawet literówka lub brak liter „;”) w kodzie tablicy często kosztuje kilka punktów wywiadu. Unikanie tego nieuchronnie sprawi, że jeden kod korekty będzie odtąd powtarzany (tracąc czas i być może energię / koncentrację neuronową) lub nawet używając prostszego (a przez to mniej efektywnego) algorytmu - i oba te sposoby są znowu „kosztowne”!

Dlaczego więc nie napisać szybko tak eleganckiego i skutecznego kodu, który miałby do dyspozycji (jednostkową) platformę testową, a następnie normalnie ją przetestować (tylko na tablicy)?

Czy ktoś próbował / widział takie podejście? Czy cały pomysł jest godny?

[dotyczy to oczywiście również długopisu i kartki]

Absolutnie chcę, żebyś przetestował kod tablicy, o którą proszę napisać. Chcę, żebyś mówił głośno podczas pisania, przeglądał go, dostrzegał większość popełnianych błędów składniowych i wskazywał, w jaki sposób może być bardziej wydajny. Właściwie to taki punkt na tablicy. To nie jest jednorazowe, napisać to wszystko, uh-huh-you-get-70/100. To rozmowa, w której pośredniczy kod i odbywa się na tablicy zamiast na moim biurku.

Oto kilka świetnych sposobów na niepowodzenie testu „Kodowania tablicy”:

• odrzuć to
• nie zadawaj ani jednego wyjaśniającego pytania (język, platforma, coś na temat wymagań) ORAZ nie mów mi swoich założeń na temat któregokolwiek z nich ORAZ nie rób założeń, które są dalekie od tego, na co odpowiedziałbym

(np .: napisz to w Fortranie, zinterpretuj „wyświetl” lub „drukuj” jako „napisz do dziennika zdarzeń”, tego rodzaju rzeczy. Mogę na to pozwolić, jeśli wcześniej powiesz mi, jakie były twoje założenia)

• zapytaj mnie, w jakim języku chcę, otrzymaj odpowiedź, która jest w opisie stanowiska, a następnie napisz w innym języku, ponieważ nie czujesz się komfortowo w języku, o który prosiłem.

(Jesteśmy tutaj konsultantami. Testuję zachowanie konsultanta tak samo jak kodowanie. Pytanie klienta jest poprawne tylko wtedy, gdy klient rzeczywiście ma wybór. Kontrolowanie rozmów z ludźmi, którzy ci zapłacą, jest trudne. To lekcja 1. To jest zaznacz przeciwko tobie na dowolny temat, ale dla konkretnego „zatrudniasz programistę X, ale nie chcę pisać w X dla ciebie”, masz teraz dwa duże czarne znaki).

• pokaż mi, jakim jesteś astronautą architektury, wypełniając dwie tablice interfejsami, wzorami fabrycznymi, abstrakcjami, zastrzykami i testami, kiedy chciałem, abyś „wydrukował liczby od jednego do 5”.

(myślisz, że przesadzam, ale miałem faceta, który dramatycznie uogólnił mój problem - trzymając się powyższego przykładu powiedzmy, że zamiast 1 do 5 jego rozwiązanie wykonałoby dowolną sekwencję liczb całkowitych (skąd? Zastanawiałem się) i było 5 razy tak długo, jak ktokolwiek inny - i zapomniał faktycznie zadzwonić do funkcji, która wykonała tę pracę. Powtarzające się podpowiedzi i sugestie, aby przejść przez nią tak, jakby był debuggerem, nie spowodowały, że zauważył, że funkcja nigdy nie została wywołana).

Zawsze mówię „lubisz to?” „czy możesz to poprawić?” „poprowadź mnie przez to” i tym podobne. Zazwyczaj w tej rozmowie zauważany jest brakujący dwukropek lub osobno. Jeśli nie, zwykle oceniam to na nerwy.

Inne rzeczy, które mogą nie mieć znaczenia na tablicy, które są dla mnie ważne:

• kiedy skończysz, czy nadal mogę to przeczytać? Czy rozmazałeś się, nabazgrałeś, zmieniłeś kolory, narysowałeś strzały, przekreśliłeś i ogólnie zostawiłeś bałagan, którego nie można teraz użyć? A może zdajesz sobie sprawę, że tablice są kasowalne, wskazują linie kodu w powietrzu zamiast krążyć / arroryzują je i pozostawiają mi coś, co mógłbym zrobić zdjęcie i zachować w pliku projektu?
• ile mnie zapytałeś, gdy to zrobiłeś? Czy lubisz być sam i nie dyskutować o swoim kodzie, czy widzisz kod jako coś wspólnego? Jak zareagowałeś, kiedy pytałem cię o to, pisząc jeszcze?
• szydziłeś z „łatwego” zadania, czy zemdlałeś z „trudnego” zadania? Czy byłeś niegrzeczny z powodu poproszenia Cię o pokazanie, że umiesz pisać? Czy łatwo Cię zastraszy problem techniczny, czy arogancka umiejętność wymyślenia dobrego algorytmu?
• pracujesz nad tym w swojej głowie, czy pamiętasz rozwiązanie, które gdzieś przeczytałeś? Zwykle potrafię rozpoznać trudne problemy.
• czy planowałeś z wyprzedzeniem, gdzie zacząłeś pisać? Ludzie, którym kończy się tablica, zwykle zaczynają za mało lub piszą za dużo - mogę powiedzieć, że nie wiedzieli, że to będzie 20 linii kodu, więc zostawiłem tylko miejsce na 5 - wierzcie lub nie, ten drobny szczegół jest odzwierciedlony w większe zadania szacowania.
• obejrzałeś to zanim powiedziałeś, że skończyłeś? Czy widziałem, jak wskazujesz lub stukasz swoją drogę i testujesz to, zanim cię o to poprosiłem? Kiedy zapytałem cię lub zadałem ci konkretne pytania, czy spojrzałeś na to ponownie, czy po prostu odszedłeś z pamięci? Czy chcesz wziąć pod uwagę, że Twój pierwszy szkic może nie być kompletny?

Zdecydowanie polecam ćwiczenie kodowania na tablicy. Zawsze ostrzegam rozmówców, że zostaną o to poproszeni. Jeśli masz dostęp do rzeczywistej tablicy, postaw sobie kilka prostych problemów i poćwicz je tam. Pomoże to w osiągach i zaufaniu.

Przepraszam, wiem, że jestem na terytorium TL; DR, ale o to chodzi - kodowanie na tablicy to coś więcej niż kodowanie . To test na więcej niż znajomość składni. Istnieje wiele zachowań dobrych programistów, które zostały przedstawione w odpowiedzi na to zadanie. Jeśli uważasz, że chodzi tylko o kodowanie, nie rozumiesz sedna sprawy.

W innych rozmowach na temat testowania tablicy ludzie mówią mi, że mogę odrzucić dobrego kandydata. Szczerze mówiąc, to ryzyko, które chętnie podejmę. Każda runda zatrudniania zawiera kilka osób, które mógłbym zatrudnić. Niektóre osoby ze świetnymi życiorysami, które dobrze sobie radzą w części wywiadu z pytaniami i odpowiedziami, rozpadają się na tablicy i najwyraźniej nie mogą (bez żadnej zachęty) pisać prostego kodu w języku, który, jak twierdzą, znają. Mogłem zatrudnić niektóre z nich. Każde narzędzie, które temu uniemożliwia, będzie narzędziem, którego będę nadal używać. Nigdy nie znalazłem nikogo, kto wynająłby łódź, ponieważ wszyscy moi kandydaci zawiedli przy tablicy i nie oczekuję, że kiedykolwiek to zrobię.

Myślę, że podjąłeś tutaj błędne założenie. Nie ma mowy, żebym spodziewał się, że kandydat piszący kod na tablicy będzie w stanie uzyskać każdy ';' idealnie na miejscu. Jeśli przeprowadzasz wywiad w miejscu, które cię za to karze, sugeruję, że nie jest to organizacja, w której chcesz pracować :-).

Testy na papierze lub tablicy są wyjątkowo nieskuteczne. Pamiętam raz, kiedy miałem wywiad, w którym musiałem szukać błędów w jakimś kodzie na papierze. Jednym z nich było to, że klasa odziedziczyła interfejs, ale brakowało implementacji elementu członkowskiego. Wiedziałem, że to prawdopodobnie jeden z błędów, szukałem go iz jakiegokolwiek powodu na miejscu po prostu go nie widziałem (chociaż wspomniałem, że szukałem tego jako jednego z problemów).

Tak się składa, że ​​wciąż dostałem tę pracę, ale to sprawiło, że pomyślałem o tym, co się stało. W realistycznym scenariuszu dla tego typu rzeczy będę miał zawiłe linie w momencie, gdy coś jest nie tak (jest to C # w Visual Studio) i rzecz nie będzie się kompilować. Nigdy tego nie sprawdzam w prawdziwym życiu, ponieważ to się nigdy nie zdarza (jest to niemożliwe) i dlatego przestałem patrzeć na takie rzeczy. Brakujące średniki są jeszcze bardziej ekstremalnym przykładem - całkowicie nierealistycznym w prawdziwym świecie, chyba że piszesz w notatniku i wysyłasz swój kod e-mailem do kogoś innego, aby go skompilować!

Jeśli ktoś podczas rozmowy poprosi o użycie tablicy, aby wesprzeć coś, co chce powiedzieć, to świetnie, ale nigdy nie zrobiłbym tego na odwrót.

To zrobiłem. Podczas wywiadu poproszono mnie o zaimplementowanie kodowania na całej długości tablicy i chociaż skróciłem część kodu (wyjaśniając, co skracam), aby dopasować się do tablicy, nadal opracowałem zbiór testów dla tego urządzenia, i przejrzałem jedno z nich, aby sprawdzić poprawność mojego rozwiązania i pokazać, w jaki sposób testy mogłyby pomóc. Zaproponowano mi tę pozycję, więc zakładam, że testowanie okazało się pomocne, aw najgorszym przypadku nie irytujące.

Używam tego podejścia podczas egzaminów do szkoły. Najpierw piszę funkcję, a potem z boku piszę tabelę wejść, wyjść i zmiennych. W ten sposób złapałem kilka głupich błędów. Testowanie, nawet testowanie na papierze / tablicy, jest zawsze lepsze niż nie testowanie.

Nie zgadzam się jednak z wariowaniem na temat średników w profesjonalnym otoczeniu.

Proszenie kandydata o kodowanie na tablicy jest głupie. Istnieją nowoczesne narzędzia, takie jak snippits, jsfiddle i intellisense. Ponadto żaden inżynier nie powinien być zobowiązany do zapamiętywania składni. Składnia jest sprawdzana i odwoływana. Jeśli zapamiętujesz kod, prawdopodobnie nie spędziłeś czasu w swojej karierze, ucząc się kodowania w środowisku z wieloma dzierżawcami, optymalizując składnię, a nawet środowisko hostowane.

Kiedy restauracja chce zatrudnić szefa kuchni, właściciel nie prosi go, aby ugotował „pot au feu” z wykałaczką i czapką.

Nie proś dewelopera o kodowanie na tablicy w wywiadzie.

Kodowanie na białej tablicy jest trudne. Nigdy nie zostałem o tym poinformowany, dopóki nie przesłuchał mnie Disney. Nie wiedząc, czego się spodziewać i nie mogąc go debugować, natknąłem się na to, omawiając i rozwiązując problem, ale w pewien pseudo-kodowy sposób. Gdy zapytali, czy to może działać.

Mam na myśli, że to może po prostu naprawić błędy składniowe, popraw. Uważam, że stracili bardzo dobrego kandydata, jeśli nie zostałem zatrudniony z powodu tablicy. Patrzę na kwalifikacje i wygląda na to, że mam odpowiednie kwalifikacje na to stanowisko i mogę wykonać tę pracę. Świetnie sobie radzę z obecną pracą i żałuję, że nie mogę z nimi pracować.

Dziękuję za twój wkład, Kate, czytam każde słowo. To tylko dla mnie jako programisty, biała tablica naprawdę nie pokazuje twoich umiejętności. Jestem świetnym programistą pracującym w wielu językach. Znałem język, w którym zostałem poproszony, ale nagle na białej tablicy nagle zapomniałem.

Buduję złożoną integrację i przetwarzanie kart kredytowych, ale na białej tablicy nie pamiętałem, jak nawet wykonać właściwą składnię, nic mnie nie podpowiada.

Jako pracodawca lubię testy białej tablicy; jednak zatrudniam programistę, który chce zobaczyć ich rzeczywiste umiejętności, jeśli wykonują swoją pracę. To świetnie, jeśli potrafią się komunikować, ale muszę zobaczyć, jak potrafią rozwiązywać problemy.