Czy powinienem martwić się zleceniami programowymi nadinżynieryjnymi podanymi w trakcie rozmowy kwalifikacyjnej? [Zamknięte]

Niedawno miałem wywiad telefoniczny z firmą. Po tym wywiadzie telefonicznym powiedziano mi, aby ukończyć krótkie zadanie programistyczne (mały program; nie powinno to zająć więcej niż trzy godziny). Jestem tylko bezpośrednio instruowany, aby wykonać zadanie i przekazać kod. Dano mi pełną swobodę w używaniu dowolnego języka, który chciałem i nie powiedziano mi dokładnie, jak wprowadzić kod.

Natychmiast planowałem rzucić go na Github, napisać dla niego pakiet testowy, używając Travis-CI (darmowa ciągła integracja dla publicznych repozytoriów Github) do uruchomienia zestawów testowych i używając CMake do zbudowania plików makefile dla Travis-CI. W ten sposób nie tylko mogę wykazać, że rozumiem, jak korzystać z Git, CMake, Travis-CI i jak pisać testy, ale mogę również po prostu link do strony Travis-CI, aby mogli zobaczyć wyniki testów. Pomyślałem, że to sprawi, że będzie to nieco wygodniejsze dla ankietera.

Ponieważ znam te technologie, nie przydałoby się to w zasadzie do zadania.

Martwię się jednak trochę, że wykonanie tego wszystkiego dla stosunkowo prostego zadania wyglądałoby źle. Chociaż nie dałoby mi to więcej czasu, nie chcę, żeby myśleli, że spędzam zbyt dużo czasu na rzeczach, które powinny być proste.

Jako ankieter byłbym szczęśliwy widząc wiedzę na temat procesu tworzenia oprogramowania wykazaną przez to podejście; w przeciwieństwie do samego pisania kodu.

W szczególności posiadanie zestawu testów nawet dla bardzo prostych problemów byłoby dobrym znakiem (nawet poziom FizzBuzz). Widziałem kandydatów przedstawiających rozwiązania, które nawet nie rozwiązały problemu, i pokazałby to prosty zestaw testów. Ponadto posiadanie historii zatwierdzeń pozwala mi zorientować się, jaki proces myślowy wykorzystał kandydat, aby znaleźć rozwiązanie.

Z drugiej strony, wiem, że niektóre firmy odrzucają ludzi na wczesnym etapie procesu nadmiernej inżynierii. Jednak w większości przypadków było to spowodowane nadmierną inżynierią rozwiązania, niekoniecznie stosowanymi procesami.

Posiadanie jako rozmówcy kogoś, kto rozumiał takie rzeczy jak kontrola wersji, CI, testy jednostkowe i tym podobne, byłby krokiem naprzód w stosunku do tego, co zwykle widzę.

Chociaż dla mnie najważniejsze jest to, że problem został rozwiązany i rozwiązany dobrze, wiedząc, że kandydat zrozumiał sposoby poprawy jakości swoich produktów z pewnością zwróci moją uwagę.

To, co ogólnie widzę, to ludzie, którzy nie tylko nie rozumieli problemu, ale także nie rozumieli, jak rozwiązać problem - i byliby ignorowani bez względu na to, ile dodatkowych narzędzi użyli w tym procesie.

Pamiętaj, że istnieje limit czasowy. Ankieter wie o tym, więc oznacza to (gdybym był ankieterem), że zobaczy, że nie tylko rozwiązałeś problem w wyznaczonym czasie, ale czy zrobiłeś to tak szybko, że pozostał ci czas na złocenie, co jest dobrym znakiem umiejętności rozwiązywania problemów, a także docenienia rygoru i staranności.

Nadmierna inżynieria to złe słowo, gdy tworzysz adaptery AbstractFactoryManager, które są podłączane do systemu BuzzManager i FizzManager w celu rozwiązania FizzBuzz.

To, co robisz, to nadmierna staranność, co nawet nie jest rzeczą (choć zdecydowanie niedostateczna jest zdecydowanie).

To powiedziawszy, jeśli skończysz z czasem lub z jakimś półhackowanym rozwiązaniem, ponieważ wykorzystałeś swój czas na dodatki, które, jak twierdzisz, „nie dodają czasu”, będzie to wyglądać tak, jakbyś bardzo słabo rozumiał, jak duże wydają się małe zadania mogą być. Może to być niebezpieczna cecha u inżyniera i zbyt powszechna wśród juniorów. Nadaj odpowiednie priorytety i zrób dodatkowe czynności dopiero po ukończeniu wymaganego rozwiązania.

Kolejnym punktem do rozważenia jest to, że twoje podejście nie jest ani dobre, ani złe. Mogę sobie wyobrazić ankieterów, którzy uważają, że to za dużo, i wyobrażam sobie ankieterów, którzy chcieliby jeszcze więcej inżynierii.

Nie martw się tak bardzo. Zamiast tego rozwiąż problem w sposób, który uważasz za najlepszy, a prawdopodobnie otrzymasz oferty pracy od osób, które się z tobą zgadzają. To świetny pierwszy krok w kierunku produktywnego środowiska pracy. Pamiętaj, że wywiady odbywają się na dwa sposoby. Odpowiedź ankietera na twoje rozwiązanie również wiele o nich powie. Czy naprawdę chcesz pracować z ludźmi, którzy uważają, że twoje instynkty rozwojowe i filozofia są błędne?

W rzeczywistości nikogo nie obchodzi, czy kandydat może w pośpiechu przygotować repozytorium git lub utworzyć makefile, ponieważ to tylko przypomnienie tego, czego nauczył się na pamięć. Są to umiejętności drugorzędne w stosunku do faktycznego rozwiązywania problemów i projektowania aspektów pytania podczas rozmowy kwalifikacyjnej.

Tak, twoja intuicja wskazuje, że potencjalnie źle wygląda, ponieważ może wyglądać, jakby kandydat wierzył, że ktoś, kto potrafi cofnąć kilka zapamiętanych poleceń i wzorców, aby stworzyć szkielet projektu, ma imponujące umiejętności programistyczne.

Aspekt pakietu testowego rozwiązania jest jednak dobry. Dostarczenie odpowiedzi za pomocą zestawu testów regresji prawdopodobnie zapewni ci punkty. Tym bardziej, jeśli Twój zestaw testów wykonuje najistotniejsze przypadki w kodzie. Zestaw testowy nie musi mieć wielu pułapek formalnych i opierać się na narzędziach; sam fakt, że jakoś tam masz, wystarczy na rozmowę kwalifikacyjną. Jest mniej lub bardziej oczywiste, że jeśli możesz przygotować testy jednostkowe ad hoc w quizie wywiadu, możesz to zrobić za pomocą narzędzi w prawdziwym projekcie.

Niedawno miałem wywiad telefoniczny z firmą. Po tym wywiadzie telefonicznym powiedziano mi, aby ukończyć krótkie zadanie programistyczne (mały program; nie powinno to zająć więcej niż trzy godziny).

Postępowałbym ostrożnie. Oceń trafność wyzwania dla pracy i upewnij się, że w przyszłości zwrot kosztów od pracodawcy sprawi, że 3 godziny twojego czasu będą warte zachodu.

Kwestionuję wartość tego rodzaju testów i wolę oceniać kogoś na podstawie jego przeszłych osiągnięć. Predefiniowane krótkie zadanie nie może powiedzieć pracodawcy niczego o tym, co możesz zrobić. Tylko to, czego nie możesz zrobić, a to można szybko ustalić za pomocą kilku pytań przez telefon.

Testowanie ma swoje miejsce. Zadaj sobie następujące pytania dotyczące testu i odpowiednio odpowiedz.

1. Czy biorąc pod uwagę aktualny poziom kariery, testy są uczciwe?
2. Czy test ma jasno określoną poprawną odpowiedź?
3. Czy osoba przeprowadzająca wywiad interesuje się twoim potencjałem jako osoby, czy też wykazuje większe zainteresowanie wynikami testu (tj. Agencje zatrudniające są do tego straszne).
4. Czy test reprezentuje rodzaj pracy, którą lubisz wykonywać, czy też jest to niejednoznaczna weryfikacja umiejętności (tj. Test, jeśli znasz składnię Java).

Jestem tylko bezpośrednio instruowany, aby wykonać zadanie i przekazać kod.

Właśnie odpowiedziałeś na swoje pytanie.

Natychmiast planowałem rzucić go na Github, napisać dla niego pakiet testowy, używając Travis-CI (darmowa ciągła integracja dla publicznych repozytoriów Github) do uruchomienia zestawów testowych i używając CMake do zbudowania plików makefile dla Travis-CI.

Nie, nie o to prosili.

W ten sposób nie tylko mogę wykazać, że rozumiem, jak korzystać z Git, CMake, Travis-CI i jak pisać testy, ale mogę również po prostu link do strony Travis-CI, aby mogli zobaczyć wyniki testów. Pomyślałem, że to sprawi, że będzie to nieco wygodniejsze dla ankietera.

Ostrożnie wykazywałbym umiejętności zbyt wcześnie lub za późno w trakcie rozmowy kwalifikacyjnej. Jeśli uważasz, że nie poradziłeś sobie dobrze podczas rozmowy, a teraz próbujesz to zrekompensować, to nie zadziała. Z drugiej strony robienie zbyt wiele, gdy się o to nie pyta, demonstruje nadmierną chęć. Może to spowodować, że pracodawca skontaktuje się z ofertą niższego wynagrodzenia, niż się spodziewałeś.

Martwię się jednak trochę, że wykonanie tego wszystkiego dla stosunkowo prostego zadania wyglądałoby źle.

Tak, wygląda źle. Rozwiązanie ich problemu za pomocą jednego wiersza kodu będzie znacznie bardziej imponujące niż pełny projekt.

Z mojego doświadczenia wynika, że ​​nie tak wygrywasz rozmowę o pracę, ale jest to jeden ze sposobów na utratę pracy. Test kodu jest kwestią kontroli jakości. Robi to każda firma, która korzysta z testów kodu podczas zatrudniania ludzi, ponieważ wcześniej nie korzystali z testów kodu. Mieli złe doświadczenia, że ​​ktoś prześlizguje się przez pęknięcia procesu wywiadu, co nie powinno mieć miejsca.

Zabiorą kod źródłowy i przekażą go w biurze. Ludzie skomentują to, a ty nie chcesz, żeby powiedzieli: „Popełnił ten błąd? Spędzał czas, używając Git, CMake i Travis-CI. Co za idiota, który nie zauważył tego błędu”.

to jest to! Straciłeś.

Chcą wiedzieć, że umiesz kodować, ponieważ nie mogą cię tego nauczyć. Git, CMake i Travis-CI można łatwo nauczyć.

Myślę, że twoje podejście nie jest ani dobre, ani złe samo w sobie . Zapytałbym ankietera, czy korzystanie z Github i innych narzędzi jest w porządku. Jak wskazał @Izkata w komentarzach, upubliczniasz swoje rozwiązanie.

Jako ankieter wiedziałem, że kandydat zwykle nie szkodzi próbując wyjaśnić kilka rzeczy. Zadanie jednego lub dwóch pytań może być dobrym znakiem, ponieważ nie spiesz się, aby robić rzeczy, których nie rozumiesz.

Pamiętaj jednak, że najważniejsze jest to, że problem został rozwiązany i rozwiązany dobrze. W tym względzie wszyscy zgadzają się, że zestaw testów pomaga. Ale w tym celu może wystarczy wysłać kilka klas testowych wraz z projektem / rozwiązaniem.