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

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?

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

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.

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.

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

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.

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?

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.

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.

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.

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.

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.