Jak zaprojektować dowolny system w wywiadzie? [Zamknięte]

36

Częstym pytaniem w Wywiadzie Technicznym jest zaprojektowanie konkretnego systemu, zwykle istniejącego produktu firmy. Na przykład „Zaprojektuj Dokumenty Google”.

Jaka jest oczekiwana odpowiedź na takie pytanie? Mam na myśli, że takie systemy z pewnością mają złożoną konstrukcję, która jest poza zakresem jakiegokolwiek wywiadu. Czego oczekują ankieterzy w tak krótkim czasie?

Shamim Hafiz
źródło
4
+1 Mój przyjaciel został właśnie o to zapytany innego dnia. Powiedziałem to samo. Staram się zadawać pytania na rozmowę kwalifikacyjną na czas nieokreślony. Zapytaj rozmówcę o ich projekty i jak / dlaczego ich projekt. W ten sposób mogą mi powiedzieć o czymś, co już wiedzą i zrobili. Zamiast potknąć się o projektowanie białej tablicy, zastanawiając się, czy zacząć od spełnienia wymagań, czy poczynić pewne założenia, ponieważ oczywisty limit czasu ...
P.Brian.Mackey
6
Jeśli jest to istniejący produkt, strzeliłbym do niego z pytaniem: „Co uważasz za wadliwe w swoim dotychczasowym projekcie?”
Blrfl,
5
„no cóż… krok 1 to skontaktowanie się z prawnikiem, aby sprawdzić, czy naruszamy jakiś znak towarowy lub prawo autorskie”
Steven Evers,
12
„Masz coś przeciwko, jeśli zobaczę dokumenty wymagań?”
Joel Etherton
4
„Nigdy go nie używał. Jakie są jego główne cechy?”
Steven A. Lowe

Odpowiedzi:

22

Wgląd w to, jak twój mózg patrzy na ten problem. Oto kilka punktów początkowych, które mogłem zobaczyć, jak można spróbować przeprowadzić tę rozmowę:

  • Z góry na dół - Patrząc w dół z bardzo wysokiego poziomu, stwórz projekt i dopracuj projekt, gdy różne komponenty zostaną wykonane, a oto garść komponentów, które mogłem zobaczyć ...

  • Od dołu - patrząc od podstaw, oto fragmenty, które można zbudować, aby spróbować połączyć ...

  • Wyjaśnienie wymagań - Zadawanie pytań o prognozowaną skalę, rozmiar, budżet i zespół zastosowany w tym projekcie. Możesz spróbować wprowadzić kod osoby w bardzo uproszczonym edytorze tekstu lub możesz wydać setki milionów dolarów, aby stworzyć najlepszy system zarządzania dokumentami, który Twoim zdaniem jest tak ekstremalny, jak Google Doc. Również tutaj jest możliwość zadania pytania „Co masz na myśli przez Dokument Google? Jaką część tej funkcji chcesz powielić?” również pytania.

Kluczem jest to, jak dobrze potrafisz przekazać swoje przemyślenia i podejście do rozwiązania tego rodzaju problemu, ponieważ użytkownik może się do ciebie zwrócić i zapytać: „Psst, czy mógłbyś zrobić coś takiego w ciągu 2 tygodni?”. to może się zdarzyć. Tak więc, w jaki sposób dać odpowiedź jest ważniejsze niż to, co jest odpowiedzią.


Osobiście uważam, że wcześniejsze projekty nie są tutaj dobrym pomysłem. To, co próbuje się znaleźć, to rodzaj kreatywności i umiejętności komunikacyjnych w nowym obszarze, a nie tylko przypominanie sobie, jak coś zostało zrobione w przeszłości. Są szanse, że chociaż coś, co dzieje się na nowej pozycji, może być podobne do czegoś z przeszłości, mogą występować tylko takie różnice, że stare rozwiązanie nie jest możliwe. Dlatego, chociaż to, co można zbudować, jest podobne do istniejącej aplikacji, mogą istnieć różne dostosowania, które znacznie różnią rozwiązanie od początkowego przykładu.

Wywiady są ulicą dwukierunkową. Menedżerowie i inni programiści rzadko są mistrzami przeprowadzania rozmów kwalifikacyjnych, więc nie jestem pewien, czy dostrzegam wartość próby stwierdzenia, że ​​powinni oni być ekspertami merytorycznymi podczas rozmów kwalifikacyjnych. Osoby rekrutujące spodziewałem się, że będę wiedział, jak przeprowadzić rozmowę kwalifikacyjną, ale jest wielu biednych rekrutujących, których można by użyć jako przykładów, dlaczego nie zawsze jest to dobry pomysł.

JB King
źródło
2
Lepiej zapytać rozmówcę o projekt, który znają. W ten sposób możesz zobaczyć, jak działa ich umysł podczas prawdziwego procesu pracy. Możesz je zatrzymać i poprosić o wyjaśnienie szczegółów, aby zobaczyć, jak daleko posuwa się ich wiedza na temat ich domeny. „Dlaczego nie użyłeś interfejsu jako parametru metody?” Następnie, jako ankieter, musisz zadać właściwe pytania. Jest to właściwe, ponieważ rozmówca jest w Twojej domenie ... nie jest ich własnością.
P.Brian.Mackey
2
+1, gdybym mógł: „Kluczem jest to, jak dobrze potrafisz przekazać swoje myśli” ... niestety uważam, że większość zarówno ankieterów, jak i kandydatów ma braki w tym obszarze.
Anon
2
„Lepiej zapytać rozmówcę o projekt, który zna. W ten sposób możesz zobaczyć, jak działa ich umysł podczas prawdziwego procesu pracy”. Właściwie wszystko, co zrobią, to przetestować ich wycofanie z wcześniej wykonanych prac projektowych. Ankieterzy najczęściej szukają sposobu, w jaki będą atakować nowe problemy.
DJClayworth,
16

Myślę, że te pytania mogą być bardzo dobre, szczególnie dla starszych programistów. Pokazują, że programista jest w stanie przejść od dużego, skomplikowanego opisu do realistycznej implementacji. Nawet przy zupełnie nieznanym systemie powinieneś być w stanie wykonać szereg interesujących działań dla ankietera:

  • Zbierz wymagania, aby odpowiedzieć na pytanie (np. Zakres)
  • Podziel problem na łatwiejsze do opanowania części; ewentualnie zidentyfikować interfejsy lub obiekty, które mogą być potrzebne, lub rozbić logikę na front-end, back-end, DB itp.
  • Wykazać znajomość struktury i koncepcji tego rodzaju systemu, np. Aplikacji internetowych w przypadku Dokumentów Google
  • Pokaż, na czym się skupiasz, gdy pojawia się problem z projektem (Projektowanie obiektów? Tabele SQL? Wzorce projektowania?)
  • Pokaż szefowi, jak to będzie z tobą opracować nowy system, w którym szef wchodzi ze specyfikacją i pyta: „Co by to zbudowało?”

To pytanie jest tylko wersją wyższego poziomu „Opisz hierarchię obiektów, której byś użył do tego.” „Opisz interfejs, który chcesz dla tego zaprojektować…” „Zaprojektuj zestaw relacyjnych tabel DB dla tych danych ...” itp., Które zostaną przekazane programistom średniego i średniego poziomu. W programistach niższego poziomu ankieter może oceniać długoterminowy potencjał rozwoju firmy w danej firmie lub po prostu widzieć, co robi, gdy staje w obliczu dużego problemu, który może być przytłaczający.

Ethel Evans
źródło
2
Tak więc oczekiwaną odpowiedzią na pytanie są niektóre uproszczone diagramy UML?
Shamim Hafiz
3
Myślę, że uproszczony UML byłby powszechną częścią odpowiedzi. Mogą się również pojawić diagramy serwerów. Kluczową rzeczą jest pokazanie, że nie przeszkadza ci rozmiar problemu i że możesz płynnie przejść od niejasnej koncepcji do prawdziwej architektury (z konkretnymi - nie niejasnymi - problemami do rozwiązania). A następnie przekaż tę architekturę. Ankieter może również słuchać, czy wybierasz aktualne najlepsze praktyki, czy też wybierasz rozwiązania, które są nieaktualne.
Ethel Evans
11

Chodzi o obserwowanie procesów myślowych w działaniu; nie są zainteresowani rozwiązaniem, ale sposobem podejścia do rozwiązania problemu, zadawanymi pytaniami, zidentyfikowanymi problemami itp.

Biorąc pod uwagę przykład Dokumentów Google, oczywiste problemy, które przychodzą na myśl, to między innymi pamięć, bezpieczeństwo, skalowalność, dostępność, projekt interfejsu klienta, kompatybilność przeglądarki itp. W jaki sposób podzieliłbyś odpowiedzialność między serwer a klienta? Jak poradziłbyś sobie z kopiami zapasowymi? Co się stanie, gdy serwer przestanie działać? Co zrobiłbyś z „porzuconymi” dokumentami (rzeczy, które nie były dostępne ani modyfikowane przez długi czas)?

Ponownie chodzi o to, aby nie rozwiązać żadnego z tych problemów, ale je zidentyfikować , omówić je, przeprowadzić burzę mózgów na temat sposobu ich rozwiązania itp.

John Bode
źródło
9

Jestem jedną z tych winnych stron, które często zadają tego rodzaju pytania w wywiadach. (Dla przypomnienia zadaję również podobne pytania dotyczące ich „ulubionego projektu”). Powód, dla którego zadaję to to, że często robimy to tutaj. Pozyskujemy inżynierów projektantów ze wszystkich stron interfejsu, kogoś z inżynierii systemów, kogoś z testów i kogoś znającego przypadki użycia tej funkcji przez klientów. Stoimy wokół tablicy i mówimy: „Dobra, jak zamierzamy to zbudować?” Często wiesz bardzo niewiele o nowej funkcji w tym momencie i jesteś tam tylko ze względu na swoją wiedzę specjalistyczną w swojej części systemu, ale nadal oczekuje się, że wniesiesz produktywny wkład. To nie tylko hipotetyczne ćwiczenie akademickie.

Jeśli chodzi o odpowiedzi, których oczekuję, weźmy na przykład zaprojektowanie systemu do pobierania nowego oprogramowania wewnętrznego z serwera za pośrednictwem 20 wbudowanych kart linii w centralnym biurze, aby zaktualizować 5000 dekoderów jednocześnie. Załóżmy, że połączenie między serwerem a kartami liniowymi jest bardzo wolne.

Zła odpowiedź:

Um, prawdopodobnie użyłbym Ethernetu lub czegoś takiego.

Dobra odpowiedź:

Jak duży obraz mówimy? [Około 7 MB.] Chcesz się upewnić, że usługa nie została naruszona podczas pobierania. Będziesz potrzebował dodatkowej pamięci flash lub RAM, aby przechowywać dwa obrazy jednocześnie. Prawdopodobnie zechcesz buforować obraz na kartach linii, aby uniknąć ciągłego pobierania tego samego obrazu z serwera. Będąc osadzonym, Twoje karty liniowe prawdopodobnie same mają ograniczony procesor, więc może być konieczne serializowanie pobranych plików, aby pozostawić wystarczającą pojemność do obsługi. Chciałbyś w jakiś sposób sprawdzić, czy obraz jest dobry i wrócić do starej wersji, jeśli nie działał. Będziesz potrzebować sposobu, aby spróbować kilka razy i zgłosić błędy człowiekowi, jeśli aktualizacja się nie powiedzie. Jeśli masz różne marki dekoderów, potrzebujesz jakiegoś sposobu na określenie, który obraz chcesz wysłać.

To prawie transkrypcje słowo w słowo dwóch różnych kandydatów. Większość kandydatów znajduje się gdzieś pośrodku, ale zazwyczaj dociera do celu z niewielkim podpowiedzi, co jest całkowicie w porządku. Nie szukamy tutaj następnego Einsteina, tylko wskazówkę, że faktycznie możesz inteligentnie rozumować o rodzajach problemów, nad którymi pracujemy na co dzień.

Karl Bielefeldt
źródło
1
gdzie pracujesz i potrzebujesz nowych pracowników? : D
Maggie,
1
Chociaż wszystkie przykłady tego, co nazywacie „dobrą odpowiedzią”, mogą być istotne. Pytanie brzmiało: „Zaprojektuj system, który…”. Biorąc pod uwagę, że jest to sytuacja podczas rozmowy kwalifikacyjnej, więc można oczekiwać, że na odpowiedź pozostanie najwyżej 5–10 minut, większość tego, co zidentyfikowałeś, wydaje się być chwastami na rozwiązanie rozmowy. Gdzie jest właściwe rozwiązanie w twojej „dobrej odpowiedzi”? Gdy dana osoba znajdzie rozwiązanie „szczęśliwego dnia”, może zacząć rozważać „co-jeśli”, o których mówisz w „dobrej odpowiedzi”. Ale do tego czasu sądzę, że czas się skończył.
Dunk
5

Zadaję również tego rodzaju pytania i zgadzam się z większością innych odpowiedzi. Może pomogłoby rozmówcom zrozumieć, DLACZEGO tego typu pytanie jest ważne? Załóżmy, że musimy podjąć ważną decyzję biznesową, a aby to zrobić, musimy zbudować nowy system. Jeśli ktoś podbiegnie do ciebie i zapyta, co trzeba zbudować system działający na X, czy możesz dać mu wnikliwą odpowiedź, która przewiduje główne wyzwania i wymagane zasoby?

Młodszy programista nie ma pojęcia, od czego zacząć. Nie są gotowi do rozmowy bez szczegółowej specyfikacji. Starszy programista natychmiast zauważy, że problem ma wiele aspektów, i spróbuje dopracować wyzwanie. Nie musisz projektować każdego aspektu, wystarczy zidentyfikować wyzwanie architektoniczne, a następnie wymyślić, jak je rozwiązać.

Rozważ problem z Dokumentami Google:

Jedną interesującą rzeczą jest skala ścinania żądań, które będą nadchodzić. Nie możesz po prostu zdobyć jednego serwera i wdrożyć na nim kodu - jest to większe przedsięwzięcie. Udany rozmówca może zająć się tym i opisze rodzaje zasobów, które będą potrzebne, a także niektóre techniczne wyzwania związane z wdrażaniem na taką skalę, w przypadku aplikacji, która ma nie tylko stan, ale dzieli stan wielu użytkowników.

Kolejną interesującą rzeczą w Dokumentach Google jest to, że wiele osób może edytować jednocześnie. Udany rozmówca będzie mógł omówić mechanizmy zapewniające, że wynikowy dokument nie będzie śmieci, a naprawdę świetny kandydat zda sobie sprawę, że różne metody synchronizacji lub scalania zmian będą miały duży wpływ na wydajność i UX. Może nawet omawiamy różne warianty: edytor współdzielonego dokumentu do pisania kodu powinien prawdopodobnie używać innej metody rozwiązywania konfliktów niż typowy Dokument Google, ponieważ istnieją inne konsekwencje dla rzeczy dziejących się w innej kolejności lub mających nieco inną strukturę.

Nie ma jednego właściwego sposobu na utworzenie aplikacji takiej jak Dokumenty Google, nie musisz określać, co byś zrobił przy każdej wymianie, ale naprawdę świetnie jest znaleźć obszar, który ma interesujący problem i jasno wyjaśnić, na czym polega wymiana może być.

-t.

Tristan Reid
źródło
Głosowałem za tym, ponieważ jesteś jedyną odpowiedzią, która skierowała swoją odpowiedź na „architektoniczne” rozwiązanie projektowe. Jest to najlepsze, co możesz zrobić w kontekście wywiadu dotyczącego problemu o danym zakresie. Rozmówca, który rozumie, że rozwiązanie architektoniczne jest wszystkim, co można osiągnąć, pokazuje, że wie, co robi.
Dunk
2

Podejrzewam, że ankieterzy chcą usłyszeć:

Dokument Google to interfejs internetowy edytora tekstu. Dokumenty użytkownika są wpisywane i przechowywane, a użytkownik może je odzyskać na tym samym lub innym komputerze.

O czym chciałbyś dyskutować dalej?

Następnie piłka trafia do sądu ankietera. Jeśli chce więcej szczegółów, może zapytać. To, czego szuka ankieter, czy możesz spojrzeć na problem lub produkt i wyodrębnić projekt?

Gilbert Le Blanc
źródło
1
Odpowiedź jest dobra, ale nie sądzę, że osoba przeprowadzająca wywiad będzie z niej zadowolona. Jak dotąd czytając posty, wydaje się, że takie pytania nie są popularne wśród rozmówców.
Shamim Hafiz,
-1 @ Gilbert Le Blanc - Czas „przyspieszenia” zdefiniowany przez prawo Brook'a w The Mythical Man Month sprawia, że ​​to pytanie jest w najlepszym razie głupie. Jeśli wiemy, że nauczenie się wnoszenia wartości dodanej do projektu oprogramowania zajmuje około 6 miesięcy, czego można się spodziewać po „ekstrakcji projektu” w ciągu zaledwie 6 godzin? en.wikipedia.org/wiki/Brooks%27s_law
P.Brian.Mackey
1
@Shamim Hafiz: Na podstawie twojego pytania i komentarza powiedziałbym, że to pytanie nie jest popularne, ponieważ ty i inni mają trudności z zawężeniem zakresu pytania. Odpowiedź JB Kinga jest bardziej kompletna niż moja. Wszystkie jego punkty są poprawnymi sposobami na zawężenie zakresu pytań, chociaż najpierw jestem stronniczy, a potem wymagam wyjaśnienia. W prostszym języku angielskim najpierw narysuj analogię, a następnie zaznacz różnice.
Gilbert Le Blanc
4
Gdybym przeprowadzał wywiad, nie byłbym zadowolony z tej odpowiedzi. Odpowiedź tutaj mówi mi tylko, czym są dokumenty Google, coś, co już wiem.
whatsisname
1
@ biała nazwa - myślę, że ankieter chciałby poznać odpowiedź na pytanie (lub boisko) w kontekście wywiadu.
Morgan Herlocker
2

Dla mnie, jeśli dana osoba nie zaczyna od zidentyfikowania kluczowych przypadków użycia / historii, wystarczyłoby, aby wiedzieć, że nie są przygotowani na stanowisko wymagające tej konkretnej umiejętności.

Następnie powinni być w stanie zaproponować rozwiązanie architektoniczne oparte na kluczowych przypadkach użycia / historiach. Mam nadzieję, że wykorzystali jakiś systematyczny proces do identyfikacji modułów innych niż wyciąganie ich z ich .... Nie spodziewałbym się więcej po rozwiązaniu problemu.

Mogę jednak wybrać jeden z modułów architektonicznych i poprosić o bardziej szczegółowy projekt, aby sprawdzić, czy mają jakieś umiejętności projektowe. Byłoby również miło zobaczyć, że rozważają przypadki awarii / problemy z wydajnością. Ale podejrzewam, że w tym momencie wpadlibyśmy na ścianę czasu. Dlatego naprawdę nie mogłem ich ukarać za nieuwzględnienie tych kwestii, ponieważ jest tylko tyle czasu i uważam, że rozsądnie jest założyć, że rozważenie każdego możliwego scenariusza nie jest spodziewane w sytuacji ograniczonej czasowo rozmowy.

Maczać
źródło
1

Niedawno miałem wywiad, w którym poproszono mnie o zaprojektowanie systemu sterowania windą. Zasadniczo chcą zobaczyć twoje podejście do zadania. Jeśli zostaniesz zapytany o to pytanie, prawdopodobnie mają na myśli bardzo wysoki poziom pracy. Gratulacje.

Michael Brown
źródło
1

Kluczową kwestią jest to, jak rozwiązujesz problemy w porównaniu do zalet rozwiązania, które dajesz i czy potrafisz poradzić sobie z problemami z dużym obrazem.

Myślę, że jedną ważną rzeczą jest zadawanie pytań na temat wymagań. Nie rób tylko założeń, które umożliwią działanie twojego zwierzaka. Na przykład może się zdarzyć, że znasz jakąś naprawdę sprytną metodę drukowania dokumentów, którą możesz pokusić się od razu o opisanie. Ale Dokumenty Google nie drukują bezpośrednio; tworzy plik PDF, który następnie drukuje klient. Więc jeśli zaczniesz od tego, poświęcisz połowę swojego czasu na rozwiązanie problemu, który nie jest częścią problemu, i udowodniłeś, że jesteś bardziej zainteresowany korzystaniem z gorącej technologii niż rozwiązywanie problemu klienta.

JohnMcG
źródło
0

Aby poradzić sobie z tego rodzaju pytaniami do rozmowy kwalifikacyjnej, musisz mieć ogólny interes w zrozumieniu „jak działają rzeczy”, nie tylko w projektach, którymi jesteś zainteresowany, ale także w projektach, które Twoim zdaniem są zbyt odległe od twoich doświadczeń.

Oznacza to czytanie blogów, artykułów, http://www.infoq.com , Hacker News itp. Nawet sprzętowe blefy z Coding Horror.

Pomimo faktu, że zapomnisz większość tego, co przeczytałeś (ponieważ te informacje i tak nie są osobiście powiązane z twoją pracą), mogą istnieć pewne ciekawostki, które są „ziarnem wyobraźni” i niewielką część tych nasion będzie kiełkować, gdy napotkasz podobny problem w dalekiej, dalekiej przyszłości.

Osoba przeprowadzająca wywiad może być więc zainteresowana twoimi nawykami czytania (w ramach hobby) i sprawdź, czy masz zwyczaj nawyk zbierania nasion pomysłów z przypadkowych miejsc.

rwong
źródło
Nie wiem o tobie, ale bardziej przychylnie patrzę na programistów, którzy formułują projekty w oparciu o fakty i doświadczenia, a nie rzeczy, które czytali kiedyś na blogu.
Aaronaught
@Aaronaught: oczywiście prawdziwe doświadczenie z podobnych projektów jest nieskończenie cenniejsze niż słyszane pomysły. Ale kiedy zlecasz projekt w obszarze, w którym nie masz doświadczenia, po prostu rezygnujesz z okazji? (Zakładając, że poinformujesz pracodawcę, że nie masz odpowiedniego doświadczenia, a pracodawca nie ma nic przeciwko temu). Jeśli zdecydujesz się go wziąć, to jak zacząć? Zaczynasz od lekcji zdobytych od innych ludzi, innych firm i tak dalej. Nie możesz zaczynać znikąd. Być może miałeś rację, oddając mi głos, ponieważ OP wydaje się przesłuchiwać na wyższym stanowisku, ale
rwong
(ciąg dalszy) Proszę nie lekceważyć znaczenia wniosków wyciągniętych z innych źródeł.
rwong
W porządku, być może opinia nie była zasłużona (chociaż nie mogę jej usunąć na tym etapie). Mimo to, naprawdę nie sądzę, że ankieter zadałby takie pytanie, aby dowiedzieć się, co czytasz; gdyby tak było, po prostu zapytaliby, co czytasz. Ważne jest, aby zadawać właściwe pytania, abyś nauczył się, jak to ma działać, a nie na wpół przechylony w oparciu o porozrzucane fragmenty informacji, które mogą, ale nie muszą być powiązane.
Aaronaught
0

Zadaniem tego rodzaju pytania jest uzyskanie wglądu w swój umysł. Często zadawanym przeze mnie pytaniem jest prosić programistów o zaprojektowanie systemu, który może symulować PacMan.

I tak, najpierw szukam przypadków użycia, pokazuje mi, że dana osoba myśli. Następnie, w przypadku wielowątkowości, najpierw rozważ struktury danych (te, które mogą być wykorzystane do rozwiązania problemu, a następnie bardziej odpowiednie lub konkretne z motywem decyzji).

Jest to uważane za konieczne na wyższych stanowiskach rozwojowych. To głupie i bezcelowe, aby ludzie siedzieli i odpowiadali na pytania dotyczące implementacji sortowania na tym poziomie doświadczenia programisty. Na tym poziomie oczekiwałbym projektowania systemu.

Wile EK
źródło