💎 Закончил первый блок вопросов для собеседований на джунов

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

📺 ~80 вопросов с ответами
📺 ~30 задач с объяснениями
📺 ~50 ресурсов и ссылок для изучения

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

Поэтому было решено сделать еще 2-3 части для джуниорова и других грейдов.

Нельзя объять необъятное, но мы попробуем.

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

🌄 Опрос пройди еще раз.

Привычки великих инженеров

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

Тезисно о чем статья:
⏺ Обучайтесь не только в коде. Часто как разработчик вы будете писать код лишь 20% времени.
⏺ Получайте удовольствие от работы. Тут все понятно. Даже мой канал старается искать лучшее в программировании и любить это ремесло.
⏺ Копайте глубже. Могу сказать по-своему опыту в бигтехах, что многие разработчики утопают в абстракциях и многие их навыки атрофируются. Они не хотят знать или забывают как работают внутри многие вещи, легко деградируя как спецы.
⏺ Развивайте системное мышление. Нужно не только понимать кишки, но и обширно видеть работу систем за границами своих ответственностей, платформ.
⏺ Технический детокс. Не забывайте изучать реальный мир и отдыхать от компа
⏺ Всегда формируйте свою базу знаний и ищите разные подходы к решению задач. С годами чужие мнения слабеют и у вас появляются свои взгляды на решение проблем
⏺ Делайте простыми сложные вещи. Эта идея также впитана в мой канал. Если вы не можете объяснить это просто, значит, вы недостаточно хорошо это понимаете

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

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

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

Что было обновлено:
⏺ Закончил блоки с 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

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

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

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

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