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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-t.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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