Большая подборка вопросов и задач на хештаблицы

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

В подборке:
🟣Какие структуры данных в Swift используют хештаблицы
🟣Как Swift помогает решить проблему коллизий: Hashable, Equatable, hasher, hashValue
🟣Решение задач в реальной практике и на собесах
🟣Как сделать кастомную хештаблицу

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

Сосредоточьтесь не на задаче, а на проблеме, стоящей за задачей

Мы продолжаем копать в сторону Software Engineer'инга.

Bruno Rocha из Spotify поднял популярную тему постановки задач. Как найти виноватого между инженером и продактом?

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

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

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

Новые форматы собесов System Design. Что не так с текущими собесами в снг?

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

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

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

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

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

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

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

🟣задач должно быть больше. У некоторых компаний всего 3-4 задачи в базе, которые легко опять же сливаются всякими паровозиками и разбираются рейдами буквально за пару недель. Добавьте в базу 10-15 задач

🟣минимализация повторов. В каждой задаче должно быть по 2-3 варианта для вариативности. Так сложнее зазубрить. Яндекс и FAANG'и также делает с алгоритмами. Вроде задача из литкода, но немного изменена. Это очень эффективная защита.

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

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

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

Подборка ред флагов от рекрутеров фаанга и не только

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

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

Кстати, скоро для подписчиков бусти выйдет крутой материал на 2 часа с руководителем Яндекса. Все о собесах, красных флагах, резюме, алгоритмах, развитии, софтах и хардах. Один из полезнейших выпусков.

Ссылки:
- Recruiters: what are some non-obvious candidate red flags
- Candidate Red Flags: What Recruiters Should Watch Out For
- Ред-флаги в резюме ИТ-специалистов: топ ошибок глазами рекрутеров

💎 Продвинутый System Design: Logger

Логирование — одна из важных суперспособностей программиста. Более 50% задач у программиста — поиск багов и других дефектов.

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

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

В этой статье я к своему запроектированному решению также:
🟣дал код
🟣разобрал основные сущности
🟣дал комментарии
🟣Ожидаемые ответы на джуна, мидла, сеньора.

Такие статьи дают лучшую усваемость материала


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

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

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

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

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