Nie udało mi się FizzBuzz, zatrudniłbyś mnie? [Zamknięte]

Jestem programistą z dyplomem CS i mam doświadczenie w pracy w wielu językach od prawie 3 lat.

Dzisiaj miałem wywiad, ogólnie poszło całkiem nieźle, przygotowałem się na większość pytań i czułem się gotowy na wszystko. Pod koniec wywiadu zadali mi JEDNE pytanie programistyczne ... problem taki jak FizzBuzz (bez części liczbowej). Uważam, że popełniłem zbyt wiele błędów i dlatego „nie zdołałem”. Czy cała nadzieja jest dla mnie stracona?

Oto mój kod:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Jak widać pomieszałem boole, które powinny mieć składnię i% 3 == 0; Jeśli dobrze pamiętam pytanie, w isThree && isFive umieściłem także else zamiast elseif. Byłem dość zestresowany, ale to nie usprawiedliwia pominięcia prostego problemu.

Pytanie brzmi, jak ważna jest umiejętność natychmiastowego tworzenia działającego kodu w stosunku do innych czynników, takich jak doświadczenie i osobowość? Na przykład, czy powyższy kod złamie umowę?

Celem FizzBuzz jest pokazanie, że naprawdę umiesz programować , a nie to, że zapamiętałeś wszystkie dokładniejsze reguły składniowe języka, w którym zostałeś poproszony (choć to ma znaczenie, jeśli chcą wiedzieć, jak doświadczony jesteś w języku).

Jeśli doszedłeś tak daleko w stresie środowiska wywiadu i możesz pokazać, że rozumiesz błędy, które popełniłeś, powiedziałbym, że zdałeś.

tak

Większość osób, z którymi rozmawiałam, które nie wykonały części ćwiczenia kodu z powodu niewielkiej składni lub nieco nielogicznej logiki, okazały się być lepszymi pracownikami.

Wyprostowanie podstawowego pojęcia logiki (co zrobiłeś) i przekształcenie go w coś przyzwoitego i zwięzłego z punktu widzenia kodu (co myślę, że w większości zrobiłeś) jest dla mnie o wiele ważniejsze niż uzyskanie go absolutnie idealnego.

Kupuję IDE za sprawdzanie jego składni, nie wynajmuj dla niego dewelopera, a inne błędy zdasz sobie sprawę w ciągu pierwszego debugowania.

Przeszedłeś od początkowego wymogu do pierwszej próby dość bezpośrednio i bez robienia niczego strasznego. Jest to cenniejsze w wielu środowiskach niż doskonałość przy braku informacji zwrotnej. Jeśli pracodawca nie rozumie szczegółów, które przegapiłeś, może to oznaczać pojawienie się otoczenia.

Gdyby zadanie polegało na wariancie wydruków, pominięcie szczegółów wyglądałoby trochę źle, ale nie miałoby wystarczającej wagi, aby zmienić moją decyzję, gdybym polubił cię za inną pozycję.

[Edytuj] Jak zauważył Alex, istnieje także aspekt reakcji i opanowania. Osobiście staram się to usunąć, zanim przejdę do ćwiczeń praktycznych, próbując przekonać rozmówcę do czegoś nieco poza ich doświadczeniem, ale niektórzy mogą zdecydować się na połączenie tych dwóch. Od czasu do czasu natknęłam się na kogoś, kto ma jedynie wiedzę z podręczników i przeglądają teoretyczne i podstawowe zagadnienia, ale poważnie odkładają słuchawkę na temat tego, od czego zacząć ćwiczenie praktyczne. Niektórzy nie mogą nawet dowiedzieć się, od czego zacząć.

Te osoby są właśnie tym, czego chcę odrzucić po tym ćwiczeniu.

Tak więc, chyba że zajęło ci 20 minut, aby ankieter wyjaśnił wymóg, myślę, że twoje rozwiązanie było mniej więcej pierwszą próbą z kilkoma poprawkami. Jeśli dostałeś to, co postawiłeś powyżej w ciągu 5 minut, pokazałeś, że możesz pomyśleć wystarczająco dużo, by sprostać moim standardom.

Powyższy kod prawdopodobnie byłby dla mnie przełomowy, gdybym nie miał nic innego do roboty. Jeśli podążą za stylem wywiadu Microsoft, osoba, która zadała ci to pytanie, prawdopodobnie Cię zablokuje - i to często wystarczy.

Zaskakuje mnie to, że osoba przeprowadzająca wywiad nie zapytała cię o ten kod. Dobry ankieter widział wystarczająco dużo własnego kodu, aby wiedzieć, że ludzie popełniają błędy - zwłaszcza gdy się spieszy. Zwykle mówią: „Czy widzisz coś złego w tym kodzie?” „Nie? ​​Cóż, przetestujmy to”. Wymyślisz kilka zestawów wyników, a następnie uruchomisz je przez funkcję. Potem mówicie: „Cholera, to nie działało”. „Ok, jak to naprawisz…” i tak dalej. Jeśli przetrwasz to okno dialogowe, jest ono naprawdę imponujące i pokazuje umiejętność krytycznego myślenia, wymyślania przypadków testowych i debugowania własnego kodu.

Zauważ też, że zwykle nie szukają „działającego kodu”. Kto produkuje tę pierwszą próbę? Ale logicznie poprawne z obsługą błędów i dobrymi zestawami testów jest dobrym celem.

Ponadto może Cię to zaskoczyć, ale konkurujesz z wieloma osobami, które nawet nie mogą zacząć korzystać z fizzbuzz. Zakładamy, że wszyscy inni przemierzają drzewa B + we śnie .... ale w rzeczywistości nie potrafią nawet wyliczyć wielokrotności 3 i 5 i użyć operatora modułu. Możesz być zdziwiony zaskoczeniem, o ile lepiej zrobiłeś niż inni kandydaci.

Moja rada, po prostu strzep ją. Niedawno przeprowadziłem wywiad w dużych firmach programistycznych (Microsoft, Amazon itp.) I po raz pierwszy miałem tak dokładny wywiad. Zrobiłem z siebie głupca podczas wywiadu Microsoft na miejscu, głównie z powodu nerwów, ale też po prostu nie wiedziałem, czego się spodziewać ani czego dokładnie szukali. Przybiłem najkrótszą ścieżkę tylko po to, by wysadzić kilka naprawdę prostych problemów. Zrzuciłem wartości ze złego końca stosu, zapomniałem w int atoi(char* value)implementacji tegoint val = value[i] - '0';dałoby mi całkowitą wartość postaci i kilka innych głupich błędów. W większości byłem zadowolony z wywiadu, ale nadal rozumiałem, dlaczego nie otrzymałem oferty. Musiałem zdać sobie sprawę, że nie tyle odzwierciedlało to moje umiejętności, co było wskaźnikiem, że po prostu musiałem próbować, aż będę w stanie opanować nerwy. W końcu zebrałem kilka wywiadów ze znacznie trudniejszymi pytaniami i znalazłem wymarzoną pracę. Tak naprawdę jest - dla większości ludzi, którzy faktycznie wiedzą, co robią - po prostu zastanawia się, czego chcą ankieterzy, jest pewny siebie i daje im to. To zajmuje chwilę.

Musiałbym powiedzieć nie, ale nie z tego powodu, który podałeś, ale że umieściłeś sekcję FizzBuzz na końcu. Dzięki temu, jak działa Twój kod, nigdy nie wydrukuje FizzBuzz, gdy tego oczekujesz. Jak skomentował Lee, będzie wydrukować go dla każdej wartości nie podzielna przez 3 lub 5.

Ale najważniejsze jest to, że uczysz się z tego. Podoba mi się to, że tutaj pytasz o to, co mogłeś zrobić lepiej. Pamiętaj, aby wykonać kilka zagadek z kodem i znaleźć odpowiedzi na często zadawane pytania podczas rozmowy kwalifikacyjnej. Może także spróbuj samemu ustalić czas lub zrób coś innego, co zwiększy presję, abyś mógł naśladować uczucie, jakie spotka cię podczas rozmowy kwalifikacyjnej. Przygotuj, przygotuj i przygotuj więcej na rozmowę kwalifikacyjną, jeśli naprawdę chcesz wyrzucić ją z parku.

Nie. Celem FizzBuzz jest sprawdzenie, czy jesteś w stanie wypracować podstawową logikę warunkową, która obejmuje wszystkie przypadki. W przeciwieństwie do opinii niektórych osób, FizzBuzz nie polega na operatorze modułu, znajomości operacji trójkowych lub operandach boolowskich. To proste ćwiczenie warunkowe i nie udało ci się.

Problem jest tak skonstruowany, że cały „elegancki” kod nie obejmuje co najmniej jednego przypadku.

Dopuszczalne odpowiedzi:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

Daję ludziom trywialne problemy programistyczne do zrobienia na tablicy. To, czy wynikowy kod jest wolny od błędów, wcale nie jest decydujące. Zamiast tego zależy mi na szeregu zachowań ujawnionych podczas pisania kodu. Jest interaktywny, a ja się dużo uczę o kandydatach.

Bardziej szczegółowo omawiam „testowanie” tablicy podczas wywiadu: uzasadniony sposób na wykonanie kopii zapasowej kodu (tablicy)?

Oczywiście, twój ankieter może nie być taki jak ja. Ale jest całkowicie możliwe, że przeszliście ze mną wywiad podczas tworzenia kodu, który jest bardzo mały, i całkowicie możliwe, że zawiodłem z tym samym kodem.

Gdybym to oceniał, szukałbym następujących rzeczy:

1. Czy kandydat stara się dobrze zrozumieć wymagania przed przejściem do wdrożenia? Czy kandydat stara się rozwiązać mój problem lub użyć swoich domowych narzędzi w swoim zestawie narzędzi programistycznych? W jaki sposób kandydat rozwiązuje problemy?
2. Czy kandydat biegle włada co najmniej jednym językiem programowania?
3. Czy kandydat rozumie logikę logiczną?
4. Co robi kandydat, aby zapewnić jakość swoich rozwiązań?
5. Jak kandydat reaguje na opinie na temat swojego kodu?

-

Trudno powiedzieć na nr 1. Twoje pytanie mówi, że twój problem nie zawierał części „numer wydruku”, a twoje rozwiązanie tego nie obejmuje. Nie mam innego wyboru, jak tylko uwierzyć na słowo, ale jeśli w rzeczywistości był to klasyczny problem FizzBuzz obejmujący wydrukowanie liczb, których nie można było podzielić, to wygląda na to, że przeskoczyłeś do rozwiązania, zanim w pełni zrozumiałeś wymagania, które byłby oznaką.

Dałbym ci częściowe uznanie za # 2 i # 3. Wiedziałeś, że używasz operatora modułu, i miałeś strukturę działającego rozwiązania, ale brakowało części obu.

Wygląda na to, że nie zrobiłeś # 4, co oznaczałoby cię w dół. W przyszłości zalecałbym cofnięcie się od tablicy i przejrzenie swojego rozwiązania przed nazwaniem go zakończonym. Przeprowadziłbym również (bez monitu) kilka testów jednostkowych dla twojego rozwiązania, które szybko pokazałyby, gdzie popełniłeś błąd.

Nie dali ci szansy na # 5, co jest niefortunne. Ale chodzi o to, że nie chcę kogoś, kto uważa, że ​​każdy wiersz kodu, który kiedykolwiek napisali, jest czystym złotem, którego nie da się poprawić, ale raczej kogoś, kto chce zaakceptować opinie na temat jego rozwiązań i zaangażować się w rozmowę na temat jego podejścia .

-

Tak więc, gdybym oceniał to sam, oddałbym głos „Bez zatrudnienia”. Takie rzeczy to raczej mierzenie sztuki performance niż umiejętności programistyczne , ale opanowanie jej może nadal pomóc w karierze. Tak więc moje zalecenia dotyczące przyszłych wywiadów technicznych będą następujące:

1. Przed rozmową przećwicz kilka tego rodzaju ćwiczeń na zimno, wykorzystując jak najmniej zasobów zewnętrznych. Nie po to, by zapamiętać rozwiązania, ale by mieć pewność, że czujesz się swobodnie w swoim preferowanym języku

2. Zadawaj pytania dotyczące problemu, aby zweryfikować swoje założenia.

3. Przed ogłoszeniem ukończenia rozwiązania, zejdź z tablicy i przejrzyj ją, a następnie przejrzyj kilka prostych przypadków testowych.

Poproszenie kogoś o rozwiązanie problemu bez umożliwienia mu uzyskania opinii na temat jego rozwiązania jest wątpliwym podejściem, ponieważ nie wolno mu się poprawiać.

Wszystko to pokazuje nam, że nie wykazałeś się bardzo dobrymi umiejętnościami rozwiązywania problemów.

Może to być jeden z elementów decyzji o zatrudnieniu lub nie, ale dla mnie zdecydowanie nie powinien być jedyny.

Gdyby dostarczyły ci środowisko do testowania lub wykonywania jednostek, popełnione błędy byłyby mniej usprawiedliwione.