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

22

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.

Nim
źródło
43
czy możesz podać przykład tego ćwiczenia? Problemem może być wyzwanie, a nie kandydat.
Reactgular,
13
Czy na pewno kandydaci zrozumieli problem przedstawiony w ćwiczeniu? Prosty dla osoby prezentującej ćwiczenie nie zawsze jest jednoznaczny z kandydatem w stresie.
cdkMoose,
23
Czy fakt, że nazwałeś to „nadinżynierią”, nie narzuca odpowiedzi? To jak pytanie „Czy zbyt pewny siebie kandydat jest znakiem ostrzegawczym”? Jasne, chyba że jest po prostu pewny siebie, ale już wyciągnąłeś wnioski z założenia pytania.
psr
3
@MathewFoscarini Czy nadmierna inżynieria nie zawsze jest negatywna? Oznacza to, że osoba skoncentrowała się na niewłaściwych rzeczach i wdrożyła rozwiązanie, które jest niepotrzebnie złożone, czasochłonne lub trudne do zrozumienia i utrzymania. Jak można tego nie postrzegać jako wady?
Andres F.,
2
@AndresF. to wywiad. Ponad inżynieria odpowiedź na pytanie w wywiadzie, biorąc pod uwagę, że większość wywiadów trwa tylko godzinę. To może być osiągnięcie. Tak, napisanie 1000 linii kodu w celu posortowania czegoś jest zbyt skomplikowane, ale napisał 1000 linii kodu w mniej niż godzinę! Jeśli nadmiar inżynierii jest problemem, który należy odfiltrować w trakcie rozmowy kwalifikacyjnej. Powinien istnieć bardziej szczegółowy test związany z zakresem projektu i złożonością. Wolę dać tej osobie wyzwanie architektoniczne do rozwiązania. Na przykład; „utwórz diagram UML dla samodzielnego systemu samochodowego”.
Reactgular,

Odpowiedzi:

48

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?”

Karl Bielefeldt
źródło
5
gdzie w pytaniu jest napisane „złożone oprogramowanie na poziomie przedsiębiorstwa”?
Reactgular,
12
@Nim - Myślę, że chodzi o to, że Karl uważa, że ​​to, co uważasz za nadmierną inżynierię, inni ankieterzy mogą rozważyć dobrą reprezentację zrozumienia OOD przez rozmówcę. Odniesienie do pseudokodu może nie być tak jednoznaczne, jak myślisz, opisując oczekiwane podejście.
Mike Partridge
7
Nie mówię nic o twoich zamiarach, @Nim. Kandydaci czytają różne rzeczy w pytania, które nie zostały wyraźnie określone, a wielu ankieterów faktycznie tego oczekuje. Kandydaci nie mają możliwości dowiedzenia się, czy jesteś tego rodzaju ankieterem, czy nie, więc popełniają błąd po bezpiecznej stronie.
Karl Bielefeldt,
5
@KarlBielefeldt: tak, czasami ludzie czytają rzeczy w pytania, które nie są wyraźnie określone - na przykład w pytania zadawane tutaj na PSE ;-)
Doc Brown
3
A co z prostym rozwiązaniem polegającym na dodaniu na końcu ćwiczenia zdania z napisem „opisz jak najmniej kodu” lub czegoś w tych kategoriach
user60812
30

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.

DemetriKots
źródło
23

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.

psr
źródło
Nigdy tego nie widziałem. W rzeczywistości większość firm chce najprostszego i najbardziej zwięzłego rozwiązania. Byłbym ostrożny, jeśli chodzi o pracę w jakiejkolwiek firmie, która nie jest w stanie złożyć odpowiedniego wniosku, a ze względu na brak zrozumienia przez kandydata „jasnych wymagań” nie zatrudniłbym go.
Shaun Wilson
1
@ShaunWilson: To bardzo zależy. Wyobrażam sobie, że duże firmy mogą być zainteresowane zobaczeniem, co możesz zrobić z jasnymi specyfikacjami. W mniejszych zespołach ludzie polegają na wzajemnych zdolnościach do empatii, ekstrapolacji, czytania między wierszami i samodzielnego odkrywania przestrzeni problemów.
back2dos
@ShaunWilson Widziałem to wiele razy. Daj zadanie, nawet powiedz kandydatowi, aby zignorował takie rzeczy, jak sprawdzanie błędów i podaj tylko podstawy, a potem ich nie powiedz, ponieważ nie zawierały one wszystkich przypadków narożnych i nieprzewidzianych okoliczności. To niestety bardzo, bardzo powszechne.
jwenting
W przypadku programowania należy spodziewać się od kandydatów przestrzegania standardów i stylu kodowania - ale spójność jest uczciwym oczekiwaniem. Oczekujemy, że kandydaci będą posługiwać się językiem idiomatycznie, ale nie zajmujemy się przypadkami testowymi - ramy czasowe to tylko dwie godziny (myślę, że to nierealne). Nie wierzę w sztuczki w wywiadach, nie ma sensu - mam były w takich sytuacjach wcześniej i szczerze mówiąc, uważam, że są one wyprawą ego dla ankietera i dlatego najlepiej ich unikać. Mówimy wprost o OOD (a mimo to niesamowite jest widzieć rozwiązania, które nie wykorzystują OO ..)
Nim
@ jwenting, zapewniam cię, nie robimy nic takiego, to po prostu podstępne. Jeśli jednak przejdziemy dalej, podczas wywiadów f2f omówimy, w jaki sposób można je rozszerzyć, aby dodać przypadki narożne, ale tylko wtedy, gdy kandydaci się o tym dowiedzą.
Nim,
12

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

Doktor Brown
źródło
1
+1 dla elementu interaktywnego. W wielu przypadkach specyfikacje są niejasne, niepełne lub zawierają terminologię specyficzną dla domeny. Bez możliwości wyjaśnienia jakichkolwiek problemów niewłaściwe może być obwinianie kandydata.
HABO,
1
+1 za to, że Twoja odpowiedź idealnie modeluje proces. Wyraźnie odpowiedziałeś dokładnie na pytanie zadane przez PO.
dcaswell
1
+1, to jest mój obecny proces myślowy, myślę, że dobrze jest zobaczyć, że to nie jest naiwne ani głupie ... Dzięki za dwa linki Joela ...
Nim,
1
Nie bądź tak szybki w pogardzie dla astronautów architektury. Bycie astronautą architektury jest fazą, przez którą deweloper musi przejść, zanim stanie się naprawdę sprawnym programem taśm klejących. Zobacz tę odpowiedź Aaronaught szczerze, czy wolisz kodowanie Cowboy? pytanie.
Marjan Venema,
1
@MarjanVenema: Mam wątpliwości, czy Aaronaught miał na myśli to samo słowo, co Joel Spolsky, który stworzył ten termin. I szczerze mówiąc, nie sądzę, żebym nikogo „pogardzał” - jeśli chcesz, aby twórcy w swoim zespole tworzyli, cóż, powiedzmy wizjonerskie rozwiązania, nie krępuj się ich zatrudnić.
Doc Brown
5

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.

Philip
źródło
3

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.

Telastyn
źródło
2
Jeśli problem jest trudny do zrozumienia lub nie został dobrze zakomunikowany, nadszedł czas, aby zademonstrować umiejętność krytyczną dobrą do moderacji programistów MUSZĄ mieć - określenie problemu.
Adam Davis,
Pytanie nie mówi, że kandydat nie wykorzystał okazji do zadawania pytań.
dcaswell
3

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ć.

bjackfly
źródło
1
Solidna odpowiedź, ale trudno przebrnąć przez ścianę tekstu. Rozważ edycję swojej odpowiedzi i podzielenie głównych sekcji.
2

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ć?

JeffO
źródło
„Co to jest 2 + 2?” 4 a „Zobaczmy, jak jesteś kreatywny. Co to jest 2 + 2?” Granica sekwencji 3.9, 3.99, 3.999, 3.9999, ...
emory
„Zobaczmy, jak jesteś kreatywny. Co to jest 2 + 2?” 5, dla wystarczająco dużych wartości 2.
Michael
i zdefiniuj „nadinżynieria”. W zależności od środowiska coś, co może się wydawać nieznajomym inżynierem, może zostać uznane za przejawianie zbyt wielu swobód i skrótów dla kogoś w tym środowisku. Pomyśl o oprogramowaniu do kontroli pocisków, gdy patrzy na niego ktoś, kto zajmuje się głównie pisaniem gier na telefony komórkowe ...
jwenting
2

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.

Mr.Mindor
źródło
1

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.

Andrew Neely
źródło