💎 Обновление ноушена за неделю:

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

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

Что было обновлено:
⏺ Закончил блоки с Swift, UIKit для джуниров. Окончательно закрылся первый блок с первой частью вопросов
⏺ Начал писать вопросы для джунов по SwiftUI
⏺ Добавлено 7 новых задач с решениями в блок алгоритмы на собеседованиях
⏺ Добавлены техники решения задач: Два поинтера, Скользящее окно
⏺ Статья про Some and Any: разбор задач, подборка ресурсов
⏺ Виды сортировок: merge sort, insertion sort. Как sort реализована в кишках
⏺ Как проходить behavioral interview
⏺ Как вести себя на собеседованиях по алгоритмам
⏺ Добавлен блок SwiftUI
⏺ Добавлены архитектуры и топ паттернов проектирования в реальных задачах
⏺ Добавлены принципы проектирования:

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

🌿 Доступ к ноушену и ко всем материалам

📺 Напоминаю, в воскресенье у нас первый созвон в комьюнити

Проснулся утром в воскресенье и не знаешь чем заняться? Проведи утро с пользой.

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

Там я попробую разобрать:
🟣 Как развиваться разным грейдам
🟣 Как дела на рынке труда (попробую собрать аналитику вакансий и комментарии рекрутеров и менеджеров)
🟣 Стоит ли идти в иос или развиваться в другом направлении
🟣 бигтехи, стартапы или фриланг. Когда куда идти и что ожидать?
🟣 Какие компании лучший выбор для иос разраба
🟣 Когда лучше всего искать работу?
🟣как разнообразить свое развитие
🟣худшее время для увольнения
🟣советы по резюме

Все это будет подкреплено наблюдениями нанимающих менеджеров, тимлидов, хэдов и рекрутеров.

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

Разговоры будут открытые и откровенные, особенно с риском блокировки appleStore и смерти иос-разработки.

Так как это мои первые мини доклады доступ к встрече будет только для участников сообщества любого уровня

Дрейфусовская модель приобретения навыков

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

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

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

Подборборка интересных ресурсов по теме:
- Как построить матрицу компетенций с нуля
- Матрица компетенций в авито для инженеров
- iOS skills matrix

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

System Design: Сбор требований

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

В реальных задачах писать код чаще это 30-40% рабочего времени. Все остальное большая роскошь. В крупных бигтехах создаваемые инструменты будут надолго. Ими будут пользоваться множество других разработчиков. Поэтому уделять этому этапу необходимо много времени.

Почему?
🔘Хороший дизайн вашего апи будет удобен клиентам
🔘Чистый код и логичные конструкции избавят от проклятий других разработчиков
🔘Умение замечать функциональные и нефункциональные требования перед дорогой реализацией.

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

Основные этапы проектирования:
🔘 Сбор требований
🔘 Оценка нагрузки
🔘 Высокоуровневый дизайн
🔘 Компонентный дизайн
🔘 Повышение отзывчивости и отказоустойчивости
🔘 Мониторинг и алертинг
🔘 Безопасность

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

1️⃣ Сдается и отпускает руки
2️⃣ Сразу преступает молча к реализации

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

***Уточнение:** На интервью не стоит тратить много времени на сбор требований. Но на реальном проекте это один из важнейших этапов.*

Вы получаете дизайн экранов от дизайнеров или менеджеров и сразу должны задать вопрос:

*️⃣Все ли состояния экрана проработанные
*️⃣Что будет при ошибках?
*️⃣Что будет, если данных не будет хватать?
*️⃣Что будет, если нет интернета?
*️⃣Будет ли поддержка планшетов, макОС?
*️⃣Откуда берутся данные?
*️⃣Кэширование или локальное хранилище?

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

📌С чего же начать? Правильней всего будет выдержать баланс и не закопаться в деталях. Уметь быстро выявить важные требования и отсеять второстепенные. На этом этапе нужно забыть об архитектурах или выборе SwiftUI или UIKit

Лучшее решение на первом этапе - это лучше понять проблему.

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

Об этом в следующих постах.

Полная и расширенная статья с ресурсами уже доступна в ноушене

Неписанные правила: как вести переговоры с Meta*

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

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

Прежде чем вести переговоры:
1️⃣ Не говорите, что вы будете торговаться или собеседуетесь. Если вы сообщите заранее, то торги начнутся преждевременно
2️⃣ Убедитесь, что у вас есть несколько других офферов перед торгами. И не просто офферы от обычных компаний, а по статусу не меньше, с кем намечается торг
3️⃣ Если вы метите торг в крупную компанию, то подготовьте офферы заранее.
4️⃣ Будьте френдли. Налаживайте отношения с рекрутерами. Задача рекрутеров — закрыть ставку. Но это не значит что нужно на них давить и примерять роль избалованного хамла.

*Запрещенная в РФ

⚙️ Коллекции в Swift

Если вы думаете, что в iOS только три типа коллекций (Array, Set, Dictionary), то вы ошибаетесь.

Вчера в чате мы разобрали еще около 20 видов. Из которых многие очень экзотичные. А какие-то популярные:

⏺ OrderedSet — упорядоченная коллекция уникальных элементов.
⏺ OrderedDictionary — упорядоченная коллекция пар ключ-значение.
⏺ Heap — контейнер элементов Comparable, с константным доступом к min и max членам. И вставкой новых элементов с logn сложностью.
⏺ Deque — упорядоченная двухсторонняя очередь

Уже сформировали вопросы на мидла для ноушена по Swift.

💬 Техники решения алгоритмов: Скользящее окно

Продолжаю цикл постов про техники, которые упрощают написание алгоритмов.

Техника скользящего окна по реализации и сложности похожа на технику двух указателей, о которой я писал ранее.

Она используется для решения некоторых типов проблем:
⏺ Максимальная сумма подмассива размера
⏺ Минимальная сумма подмассива размера
⏺ Сумма подмассива минимального размера
⏺ Самая длинная подстрока без повторяющихся символов

Условия для понимания, что проблема может быть решена с помощью этой техники:
⏺ Мы ищем свойство, принадлежащее диапазону элементов массива (например, сумма, длина, уникальность и т. д.).
⏺ Интуитивный метод грубой силы для решения этих задач часто представляет собой встроенный цикл for/ while, требующий временной сложности в n-квадрате или n-кубе.

Когда использовать метод скользящего окна?
⏺ в задаче передаётся упорядоченная и итерируемая структура данных, вроде массива или строки
⏺ просят найти подпоследовательность в массиве/строке, самое длинное/короткое, среднее/большое/маленькое и т. д.
⏺ первым в голову приходит наивное решение со сложностью *O*(*n*2) или даже *O*(2*n*)

💎 Еще больше техник с разбором задач из собеседований тут

🌄 Подборка обязательных видосов WWDC за все время

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

Мы в комьюнити решили собрать подборку обязательных видосов (включая удаленные). Список будет пополняться, а также в будущем появятся конспекты.

Получить доступ можно тут.