Jak ważne jest poprawne składniowo podczas wywiadu? [Zamknięte]

Czy pytając kandydata na rozmowę kwalifikacyjną o napisanie programu na tablicy, czy oczekujesz od kandydata napisania kodu, który jest poprawny pod względem składniowym?

Miałem dwóch kandydatów, z których jeden napisał poprawny składniowo program, ale logika nie była do końca zgodna, a drugi miał lepszą logikę, ale składnia była bzdura.

Preferuję pierwszego kandydata.

Faworyzuję osobę, która była w stanie uzasadnić problem, znaleźć dobre rozwiązanie, a następnie wyjaśnić mi swoje rozwiązanie. Nawet jeśli ich logika nie była w 100%, jeśli byli na dobrej drodze i rozważali problem, zadawali właściwe pytania i podążali właściwą ścieżką, to byłby mój zwycięzca.

Podczas opracowywania kodu w zadaniu masz wiele narzędzi - IDE, kompilatory, analizy statyczne, testy jednostkowe, testy integracyjne i procedury testów akceptacyjnych - aby znaleźć błędy w składni i logice. Jeśli piszesz na białej tablicy, nie masz tych narzędzi i musisz popełniać błędy w składni (zapominając o nazwie metody, średniku, nawiasie klamrowym) i mogę ci to wybaczyć.

Moje jedyne pytanie do ciebie: dlaczego twoi kandydaci piszą rzeczywisty kod na tablicy, zamiast skupiać się na algorytmach, strategiach projektowych i logicznym myśleniu? Języki programowania zmieniają się, rozwiązywanie problemów nie.

Faworyzuję drugiego kandydata. Logika może być trudna ( czasami bardzo trudna), aby uzyskać dokładne rację. Składnia może być bardzo łatwa do uzyskania, gdy IDE, kompilator i inne wybrane narzędzia pomagają.

Pierwszy kandydat może nigdy nie wywołać błędu kompilatora, ale jeśli jego kod często zawodzi we wszelkiego rodzaju dziwnych (i mniej dziwnych) przypadkach granicznych, jego wiedza, gdzie umieścić średnik, nie jest aż tak warta.

W zależności od rzeczywistych błędów składniowych, myślę, że wolałbym drugiego kandydata , ponieważ sprawdzanie składni jest zwykle lepiej pozostawione maszynom .

Błędy, takie jak brakujące średniki, zapominanie nawiasów zamykających, zapominanie przecinków na listach argumentów itp., A nawet błędy nie syntaktyczne, takie jak zmiana kolejności argumentów podczas wywoływania funkcji, zwykle zostają złapane przez wyróżnienie składni, kompilator lub przy pierwszym uruchomieniu kodu , wszystkie rzeczy, których zwykle używa się, ale nie są dostępne na tablicy.

Istnieją jednak pewne błędy, które, choć technicznie tylko błędy składniowe, wskazują na głębsze nieporozumienie.

Jako nieco sztuczny przykład, aby przejść do sedna: rozważmy programistę python, który poprzedza wszystkie swoje zmienne znakiem $ lub zapisuje pętlę for jako for list as item. Technicznie oba są błędami składniowymi, ale nawet przy ograniczonym kontakcie z pythonem należy wiedzieć, co z legalnymi znakami i pętlą for. Byłoby dobrze zgadnąć, że kandydat zna php (lub Perl?) I próbuje blefować o swoich umiejętnościach w Pythonie

Wolałbym drugiego kandydata, zgodnie z teorią, że tablica ma większy wpływ na składnię niż na logikę i że błędy składniowe są łatwiejsze do poprawienia - zwykle może to zrobić IDE lub kompilator.

Piszę SQL i CSS (najprostsze i podstawowe języki, jakie znam) od prawie 13 lat i nie zawsze pamiętam składnię.

Mój przyjaciel (także programista) pracuje dla funduszu hedgingowego, nigdy nie pamięta składni instrukcji insertowej.

Oboje skończymy na W3CSchools , myślę, że powinniśmy się wstydzić (on ma stopień naukowy, a ja mam doktorat).

Jednak szczerze mówiąc, uważam, że nasze priorytety są prawidłowe. Składnia nie jest ważną umiejętnością.

Kilka myśli o błędach składniowych ... Zastanawiałem się, czy wyjaśniłeś obie, że składnia musi być poprawna. Czasami ludzie zakładają, że pseudo kod jest OK.

Ponadto, jeśli ktoś twierdzi, że ma wieloletnie doświadczenie w języku i nie może poprawić podstawowej składni, należy wątpić w to twierdzenie.

Błędy składniowe mogą się różnić, więc jeśli ktoś zapomni nazwę metody, jest to w porządku (dla mnie), ale jeśli ktoś nie wie, jak odwołać się do metody w klasie (notacja kropkowa) lub nie zna podstawowej myśli, takiej jak składnia prosta klasa, więc są szanse, że ta osoba nie używa języka od dawna.

Czy dla faceta, który nie uzyskał poprawnej składni, czy uważasz, że jego błędy można było łatwo naprawić za pomocą odpowiedniego edytora językowego? jeśli tak, głosuję na niego.

Myślę, że myślę o tym, że błędy składniowe są dopuszczalne w określonych granicach.

Młodszy asystent programisty lub nawet narzędzie programowe może znaleźć i naprawić złą składnię, jeśli logika jest dobra. Zła logika ... każda poprawka jest znacznie mniej pewna. Wszyscy programiści spieprzą. Wybrałabym tego, który ma błędy, które łatwiej jest zlokalizować i naprawić.

O ile problem nie jest subtelny, a większość pytań podczas rozmowy nie jest, pierwszy kandydat zostaje zdyskwalifikowany. O wiele łatwiej jest nauczyć się składni języka niż projektowania algorytmów. Zatrudnię programistę z historią udanej pracy w wielu językach, nawet jeśli nie ma on doświadczenia w mojej obecnej technologii. Nie jest to najlepsza strategia, jeśli potrzebuję dziś czegoś, ale jeśli potrzebuję wielu rzeczy do zrobienia w ciągu następnych dwunastu miesięcy, zawsze wybiorę ogólną umiejętność zamiast określonego doświadczenia.

Sprawdzanie składni jest tym, do czego służy kompilator. Kompilator nie może poprawić twojej logiki, ale może ci powiedzieć, jak naprawić składnię. Oznacza to, że w każdym zadaniu, w którym piszesz kod za pomocą kompilatora, logika jest z natury znacznie bardziej wartościowa niż poprawność składniowa.

Wywiady są zawsze niewygodne sytuacje - można powiedzieć o tym, ponieważ kiedy wyjdziesz, od razu pomyśleć o wszystkich rzeczach, które powinny być wymienione lub prawo odpowiedzi na pytania i rzeczy, które chcieli ich zapytać ale zapomniałem. Biorąc to pod uwagę, oczekiwanie idealnie napisanego kodu bez błędów składniowych jest nierealne.

Dodatkowo, twoje oczekiwania dotyczące idealnego kodu (na tablicy!) Mogą nie odpowiadać ankieterom - na przykład podczas jednego wywiadu, w którym uczestniczyłem, zostałem poproszony o napisanie zajęć, co zrobiłem, tylko po to, aby ankieter mnie podniósł w konstruktorze kopii. Więc napisałem jeden w, który nie zrobił nic poza ustawieniem a = b, ale to wystarczyło, aby go zadowolić. Moje oczekiwania co do problemu nie wymagały ctor kopiowania, więc pominąłem go jako niepotrzebny do rozwiązania problemu - nie spodziewałem się, że będę musiał napisać w pełni zgodny, kompilujący kod (zgodnie z jego standardami ukrytego kodowania), po prostu pokaż moje zrozumienie rozwiązania. (ten sam ankieter również nie polubił mojego rozwiązania, nie zrobiłby tego w ten sposób, więc oczywiście popełniłem błąd, westchnienie).

Jeśli chcesz uzyskać działający kod od rozmówcy, daj mu kompilator. Więc nie narzekaj, kiedy będą Cię fakturować :)

Wybierz więc osobę, która wie, co robi, a nie tę, która potrafi papugować słowa, ale nie rozumie znaczenia.

Podczas wywiadu ankieter jest bardziej zainteresowany twoją wizytą

1. Podejdź do problemu
2. Umiejętności wykorzystane do rozwiązania problemu i
3. Czas potrzebny na skuteczne podanie właściwego rozwiązania

Składnia nie jest jednak tak ważna, ale zajmuje znaczące miejsce podczas rozwiązywania problemu, z poważnymi błędami w składni, których nie można oczekiwać od wrażenia osoby przeprowadzającej wywiad.

Odpowiednia logika i składnia razem mogą pomóc ci w wywiadzie.

Mały lub drobny błąd nigdy nie kosztowałby cię dużo, gdyby logika była wystarczająco dobra.

Co więcej, mogą być dostępne IDE, które mogą z łatwością stworzyć składnię nawet dowolnego w odpowiednim kształcie. Ale aby użyć tej metody, gdzie i kiedy i co najważniejsze DLACZEGO , byłby znany tylko facetowi z odpowiednią logiką i znajomością rzeczywistego tematu.

Mam nadzieję i zachęcam do podania czegoś więcej niż białej tablicy lub notatnika do napisania kodu.

Poszedłbym z drugim kandydatem. ..

Cóż, niektórzy ludzie chcą świetnych programistów Java, świetnych programistów C #, świetnych programistów C ++ itp. Jeśli tak jest w twoim przypadku, wybierz A i więcej mocy. Jedną z moich obaw jest to, że jeśli nie potrafią rozwiązać problemu, jak możesz oczekiwać, że rozwiążą twoje problemy biznesowe?

Inni ludzie chcą po prostu świetnych programistów, którzy mogą pracować w dowolnym języku. Myślą / modelują problem, a następnie wdrażają go w dowolnym języku. Jeśli nagle zdecydujesz, że .NET jest do bani i przełączasz się na Javę lub odwrotnie, są to programiści, którzy nie rzucą się na statek ani nie odmówią nauki. Również jeśli otrzymasz jakiś pakiet automatyzacji / pakiet obliczeniowy, który ma zastrzeżony język i potrzebujesz niektórych zadań zautomatyzowanych, są to typy programistów, którzy mogą to zrobić. Przykład z prawdziwego życia ... Musiałem wymyślić własny, zastrzeżony język skryptowy dla pakietu oprogramowania do mapowania, aby wyodrębnić kody pocztowe dla niestandardowych rysowanych regionów dla starego pracodawcy. Kolejny przykład ... mój obecny pracodawca ma zastrzeżony system zarządzania nieruchomościami, który zawiera niestandardowy język do pisania raportów ... W każdym razie

Również na białej tablicy jest dodatkowy nacisk / nerwowość, więc nikt nie jest w najlepszej formie. Poza tym bardzo wątpię, aby kodowanie było idealne za każdym razem. Podejrzewam, że kompilujesz lub po prostu uruchamiasz się i znajduję błędy. Dodatkowo zależy to od języka. C jest na tyle mały, że prawdopodobnie możesz zapamiętać większość bibliotek językowych / podstawowych (choć nie wymagałbym tego). Java / C # ma tak ogromne biblioteki (z tak częstymi zmianami), że zapamiętywanie biblioteki nie wchodzi w rachubę.

Również znajomość wielu języków może działać przeciwko tobie. C # i Java kolidują ze mną. Ale znajomość wielu języków może również poszerzyć twoją perspektywę, szczególnie jeśli znasz język skryptowy i język funkcjonalny oprócz C # / Java.

Mimo to, jeśli obaj kandydaci rozwiążą problem z prawidłową logiką, facet z poprawną składnią prawdopodobnie ma przewagę. Jeśli ktoś rozwiąże problem, a nie rozwiąże problemu, osobiście poszedłbym z facetem, który może rozwiązać problem.

Mimo to, jeśli ktoś twierdzi, że jest ekspertem w Javie i nie może zadeklarować tablicy użycia instrukcji if lub pętli while, może kłamać. Mogę jednak zrozumieć, czy ktoś jest ekspertem w Javie, ale ostatnio dużo C # i próbuje zrobić Mapę lub coś takiego ... Również jeśli wejdziesz w specyfikę biblioteki, lub ktoś zrobi myArray.length zamiast myArray .Length lub string.length () / string.Length / string.length zamiast string.length () ... Drobne rzeczy, które wybaczyłbym. Lub jeśli zapomną kolejność argumentów jakiegoś wywołania biblioteki. Lub literówka / dwukropek tu czy tam ....

Nie wezmę żadnego z nich.

Dobra składnia jest bezużyteczna, jeśli programista nie jest dobry w rozwiązywaniu problemów. A zła składnia dla danego języka oznacza, że ​​kandydat nie czuje się dobrze z tym konkretnym językiem, być może z powodu braku bezpośredniego doświadczenia.

W każdym razie logika jest znacznie ważniejsza niż składnia.

To, jak zawsze, zależy. Jeśli błędy składniowe są stosunkowo niewielkie, zignoruję je. Jeśli są wstrząsająco wielkie, zwrócę na nie uwagę i spróbuję wywnioskować, dlaczego tam są.

Myślę, że błędy logiczne są gorsze niż błędy składniowe, te ostatnie prawie zawsze mogą zostać wychwycone mechanicznie, te pierwsze mniej (zależy w pewnym stopniu od tego, jakim językiem piszesz, niektóre klasy błędów logicznych są wychwytywane przez wystarczająco zaawansowany typ wnioskowanie i sprawdzanie).

Z pewnością zależeć to będzie od stanowiska, na którym odbywa się wywiad, i prawdopodobnie również od języka.

Praca nad C ++, facet jąkający się przy składni jest przerażający. C ++ jest pełen ciemnych narożników, pułapki leżą praktycznie wszędzie. Jąkanie się w składni oznacza słabą znajomość języka, a początkujący w C ++ popełniają wiele błędów (nie mówiąc, że inni nie robią tego od czasu do czasu).

Aby odpowiedzieć na twoje pytanie:

• gdybym musiał obsadzić prostą pozycję programistyczną, wziąłbym faceta z dobrą znajomością składni C ++. Nie będzie świecił, ale nie powinien wywoływać zbyt wielu katastrof.
• gdybym musiał obsadzić wiodącą pozycję programisty, nie wziąłbym żadnego z nich. Główny programista powinien mieć zarówno doświadczenie, jak i logikę.

Jest tylko jedno zastrzeżenie: ludzie uznają brak doświadczenia. Najlepiej byłoby, gdyby ludzie kodowali w wybranym przez siebie języku lub pseudokod, jeśli wolą (na przykład studenci).

Prawdziwa historia, wciąż zapominam o składni zdarzeń C #, kiedy muszę je pisać ręcznie. Czasami zdarza się to w wywiadach. Nie mam problemu, gdy koduję na klawiaturze.

Wybierz faceta, który potrafi kodować, a nie tego, który nie umie, ale pamięta składnię.

Kiedy piszę kod na papierze / tablicy, nawet na rozmowę kwalifikacyjną, w zasadzie pomijam dużą część składni. Nie używam średników, fałszuję wywołania metod itp. Bardziej prawdopodobne jest napisanie zdania wyjaśniającego 4 wiersze naprawdę podstawowego kodu niż sam kod. Naprawdę używam pseudokodu php i mówię o tym, co robię, podczas gdy to robię, i notuję szybkie komentarze, aby wyjaśnić rzeczy, nad którymi się zastanawiam (które teoretycznie nie są tak naprawdę ważne dla program)

Moim celem podczas pisania kodu w wywiadzie jest pokazanie, jak rozwiązać problem, a nie dyktowanie czegoś, co maszynistka mogłaby wprowadzić do Notatnika i uruchomić.

Krótko mówiąc: Myślę, że powinieneś rozważyć, dlaczego pierwszy programista miał kiepską składnię. Bardzo dobrze mógł to wiedzieć, ale po prostu uznał to za nieistotne dla rozmowy kwalifikacyjnej i wolał skupić się na trudnych częściach tej pracy (logika i rozwiązywanie problemów).

Osoba, która nie może logicznie spełnić odpowiedzi, jest niewykwalifikowana. W naszej branży jest zbyt wiele osób produkujących kod śmieci, który jest zgodny, ale tak naprawdę nie robi tego, co powinien, ani nie obsługuje błędów ani przypadków na krawędzi.

Druga osoba może, ale nie musi być niewykwalifikowana, w zależności od rodzaju i liczby błędów oraz trudności w napisaniu. W języku SQL (język, w którym piszę), osoba, która nie pamięta składni jawnego przyłączenia, nie jest kwalifikowana do zadania wymagającego zapytania do bazy danych - bez wyjątków; ten, który nie pamięta, jak wykonać wielokrotny CTE (ale kto wie, że istnieje i próbuje go użyć) nie jest. Innymi słowy, oczekiwałbym, że składnia będzie bardziej poprawna dla podstawowego kodu, który piszesz przez cały czas, ale nie dla rzeczy wykonywanych tylko okazjonalnie, a nie dla złożonej.

Gdybym rozważał osobę, którą znałem, posiadającą doskonałe kwalifikacje w pokrewnej dziedzinie, ale jedynie minimalną znajomość mojego konkretnego języka, prawdopodobnie wybaczyłbym również błędy składniowe. Wolę zatrudnić świetnego programistę Oracle niż przeciętnego programistę SQl Server do zadania SQL Server (Oczywiście, świetna osoba SQL Server byłaby najlepsza) i nie spodziewałbym się, że ta osoba zna składnię SQL Server, jeśli mogłaby mi pokazać, jak zrób to w Oracle. To samo dotyczy ludzi Java i C #, osoba o doskonałych umiejętnościach rozwiązywania problemów pokonuje osobę o doskonałych umiejętnościach językowych, ale ta z obiema wygranymi za każdym razem (czasami trudno ją znaleźć).