Собеседования по проектированию фронтальных систем – окончательное руководство по подходу к ним

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

Введение

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

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

Нехватка ресурсов для фронтендеров

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

Мир фронтенда развивается быстро. Фреймворки приходят и уходят, а шаблоны выходят из моды по мере того, как мы учимся вместе как сообщество. Несмотря на быстро развивающийся фронтенд-ландшафт, компании, от стартапов до крупных технологических компаний, ищут в кандидатах определенный набор общих качеств.

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

Об этом руководстве

Цель данного руководства – предоставить основу для проведения собеседования по проектированию фронтенд-систем с учетом конкретных качеств, которые ищут компании.

В первой половине подробно рассказывается о том, что представляет собой каждый из этих качеств и почему они важны для инженеров-программистов фронтенда. Неудивительно, что эти качества выходят за рамки только процесса собеседования и области frontend. Кроме того, их можно постоянно развивать по мере продвижения по карьерной лестнице в качестве фронтенд-разработчика.

Во второй половине дается основа для подхода к собеседованию по проектированию фронтенд-систем. И описывается, как вы можете продемонстрировать каждый из этих качеств, проходя различные этапы собеседования.

К концу этого руководства вы будете обладать знаниями о том, как пройти собеседование по проектированию фронтенд-систем и подготовиться к нему, и будете вооружены следующим:

• Знать, какие вопросы можно ожидать на собеседовании по проектированию фронтенд-систем.

• Знать, какие специфические сигналы, выходящие за рамки конкретных технологий, активно ищет интервьюер, и как доказать, что они у вас есть, на протяжении всего интервью.

• Узнайте, как взять неоднозначную постановку задачи и разбить ее на управляемые фрагменты.

• Поймете эвристику для создания хороших вопросов.

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

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

Итак, давайте приступим к делу, чтобы вы смогли пройти следующее собеседование на должность дизайнера фронтенд-систем.

Что компании ищут за кулисами

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

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

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

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

Способность решать проблемы

Хорошо, капитан очевидность. Давайте разложим это по полочкам. Что это означает на практике:

1. Ваша способность глубоко понимать проблему/проблемы настолько, что вы можете четко сформулировать конкретную постановку проблемы/проблем, которые необходимо решить.
2. Ваша способность разбить проблему на более мелкие отдельные части. Так, чтобы они могли быть решены по отдельности, чтобы вы могли собрать их вместе для решения более крупной конкретной проблемы, которую вы сформулировали.

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

Мы не хотим тратить время на создание решений для несуществующих проблем или решений для неправильных проблем.

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

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

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

Технические навыки и знания

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

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

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

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

Способность довести решение до конца

До какой степени детализации мы должны все разбить? Сколько возможных решений мы должны перечислить и проанализировать?

Хотя “правильного” ответа на эти вопросы не существует. Прагматичный ответ – “достаточно, чтобы вы могли уверенно двигаться вперед с имеющейся у вас информацией”. Потому что всегда есть ограничения по времени.

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

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

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

Адаптивность

Этот атрибут затрагивает как “мягкие навыки”, так и жесткие навыки проектирования систем и фронтенд-компонентов, способных адаптироваться к изменениям. Это ваша способность реагировать на изменения в требованиях. На практике это зависит от двух вещей:

1. Не быть догматиком в отношении определенного подхода, паттерна или технологии и быть открытым для дискуссий. А также чувствовать себя комфортно, когда вам бросают вызов, не впадая в оборону. Полезно рассматривать собеседование как сотрудничество между вами и интервьюером.

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

Как для низкоуровневого проектирования API компонентов, так и для высокоуровневого проектирования внешних систем, можно многое сказать о способах достижения долгосрочной адаптивности. Это отдельная тема (поэтому следите за новостями и подписывайтесь на рассылку, чтобы узнать о будущих сообщениях на эту тему 😅).

Оперативная осведомленность

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

Несколько вопросов, которые следует держать в заднем кармане в процессе разработки

• Что здесь может пойти не так?
• Каковы конкретные режимы отказа?
• Что испытывает пользователь, когда что-то не работает?
• Что испытывает пользователь, когда бэкенд работает медленно?
• Как мы узнаем, если что-то пошло не так?
• Как мы узнаем, что то, что мы создали, успешно?
• Как мы будем обрабатывать в 100 раз больше данных на этом экране или компоненте?

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

Чувство продукта и дизайна

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

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

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

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

Некоторые примеры UX-шаблонов для размещения большего количества материалов на экране

• виртуализированный список
• постраничные таблицы
• вкладки
• вид прокрутки
• ящик
• схема “мастер-деталь
• полностраничная навигация
• модальный
• комбинированное окно
• складная секция

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

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

То, чего следует избегать

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

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

Переход сразу к решению проблемы без уточняющих вопросов.

Это, пожалуй, самая распространенная ошибка, которую допускают кандидаты как на собеседованиях по кодированию, так и по проектированию систем.

Нежелание сотрудничать

Помните, что интервьюеры оценивают ваши навыки технического общения и сотрудничества наряду с техническими знаниями.

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

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

Быть не в своей тарелке

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

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

Не говорите ерунды, если вы не уверены.

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

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

Не играть на своих сильных сторонах

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

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

Чего ожидать от интервью

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

Большинство собеседований по проектированию фронтенд-систем будет сосредоточено либо на высокоуровневом вопросе, например, “как вы собираетесь создать instagram?”, либо на более низком уровне, например, “как вы собираетесь спроектировать бесконечную прокручивающуюся ленту новостей?”.

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

• Начальное вступление и вопрос ~ 5 минут
• Понимание проблемы и сбор требований ~ 5 минут
• Фаза проектирования ~ 25 минут
• Оптимизация, адаптация, вопросы глубокого погружения. ~ 20 минут
• Специальные вопросы. ~ 5 минут

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

Создание артефактов проектирования и наращивание темпа

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

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

Эта способность – важный навык, которым необходимо обладать при работе в команде при разработке функций. Обеспечение такой структуры для команды позволяет другим предлагать свои идеи, а не просто держать их в голове. Если вы являетесь техническим руководителем в команде, то предоставление такого пространства для внесения предложений имеет большое значение.

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

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

Формат интервью

Общая постановка задачи и обзор

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

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

Примеры вопросов, касающихся проектирования на высоком уровне

• “Как бы вы разработали приложение для чата, например, Slack?”.
• “Как бы вы создали приложение для обмена фотографиями, как Instagram?”.
• “Как бы вы разработали текстовый редактор?”.

Примеры вопросов для проектирования низкого уровня

• “Как бы вы разработали бесконечную прокручивающуюся ленту новостей?”
• “Как бы вы разработали компонент combobox / typeahead?”
• “Как бы вы спроектировали прогресс-бар загрузки для API?”.

Сбор требований

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

Рекомендации по сбору требований

Лучший способ получить надежный набор требований – это задавать хорошие вопросы. Лучший способ создать хорошие вопросы – это начать с пользователей компонента или системы.

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

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

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

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

Кто является предполагаемыми пользователями этой системы?

Например, есть большая разница, если мы ожидаем, что пользователи – это сотрудники, имеющие доступ к внутренней системе с оборудования и сетей компании. В отличие от любого человека с компьютером и подключением к Интернету.

Как пользователи будут получать доступ к этой системе?

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

Что они будут делать, получив доступ к системе?

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

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

Откуда они будут получать доступ к системе?

Этот вопрос связан с сетевой стратегией и поддержкой в офлайне. Будут ли они находиться в разных округах? В метро с плохой связью? Как мы будем справляться с интернационализацией?

Как наше внешнее приложение будет доставляться пользователям?

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

Сколько ожидается пользователей?

Это открывает множество соображений о масштабе как для высокоуровневых вопросов проектирования, так и для низкоуровневого проектирования API компонентов.

При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемые модели поведения вашей системы будут от кого-то зависеть.

Как мы узнаем, что пользователи могут успешно использовать систему так, как мы задумали?

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

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

Может не хватить времени, чтобы упомянуть все соображения в часовом интервью, не говоря уже об их детальном обсуждении.

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

Обзор этапа сбора требований

На этом этапе у вас будет три основные цели, прежде чем перейти к этапу проектирования:

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

2. Определите рамки интервью. Совместно с интервьюером определите 2-3 основных варианта использования компонента или системы, на которых следует сосредоточиться на этапе проектирования.

3. По желанию вы также можете предложить план действий и набросок того, как вы планируете распределить время, отведенное на интервью, и на чем вы сосредоточитесь.

Артефактами, которые вы создадите на доске на этом этапе, будет список требований. Скорее всего, это будет список из нескольких пунктов, в котором 2-3 основных варианта использования будут выделены как основные.

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

• Пулевой список не функциональных требований и соображений.

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

Проектирование архитектуры высокого уровня

На этом этапе собеседования у вас будут основные варианты использования системы или компонента.

Здесь нет жестких и быстрых правил. Но один из способов структурирования этого этапа собеседования – подход сверху вниз. Может быть полезно начать с базовых схем, а затем, в зависимости от того, как вы предпочитаете думать о вещах, работать сверху вниз для уточнения деталей или снизу вверх.

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

Артефакты проектирования, которые вы будете создавать для высоко- и низкоуровневых проектов, обычно включают, но не ограничиваются ими:

• Высокоуровневая схема для определения проблемы и подтверждения того, что вы находитесь на одной странице с интервьюером.
• Сущности данных – например, псевдокод определения типов для сущностей данных.
• Разбивка схемы на отдельные компоненты, определение их иерархии и состава.
• API более высокого уровня, на которые опираются эти компоненты.
• Использование событий, инициированных пользователем и системой, которые взаимодействуют с сущностями данных, обеспечивающими функциональность данного сценария использования.

Руководящие принципы для высокоуровневых проектов

В процессе разработки решений для сценариев использования полезно постоянно задавать вопрос: “Что пользователь пытается здесь сделать?”, чтобы помочь сформулировать решение. Этот вопрос помогает предотвратить создание решений проблем, которые не имеют отношения к делу, и помогает сфокусироваться на продвижении решения, которое сохраняет простоту.

Когда вы практикуетесь на реальных примерах, хорошо сохранять простоту. Не нужно ничего усложнять. В большинстве случаев решения не являются принципиально новыми разработками. Достаточно хорошее решение – это то, которое решает конкретную задачу, стоящую перед вами, и вы проанализировали компромиссы и назвали все потенциальные ограничения. Это гораздо лучше, чем чрезмерно продуманное решение, которое пытается решить все и сразу.

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

Точка зрения пользователя

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

Например, при переходе от бесконечного прокручивающегося списка, когда пользователь возвращается, ожидает ли он, что позиция прокрутки будет находиться в том же месте списка, куда он вернулся?

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

Точка зрения архитекторов

На собеседовании по проектированию фронтенд-системы полезно поработать с интервьюером и сделать несколько предположений о пользователях, чтобы знать, на какие компромиссы идти в качестве архитектора системы. Всегда полезно исходить из того, что на самом деле делают пользователи.

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

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

Это случайный пример, но помните, что все является компромиссом. И то, что является “правильным” компромиссом, зависит от того, кто использует компонент или систему, которую вы разрабатываете, и как они на самом деле ее используют.

Неполный список некоторых дополнительных соображений:

• Безопасность – Как сделать приложение безопасным для конечных пользователей? Где находятся потенциальные уязвимости?
• Доступность – Как сделать систему доступной для всех типов пользователей?
• Производительность – Как обеспечить высокую скорость работы приложения? Как сохранить его быстродействие по мере добавления и изменения функций?
• Доставка – Как нам эффективно скомпоновать и передать код пользователю?
• Тестируемость – Как мы узнаем, что приложение не имеет критических ошибок и может быть уверенно изменено?
• Устойчивость – Каковы режимы отказов? Как мы можем изящно обработать ошибки, когда случается непредвиденное?
• Наблюдаемость – Как мы узнаем, что приложение работает так, как ожидается?

Точка зрения сопровождающих

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

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

В вопросах проектирования более низкого уровня это означает, что нужно подумать о том, как API может быть адаптирован со временем. Что произойдет, если мы захотим повторно использовать, скопировать или адаптировать определенные аспекты этого компонента с другим в отдельной части приложения? Позволяет ли абстракция это сделать? Насколько легко принять и использовать компонент в качестве потребителя?

Подведение итогов этапа высокоуровневой архитектуры

Ваша цель здесь – разработать решение для основных сценариев использования, определенных на этапе сбора требований. Вкратце:

1. Решайте проблему по частям. При этом конкретные сценарии использования служат отправной точкой для дальнейшей технической разбивки.

2. Чтобы начать работу, вы можете сформулировать пример использования, нарисовав простую схему, чтобы вы и интервьюер были на одной волне.
   Прежде чем остановиться на конкретном решении, вы можете спросить себя: “Что пользователь пытается здесь сделать?”. И “как выглядит решение этой задачи?”. Будьте проще.

3. Определите базовые сущности, на которые опирается сценарий использования.

4. Определите отдельные части и компоненты, которые будут использовать эти сущности.

5. Определите API более высокого уровня, которые потребуются этим частям, чтобы сделать возможным использование примера (на практике обычно это CRUD-интерфейсы).

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

Оптимизация, глубокое погружение и вопросы адаптивности

Итак, мы подошли к завершающей стадии интервью. Давайте закончим его.

На этом этапе интервью обычно переходит в фазу, когда интервьюер задает более прощупывающие вопросы. Обычно они сводятся к тому, как бы вы адаптировали дизайн для удовлетворения новых требований. Либо функциональные, например, “как мы будем поддерживать совместную работу в режиме реального времени?”, либо нефункциональные, например, “как мы будем поддерживать в 100 раз больше данных для крупных клиентов?”.

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

Вот несколько примеров вопросов, которые вы можете ожидать на этом этапе собеседования:

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

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

1. Надежное воспроизведение.
2. Сузьте круг поиска. Определите тип медлительности, например, производительность рендеринга браузера или медленная операция ввода-вывода.
3. Выявление первопричины.

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

“API бэкенда работает медленно, однако команда бэкенда не имеет возможности устранить проблему в этом квартале, что вы можете сделать на фронтенде, чтобы облегчить боль от этого?”.

Опять же, хороший способ исследовать проблемное пространство – спросить что-то о пользователе. Исходя из этого, вы можете спросить что-то вроде: “Насколько важно для пользователя немедленно увидеть последние данные?”.

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

“Теперь нам нужно поддерживать совместную работу в реальном времени, что нужно изменить на фронтенде?”.

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

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

“У нас есть требование, что клиенты должны поддерживать сторонние плагины – как должен измениться дизайн, чтобы поддерживать это?”.

Аналогично вопросу выше, вы должны сузить круг вопросов до основной проблемы, вызванной этим новым требованием, и решить ее в первую очередь.

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

Вкратце о данном этапе собеседования

На этом этапе собеседования вам будет задан оптимизационный вопрос, который либо углубляется в конкретный аспект более подробно. Или как можно изменить систему для поддержки новых сценариев использования. Производительность – популярная тема на этом этапе.

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

Применение всего этого на практике

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

Если вы хотите увидеть примеры применения этой схемы к ряду реальных проблем, вы можете подписаться на ежемесячную рассылку Frontend Mastery.