Każdy, kto użył R # lub CodeRush, wie, jak szybko można łączyć proste konstrukcje (i refaktoryzować złożone) za pomocą prostego skrótu klawiaturowego. Jednak czy te wtyczki produkcyjne powodują fałszywą ocenę zdolności podczas wywiadów?
Częścią bycia produktywnym pisarzem kodów (i robieniem dobrego pierwszego wrażenia w wywiadzie) jest pisanie dobrego kodu - szybko.
Gdybym miał dwóch kandydatów:
Nie używa wtyczek. Myśli o problemie, siada w magazynie IDE na komputerze PC, który wygląda dokładnie tak jak ona, i jak zwykle pisze kod za minutę lub dwie. Gotowy. Przechodzić.
Korzysta z wtyczek. Myśli o problemie, siada w magazynie IDE na komputerze z wywiadem i zdaje sobie sprawę, że „fe + tab” nie zapisuje już automatycznie pętli foreach, a wszystkie skróty zniknęły. Następnie błąka się po klawiaturze, uderzając w swoje normalne klawisze skrótów, wyskakując z dziwnych okien i denerwując się. Napisanie tego, co normalnie zajmuje 30 sekund, zajmuje mu 3 minuty. Gotowy. Wyglądało na to, że czasami nie znali się na IDE. Musi być nowy w tym IDE i dlatego nie miał dużego doświadczenia z nim, a może z językiem. Podaj, ale obok ich nazwy znajduje się znak „meh”.
Jak według własnego doświadczenia radzisz sobie z wtyczkami podczas wywiadów jako ankieter lub ankieter? Jakie są najlepsze praktyki, aby uzyskać to, co kandydat naprawdę wie? Mogą być kandydaci, którzy nie rozumieją kodu i używają R # jako kuli. Mogą być również kandydaci, którzy znają kod wejściowy i wyjściowy i używają języka R #, ponieważ jest on po prostu szybszy niż wbudowane szablony VS lub Eclipse. Czy najlepiej w ogóle nie używać IDE? Pozwól im przynieść własny komputer? Inni?
źródło
:w
wszędzie byłyby wypełnione losowymi znakami.Odpowiedzi:
Niedawno byłem kandydatem 2 w wywiadzie . Dostałem waniliową instalację IDE na PC z niestandardową klawiaturą i nieznaną platformą testową, i poproszono mnie o napisanie prostej aplikacji Fizz-Buzz z testami jednostkowymi. Puściłem to. Musiałem wyglądać jak kompletny noob, potykając się w ciemności, próbując wykraść kod. Nie trzeba dodawać, że nie zaoferowano mi stanowiska.
Nauczyłem się, że bardzo polegam na moich wtyczkach. Nie tylko szybciej wpisują kod - kształtują sposób, w jaki myślę o kodzie i sposób, w jaki go koduję. Na przykład bardzo uważnie myślałem o nazwach zmiennych, ponieważ mogą one być kłopotliwe z powodu zmiany. Teraz, dla odmiany, po prostu na wpół wypowiadam się, w jaki sposób użyję zmiennej, zhakuję trochę kodu, pozwolę zmiennej powiedzieć mi, do czego ona służy, a następnie naciśnij Refactor-> Rename, aby nazwać ją bardziej odpowiednią .
Czy to czyni mnie mniej zdolnym kandydatem? Pod pewnymi względami tak myślę . Ktoś, kto potrafi pisać kod w Notatniku, aby go kompilował i działał poprawnie, ma pewne zalety w stosunku do kogoś takiego jak ja, który potrzebuje całej dobroci IDE, jaką może uzyskać. Z tego punktu widzenia doskonale rozumiem, dlaczego żadna firma nie zdecyduje się na zatrudnienie takiego narzędzia jak ja.
Z drugiej strony nadal jestem utalentowanym i zdolnym starszym programistą. Nauczyłem się, co dla mnie działa, i ćwiczę lenistwo, które sprawia, że jestem produktywny, biorąc pod uwagę moje własne słabości i ograniczenia. Krótko mówiąc, jestem rodzajem programisty, który naprawdę mógłby przynieść korzyści firmie takiej jak ta, która mnie odrzuciła .
Co ciekawe, miałem kilka wywiadów kilka tygodni temu. Po moich wcześniejszych doświadczeniach postanowiłem zapytać o dodatkowe narzędzia lub budżet na ich zakup. Odkrycie, że nie było dla mnie żadnego innego powodu, aby odrzucić propozycję (raczej hojną), którą mi złożyli .
Parafrazując Groucho, „ nie dołączę do żadnej firmy, która miałaby kogoś takiego jak ja dla pracownika ”.
W każdym razie, chyba że pozwolą mi użyć ReSharpera.
źródło
Pozwól im ( kandydatom ) wykorzystać to, czego chcą. Stare, zbuduj Wal-Mart ze szwajcarskim scyzorykiem, aby pokazać, że możesz podejść, jest tak stare. Wykorzystają wszystko, co potrzeba w ich codziennej pracy (cóż, mam nadzieję, że tak), więc niech wykorzystają wszystko, co chcą w rozmowie kwalifikacyjnej. Najważniejszy jest wynik końcowy. O wiele chętniej zatrudnię kandydata, który wie, jakie narzędzia są dostępne na rynku i jak z nich efektywnie korzystać, niż tego, który robi to wszystko ręcznie. To jest branża zabójców.
ps Jako przykład pomyślmy o Vimie (lub Emacsie) - czy chcesz go używać bez żadnych niestandardowych ustawień, wtyczek itp.?
źródło
Twierdzę, że narzędzia takie jak ReSharper sprawiają, że jesteś lepszym kandydatem.
Po pierwsze, coś takiego jak ReSharper nauczy Cię o konstrukcjach językowych, o których być może nie wiedziałeś, a także o lepszych sposobach uporządkowania kodu w celu myślenia o problemie lub nadawania mu struktury w celu zapewnienia czytelności. ReSharper, w pewnym sensie, trzyma cię w ryzach dzięki najlepszym praktykom do zawieszania kodu, zamiast pozwalać ci wrócić do złych lub przestarzałych nawyków lub, co gorsza, złego lenistwa.
Dobry programista musi rozumieć podstawowe konstrukcje, ale nie musi ich ręcznie wpisywać. Dobry rodzaj leniwości pozwala narzędziom na pracę przy pożyczaniu, a zamiast tego poświęca się zaoszczędzony czas na myślenie o problemie. To sprawia, że ogólnie jest się lepszym programistą.
Uzupełnię tok rozumowania stwierdzając, że jeśli proces wywiadu faworyzuje patyki i kamienne noże, jest to zasadniczo zepsute.
źródło
To jeden z powodów, dla których proszę ludzi o kodowanie na tablicy, a nie w IDE. Wyrównuje szanse. I ludzie mówią: „och, kochanie, zwykle zajmuje się tym dla mnie”. Do licha, wbudowane snipety obsługują pętle i takie, których tablica nie może ci dać. W takim przypadku powiedzenie czegoś w stylu „Mam nadzieję, że interpunkcja jest tutaj; jestem facetem z R #” to prawdopodobnie wszystko, czego potrzebujesz, aby powstrzymać mnie od posiadania przed tobą problemów ze składnią.
Potrzebuję umiejętności pisania zrozumiałego kodu na tablicy, abyśmy mogli zorganizować spotkanie, podczas którego ustalimy, w jaki sposób zamierzamy to zrobić. I oczywiście chcę sprawdzić, czy kiedykolwiek napisałeś kod w swoim życiu, czy nie. Twoje wywiady mogą się różnić.
źródło
Świetne pytanie BTW - często się nad tym zastanawiałem.
Opanowanie narzędzi to umiejętność, która ma kluczowe znaczenie dla bycia dobrym programistą. Zawsze czułem dzwonki alarmowe, gdy deweloper twierdzi, że woli pisać w notatniku niż przy użyciu IDE. Sugeruje to, że jest bardziej zainteresowany procesem niż produktem.
To tak, jakbyś wolał uprawiać ziemię motyką niż ciągnikiem - w porządku, jeśli jesteś ogrodnikiem-hobby, ale nie do zniesienia jako rolnik przemysłowy w konkurencyjnej gospodarce.
Stajemy się jednak zależni od naszych narzędzi. Wydaje się, że ludzie wariują na punkcie tego, jak poradzilibyśmy sobie w hipotetycznej sytuacji, w której nagle nasze narzędzia zostały zabrane. Taki sam argument dotyczył dopuszczania kalkulatorów do egzaminów.
Rzeczywistość jest taka, że narzędzia stają się coraz lepsze i coraz tańsze z każdym rokiem i nie ma powodu, dla którego miałbyś kiedykolwiek przypuszczać, że będziesz bez nich. Narzędzia świetnie nadają się do wykonywania powtarzalnych czynności o wysokiej jakości - co oznacza, że możemy skupić całą siłę naszego niesamowitego homo-sapiennego intelektu na trudnych (i interesujących) częściach.
ReSharper to niesamowity dodatek do Visual Studio. Moja obecna firma nie miała ReSharpera podczas wywiadu - ale byłam tak ewangeliczna w tym wywiadzie, że kupili mi kopię, gdy zaakceptowałem stanowisko, a także jedną dla dewelopera, który przeprowadził ze mną wywiad. Obecnie jest wdrażany w całej firmie. Dobre narzędzia zwracają się w mgnieniu oka.
Tak więc, aby odpowiedzieć na pytanie: twoja zależność od narzędzi może powodować fałszywą ocenę twoich umiejętności podczas wywiadu, ale zawsze będą one poprawnie oceniać umiejętności ankietera. Jeśli firma nie rozpoznaje wartości wsparcia narzędziowego w twoim wywiadzie - musisz pokazać im światło. A jeśli nadal tego nie zobaczą, byłbym bardzo zaniepokojony przyjęciem stanowiska.
źródło