Как мне спроектировать произвольную систему в интервью? [закрыто]

36

Общий вопрос в Tech Interview - это разработка конкретной системы, обычно существующего продукта компании. Например, «Дизайн Google Docs».

Каков ожидаемый ответ на такой вопрос? Я имею в виду, что такие системы, безусловно, имеют сложную конструкцию, которая выходит за рамки любого интервью. Чего ждут интервьюеры в такой короткий срок?

Шамим Хафиз
источник
4
+1 Мой друг только что спросил об этом на днях. Я сказал то же самое. Я стараюсь задавать открытые вопросы для интервью. Спросите собеседника о его проектах и ​​о том, как и почему их дизайн. Таким образом, они могут рассказать мне о том, что они уже знают и сделали. Вместо того, чтобы спотыкаться о дизайне белой доски, задаваясь вопросом, стоит ли начинать с требований или делать кучу предположений, потому что очевидный срок ...
P.Brian.Mackey
6
Если бы это был уже существующий продукт, я бы ответил: «Что вы считаете недостаточным в существующем дизайне?»
Blrfl
5
«ну ... шаг 1 будет связаться с адвокатом, чтобы узнать, нарушаем ли мы какой-либо товарный знак или авторские права»
Стивен Эверс
12
"Не возражаете, если я увижу документы с требованиями?"
Джоэл Этертон
4
«Никогда не использовал его. Каковы его основные особенности?»
Стивен А. Лоу

Ответы:

22

Понимание того, как ваш мозг смотрит на эту проблему. Вот несколько отправных точек, которые я мог бы увидеть, как можно попытаться провести этот разговор:

  • Сверху вниз - глядя вниз с очень высокого уровня, выстраивайте дизайн и уточняйте дизайн по мере того, как готовятся различные компоненты, и вот несколько компонентов, которые я мог видеть ....

  • Вверх - снизу вверх - вот кусочки, которые можно собрать, чтобы попытаться собрать вместе ....

  • Уточнение требований - Задавайте вопросы о предполагаемом масштабе, размере, бюджете и команде, используемой для этого проекта. Вы могли бы попытаться сделать так, чтобы человек написал очень упрощенный текстовый процессор, или вы могли бы потратить сотни миллионов долларов на создание совершенной системы управления документами, которая, как вы считаете, соответствует вашим Google Doc. Также здесь есть возможность задать что-то вроде: «Что вы имеете в виду под Документом Google? Какую часть этих функций вы хотите дублировать?» вопросы тоже.

Ключ в том, насколько хорошо вы можете поделиться своими мыслями и подходом к решению такого рода проблем, поскольку вы можете предложить пользователю подход и спросить: «Psst, не могли бы вы сделать что-то подобное за 2 недели?» это может на самом деле произойти. Таким образом, как вы даете ответ является более важным , чем то , что есть ответ.


Мое личное мнение было бы, что прошлые проекты не очень хорошая идея здесь. То, что каждый пытается найти, - это какие творческие и коммуникативные навыки в новой области, а не просто вспомнить, как что-то было сделано в прошлом. Скорее всего, что то, что происходит в новой должности, может быть похоже на что-то из прошлого, может быть достаточно различий, что старое решение неосуществимо. Вот почему то, что может быть построено, аналогично существующему приложению, могут существовать различные настройки, которые сильно отличают решение от исходного примера.

Интервью - улица с двусторонним движением. Менеджеры и другие разработчики редко являются мастерами интервьюирования, поэтому я не уверен, что вижу смысл в том, чтобы утверждать, что они должны быть экспертами в своей области на собеседованиях. Рекрутеры, которые я мог видеть, ожидали, что знают, как проводить собеседование, но есть много плохих рекрутеров, которых можно использовать в качестве примеров того, почему это не всегда хорошая идея.

JB King
источник
2
Лучше спросить собеседника о проекте, с которым он знаком. Таким образом, вы можете увидеть, как работает их ум во время их истинного рабочего процесса. Вы можете остановить их и попросить уточнить детали, чтобы увидеть, насколько глубоко их знание их области идет. "Почему вы не использовали интерфейс в качестве параметра метода?" Затем вы, как интервьюер, должны задать правильные вопросы. Это правильно, так как собеседник находится в вашем домене ... не в их собственном.
P.Brian.Mackey
2
+1, если бы я мог: «Ключ в том, насколько хорошо вы можете поделиться своими мыслями» ... к сожалению, я считаю, что большинство как интервьюеров, так и кандидатов недостаточно в этой области.
Anon
2
«Лучше спросить собеседника о проекте, с которым он знаком. Таким образом, вы можете увидеть, как работает его ум во время их истинного рабочего процесса». На самом деле все, что нужно будет сделать, это проверить их воспоминания о проектной работе, которую они уже сделали. Интервьюеры в основном смотрят, как они будут атаковать новые проблемы.
DJClayworth
16

Я думаю, что эти вопросы могут быть очень хорошими, особенно для старших разработчиков. Они показывают, что разработчик способен перейти от большого сложного описания к реалистичной реализации. Даже с совершенно незнакомой системой вы сможете выполнить ряд интересных заданий для интервьюера:

  • Соберите требования для ответа на вопрос (например, объем)
  • Разбейте проблему на более управляемые части; возможно, идентифицировать интерфейсы или объекты, которые могут понадобиться, или разбить логику на внешний интерфейс, внутренний сервер, БД и т. д.
  • Продемонстрировать знакомство со структурой и концепциями систем такого типа, например, веб-приложений в случае Документов Google.
  • Покажите, на чем вы склонны фокусироваться, когда сталкиваетесь с проблемой проектирования (Объектный дизайн? Таблицы SQL? Шаблоны проектирования?)
  • Покажите боссу предварительный просмотр того, как будет развиваться новая система с вами, когда босс входит со спецификацией и говорит: «Что нужно сделать, чтобы построить это?»

Этот вопрос является просто версией более высокого уровня «Опишите иерархию объектов, которую вы бы использовали для этого ...» «Опишите интерфейс, который вы бы разработали для этого ...» «Разработать набор таблиц реляционных БД для этих данных ...» и т. Д., Которые будут предоставлены разработчикам младшего и среднего уровня. В разработчиках более низкого уровня интервьюер мог бы оценить долгосрочный потенциал человека для роста в компании или просто посмотреть, что он делает, столкнувшись с большой проблемой, которая может быть ошеломляющей.

Этель Эванс
источник
2
Итак, ожидаемый ответ на вопрос - это несколько UML-диаграмм, хотя бы упрощенных?
Шамим Хафиз
3
Я думаю, что упрощенный UML будет обычной частью ответа. Диаграммы сервера также могут отображаться. Главное - показать, что вас не смущает размер проблемы и что вы можете плавно перейти от расплывчатой ​​концепции к реальной архитектуре (с конкретными - не расплывчатыми - проблемами, которые необходимо решить). А потом сообщить эту архитектуру. Интервьюер также может прислушиваться к тому, следите ли вы за лучшими практиками или ищите устаревшие решения.
Этель Эванс
11

Речь идет о том, чтобы увидеть ваши мыслительные процессы в действии; они заинтересованы не в решении, а в том, как вы подходите к решению проблемы, какие вопросы будете задавать, какие проблемы вы будете определять и т. д.

Учитывая пример Документов Google, на ум приходят такие очевидные проблемы, как хранение, безопасность, масштабируемость, доступность, дизайн клиентского интерфейса, совместимость браузера и т. Д. Как бы вы разделили ответственность между сервером и клиентом? Как бы вы справились с резервным копированием? Что происходит, когда сервер выходит из строя? Что бы вы сделали с «оставленными» документами (вещи, которые не были доступны или изменены в течение длительного периода времени)?

Опять же, дело не в том, чтобы решить какие-либо из этих проблем, а в том, чтобы выявить их, обсудить их, провести мозговой штурм о том, как их решать и т. Д.

Джон Боде
источник
9

Я одна из тех виновных, которые часто задают подобные вопросы в интервью. (Кстати, я также задаю похожие вопросы об их «любимом проекте».) Я спрашиваю, потому что это то, что мы часто делаем здесь. Мы привлекаем инженеров-проектировщиков со всех сторон интерфейса, кого-то из системного инженера, кого-то из тестировщика и кого-то, кто немного знаком с клиентскими сценариями использования этой функции. Мы стоим возле доски и говорим: «Хорошо, как мы собираемся построить эту штуку?» Часто вы очень мало знаете о новой функции на тот момент и только потому, что у вас есть опыт работы с вашей частью системы, но вы все равно должны вносить свой продуктивный вклад. Это не просто гипотетическое академическое упражнение.

Что касается ответов, которые я ожидаю, возьмем, к примеру, проектирование системы для загрузки нового встроенного программного обеспечения с сервера через 20 встроенных линейных карт в центральном офисе для одновременной модернизации 5000 абонентских приставок. Предположим, что на канале между сервером и линейными картами очень мало свободной емкости.

Плохой ответ:

Хм, я бы, наверное, использовал Ethernet или что-то в этом роде.

Хороший ответ:

Насколько велико изображение, о котором мы говорим? [Около 7 МБ.] Ну, вы бы хотели убедиться, что сервис не был затронут во время загрузки. Вам понадобится дополнительная вспышка или оперативная память для хранения двух изображений одновременно. Возможно, вы захотите кэшировать изображение на своих линейных картах, чтобы избежать повторной загрузки одного и того же изображения с сервера. Будучи встроенными, ваши линейные карты, вероятно, сами имеют ограниченный процессор, поэтому вам может потребоваться сериализовать загрузки, чтобы оставить достаточно ресурсов для обслуживания. Вы хотите, чтобы какой-нибудь способ убедиться, что изображение было хорошим, и вернуться к старой версии, если она не работает. Вам понадобится какой-нибудь способ повторить попытку несколько раз и сообщить об ошибке человеку, если обновление завершится неудачно. Если у вас есть разные марки телевизионных приставок, вам понадобится какой-то способ определить, какое изображение вам нужно отправить.

Это почти дословные транскрипции двух разных кандидатов. Большинство кандидатов находятся где-то посередине, но обычно добираются до конца с небольшим побуждением, что совершенно нормально. Мы не ищем здесь следующего Эйнштейна, просто указание на то, что вы действительно можете разумно рассуждать о типах проблем, над которыми мы работаем каждый день.

Карл Билефельдт
источник
1
где ты работаешь и нужны ли тебе новые сотрудники? : D
Мэгги
1
Хотя все примеры того, что вы называете «хорошим ответом», могут быть актуальны. Вопрос заключался в том, чтобы «спроектировать систему, которая ....». Принимая во внимание, что это ситуация с собеседованием, поэтому можно ожидать, что на ответ у вас будет не более 5-10 минут, большая часть того, что вы определили, кажется сорняками для решения собеседования. Где актуальное решение в вашем "хорошем ответе"? Как только у человека есть решение «счастливого дня», он может начать рассматривать «что-если», на которое вы ссылаетесь в «хорошем ответе». Но к тому времени, я думаю, время истекло.
Данк
5

Я также задаю такой вопрос, и я согласен с большинством других ответов. Может быть, это поможет респондентам понять, ПОЧЕМУ этот тип вопроса важен? Предположим, у нас есть важное деловое решение, и для этого нам нужно создать новую систему. Если кто-то подбегает к вам и спрашивает, что нужно сделать, чтобы построить систему, которая выполняет X, вы можете дать им проницательный ответ, который предсказывает основные проблемы и необходимые ресурсы?

Младший программист понятия не имеет, с чего начать. Они не готовы начать разговор без подробной спецификации. Старший программист сразу увидит, что у этой проблемы много аспектов, и попытается решить проблему. Вам не нужно разрабатывать каждый аспект, просто определить архитектурную проблему, а затем выяснить, как ее решить.

Рассмотрим вопрос о Документах Google:

Одна интересная вещь - это сдвиговая шкала запросов, которые будут поступать. Вы не можете просто получить один сервер и развернуть на нем свой код - это большая задача. Успешный собеседник может сосредоточиться на этом и опишет типы ресурсов, которые будут необходимы, и некоторые технические проблемы при реализации в таком масштабе, когда приложение не только имеет состояние, оно разделяет состояние между несколькими пользователями.

Еще одна интересная вещь о Google Docs - это то, что несколько человек могут редактировать одновременно. Успешный собеседник сможет обсудить механизмы, позволяющие убедиться в том, что полученный документ не является мусором, и действительно хороший кандидат поймет, что различные методы синхронизации или объединения правок будут иметь большое влияние на производительность и UX. Возможно, даже обсудите варианты: в редакторе общих документов для написания кода, вероятно, следует использовать другой метод разрешения конфликтов, чем в типичном Документе Google, потому что последствия для событий, происходящих в другом порядке или имеющих немного другую структуру, различны.

Не существует единственного правильного способа создания приложения, такого как Google Docs, вам не нужно определять, что вы будете делать для каждого компромисса, но действительно здорово найти область, которая имеет интересную проблему, и четко объяснить, в чем суть сделки. может быть.

-t.

Тристан Рейд
источник
Я проголосовал, потому что вы единственный ответ, который направил свой ответ на «архитектурное» дизайнерское решение. Так как это лучшее, что вы могли бы сделать в контексте интервью для проблемы данного масштаба. Собеседник, который понимает, что архитектурное решение - это все, что может быть достигнуто, показывает, что он знает, что делает.
Данк
2

Я подозреваю, что интервьюеры хотят услышать:

Google Doc - это веб-интерфейс для текстового процессора. Пользовательские документы набираются и хранятся, и могут быть извлечены пользователем на том же или другом компьютере.

Что бы вы хотели обсудить дальше?

Затем мяч находится на площадке интервьюера. Если она хочет больше подробностей, она может спросить. Интервьюер ищет то, можете ли вы посмотреть на проблему или продукт и извлечь дизайн?

Гилберт Ле Блан
источник
1
Ответ хороший, но не думайте, что интервьюер будет доволен. Читая посты до сих пор, кажется, что такие вопросы не пользуются популярностью среди респондентов.
Шамим Хафиз
-1 @Gilbert Le Blanc - «Время разгона», определенное законом Брука в «Мистическом месяце человека», в лучшем случае делает этот вопрос глупым. Если мы знаем, что потребуется около 6 месяцев, чтобы научиться увеличивать ценность программного проекта, чего можно ожидать от «извлечения дизайна» всего за 6 часов? en.wikipedia.org/wiki/Brooks%27s_law
P.Brian.Mackey
1
@Shamim Hafiz: Исходя из вашего вопроса и комментария, я бы сказал, что этот вопрос не пользуется популярностью, потому что вам и другим трудно сузить суть вопроса. JB King ответ более полный, чем мой. Все его пункты являются верным способом сузить сферу вопросов, хотя я сначала неравнодушен к нисходящему, а затем к разъяснению требований. На простом английском языке сначала проведите аналогию, затем выделите различия.
Гилберт Ле Блан
4
Если бы я брал интервью, я не был бы доволен этим ответом. Ответ здесь просто говорит мне, что такое документы Google, что я уже знаю.
whatsisname
1
@whatisname - я думаю, что интервьюер захочет узнать ответ на вопрос (или приблизительную оценку) в контексте интервью.
Морган Херлокер
2

Для меня, если человек не начинает с определения ключевых вариантов использования / историй, то этого будет достаточно, чтобы знать, что он не подготовлен к позиции, требующей этого конкретного навыка.

После этого они должны иметь возможность придумать архитектурное решение, основанное на ключевых сценариях использования / историях. Надеюсь, они использовали какой-то систематический процесс для определения модулей, отличных от извлечения их из своих ... Я бы не ожидал гораздо большего от ситуации интервью для решения.

Тем не менее, я мог бы выбрать один из архитектурных модулей и попросить более подробный дизайн, просто чтобы посмотреть, есть ли у них некоторые навыки дизайна. Было бы также приятно видеть, что они рассматривают случаи сбоев / проблемы с производительностью. Но я подозреваю, что в этот момент мы столкнемся с временной стеной. Таким образом, я действительно не мог наказать их за то, что они не рассматривали эти вопросы, потому что осталось слишком много времени, и я думаю, что для них было бы разумным предположить, что рассмотрение каждого возможного сценария не ожидается в условиях ограниченного по времени интервью.

Замочить
источник
1

Недавно у меня было интервью, где меня попросили разработать систему управления лифтом. В основном они хотят видеть ваш подход к задаче. Если вам задают этот вопрос, они, вероятно, имеют в виду работу на очень высоком уровне. Congrats.

Майкл Браун
источник
1

Ключевым моментом является то, как вы решаете проблемы в сравнении с преимуществами решения, которое вы предлагаете, и способны ли вы справиться с большими проблемами.

Я думаю, что одна важная вещь, чтобы сделать, это задать вопросы о требованиях. Не просто делайте предположения, которые позволят вашему питомцу работать. Например, вам может случиться, что вы знаете какой-то действительно изящный метод печати документов, который вы можете попробовать описать. Но Google Docs не печатает напрямую; он создает PDF, который затем печатает клиент. Поэтому, если вы начнете с этого, вы потратите половину своего времени на решение проблемы, которая не является частью проблемы, и продемонстрировали, что вы больше заинтересованы в использовании вашей горячей технологии, чем в решении проблемы клиента.

JohnMcG
источник
0

Чтобы ответить на вопросы такого типа, вам необходимо иметь общий интерес к пониманию того, «как все работает», не только к проектам, которые вас интересуют, но и к проектам, которые, по вашему мнению, слишком далеки от вашего опыта.

Это означает чтение блогов, статей, http://www.infoq.com , Hacker News и т. Д. Даже аппаратный блеф из Coding Horror.

Несмотря на тот факт, что вы забудете большую часть прочитанного (поскольку эта информация никак не связана с вашей работой), могут быть некоторые лакомые кусочки, которые являются «семенами воображения», и крошечная доля этих семян прорастет, когда вы столкнетесь с подобной проблемой в далеком, далеком будущем.

Итак, интервьюер, возможно, заинтересован в вашей привычке читать (как часть вашего хобби) и посмотреть, есть ли у вас обычная привычка собирать семена идей из случайных мест.

rwong
источник
О, я не знаю о вас, но я смотрю гораздо лучше на разработчиков, которые формулируют проекты, основанные на фактах и ​​опыте, а не на материалах, которые они когда-то читали в блоге.
Ааронаут
@Aaronaught: конечно, реальный опыт от подобных проектов бесконечно более ценен, чем услышанные идеи. Но когда вам поручают проект в области, где у вас нет опыта, вы просто отказываетесь от этой возможности? (Предполагая, что вы сообщите работодателю, что у вас нет соответствующего опыта, и с этим у работодателя все в порядке). Если вы решите принять его, то как начать? Вы начинаете с уроков, извлеченных из других людей, других компаний и так далее. Вы не можете начать с нуля. Возможно , вы были правы downvoting меня , потому что ОП , кажется, интервью для должности старшего, но
rwong
(продолжение), пожалуйста, не стоит недооценивать важность уроков, извлеченных из других источников.
Rwong
Справедливо, может быть, голосование было незаслуженным (хотя я не могу удалить его на данном этапе). Тем не менее, я действительно не думаю, что интервьюер задаст такой вопрос, чтобы узнать о том, что вы читаете; если бы они были, они бы просто спросили, что вы читаете. Важно задавать правильные вопросы, чтобы вы узнали, как это должно работать, а не уклонялись, основываясь на разбросанных кусочках информации, которая может или не может быть связана.
Ааронаут
0

Задача такого рода вопроса - получить представление о вашем уме. Обычный вопрос, который я использую, - попросить программистов спроектировать систему, которая может имитировать PacMan.

И да, я сначала ищу варианты использования, это показывает мне, что человек думает. Затем, для многопоточности, сначала рассматривается структура данных (те, которые могут быть использованы для решения проблемы, затем более подходящие или специфичные для решения).

Это считается обязательным для старших должностей в области развития. Людям глупо и бессмысленно сидеть и отвечать на вопросы по реализации сортировки на этом уровне опыта разработчика. Системный дизайн - это то, что я ожидал бы на этом уровне.

Wile EK
источник