Подборка мок-интервью по mobile system design

Иногда, между книгами и задачами, очень полезно посмотреть чужие видео. Так ты структурируешь свои идеи, которые отложились фрагментами. А где-то можешь и вдохновиться новыми.

Сделал подборку интересных мок-интервью:

🟣Design Story Viewer. Сторисы почти незаменимая деталь любого приложения. Поэтому вероятность, что вы когда-нибудь будете их делать — высокая.

🟣Chat App. Чат — любимая задача на интервью. В ней правда есть многое, что поможет оценить насмотренность и глубину.

🟣Design the Facebook feed. Лента встречается почти в 99%. Очень полезно посмотреть как ее проектируют сеньоры из FAANG'а

🟣Мок-дизайн приложения. Наш друг Саша Сычев из Яндекса поделился форматом интервью и какие оценки кандидата в этой секции есть в СНГ.

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

Получить это можно по скидке 💰 тут или ⭐️ тут

Цикл про System Design: Как определять требования к системе

Самый важный этап, который недооценивают многие. Что на работе, что на интервью.

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

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

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

Статьи полезны тем, кто хочет изучить или улучшить свои навыки сбора требований.

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

System Design: Методики сбора требований

Нашу компетенцию чаще оценивают только по срокам.

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

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

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

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

Чуть подробнее мы говорили об этом в посте про ресурсного инженера.

Вот несколько методик для качественных ресерчей:

🟣Интервью с заказчиками и пользователями
Не бегите сразу клепать экран. Если вы услышали мяуканье, то это не значит, что перед вами кошка. Возможно это тигр, что разорвет вам жопу. Разработка занимает чаще лишь 20-30%, а остальное время проработка требований и краевых условий.

Уточники у заказчиков чего они хотят. Как будет вести себя программа без данных или условий.

🟣Методика “5 Почему” (5 Whys)
Чаще всего многие вопросы вскрываются в процессе разработки. Но лучше бОльшую часть попытаться заранее предусмотреть. Качественный ресерч от плохого зависит насколько много инженер задал вопросов перед разработкой.

В отмеченной статье кратко объясняется как техника отлично помогает это сделать.

🟣User Story
Отличная практика ставить себя на место пользователя и видеть его сценарии. Перебирать в голове разные пути на реакции системы. Например, что будет если не оказалось интернета? Если произошла ошибка с сервера? Как онлайн получить или синхронизовать информацию?

Качественный и понятный команде ресерч — это черта хорошего инженера.

Делитесь своими методиками.

Изучаем как собирать нефункциональные требования для разработки мобильных приложений

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

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

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

Здесь одни из требований — это нефункциональные требования.

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

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

🟣Performance. Как сделать приложение более плавным, быстрым.
🟣Security. Сделать приложение более безопасным. Использовать ли HTTPS, Keychain, криптошифрование и тп
🟣Совместимость. Обсуждение на каких версиях будет использоваться приложение.
🟣Надежность. Нужен ли хэндлинг ошибок и их мониторинг.
🟣Поддерживаемость. Вопрос понятности и читаемости кода, модуляризации и CI/CD.

Интересно также почитать про лучшие практики.