И еще.

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

⏺ Сейчас я буду много писать про system design. Может быть даже сниму видео-скринкаст. Это больше уровень для сеньоров
⏺ Дальше я буду делать контент по SwiftUI. Там и сам хочу развиться наконец-то. Ну и фидбэк получить от топ спецов. Будет роадмап и тоже скринкасты
⏺ Дальше алгоритмы. У меня есть большой опыт прохождения и проведения алгосекций. Основы и то, как они помогают на работе или как оценивают разные компании на собесах
⏺ На днях я сделаю в ноушене подборку ресурсов и книг по программированию, софтам и жизни. Тут будет топ от библиотек крупных компаний, крутых спецов и бизнесменов
⏺ Как проходить интервью в FAANG
⏺ VR
⏺ Мнение экспертов как создавать окупаемые продукты. Бизнес-мышление в ит
⏺ Аналитика от СЕО, хэдов и диров как повышать свою зарплату
⏺ Нейросети

✅ Цели и уровни интервью System Design

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

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

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

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

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

🟠Миддл
- Может спроектировать среднюю по масшабированию системы
- Задумывается о тестировании и логировании ошибок
- Думает о перфомансе и оптимизации
- На каждое свое решение может найти как плюсы, так и минусы
- Может заложить основу для будущих доработок

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

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

Полезные ссылки:
- Как подготовиться к собеседованию по System Design мобильному разработчику
- System Design for mobile interview
- A Simple Framework For Mobile System Design Interviews
- Step by Step Guide to Succeed in Mobile System Design Interviews

Стандарты iOS-проекта компании Bottle Rocket

Очень крутой гит-репозиторий с лучшими практикам и рекомендациями. Ее сделала одна из компаний для разработки мобильных приложений. Каждые рекомендации разделены на секции:
⏺ Accessibility
⏺ Архитектура
⏺ Управление ветками гита
⏺ Управление зависимостями
⏺ Структура проекта и многое другое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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