Czy nadmierna inżynieria jest znakiem ostrzegawczym? [Zamknięte]

Dlatego przedstawiamy proste kodowanie nowym kandydatom z pewnymi dobrze określonymi wymaganiami. Czasami otrzymujemy rozwiązania, które tak naprawdę nie rozwiązują danego problemu, ale są nadmiernie zaprojektowane, aby rozwiązać postrzegany problem - często poza granicami ćwiczenia.

Teraz moje pytanie brzmi: czy to znak ostrzegawczy?

EDYCJA: Dość dużo dyskusji opiera się na wadliwym teście - co jest słusznym punktem. Jak opisałem w komentarzu, podstawową przesłanką testu jest pokazanie, w jaki sposób możesz odczytać dane z pliku w rozsądny sposób (i będziesz zaskoczony różnorodnością podejść, które widzimy) i jak dopasować elementy przed obliczeniem opóźnienia między aktualizacjami. Teraz, aby to zadziałało, należy przyjąć pewne założenia dotyczące danych i szukamy tych założeń, a także wyraźnie stwierdzamy, że chcemy zobaczyć podejście, które Państwo przyjmują (w tym podejście OO itp.) Wszystko to za dwie godziny ramy czasowe.

IMHO, kiedy przeprowadzałem wywiad, było to najbardziej kompletne ćwiczenie, z jakim się spotkałem.

Konkretny scenariusz, nad którym się zastanawiam, polega na tym, że kandydat zamiast czytać z pliku, zaakceptował wejście „sieciowe” w aplikacji wielowątkowej, co oczywiście nie wchodzi w zakres.

Problem polega na tym, że test jest wypaczony. Poprosisz kogoś, aby zademonstrował swoją umiejętność pisania skomplikowanego oprogramowania na poziomie korporacyjnym za pomocą prostego ćwiczenia, które zajmuje tylko kilka minut. Są inni ankieterzy w innych firmach, którzy narzekają, że kandydaci nie wykazują wystarczających umiejętności w projektowaniu obiektowym za pomocą tych ćwiczeń, więc ludzie mają tendencję do nadmiernej kompensacji. Nie musi to oznaczać, że twój kandydat nie jest w stanie użyć prostszego kodu, gdy sytuacja tego uzasadnia.

Jeśli chcesz wiedzieć, czy tak jest w przypadku twojego kandydata, poproś go o ponowne wykonanie go, podając konkretne wytyczne. Powiedz: „Widzę, że prezentujesz swoje umiejętności projektowania zorientowanego obiektowo, ale wydaje się to przesadą w przypadku tak prostego problemu. Czy możesz przepisać go za pomocą tylko dwóch małych funkcji?”

Powiedziałbym, że jest to wyraźny znak ostrzegawczy, ale niekoniecznie dyskwalifikujący kandydata.

Wygląda na to, że kandydaci mają dwa osobne problemy:

1. Brak punktu ćwiczenia - to dość niepokojące. Wszystkie umiejętności programowania na świecie nie przyniosą dobrego rezultatu, jeśli ktoś nie będzie w stanie rzucić problemu, który rozwiązuje poprawnie. Przekonałem się, że najbardziej produktywni inżynierowie to ci, którzy potrafią zidentyfikować prawdziwy problem do rozwiązania, nawet jeśli nie jest to dokładnie ten problem. Umiejętność krytycznego myślenia o zadawanym pytaniu i być może przeformułowanie go na coś łatwiejszego do rozwiązania jest umiejętnością krytyczną. Pominięcie punktu, w którym problem jest jasno określony, powinno być wielką czerwoną flagą.
2. Nadmierna inżynieria rozwiązania - jest to problem drugorzędny i często wynika z pierwszego problemu. Istnieje kilka różnych patologii, które mogą mieć ten wynik. Po pierwsze, niewłaściwe zrozumienie problemu lub zbyt szerokie jego przedstawienie może skutkować zbyt złożonym rozwiązaniem. Jest to wyraźnie związane z pierwszym punktem powyżej. Po drugie, próba „popisania się” poprzez przemyślenie przyszłych scenariuszy, które mogą być naprawdę nieistotne. Może to być problematyczne, ponieważ wskazuje, że kandydat nie zrozumiał wartości prostoty rozwiązań i odraczania złożoności, dopóki nie jest to naprawdę konieczne. Jest to coś, co można poprawić za pomocą dobrych wskazówek, ale należy uważać, gdy ktoś wprowadza się do organizacji.

Sugerowałbym skontaktowanie się z kandydatem w sprawie jego odpowiedzi w trakcie procesu. Zamiast po prostu patrzeć na ich wynik, spróbuj ustalić, co doprowadziło ich do wyniku, i udzielając wskazówek, jak zareagują i zmienią odpowiedź. Prawdopodobnie będzie to bardziej odkrywcze na temat ich możliwości niż tylko bezpośrednia reakcja na problem. „Dlaczego” ich podejście może dać ci poczucie, czy po prostu tego nie rozumieją, czy też ich zrozumienie było nieznaczne, gdy zdecydowali się odpowiedzieć. Tego rodzaju działania następcze ujawnią również więcej na temat ich ogólnego podejścia do rozwiązywania problemów.

Ponownie przeanalizuj sam problem i sprawdź, czy może nie jest to jasne i może spowodować, że ludzie znajdą się na niewłaściwym tropie, gdy formułują swoje odpowiedzi.

Nie, nie podczas rozmowy kwalifikacyjnej. Zbyt wielu ankieterów robi takie rzeczy, jak celowe niedokładne określenie wymagań i oczekuje od ankietera zadawania dalszych pytań lub zwracania uwagi na rzeczywiste problemy, które nie zostały wyraźnie wymienione.

Oto kilka rzeczy, z góry mojej głowy, o których twoje wymagania prawdopodobnie nie wspominały:

• Standardy kodowania

• Komentarze

• Obsługa wyjątków

• Opisowe nazwy zmiennych, klas, metod

• Po idiomatycznym użyciu języka

• Właściwe projektowanie obiektowe

• Uwaga na możliwe problemy z współbieżnością

• Pisanie przypadków testowych dla kodu

Czy zwróciłeś uwagę na jedną z tych rzeczy, nie mówiąc wprost o tym? Skąd kandydat wiedziałby, które z nich są dla ciebie ważne, a które nie?

Wywiad jest wysoce sztucznym środowiskiem. Ankieter często próbuje „oszukać” kandydata, aby utrudnić ankieterowi powiedzenie mu tego, co chce usłyszeć, a ankieter próbuje zgadnąć, czego naprawdę chce ankieter .

Zasadniczo popełnianie błędu przy zgadywaniu jest zupełnie inne niż popełnianie błędu przy podejmowaniu rzeczywistych decyzji projektowych. Jeśli chcesz wiedzieć, czy ktoś nadmiernie ingeruje w rzeczy, prawdopodobnie musisz porozmawiać o projektowaniu, a nie spojrzeć na bardzo sztuczne ćwiczenie kodowania.

IMHO odpowiedź brzmi: tak , jeśli to znak ostrzegawczy

• zadanie kodowania miało jasne zadanie
• ma dobrze zdefiniowane (i również dobrze napisane) wymagania,
• kandydaci mieli okazję zadać pytania, aby upewnić się, że rozwiązali właściwy problem.
• chcesz ludzi inteligentnych i załatwiających sprawy w swoim zespole, a nie astronautów architektury .

Nie tak duży znak ostrzegawczy, jak nierozwiązywanie problemu . Fakt, że nie zdał quizu i nie podał poprawnego rozwiązania, jest znakiem ostrzegawczym. Niekoniecznie jest to scenariusz niemożliwy, ponieważ zależy to od tego, jak i dlaczego nie zapewnił właściwego rozwiązania.

Wiele razy pytanie jest kompletne bzdury i po prostu bez odpowiedzi. Nie udawaj, że ankieterzy nigdy nie popełniają błędów. Nadal nie udaje mu się wyjaśnić, dlaczego pytanie to bzdury. Jeśli zatrudniasz inżyniera, od którego oczekuje się spełnienia wymagań, jest to problem. Jeśli zatrudniasz programistę, po prostu nie oczekujesz, że on to zrobi.

Zakładając, że ćwiczenie kodowania nie jest strasznie pomieszane, wydaje się, że sposób, w jaki poniósł porażkę, błędnie zinterpretował problem i poszedł w chwasty, próbując rozwiązać problem, którego nie było. Tak, to znak ostrzegawczy.

Może.

Nie rozwiązanie problemu jest oczywiście wyraźnym znakiem ostrzegawczym, że coś jest nie tak. Co poszło nie tak? Albo źle zrozumieli problem, albo znaleźli złe rozwiązanie. Złe rozwiązanie dla czegoś prostego jest wyraźnym znakiem, że kandydat jest biedny.

Jeśli źle zrozumieli problem, przyjrzyj się dokładnie swoim wymaganiom. Nawet rzeczy, które wydają ci się krystalicznie czyste, mogą być niejasne dla osób nieznających dziedziny lub z innego pochodzenia (lokalizacja, wiek, wychowanie). Gdyby kandydat był z tobą w pokoju lub oferował możliwość zadawania pytań i nadal mu się nie udało, uznałbym to za porażkę z ich strony. Gdyby wymagania zostały przerzucone przez mur, prawdopodobnie dałbym im korzyść z wątpliwości (i pomyślałem o naprawieniu procesu rozmowy kwalifikacyjnej).

Jeśli rozwiązanie było prawidłowe, staje się mniej jasne. Osobiście uważam, że wiele osób za daleko posuwa YAGNI . Jeśli możesz podjąć konkretny problem i stworzyć ogólne rozwiązanie bez zwiększania złożoności lub szkodzenia w utrzymaniu, to dlaczego nie zrobić ogólnego rozwiązania? (Zastanów się nad odwróceniem łańcucha a odwróceniem dowolnej kolekcji). Moim zdaniem tego rodzaju „nadmierna inżynieria” jest dobra.

Cała reszta to szary środek. Czy rozwiązanie dotyczy prawdopodobnych osi zmian? Czy rozwiązanie dodaje złożoności lub szkodzi konserwacji? Dodanie odrobiny złożoności do rozwiązania przyszłych problemów, które są prawie gwarantowane na zwycięstwo. Nie szkodzi w znacznym stopniu szkodzenie łatwości konserwacji, aby uwzględnić coś, co jest całkowicie mało prawdopodobne.

Bycie dobrym inżynierem oprogramowania oznacza zachowanie odpowiedniej równowagi. Bycie dobrym ankieterem oznacza trafne osąd / wnioskowanie na temat tego, jak i dlaczego kandydat wybrał tę równowagę, często wykorzystując inne części rozmowy do oceny.

Może, ale rozważ następujące kwestie:

• Wywiady są trudne: ludzie są pod wpływem stresu. Należy to mocno uwzględnić w każdym problemie, który komuś dajesz

• Długość wymagań: jak długie i proste są wymagania? Czy sprawiłeś, że były wyjątkowo pracowite, aby upewnić się, że wszystko zawierasz? W związku z tym mogą być dla Ciebie jasne, ale wymagania mogą być przerobione! Raz na godzinę brałem udział w rozmowie o pracę z około 3 stronami tekstu na problem, który był stosunkowo prosty. Czasami cały ten tekst może być trudny do odczytania i zinterpretowania podczas wywiadu, a także może zostać źle zinterpretowany.

• Czasami mniej znaczy więcej: wolałbym raczej kilka punktorów, zdań i / lub przykładów pokazujących główne wymagania, a następnie dyskusję z kimś, z kim można zadawać pytania i w razie potrzeby skontaktować się z nim po drodze. Myślę, że próbuję powiedzieć, że powinieneś najpierw sprawdzić, czy twoje wymagania testowe nie są zbyt skomplikowane dla prostego problemu.

• Umiejętność komunikacji: powinieneś najpierw przetestować zdolność kandydatów do komunikowania się i zadawania inteligentnych pytań na temat problemu, a kiedy już wiesz, że udowodnili, że rozumieją problem, możesz przedstawić je na temat ich wdrożenia.

• Konkluzja: Jeśli nie sprawdziłeś, czy problem jest zrozumiany, to naprawdę nie wiesz, co zrobić z nadmierną inżynierią. Jak powiedzieli inni, może to być dobra lub zła rzecz, ale jeśli nie sprawdziłeś zrozumienia lub nie skontaktowałeś się z kandydatem na temat problemu z przodu, trudniej jest poznać jego ogólne zrozumienie problemu i co z tym zrobić.

Wiele z tego można przypisać temu, jak sformułowałeś pytanie i jak umieściłeś cały wywiad w perspektywie.

To jest jak „Zobaczmy, jak jesteś kreatywny. Co to jest 2 + 2?” Cztery? Wszystko, co możesz wymyślić, to najprostsza, oczywista i dokładna odpowiedź? Programiści na poziomie podstawowym / młodym, którzy tak chętnie robią wrażenie podczas wywiadu, wezmą „Chcemy przetestować twoje umiejętności kodowania lub przekonać się, jak dobry jesteś programista”. oznaczać „zrób coś bardzo wyrafinowanego”. Wszyscy lubimy myśleć, że proste jest najlepsze, z wyjątkiem sytuacji, gdy utrudnia to wszystko.

Istnieją sposoby, aby sprawdzić, czy ktoś ma skłonność do nadmiaru inżynierii. Podaj przykładowy kod czegoś, co było zbyt złożone i poproś o prostsze rozwiązanie. Gdy ktoś zaproponuje rozwiązanie, które Twoim zdaniem nie zadziała, jest to świetna okazja, aby zobaczyć, jak zareaguje na krytykę. Osobiście chciałbym, aby ktoś był otwarty na nowe pomysły i znalazł lepsze rozwiązanie niż ktoś, kto będzie popełnił te same błędy w kółko.

A w rzeczywistości, czy nie zawsze mamy możliwość zmiany naszego kodu, gdy nie działa? Możesz początkowo projektować lub przerabiać. Czy po zrozumieniu prostego rozwiązania nie powinno być łatwiej go wdrożyć?

To zależy, ale generalnie nie.

Projektowanie ogólnie jest umiejętnością nabytą z doświadczeniem. Opis Aaronaught opisujący ten postęp związany z Marjanem jest ogólnie dobry.

Komunikacja w dowolnej formie zależy również od kontekstu. To, co może wydawać się całkowicie jasne, oznaczać jedną rzecz w jednym kontekście, może równie dobrze oznaczać coś innego w innym kontekście. Wiedza, które pytania należy zadać, to także doświadczenie.

Ich proces myślowy i sposób, w jaki rozumują swoje decyzje, są znacznie ważniejsze niż ich rozwiązanie. Bez przeglądu ich rozwiązania i ich decyzji z nimi nie można w pełni ocenić kontekstu, w którym został opracowany.

Biorąc pod uwagę powyższy postęp, kandydat z nadmiernie skonstruowanym rozwiązaniem może być dalej niż kandydat z prostym rozwiązaniem.

Również: Na jakiej pozycji jesteś zatrudniony? Nadmiar inżynierii kandydata na poziomie średnim lub wyższym nie stanowi problemu niż nadmiar inżynierii kandydata na poziomie wyższym.

Jeśli programista nie rozwiązał problemu, cały dodatkowy kod jest próbą zamaskowania kodera przez brak odpowiedzi. Jest to ta sama technika, która została zastosowana w teście eseju przez studenta, który niewiele wie na ten temat. On lub ona będzie wędrować na temat przekonujących, ale niezwiązanych ze sobą kwestii w nadziei, że jego ignorancja jest zamaskowana przez liczbę słów.

Jeśli programista rozwiązał problem, ale dodał znacznie więcej kodu, należy wziąć pod uwagę tło programisty, ponieważ niektóre obszary programowania wymagają większych tolerancji niż inne.

Na przykład kod uruchamiający autopilota w komercyjnym odrzutowcu pasażerskim ma znacznie mniejszą tolerancję na awarię niż darmowa gra na Androida. Deweloper przyzwyczajony do programowania urządzeń osadzonych, które są trudno dostępne i prawie niemożliwe do zaktualizowania, będzie miał tendencję do kodowania większej liczby rzeczy, jeśli jest to programista, który może wypchnąć 15 aktualizacji dziennie.