😵 Какие навыки проверяют на интервью систем дизайна?

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

Какие навыки проверяют:
🟠Собирать и уточнять требования и ограничения
🟠Строить разумные предположения в условиях неопределённости
🟠Предлагать варианты решений и компромиссы
🟠Проектировать решение задачи и визуализировать его
🟠Объяснять решение другому человеку так, чтобы он понял

*️⃣ Ход интервью
Часто бывает, что кандидат забывает про отсутствие общего контекста и про какие-то вещи не рассказывает, как будто это и так понятно. За это часто снижают оценку. Нужно не забывать рассказать про общую картину приложения подробнее и добавить это на схему. На секции почти никогда не дают спроектировать огромную систему. Скорее это будет пара экранов или какой-то отдельный модуль.

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

*️⃣ Какие инструменты используют?
- Draw.io
- Miro
- Whimsical
- Excalidraw

Позже мы расмотрим основные задачи и артефакты. Для подписчиков ноушена уже доступа полная статья. Также ждите там первый скринкаст с проектирование задачи по систем дизайну.

*️⃣ Полезные ссылки:
- Goals and Objectives of System Design

🔄 Главный навык в жизни (и в систем дизайне)

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

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

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

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

🚩 В FAANG'ах есть два красных флага для кандидата на собесах:
- один сдается и уходит с собеса не пытаясь задать вопросы
- второй начинает делать сразу и не уточняет дополнительные кейсы и условия

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

🫂 Как общаться с дизайнерами

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

Цели общения с дизайнерами:
🔘 Убедиться, что мы хорошо понимаем приложение
🔘 Убедиться, что дизайнер понимает приложение
🔘 Найти корнер-кейсы и выставить приоритеты функциям

❕ Конструктинвый разговор должен привести к улучшению дизайна и лучшему пониманию функции в команде

Дизайнер — наш союзник. Мы вместе улучшаем продукт. Часто нужно лучше объяснять им нашу работу, а некоторые детали вы обязательно поправите, если они приоритетные.

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

Какие вопросы помогут для улучшения дизайна:
🔵 Найти возможности для упрощения разработки, но не потери функции. Например, если дизайнер придумал свой компонент, но есть хорошая системная альтернатива, которая привычна юзеру и проще разрабатывать, то лучше ему об этом сообщить.
🟢 Напомните о разных устройствах и их размерах. Бывают темные режимы и светлые. Выбор темы внутри приложения. Телефоны и планшеты. Далеко не все дизайнеры запоминают это.
🟡 Ошибки и состояния загрузки. Дизайнеры не всегда знают какую ошибку может отдавать бэкенд или системное устройство. Лучше подсветить, что пользователь может заспамить поддержку вопросами и мы потратим деньги или упустим клиента, если правильно не сообщим ему нужную информацию
🟣 Что такое пиксель-перфект? В мобильной разработке почти нельзя достичь пиксель-перфект состояния. Есть множество устройств с разным размером экрана, ориентациями и пропорциями. Разными размерами шрифта и цветопередачей. Это все означается, что понятие “идеальный пиксель” является понятием приблизительным. Даже отрисовка теней иногда может по-разному влиять на работу приложения

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

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

Задачи на собеседовании System Design

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

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

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

Самое главное это не вопросы, а качество ответов

👀 Какие задачи встречаются?

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

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

🔘Senior:
Cледующая задача может встретиться на любой грейд, но ее гибкость и учитывание всех корнер-кейсов может решиться только сеньорами. Тут и архитектуры понадобятся, и алгоритмы, и софты:
- Спроектировать апи для работы с бэкендом. В событиях могут быть дополнительные поля
- События не должны терять данные при крэше или выгрузке приложения из памяти
- Модуль должен быть самостоятельный и максимально переиспользуемый
- Логировать события должно быть безопасно с любого потока
- Хотим отправлять в несколько аналитик сразу. Список может меняться со временем.
- У события есть приоритет: высокий, нормальный, низкий. Высокий отправляем сразу. Остальные выставляем в очередь. Низкий отправляем только когда телефон на WIFI с зарядкой

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

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

Как-нибудь разберу одну из задач и запишу воркшоп на час,полтора. Но доступен он будет сами знаете кому. Расширенная и общая статья, со всеми ресурсами, уже давно доступна подписчикам ноушена.

Интересные статьи:
- Как мы убрали секцию алгоритмов и к чему это привело
- System Design. Общие принцип прохождения интервью

‼️ Альтернативные магазины приложений уже доступны!

Apple анонсировала долгожданные изменения в политике распространения приложений для Европейского Союза

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

Уже в бете 17.4 сегодня.

😃 iOS Dev