iOS проектирование
Шаблон отзыва
Цель интервью
Проверяем что кандидат умеет и понимает, как строить архитектуру
клиент-сервер или проектировать клиентское приложение.
Важно, что мы хотим проверить как кандидат двигается по процессу. Нет задачи
оценивать финальное решение, потому что за час невозможно спроектировать
идеальную систему.
Главное, как он принимает решение, какие вопросы задает, какие компромиссы
находит.
Для проведения интервью берём одну задачу из списка ниже.
Секция применяется также для оценки кандидатов на позицию TL у которых iOS
разработка - основной технический профиль.
Как определить уровень кандидата:
Ответы уровня Начальный
Может спроектировать систему «в лоб»:
●​ Описывает работоспособную, но не масштабируемую систему
●​ Не пытается собрать требования, работает с тем, что дали
●​ Не предвидит потенциальные проблемы предложенного решения
●​ Про потенциальные проблемы или не думает, или думает, но не может
предложить решения
●​ Не может аргументированно обосновать выбор фреймворка / технологии
Ответы уровня Средний
Может спроектировать условно масштабируемую систему:
●​ Закладывает основу для будущих доработок
●​ Предвидит потенциальные проблемы предложенного решения
●​ Может объяснить, в чем преимущества и недостатки фреймворков /
подходов
●​ Думает про производительность и оптимизацию своего решения на основе
новых данных
●​ Предлагает стратегии тестирования и сбора ошибок
Ответы уровня Продвинутый
Может спроектировать масштабируемую систему:
●​ Требования те же что и у среднего уровня, плюс:
●​ Предвидит потенциальные проблемы предложенного решения, предлагает
пути разрешения проблем или принимает риски
●​ Сам «ведет» беседу, по своей инициативе узнает требования бизнеса. Если
бизнес чего-то не знает, делает разумные допущения
●​ Собирает функциональные и нефункциональные требования к системе
●​ Думает про корнер-кейсы, предлагает решения
●​ Учитывает особенности и слабые места конкретных продуктов
(фреймворки / библиотеки)
Подготовка к проведению интервью
До проведения интервью HR должен рассказать, как будет проходить секция и
сообщить следующую информацию:
Понадобится использовать онлайн-доску и шарить экран. Рекомендуемые
инструменты: доска для рисования Miro, Whimsical или Draw.io или другой
подходящий инструмент. Желательно зарегистрироваться заранее (если это
необходимо) и немного освоиться с инструментом до собеседования.
Интервью проходит в формате беседы, где интервьюер - заказчик. Он даёт
задание и отвечает на вопросы кандидата, предоставляя информацию о
требованиях, условиях и ограничениях.
Мы ожидаем увидеть архитектурную схему решения. Начинаем с простого
варианта, если останется время, то поговорим про расширение и усложнение
требований и адаптацию решения под них.
Можно использовать в качестве нотации диаграмму классов UML но в целом
схему можно нарисовать в свободном формате, это не влияет на итоговый
результат. Можно даже накидывать интерфейсы и комментарии в IDE или
текстовом редакторе, если кандидату так проще и в итоге получится понятно для
интервьюера.
Как пользоваться анкетой
●​ Создать себе копию этого шаблона
●​ Вести протокол ответов интервьюера с пометками затрат времени по
этапам решения
●​ Прикрепить графический результат решения, полученный кандидатом
●​ Экспортировать отчёт в pdf и передать файл HR
Ход интервью
Шаг 1. Сбор требований (5-10 мин)
Даем на вход кандидату задачу и ожидаем, что кандидат не бросится в бой, а
соберет требования, обсудит с интервьюером корнер-кейсы и потом приступит к
поставленной задаче.
Артефакты:
●​ Выводы по блоку
●​ Собранные требования
Шаг 2. Высокоуровневая архитектура (10-15 мин)
Просим кандидата построить верхнеуровневую архитектуру приложения.
Ожидаем:
●​ Схему HL- архитектуры и взаимодействие между компонентами
●​ Поговорить про компоненты зачем они нужны и как с ними будем
работать, аргументировать выбор решения
Артефакты:
●​ Выводы
●​ Схема приложения
Шаг 3. Погружение (30 мин)
Берем самый сложный кусок приложения, который должен держать большую
нагрузку, отвечать быстро и уметь масштабироваться и начинаем его
проектировать детально (в отдельной от HL-архитектуре схеме).
Артефакты:
●​ Выводы
●​ Максимально подробная схема разрабатываемого блока
Инструменты
●​ Для ведения протокола
●​ Для онлайн-кодинга с подсветкой или исполнением
●​ Онлайн whiteboard: Draw.io, Miro, Whimsical или Excalidraw
Приведенные ниже задачи являются базовыми для решения на секции, но
выбрать нужно только одну.
Рекомендуемые задачи
Проектирование библиотеки для аналитики (hard)
Проектирование библиотеки для аналитики
Спроектировать библиотеку для отправки пользовательской аналитики.
Библиотека для нашего приложения, но должна быть возможность подключить
её в любой модуль или отдельное приложение. В первую очередь хотим
подключить свою inhouse аналитику, для которой уже есть бэкенд.
Далее нужно предложить кандидату приступить и предоставить ему
возможность собрать требования и определить ограничения. То есть требования
рассказываем в ответ на вопросы.
Требования
Условия и ограничения
●​ Бэкенд умеет принимать агрегаты
Функциональные требования:
●​ В событиях есть общие обязательные поля: id события, timestamp
●​ В событиях могут быть дополнительные поля (как обязательные, так и
нет), с типами: строка, число, булево значение
Нефункциональные требования:
●​ Мы не должны терять события при крэше или выгрузке приложения из
памяти
●​ Логирование не должно существенно увеличивать сетевой трафик
приложения или сильно нагружать батарею. Хорошо, если кандидат
предложит свой вариант. Например, отправлять пачку эвентов по времени
или по количеству событий.
●​ Логировать события должно быть безопасно с любого потока
Усложнения:
●​ Хотим отправлять в несколько аналитик сразу. Список может меняться со
временем.
●​ У события есть приоритет: высокий, нормальный, низкий.
●​ Высокий отправляем сразу
●​ Нормальный пакуем в батч
●​ Низкий отправляем только когда телефон на WIFI с зарядкой
Оценка уровня
Сбор требований
Начальный
●​ Не пытается собрать требования, работает с тем, что дали
Средний
●​ Узнал про типы событий и полей в них
●​ Узнал про API и возможности бэкенда
●​ Может разделять требования на функциональные и нефункциональные
●​ Функциональные: узнал какие фичи мы хотим, гарантии доставки
●​ Не функциональные: узнал про нагрузку, кол-во событий
●​ Видит важное в системе, не заморачивается из-за деталей
●​ Задал вопросы для уточнения требований
●​ Закрыл все неопределенности
Продвинутый
●​ Сам «ведет» беседу, по своей инициативе узнает требования бизнеса
●​ Предлагает нам, как заказчикам решения, компромиссы, чтобы двигаться
дальше
●​ Задал вопросы по граничным случаям. Например, когда нет сети или
плохой интернет
●​ Спросил про количество аналитических систем, то есть подумал про
расширяемость
Схема
Начальный
●​ Спроектировал модель данных по требованиям
●​ Уточнил про backend, нужно ли его отображать на схеме
●​ Отобразил client на схеме, по ней понятен основной флоу логирования и
отправки события
Средний
●​ Сделал схему: не перегруженную деталями, но по которой всё понятно:
●​ Бизнес логика
●​ DI
●​ Поток данных на клиенте
●​ Гарантия отправки
●​ Обработка ошибок и граничных кейсов
●​ Смог выделить основные блоки на схеме и поток данных между ними
Продвинутый
●​ Отобразил все части фичи, backend + frontend
●​ Схема получилась модульной. Соблюдаются принципы SOLID
Погружаемся в реализацию
Начальный
●​ Не смог описать детали реализации
●​ Реализация абстрактная, оторвана от платформы
Средний
●​ Упоминал архитектурные паттерны, которые можно использовать
●​ Классы разделены по SOLID
●​ Учел все ограничения
Интеграция в приложение
Начальный
●​ Сделал список необходимых тестовых сценариев
Средний
●​ Добавил документацию
●​ Предложил example проект
Продвинутый
●​ Предложил метрики для мониторинга стабильности. SLA
●​ Предложил АБ или фичафлаг
Расширяемость
Начальный
●​ Система получилась не расширяемой. Пришлось бы менять большую
часть системы для удовлетворения новым требованиям.
Средний
●​ Для поддержки новой фичи пришлось доработать меньшую часть
библиотеки
Продвинутый
●​ Для поддержки новой фичи пришлось менять только API, который виден
клиентам
Экран статистики (medium)
Экран статистики
Спроектировать модуль в приложении, который занимается отображением
статистики расходов на объявления и статистики по всем объявлениям за
каждый месяц. Дизайн приведен ниже. Контракта с бэком нет, его нужно
придумать самому.
Далее нужно предложить кандидату приступить и предоставить ему
возможность собрать требования и определить ограничения. То есть требования
рассказываем в ответ на вопросы.
Функциональные требования
●​ Экран должен быть максимально расширяемым и гибким. Хотим
управлять количеством вкладок и набором данных, которые он
отображает с бэка.
●​ Данные, которые отображаются на вкладке, относятся к выбранному
месяцу на графике. При переключении месяца, данные должны
изменяться. Ситуации когда месяц не выбрал быть не может.
●​ При переключении месяца на одной вкладке, он должен переключиться на
всех остальных
●​ Должен быть реализован pull-to-refresh, который обновляет все данные,
для всех вкладок, а не только для текущей
●​ Графики могут приходить не для каждой вкладки, но временной период
совпадает на всех графиках
●​ Если произошла ошибка, а данные не были закешированы - показываем
плейсхолдер и кнопку с перезагрузкой
●​ Если произошла ошибка, а старые данные были - показываем сообщение
об ошибке
●​ Компонент с графиком уже есть, он умеет переключать вкладки, из него
можно получить выбранную вкладку
Нефункциональные требования:
●​ Стоит подумать про уменьшение сетевого взаимодействия, тк интернет
может быть нестабильным
Оценка уровня
Сбор требований
Начальный
●​ Не пытается разобраться, готов сразу проектировать модуль
Средний
●​ Выяснил функциональные требований, закрыл неопределенности
Продвинутый
●​ Выяснил, какие еще данные и в каком виде могут отображаться, чтобы
заранее заложиться и для новых типов ячеек не пришлось бы обновлять
приложение
Схема
Начальный
●​ Один модуль
●​ Контракт с бэкендом нерасширяемый, привязанный к дизайну
Средний
●​ Создал два модуля: контейнер, который управляет созданием и
переключением вкладок и модуль с коллекцией ячеек
●​ Понял, что нужно строить страницу с данными исходя из колонки в
графике
●​ Описал модели данных, которые нам нужны:
●​ Вкладка
●​ Массив данных для каждого столбца в графике
●​ Описал интерфейс взаимодействия между вкладками, для синхронизации
выбранного месяца на графике
●​ Описал полный путь данных от бэка до ячейки
●​ Описан DI
Реализация
Начальный
●​ Все в одном модуле, сложно переиспользовать элементы в других местах
приложения, невозможно менять порядок данных без внесения изменения
в код приложения
●​ Код сильно связан, взаимодействие между вкладками реализовано на
знании вкладок друг о друге
Средний
●​ Контейнер загружает данные, на основе которых строятся экраны с
вкладками.
●​ У вкладки есть фабрика ячеек, которая отдает компоненты на основе
входящих данных.
●​ Описано обновление вкладки при изменении месяца на графике
●​ Описан механизм синхронизации выбранного месяца между всеми
вкладками через общий контейнер, который управляет вкладками
●​ Выделил основные типы ячеек, которые могут использоваться