Jakich standardów można oczekiwać od absolwentów / młodszych inżynierów? [Zamknięte]

Czy przepełnienie bufora jest dopuszczalne od absolwenta programisty? Czy stawiamy poprzeczkę zbyt wysoko? Jakie są oczekiwane możliwości absolwentów / młodszych inżynierów?

Kontekst:

Obecnie rekrutujemy na stanowisko Junior Developer, pracując głównie w C na Linuksie.

W ramach tego procesu wymagamy od kandydatów wypełnienia testu kodu w wolnym czasie w C.

Do tej pory odrzuciliśmy dwóch kandydatów na tej podstawie, że ich kod, choć czytelny, aw jednym przypadku raczej idiomatyczny, cierpiał na błędy przepełnienia bufora z powodu niepowiązanych zapisów bufora.

[Edytować]:

• Wyraźnie prosimy o sprawdzenie kodu jakości produkcji pod kątem błędów.
• Zapewniamy ramy testowe i kompilacyjne dla kandydatów

[Aktualizacja]:

W wyniku tego wątku i rozmów, które osobiście przeprowadziliśmy z innymi programistami, zmieniamy sposób, w jaki przeprowadzamy testy kodu i kogo kierujemy podczas rekrutacji.

Zdecydowaliśmy, że kandydat, który nie jest w stanie naprawić lub zrozumieć przepełnienia bufora, oznacza, że ​​byłby nieodpowiedni do wykonywanej przez nas pracy, w szczególności wziąłby więcej mentoringu, niż jest nam wygodnie. Dlatego nadal będziemy odrzucać kandydatów, którzy ostatecznie nie będą w stanie dostarczyć solidnej próbki kodu.

Wprowadziliśmy jednak pewne środki, aby proces rekrutacji był bardziej produktywny zarówno dla nas, jak i dla kandydatów.

W szczególności:

• Wyrażamy nasze oczekiwania bardziej jasno, z jasnym wyjaśnieniem, co rozumiemy przez jakość produkcji, oraz ostrzeżeniem, że kod powinien być niezawodny w odniesieniu do danych wejściowych i błędów.
• W opisie testu kodu łączymy teraz kandydatów z zasobami dotyczącymi programowania obronnego i standardowej biblioteki C.
• Zmieniliśmy grupę docelową z programistów i absolwentów Junior na grupy docelowe z odpowiednim doświadczeniem.
• W przypadku, gdy przesłany kod w jakiś sposób zawiedzie, ale w innym przypadku zostałby zaakceptowany, zapewniamy teraz minimalny przypadek testowy, który powoduje warunek błędu i dajemy kandydatom szansę na poprawienie swoich błędów (chyba że kod zostanie odrzucony z innego powodu). W razie potrzeby wskażemy również problematyczne linie / funkcje.
• Cel samych testów nieznacznie zmienił się teraz z filtra front-end na szansę zbudowania lepszego obrazu kandydata, w szczególności poinformuje o naszej rozmowie telefonicznej. To powiedziawszy, nadal jesteśmy gotowi odrzucać wyłącznie na podstawie kodu.

[Aktualizacja 2015-07-09]: Andy Davis z Nujob napisał interesujący i odpowiedni artykuł na temat korzystania z testu kodu z perspektywy kandydata i ten artykuł jest wart uwagi. Znajdź je tutaj .

Nie sądzę, że ustawiłeś zbyt wysoko poprzeczkę, myślę, że możesz potrzebować innego.

Myślę, że testy kodu są przydatne do określania kompetencji kandydata, ale nie powinny być zaliczone / niezaliczone. Powinieneś użyć wyników testu kodu, aby rozpocząć dialog z kandydatem.

Jeśli zauważysz popełnione przez siebie błędy (zwłaszcza jeśli są młodszymi programistami), wskaż je i zapytaj, co zrobiliby inaczej lub czy rozumieją, dlaczego jest problem.

Myślę, że to właśnie kwalifikacje dla juniorów mają znaczenie. Juniorzy nie powinni być testowani pod kątem umiejętności, powinni być testowani pod kątem umiejętności uczenia się, ciekawości, pasji, etyki i zdecydowanie pokory. Założenie dla juniora powinno być takie, że nie są oni kompetentni , to twoja praca jako seniora to uczynić.

Oczywiście powinni umieć pisać podstawowy kod jak fizzbuzz i mieć ogólną wiedzę na temat pojęć; jeśli wskazał go do nich, a oni nawet nie wiedzą, co było przepełnienie bufora, następnie chciałbym powiedzieć, że to nie iść, ale nie spodziewam się młodszy napisać więcej niż 5 linijek kodu bez błędu.

Dzień, w którym ufasz kompetencjom swojego juniora, to dzień, w którym należy przesłuchać swoich juniorów, młodym należy liczyć się z dużym mentoringiem i zdrową dawką „zaufania, ale weryfikacji”. Byłem kiedyś młodszy i wszystkim, którzy tam byli, przepraszam. Pamiętasz straszne rzeczy, które robiłeś jako junior? (Proszę nie mów mi, że to tylko ja; dasz mi kompleks ...)

Widzę tutaj kilka problemów.

Pierwszy zakłada, że ​​przeciętny absolwent informatyki wie cokolwiek. Oni nie. Szczerze mówiąc, jestem mile zaskoczony, gdy widzę absolwenta informatyki, który wie, jak zainstalować i skonfigurować Visual Studio . Heck, ostatnio pracowałem z facetem, który twierdzi, że ma ponad pięcioletnie doświadczenie w stosie Microsoft, pisząc kod .NET , który nie mógł zrozumieć, czym był TFS i jak się połączyć.

Drugi to twoja bardzo ograniczona pula. Mamy również kandydatów na test programowy. Istnieje pięć oddzielnych „programów”, które muszą napisać. Robią to w domu i wysyłają kod. Testy są niezwykle proste (brak bazy danych, brak zewnętrznych zależności) i można je łatwo przeprowadzić za pomocą ekspresowej wersji programu Visual Studio. Same testy są z łatwością ukończone przez starszego faceta w około 30 minut. Należy pamiętać, że generalnie robimy to tylko dla absolwentów posiadających do trzech lat weryfikowalnego doświadczenia zawodowego.

Oszacowaliśmy, że około 70% osób poddanych testowi po prostu nigdy do nas nie wraca. Około 15% zmienia się w rzeczy, które nie zostaną skompilowane, zwykle z powodu rażących błędów składniowych (na przykład brakujących ;). Kolejne 10% kompiluje się, ale nie wykonuje wymaganych działań.

To pozostawia aż 5%. W tym momencie nawet nie bierzemy pod uwagę warunków, takich jak wprowadzenie znaku alfabetu jako danych wejściowych, gdy wymagany jest numeryczny. Jest to wyłącznie biorąc pod uwagę bardzo ograniczony zestaw X jako danych wejściowych, aplikacja wykonuje odpowiednie dane wyjściowe. Ponadto liczby te pochodzą od około 500 kandydatów w ciągu ostatnich czterech lat: prowadziliśmy statystyki, ponieważ chcieliśmy wiedzieć.

Gdybyśmy bardziej przyjrzeli się strukturze kodu i technikom defensywnego kodowania, takim jak prawidłowe usuwanie niezarządzanych zasobów lub użycie try .. catchinstrukcji, prawie nikt nie przejdzie.

Pytanie oczywiście brzmi: dlaczego?

Dlaczego nie można dzieckiem ze stopniem naukowym w tej dziedzinie od czterech lat uczelni osiągnąć to, co jest proste zadania programowania? Odpowiedź jest taka, że ​​uczelnie nie mają kontaktu z potrzebami biznesowymi i pozostają w tyle za tym, co uważamy za najnowocześniejsze. 10 lat temu standardy kodowania były takie, że bezpieczeństwo było czymś, co zrobiłeś po fakcie; a testy jednostkowe nie były jeszcze w modzie. Podczas gdy dzisiejsze bezpieczeństwo lepiej jest na czele z każdą funkcją lub ulepszeniem. Pamiętaj tylko: większość profesorów nigdy tak naprawdę nie pracowała w tej dziedzinie LUB nie pracowała w niej przez długi czas. Kiedy to wiesz, zaczynasz rozumieć, dlaczego są tak daleko w tyle. Co gorsza, niektórzy z tych profesorów spędzają zbyt dużo czasu na określonej technologii ( Java , PHP, cokolwiek) i nie omawia poważnych podstawowych problemów, takich jak struktura kodu lub akceptowalne podejścia (i DLACZEGO!).

Tylko boczny przykład. Niedawny absolwent opowiadał mi o swoich doświadczeniach związanych z pisaniem mobilnego systemu operacyjnego na jednej ze swoich zajęć, ale nie potrafił wyjaśnić, nawet w podstawowych terminach, jak działa serwer WWW. Po prostu nie wiedział. 15 lub 20 lat temu był prawdopodobnie właściwy czas na zrozumienie, jak stworzyć system operacyjny. Dzisiaj ... nie tak bardzo. Była to jednak klasa wymagana, gdy klasa o programowaniu obronnym byłaby o wiele bardziej przydatna dla nich ORAZ świata zewnętrznego.

Więc co robimy?

Z tych 5% przeprowadzimy wywiad, aby dowiedzieć się więcej o ich osobowości i kondycji. Następnie wybieramy „najlepszych” z pełną świadomością, że spędzimy około sześciu miesięcy na „przeprogramowaniu” ich, aby pozbyć się gówna, które wypełniali ich profesorowie.

Myślę, że patrzysz na problem w niewłaściwy sposób. Należy zadać sobie następujące pytanie: Czego wymagamy od kandydata, aby mógł wykonywać swoją pracę? Powinieneś właściwie ocenić pozycję i jej konsekwencje. Poniżej znajdują się sugestie, kiedy zatrudnić młodszego programistę, a kiedy nie.

Kiedy zatrudnić młodszego programistę: - Jeśli jest nadmiar łatwej pracy do zrobienia, co byłoby stratą czasu dla bardziej zaawansowanego programisty. - Jeśli chcesz mentorować i szkolić tę osobę w ciągu najbliższych kilku lat. - Jeśli próbujesz rozwijać firmę i chcesz kogoś, kto pozostanie na długo. Młodszy programista, który zostaje tylko przez rok, byłby marnotrawstwem zasobów firmy, niewiele robiłby, aby cokolwiek produkować, a większość rezultatów byłaby w ich osobistym rozwoju. - Kiedy masz ochotę wydać pieniądze na czyjś wzrost. Odtąd większość korzyści będzie tym, czego się nauczą.

Kiedy nie zatrudnić młodszego programisty. - Gdy praca jest zbyt skomplikowana. W tym przypadku jest to po prostu poza ich ligą. - Kiedy chcesz zaoszczędzić pieniądze. Starszy programista powinien wykonać te same zadania w ułamku czasu, uzyskując lepszą jakość wyników, a zatem zawsze powinien być tańszy. - Gdy praca może być zlecona na zewnątrz lub nie jest wystarczająca, aby pracownik był zajęty. W takich przypadkach lepiej byłoby zlecić część pracy prywatnemu wykonawcy.

Ostatni ważny punkt. Nie zatrudniaj młodszego programisty, ponieważ „to wszystko, na co możemy sobie pozwolić” lub „to wszystko, co jesteśmy gotowi wydać”, gdy nie są odpowiednie do pracy. W końcu wszystko, co skończysz, to spłukanie pieniędzy w toalecie. Poza tym, kiedy zdobędą te umiejętności, i tak będą prosić o duże pieniądze.

O mnie:

• Dyplom z fizyki prawie bez formalnego szkolenia.
• Dwa lata doświadczenia zawodowego. Więc wiem, o co chodzi w procesie uczenia się.
• Uruchom programistę. Wykonałem bardzo wymagającą pracę i widziałem różne poziomy umiejętności różnych osób. Wielu z nich nie radzi sobie z wieloma rzeczami, które robię.

Jak wspomnieli inni, młodsze stanowiska mogą mieć niewielkie doświadczenie z C. Ja osobiście krótko uczyłem się o przepełnieniu bufora w C i nawet gdybym mógł na nie uważać, prawdopodobnie nadal wprowadziłbym niektóre (szczególnie jeśli otrzymam zadanie, które pożycza do tworzenia przepełnień bufora). Prawdopodobnie wielu młodszych programistów będzie miało podobną sytuację, w której mogą wiedzieć o przepełnieniu bufora, ale nie byli przygotowani na ich identyfikację i obsługę w jakikolwiek sposób.

Biorąc to pod uwagę, uważam, że właściwą odpowiedzią jest, aby problem został poruszony w następnej możliwej interakcji i zapytać ich, co wiedzą o przepełnieniu bufora, aby sprawdzić swoją ogólną wiedzę. Następnie powiedz im, że znalazłeś taki kod w przypuszczalnie gotowym do użycia kodzie. To da ci dobre okno do oceny, jak zareagują na korektę i instrukcje.

Czy powszechna opinia, że ​​młodszy programista, który wie mniej, ale chce i jest w stanie się uczyć i doskonalić, jest cenniejszy niż młodszy programista, który wie więcej, ale nie może lub nie poprawi się?

To powiedziawszy, w jednym z twoich komentarzy, które wspomniałeś, podałeś im testy, które wskazałyby na przepełnienie bufora w kodzie, gdyby je wykorzystały. Być może więc większym pytaniem jest to, dlaczego nie przeprowadzili testów (a jeśli tak, to dlaczego wprowadzili błędny kod)?

Przepełnienie bufora jest absolutnie niemożliwe. Możesz mieć odpowiadające pytanie kodowe. W przypadku tego, co wszystko jest nie tak (może się nie udać) z tym fragmentem kodu, kandydat powinien być w stanie wskazać problem. Pytanie brzmi, czy problem nie jest istotny, ponieważ i tak używasz Clinta.

Jednak w sztucznym teście kodu w dowolnej formie byłbym łagodny w przypadku naruszenia takiego jak sprintf. Za mało czasu (zakładany), nadpobudliwość umysłu, zbyt duża chęć przedstawienia czegoś działającego.

Myślę, że zadajesz złe pytanie. Nie ma żadnego obiektywnego paska, aby być profesjonalnym programistą. Gdyby tak było, odbyłby się standardowy egzamin z programowania, ale go nie ma. Indywidualny pasek musi być ustawiony w oparciu o to, jak wybredny możesz sobie pozwolić, ile możesz zapłacić, ile błędów możesz sobie pozwolić na oprogramowanie i ile czasu możesz poświęcić na nauczanie.

W tym przypadku zgaduję, że przepełnienie bufora prawdopodobnie oznacza, że ​​ten kod, który kandydat przedstawił jako próbkę przykładowej pracy, zawiesza się z błędem segmentacji zamiast robić to, o co prosiłeś. Czy więc powinieneś zaakceptować kodera, który pisze kod, który ulega awarii z błędem segmentacji, zamiast robić to, o co prosiłeś? Zapytać:

• Czy Twoja organizacja jest w stanie przyciągnąć każdego, kto umie pisać działający kod?

• Czy Twój proces programowania jest na tyle solidny, że ktoś, kto potrafi prawie pisać kod, mógłby napisać działający kod przy pomocy recenzji i wsparcia testowego?

• Czy jesteś w stanie nauczyć programistów, jak być programistą, i czy jesteś gotów poświęcić ten wysiłek i poczekać kilka lat i mieć nadzieję, że wewnętrzny talent kandydata dojdzie do skutku?