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

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

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

На первом созвоне коммьюнити я также немного попытался разобрать этот вопрос. В своем докладе хотел разобрать тему оценки спецов. В этом мне помог доклад Саши Сычева, 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 очень информативные. В них тонны ценой инфы. Но далеко не у всех есть время их смотреть, а еще важно обсудить и понять. Часто бывает, что одного просмотра мало и непонятно.

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

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