🧬 Как формируется грейд после собеседований или почему технические собеседования лишь малая часть общего грейда

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

Чем глубже погружаюсь, тем больше вижу заблуждений среди обычных разработчиков и в общем медиаполе. Главное массовое заблуждение — на грейд влияет только результаты технического собеседования. На практике результаты технических интервью лишь 1/5 часть общей оценки. Давайте разберемся.

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

1️⃣. Созвон с HR. Тут все понятно, hr собирает у вас комментарии о ваших требованиях и примерно оценивает взаимный матч. Смотрит на опыт.

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

Эту секцию проводят технические эксперты, которые дают свою оценку.
⚠️ Важный момент: с ней могут не согласиться

3️⃣. После всех интервью вас оценивает нанимающий менеджер. Чаще это тимлид или, если его пока нет, руководитель тимлида. Здесь нужно понимать, что это самый важный этап. Тк, вопреки общему мнению, на ваши года опыта и задачи смотрят не только hr, но еще внимательней — ваши руководители.

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

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

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

В следующем интервью (надеюсь выйдет на неделе) мы подробнее поговорим про это

Что такое Problem Solving Skill?

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

Problem Solving Skill (навык решения задач) — это способность эффективно анализировать, структурировать и решать проблемы, используя технические, логические и аналитические подходы. В контексте FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google), этот навык является критически важным, поскольку компании ищут инженеров, которые могут справляться со сложными, неопределёнными проблемами в условиях высоких нагрузок и сложных систем.

Problem Solving оценивает:
🔘как кандидат анализирует и понимает суть задачи
🔘декомпозирует и оценивает приоритеты
🔘генерирует идеи и учитывает компромиссы
🔘реализует чистый и понятный код
🔘обрабатывает edge case'ы
🔘оценивает решения по тестированию и предлагает оптимизацию
🔘ведет хорошую коммуникацию и умеет объяснять свое решение интервьюеру

Я все сильнее считаю problem solving interview — лучшим процессом собеседований

🗿 Правила хорошего Software Developer’а

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

Пройдемся по основным требованиям для разработчиков у нас и на западе:

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

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

🟣Изучи основные фреймворки и библиотеки своего языка.
Например, если мы iOS разработчики, то очень хорошо должны владеть UIKit или SwiftUI, GCD или Swift Concurrency.
Если ты JavaScript разработчик, то должен хорошо знать React.js или Angular.

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

С развитием AI это стало в разы проще.

🟣Изучай инструменты для дебаггинга
Начни изучать инструменты своего IDE. Пойми, чем они помогают и какие их плюсы или минусы.
После выйди за пределы среды разработки и найди другие инструменты. Например, написание тестов или методологии поиска проблем.

🟣Имей навыки рефакторинга
Разбираться в чужом коде и править сложные баги чаще сложнее, чем переписать. Почти все задачи сейчас — это переписывание старых библиотек, модулей, экранов. Мало делать как было — нужно делать лучше.

🧬 Подборка задач и вопросов: Сopy-on-Write

Эту тему разбирают почти все, когда затрагивают тему управления памятью.

В этом сборнике вы наконец поймете:
🟣что такое value и reference семантика
🟣чем Copy-On-Write отличается от полноценного копирования
🟣какие задачи решаются на практике с помощью CoW
🟣многое другое

💎 Получить доступ можно на бусти и в телеграмм.

Mobile Meetup SberHealth

Привет, коллеги 👋

18 декабря в 18:00 приглашаем на предновогодний открытый митап для мобильных разработчиков в Москве 🩵

В программе доклады от:
▪️ Смирнова Кирилла, Технического лидера iOS команды, про компиляцию массивного проекта и как её готовить.
▪️Беспалова Владислава, Старшего разработчика, о процессе оптимизации аналитики в компании.

⭐️ В качестве приглашенного спикера Сычев Александр — руководитель разработки рекомендательной ленты Яндекс Go, он расскажет про будущее мобильной разработки на основе грядущих трендов.

Принять участие можно как офлайн, так и онлайн.

Узнать подробнее и зарегистироваться 🔗

👨‍🦱 Топ популярных техник для решения задач с массивами и строками

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

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

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

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

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

👨‍🦱 2. Метод скользящего окна. Используется для задач, связанных с подмассивами или подстроками, где важно анализировать последовательные элементы массива или строки.

👨‍🦱 3. Prefix Sum. создать массив prefix, где prefix[i] равно сумме всех элементов до i индекса включительно. Используется, когда нужно работать с суммами элементов подмассивов.

Эти техники очень сильно помогают улучшить навыки программирования

📺 Управление памятью в iOS: Stack, Heap, RAM

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

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

Я хочу переписать эти статьи и сделать расширенный материал. В этой статье мы изучим фундаментальные вещи связанные с управлением памятью.

В этой статье мы разберем:
🟣Что такое RAM и какие виды бывают
🟣Что такое стэк и куча
🟣Что такое Stack Pointer
🟣Сравним плюсы и минусы
🟣Какие данные хранятся в куче, а какие в стэке
🟣И многое другое

Подходящая статья, чтобы изучить глубже на выходных.

💎 Получить доступ можно на бусти и в телеграмм.

Я переделываю большой блок про память для книги. Хочется ультимативно подойди к этому вопросу. Изучить основы операционных систем, погрузиться в дебри Computer Sience, прочитать все пропозалы, посмотреть все WWDC, залезть в каждый исходник и комментарий. Для книги ожидается от 40 до 100 страниц только про память. Поэтому мой контент чуть замедлил скорость, но повысил качество.

🧠 Набор задач для закрепления популярных техник для массивов и строк

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

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

🟣 Не бегите сразу писать решение. Написание кода должно быть в последнюю очередь.
🟣Проговорите вслух условие. Много раз. Часто много проблем банально, что неправильно поняли задачу
🟣Подумайте о краевых кейсах. Обычно, во многих задачах специально спрятаны сценарии, которые должен найти кандидат
🟣Подумайте о решениях. Расскажите о них вслух. Оцените их понятность. Сгенерируйте в голове несколько и выберите лучшее
🟣Не смотрите сразу на ошибку и тест кейс, который выдает литкод. Попробуйте сами понять где могли ошибиться.
🟣Помните, ваша задача не просто сгененировать решение, копируя ответы. Вы качаете problem solving skills

Two pointers:
557. Reverse Words in a String III
917. Reverse Only Letters
2540. Minimum Common Value
283. Move Zeroes
2000. Reverse Prefix of Word

Sliding window:
209. Minimum Size Subarray Sum
1456. Maximum Number of Vowels in a Substring of Given Length
1208. Get Equal Substrings Within Budget

Prefix sum
1732. Find the Highest Altitude
724. Find Pivot Index
303. Range Sum Query - Immutable