Перейти к основному содержимому

Собеседование Go-разработчика глазами нанимателя | GoGetPodcast №4

· 37 мин. чтения
Николай Тузов — Golang
Николай Тузов — Golang

Сегодня мы разберём расшифровку группового интервью-дискуссии, в которой опытные разработчики, тимлиды и технические руководители обсуждают актуальные проблемы найма в IT. Участники спорят о зарплатных ожиданиях кандидатов, частоте смены работы, необходимости алгоритмических собеседований, оценке бэкграунда (DevOps, embedded, другие языки программирования) и роли возраста и образования при приёме на работу. Дискуссия раскрывает разные подходы к фильтрации кандидатов — от жёстких формальных критериев до гибкой оценки потенциала и культурного соответствия.

Вопрос 1. Какова типичная структура технического собеседования, какие секции используются, с какой целью и почему?​

Таймкод: 00:05:37

Ответ собеседника: Правильный. Выделяет три типа собеседований. Первый — когда компания берёт человека под конкретную задачу на конкретную должность, нужно найти того, кто лучше всего подойдёт, как лампочка к патрону. Это самый хардкорный вариант. Второй — когда большая компания берёт человека про запас или под несколько отделов, собеседуют потоком, а потом распределяют. Третий — когда вообще неизвестно, зачем беседуют человека, это когда крупная компания спускает задание сверху, а нанимающий менеджер не понимает, что спрашивать. Сам проводит собеседования по опубликованному опроснику с системой оценки, который хорошо выявляет неквалифицированных кандидатов, коррелирует с квалификацией на уровнях junior и senior, но слабо различает middle и senior.

Правильный ответ:

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

1. Скрининг с HR / рекрутером (15–30 минут)

Цель: быстрая фильтрация кандидатов, которые заведомо не подходят по «мягким» критериям.

На этом этапе проверяется:

  • Соответствие ожиданий по компенсации бюджету компании.
  • Мотивация и причины смены работы.
  • Наличие релевантного опыта на уровне «да/нет».
  • Готовность к формату собеседований (онлайн/офлайн, количество раундов).
  • Визовые и релокационные ограничения.

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

2. Технический скрининг (30–60 минут)

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

Форматы:

  • Онлайн-тест на платформах (HackerRank, Codility, TestDome) — 1–2 алгоритмические задачи за 30–60 минут.
  • Звонок с техническим специалистом — вопросы по языку, базовым структурам данных, простые задачи на кодирование в реальном времени.
  • Take-home assignment — небольшое задание домой на 1–3 часа.

Для позиций junior и middle этот этап часто является единственным техническим фильтром. Для senior-позиций он менее информативен, поскольку проверяет только базу.

3. Глубокое техническое интервью (60–120 минут)

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

Типичные подсекции:

А. Алгоритмы и структуры данных Проверяется умение выбрать подходящую структуру данных, оценить сложность решения, написать корректный код на доске или в онлайн-редакторе. Для senior-позиций акцент смещается с «решить задачу» на «объяснить trade-offs разных подходов».

Б. Проектирование систем (System Design) Актуально для middle+ и senior. Кандидату предлагается спроектировать распределённую систему (URL-shortener, chat, rate limiter и т.д.). Оценивается:

  • Умение собирать требования и определять scope.
  • Знание паттернов масштабирования (шардирование, репликация, кэширование).
  • Понимание компромиссов (consistency vs. availability, latency vs. throughput).
  • Способность рассуждать о нагрузке и ёмкости.

В. Вопросы по языку и экосистеме Для Go-разработчика это может включать:

  • Модель памяти, горутины, каналы, планировщик.
  • Работа с контекстом, обработка ошибок.
  • Паттерны конкурентности и их ограничения.
  • Инструменты экосистемы (pprof, race detector, go vet).

4. Интервью на культурное соответствие / поведенческое (30–60 минут)

Цель: оценить, насколько кандидат впишется в команду и культуру компании.

Проверяются:

  • Коммуникативные навыки и умение работать в команде.
  • Отношение к конфликтам и сложным ситуациям.
  • Способность признавать ошибки и учиться на них.
  • Лидерские качества (для senior-позиций).

Часто используется методология STAR (Situation, Task, Action, Result) для структурирования ответов.

5. Интервью с менеджером / руководителем команды (30–45 минут)

Цель: двусторонняя оценка — менеджер оценивает кандидата, кандидат оценивает команду и менеджера.

Обсуждаются:

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

Три модели найма, описанные собеседником, действительно существуют:

Модель 1: «Лампочка к патрону» (hire-to-role) Самая целенаправленная. Компания знает, что нужно, и ищет максимально подходящего кандидата под конкретную задачу. Собеседования максимально приближены к реальной работе. Это наиболее эффективная модель с точки зрения качества найма, но она требует вовлечённости команды и не масштабируется.

Модель 2: Поточный найм (batch hiring) Крупные компании нанимают потоком, а потом распределяют по командам. Собеседования стандартизированы, но менее специфичны. Риск — кандидат может попасть не в ту команду. Преимущество — масштабируемость процесса.

Модель 3: «Спущенное сверху» задание Наименее эффективная модель. Менеджер не понимает, кого ищет, и следует формальному опроснику. Такие процессы хорошо отсеивают совсем слабых кандидатов, но плохо различают уровни middle и senior, поскольку не проверяют глубину экспертизы и способность к проектированию.

Почему структура важна:

Хорошо выстроенный процесс собеседований решает несколько задач одновременно:

  • Минимизирует вероятность ошибочного найма (false positive) и ошибочного отказа (false negative).
  • Создаёт предсказуемый опыт для кандидата, что влияет на бренд работодателя.
  • Позволяет сравнивать кандидатов объективно через стандартизированные критерии оценки.
  • Распределяет нагрузку: не каждый интервьюер должен проверять всё.

Вопрос 2. Какой подход к проведению собеседований используется в Lamoda?​

Таймкод: 00:18:39

Ответ собеседника: Правильный. Нанимают потоками, нет специфики найма под конкретный проект. Техническое собеседование всегда проходит по шаблону, потому что нужен чёткий структурированный фидбэк, чтобы люди из команды, читая отзыв, понимали, что спрашивали и какие ответы ожидали. Собеседование делится на четыре части: 1) 10 минут на рассказ о прошлых проектах — позволяет определить понимание человеком того, что он делал, его мотивацию, глубину знаний; 2) задачки на алгоритмы и структуры данных — от простых к сложным, уровень закапывания зависит от уверенности кандидата; 3) вопросы по языку и технологиям — жёстко спрашивают про транзакции, уровни изоляции, индексы, потому что это коррелирует с микросервисной архитектурой; 4) вопросы от кандидата — по ним тоже можно многое понять о кандидате. Подчёркивает, что оба этапа — хардовая часть и свободная беседа — одинаково важны. Также Lamoda иногда собеседует PHP-разработчиков с целью переучивания на Go, при этом важно не знание PHP, а понимание программирования в целом.

Правильный ответ:

Описанный подход Lamoda — это зрелая модель поточного найма с сильным акцентом на стандартизацию и воспроизводимость результатов. Разберём каждый элемент подробнее.

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

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

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

Структура собеседования в Lamoda:

Секция 1: Рассказ о прошлых проектах (10 минут)

Эта секция выполняет несколько функций одновременно. Во-первых, она «разогревает» кандидата и снижает стресс. Во-вторых, она позволяет интервьюеру быстро оценить уровень кандидата и адаптировать сложность последующих вопросов.

На что обращают внимание:

  • Способность кандидата объяснить архитектуру проекта на разных уровнях абстракции.
  • Понимание принятых решений и их последствий («почему выбрали PostgreSQL, а не MongoDB?»).
  • Глубина владения технологиями — кандидат говорит поверхностно или может объяснить внутреннее устройство?
  • Мотивация — чем кандидат гордится, а что считает ошибкой.

Секция 2: Алгоритмы и структуры данных

Адаптивный подход «от простого к сложному» — это хорошая практика. Он позволяет:

  • Не демотивировать junior-кандидата сразу сложной задачей.
  • Точно определить потолок кандидата — до какого уровня сложности он может решать задачи.
  • Оценить не только результат, но и процесс мышления.

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

Секция 3: Вопросы по языку и технологиям

Акцент на транзакциях, уровнях изоляции и индексах — это не случайный выбор. В микросервисной архитектуре эти знания критически важны, потому что:

  • Каждый сервис обычно имеет свою базу данных (database per service).
  • Распределённые транзакции — одна из главных сложностей микросервисов.
  • Понимание уровней изоляции помогает избежать трудновоспроизводимых багов.
  • Умение работать с индексами напрямую влияет на производительность.

Секция 4: Вопросы от кандидата

Эта секция недооценена многими компаниями. Качество вопросов кандидата действительно многое говорит о нём:

  • Опытный кандидат спрашивает о технических вызовах, архитектурных решениях, процессах.
  • Слабый кандидат может не задать ни одного вопроса или спросить только про зарплату.
  • Вопросы о code review, CI/CD, мониторинге показывают зрелость кандидата.

Переучивание PHP-разработчиков на Go:

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

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

Вопрос 3. Как справиться со страхом перед собеседованиями, даже если есть опыт и знания?​

Таймкод: 00:29:34

Ответ собеседника: Правильный. Считает, что страх собеседований происходит от неправильного позиционирования. Нужно воспринимать собеседование не как экзамен, а как возможность узнать о компании. Компания заинтересована в найме — она уже потратила деньги на организацию собеседования (отвлечение людей, поиск кандидатов, рассылка приглашений). Компания старается получить максимум информации о кандидате, чтобы нанять его, а не выгнать с позором. Любое интервью стоит денег компании, поэтому она заинтересована в успехе. Также отмечает, что интервьюер тоже испытывает стресс, и опросник помогает ему не забыть вопросы и структуру. Если собеседование прошло плохо — это не конец, можно пойти в другую компанию. Среди программистов нет безработицы — если не берут в одну компанию, возьмёт другая. Не стоит задирать планку зарплатных ожиданий — если человек долго не может найти работу, возможно, его ожидания завышены относительно его уровня. Важно также учитывать частоту смены работы — 8 мест работы за 8 лет вызывает вопросы у работодателей, так как это сигнал о рисках.

Правильный ответ:

Страх перед собеседованиями — это распространённое явление, которое затрагивает даже опытных разработчиков. Разберём причины и способы борьбы с ним системно.

Почему мы боимся собеседований:

Когнитивное искажение — мы воспринимаем собеседование как ситуацию, где нас «оценивают» и «судят». Это создаёт асимметрию: кажется, что интервьюер имеет власть, а кандидат — нет. На практике это не так.

Смена перспективы: собеседование — это двусторонний процесс

Собеседование — это не экзамен, а взаимная оценка. Компания оценивает кандидата, но и кандидат должен оценивать компанию. Вопросы, которые стоит задать себе:

  • Хочу ли я работать с этими людьми?
  • Интересны ли мне технические задачи?
  • Соответствует ли культура компании моим ценностям?
  • Есть ли возможности для роста?

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

Экономика найма: почему компания заинтересована в вас

Собеседование — это дорогой процесс для компании. Расходы включают:

  • Время рекрутера на поиск и скрининг кандидатов.
  • Время технических интервьюеров (обычно 2–4 человека на каждом раунде).
  • Административные расходы: планирование, координация, запись фидбэков.
  • Упущенная выгода: интервьюеры не пишут код, пока проводят собеседования.

По различным оценкам, стоимость одного технического собеседования для компании составляет от 2000 до 5000 долларов с учётом всех косвенных расходов. Компания заинтересована в том, чтобы вы прошли — это означает, что инвестиции окупились.

Интервьюер тоже нервничает

Многие кандидаты не осознают, что интервьюер тоже испытывает стресс:

  • Он боится пропустить хорошего кандидата (false negative).
  • Он боится пропустить плохого кандидата (false positive).
  • Он боится выглядеть некомпетентным перед коллегами.
  • Он боится, что кандидат даст плохой отзыв о компании.

Структурированные опросники и чёткие критерии оценки — это не только для кандидата, но и для интервьюера. Они помогают снизить субъективность и стресс.

Практические советы по снижению страха:

1. Практика на реальных собеседованиях Пройдите 3–5 собеседований в компании, которые вам не очень интересны. Это даст вам опыт без высоких ставок. После этого собеседования в «целевых» компаниях будут восприниматься гораздо спокойнее.

2. Подготовка снижает тревожность Когда вы знаете материал, страх уменьшается. Подготовьтесь к типичным вопросам по Go, алгоритмам, базам данных. Чем лучше вы подготовлены, тем увереннее будете себя чувствовать.

3. Рефрейминг неудачи Если собеседование прошло плохо — это не катастрофа. Это опыт. Рынок IT достаточно большой, и отказ в одной компании не означает, что вы плохой разработчик. Возможно, просто не совпали ожидания или формат.

4. Реалистичные зарплатные ожидания Если вы долго не можете найти работу, стоит критически оценить свои ожидания. Возможно, они завышены относительно вашего текущего уровня. Это нормально — корректировать ожидания на основе обратной связи рынка.

5. Стабильность в резюме Частая смена работы (например, 8 мест за 8 лет) вызывает вопросы у работодателей. Это сигнал о рисках: компания инвестирует в адаптацию нового сотрудника, и если он уйдёт через год, инвестиции не окупятся. Старайтесь задерживаться в компаниях минимум на 1.5–2 года, если это возможно.

Вопрос 4. Какие зарплатные ожидания соответствуют разным уровням разработчиков на рынке?​

Таймкод: 00:51:53

Ответ собеседника: Правильный. Приводит модель оценки кандидатов по приносимой пользе компании. Junior — человек, который приносит убыток: ему платят 200 тысяч, а он делает задачи на 150 тысяч, то есть минус 50 тысяч с каждого джуна. Middle выходит в ноль — платят 300 тысяч, задачи делает на 300 тысяч. Senior кормит компанию — платят 500-700 тысяч, а он приносит в компанию миллион. Отмечает, что прибыльность сеньоров увеличивается, но одновременно повышаются требования: раньше нужен был middle за 300, теперь нужен middle за 400; раньше нужен был junior за 200, теперь нужен junior за 300. Многие кандидаты, которые 3-5 лет назад вошли в индустрию и не росли, теперь оказываются за бортом — уровень воды поднялся, а они остались на месте. Конкретные цифры: junior — около 200 тысяч, middle — 250-350 тысяч, senior — от 300 и выше. Подчёркивает, что оценивать человека надо не по деньгам, а по его актуальности и способности решать задачи компании. Зарплата зависит от внутренних градаций компании, и человек за 300 может принести больше профита, чем человек за 200. Также отмечает, что первые полтора года в компании человек работает на зачётку (адаптируется), а потом зачётка работает на него (репутация предыдущих мест работы помогает в трудоустройстве).

Правильный ответ:

Описанная модель «приносимой пользы» — это фундаментальный принцип, который лежит в основе любой системы компенсации. Разберём его подробнее и дополним контекстом.

Экономика найма: модель приносимой ценности

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

Junior-разработчик

Junior — это инвестиция в будущее. Первые 6–12 месяцев он приносит отрицательную ценность:

  • Ему нужно время на адаптацию (onboarding).
  • Его код требует тщательного code review.
  • Он задаёт много вопросов, отвлекая коллег.
  • Он может допускать ошибки, которые потом приходится исправлять.

По разным оценкам, полная адаптация junior-разработчика занимает 3–6 месяцев, а выход на полноценную продуктивность — до 12 месяцев. Компания сознательно идёт на эти расходы, рассчитывая, что junior вырастет в middle.

Middle-разработчик

Middle — это «рабочая лошадка» индустрии. Он:

  • Самостоятельно решает большинство задач.
  • Требует минимального руководства.
  • Может менторить junior-разработчиков.
  • Понинимает бизнес-контекст и может предлагать решения.

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

Senior-разработчик

Senior — это множитель команды. Его ценность не только в том, что он сам делает, но и в том, как он влияет на команду:

  • Проектирует архитектуру, которая позволяет команде двигаться быстрее.
  • Принимает технические решения, которые экономят ресурсы компании.
  • Менторит middle и junior, ускоряя их рост.
  • Предотвращает дорогостоящие ошибки на этапе проектирования.
  • Участвует в найме, повышая качество команды.

Именно поэтому senior может приносить в 2–3 раза больше стоимости, чем стоит.

Инфляция требований: «подъём уровня воды»

Важный феномен, который отметил собеседник: требования со временем растут. То, что 5 лет назад было достаточно для middle-уровня, сегодня может быть базовым требованием для junior.

Причины:

  • Усложнение технологического стека (микросервисы, контейнеризация, облака).
  • Рост ожиданий по качеству кода (тесты, CI/CD, мониторинг).
  • Увеличение объёма знаний, необходимых для работы (не только Go, но и базы данных, очереди сообщений, кэширование).

Разработчики, которые не инвестировали в свой рост, оказываются в ситуации, когда их навыки обесценились.

Зарплатные ориентиры (обобщённые)

Конкретные цифры сильно зависят от региона, компании и года. Однако общие пропорции сохраняются:

  • Junior: получает меньше, чем приносит в продуктивности, но компания инвестирует в его рост.
  • Middle: примерно выходит в ноль — его компенсация соответствует его вкладу.
  • Senior: приносит значительно больше, чем стоит, за счёт множительного эффекта на команду.

Важные нюансы:

Зарплата — это не точный показатель уровня. Внутренние градации компаний различаются: senior в одной компании может соответствовать middle в другой. Оценивать человека нужно по его способности решать задачи, а не по текущей компенсации.

Также стоит учитывать «зачётку» — первые 1.5–2 года в компании человек работает на репутацию, адаптируется и набирает опыт. После этого репутация предыдущих мест работы начинает работать на него, облегчая трудоустройство в будущем.

Вопрос 5. Зачем на собеседованиях спрашивают алгоритмы, live coding и теоретические вопросы? Какова роль GitHub-проектов и тестовых заданий?​

Таймкод: 01:05:25

Ответ собеседника: Правильный. Алгоритмические задачи и live coding — это удобный фильтр, который позволяет отличить инженера от ремесленника. Ремесленник — человек, который выучил набор заклинаний (конкретные фреймворки, библиотеки) и применяет их, не понимая глубинных принципов. Инженер умеет строить модели, оперировать абстракциями, мыслить структурированно. Алгоритмические задачи проверяют способность человека решать экономические (эффективные) задачи, строить логические конструкции в голове. Live coding показывает, как человек реально пишет код — медленно или быстро, с ошибками или без. Многие люди с большим стажем прекрасно рассказывают о технологиях, но пишут код плохо — live coding это выявляет. Теоретические вопросы проверяют понимание фундаментальных концепций и способность мыслить абстрактно. Программирование — это инженерия, а не искусство, и математика учит строить модели и видеть закономерности. Знание алгоритмов также говорит о способности человека учиться и заниматься самообразованием — это важнее, чем умение писать код, потому что если человек способен учиться, его можно научить всему. Что касается GitHub-проектов — наличие pet-проектов это плюс, это говорит о том, что человек увлечён программированием, но качество pet-проектов плохо коррелирует с реальной production-работой, поэтому опираться на них при оценке не стоит. Тестовые задания — хороший инструмент: они показывают заинтересованность кандидата, его реальные навыки написания кода. Предлагает два варианта: на время (4 часа) или без жёстких ограничений. Также предлагает идею тестового задания в виде полезного pull request к реальному проекту/библиотеке компании. Алгоритмы на работе напрямую могут не использоваться, но понимание внутренних механизмов важно для диагностики проблем в production. Проверка алгоритмов — это один из способов снизить риски ошибочного найма.

Правильный ответ:

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

Инженер vs. Ремесленник

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

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

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

Алгоритмические задачи — это один из способов отличить инженера от ремесленника.

Алгоритмические задачи: что они проверяют на самом деле

Критика «зачем мне алгоритмы, если я пишу бизнес-логику» упускает из виду, что алгоритмы проверяют не способность реализовать красно-чёрное дерево, а несколько других качеств:

А. Способность оценивать эффективность

Когда разработчик выбирает между линейным поиском и бинарным, между массивом и хеш-таблицей, он демонстрирует понимание того, что код имеет стоимость. В production это критически важно: разница между O(n) и O(n²) может стоить компании миллионы на инфраструктуре.

Б. Умение строить модели

Алгоритмическая задача — это упрощённая модель реальной проблемы. Способность абстрагироваться от деталей и построить модель — это ключевой навык инженера. Реальные задачи в работе тоже требуют моделирования: «как спроектировать rate limiter», «как организовать очередь задач», «как эффективно дедуплицировать данные».

В. Способность учиться

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

Г. Понимание внутренних механизмов

Знание алгоритмов помогает в диагностике проблем. Когда запрос к базе данных тормозит, нужно понимать, как работают индексы (B-деревья). Когда приложение потребляет много памяти, нужно понимать, как работают структуры данных.

Live coding: почему это важно

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

  • Разработчик с 10-летним стажем не может написать простую функцию без подсказок.
  • Кандидат, который блестяще рассказывает о микросервисах, пишет код без обработки ошибок.
  • Человек, который знает все паттерны, не может написать читаемый код.

Live coding проверяет:

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

Теоретические вопросы: зачем они

Теоретические вопросы проверяют глубину понимания. Примеры для Go:

  • «Как работает планировщик Go?» — проверяет понимание конкурентности.
  • «Что такое escape analysis?» — проверяет понимание модели памяти.
  • «Как устроен интерфейс внутри?» — проверяет понимание типизации.

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

GitHub-проекты: плюсы и минусы

Плюсы:

  • Показывают увлечённость разработчика.
  • Демонстрируют способность довести проект до конца.
  • Многое говорят о стиле кода и подходе к архитектуре.

Минусы:

  • Pet-проекты сильно отличаются от production-кода.
  • Нет code review, нет дедлайнов, нет необходимости поддерживать чужой код.
  • Сложно оценить вклад в групповых проектах.
  • Многие хорошие разработчики не имеют публичных проектов, потому что заняты работой или семьёй.

Поэтому GitHub — это бонус, но не основной критерий.

Тестовые задания: лучшие практики

Тестовые задания — мощный инструмент, но они должны быть правильно спроектированы.

Хорошее тестовое задание:

  • Реалистично: похоже на реальные задачи, которые будут на работе.
  • Ограничено по времени: 2–4 часа, не больше.
  • Оценивает важные качества: читаемость кода, обработка ошибок, тесты.
  • Не бесплатная работа: не должно решать реальные бизнес-задачи компании.

Вариант с PR к реальному проекту, который предложил собеседник, — это отличная идея. Кандидат получает реалистичный контекст, а компания — бесплатный вклад в open source. Это выигрыш для обеих сторон.

Плохое тестовое задание:

  • Занимает больше 8 часов.
  • Не связано с реальной работой.
  • Не даёт обратную связь кандидату.
  • Используется как бесплатная работа.

Итог: зачем всё это вместе

Каждый инструмент проверяет свой аспект:

  • Алгоритмы — инженерное мышление и способность учиться.
  • Live coding — реальные навыки написания кода.
  • Теория — глубина понимания.
  • GitHub — увлечённость и стиль.
  • Тестовые задания — способность решать задачи самостоятельно.

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

Вопрос 6. Насколько охотно компании берут разработчиков с нетипичным бэкграундом: DevOps, embedded, джунов и разработчиков с других языков?​

Таймкод: 01:24:53

Ответ собеседника: Правильный. Lamoda активно нанимает людей с опытом работы на PHP и переучивает их на Go, потому что у компании есть PHP-сервисы, которые постепенно переписываются или спиливаются, и нужны программисты, способные разобраться в слоях абстракции и вычленить бизнес-логику. При этом PHP в режиме readonly крайне важен. В целом подход к найму зависит от задач компании — если компания занимается высоконагруженными системами (миллионы запросов в секунду), требования будут другими, чем если она просто гоняет данные по сети. По поводу DevOps-опыта: для Go-разработчика наличие DevOps-бэкграунда не даёт явных плюсов или минусов, если нет специфики в работе. По поводу джунов: Lamoda обычно не берёт новичков, но в целом компания может позволить себе джунов, когда у неё есть на это средства и команда готова к потере производительности на обучение. Это долгосрочная инвестиция, которая окупается, если джун остаётся в компании и растёт — такие специалисты хорошо знают бизнес-процессы и становятся значимыми для компании. По поводу людей с других языков: есть негативный опыт с переучиванием с Python — люди довольно сильно застревают в парадигме своего языка. В то же время брать людей из смежных индустрий (например, из бизнеса, которым занимается компания) — это большой плюс, даже если они не очень хорошо пишут код, потому что они понимают бизнес-логику и могут быть продуктивными в команде. По поводу выбора между Python и PHP разработчиками для переучивания на Go: примерно безразлично, так как всё равно придётся переучивать. Важнее не предыдущий язык, а способность человека учиться и адаптироваться. Люди, выросшие внутри компании, являются гиперлояльными и лучше всех понимают культуру компании — это видно по тому, как они работают и взаимодействуют с командой.

Правильный ответ:

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

PHP-разработчики: переучивание на Go

Lamoda использует интересный подход: нанимает PHP-разработчиков не только для работы с Go, но и для поддержки существующего PHP-кода. Это прагматичное решение:

  • Компания не может мгновенно переписать весь PHP-код на Go.
  • PHP-разработчики могут поддерживать существующие сервисы в режиме readonly.
  • Параллельно они могут постепенно переходить на Go.

PHP в режиме readonly — это важная концепция. Когда сервис работает стабильно и не требует активной разработки, достаточно уметь читать код, понимать бизнес-логику и вносить минимальные изменения. Это снижает порог входа для новых разработчиков.

DevOps-бэкграунд: плюсы и минусы

Для Go-разработчика DevOps-опыт может быть как плюсом, так и нейтральным фактором:

Плюсы:

  • Понимание инфраструктуры: как работают контейнеры, оркестрация, сеть.
  • Умение диагностировать проблемы: если сервис тормозит, DevOps-бэкграунд поможет понять, проблема в коде или в инфраструктуре.
  • Понимание CI/CD: как код попадает в production.
  • Автоматизация: привычка автоматизировать рутинные задачи.

Минусы:

  • Может не хватать глубины в разработке приложений.
  • Разный фокус: DevOps думает о надёжности и доступности, разработчик — о функциональности и производительности кода.

В целом, DevOps-бэкграунд — это скорее плюс, особенно в компаниях, где разработчики участвуют в эксплуатации своих сервисов (You Build It, You Run It).

Embedded-разработчики: специфика перехода

Embedded-разработчики имеют уникальный набор навыков:

Плюсы:

  • Глубокое понимание работы компьютера: память, процессор, ввод-вывод.
  • Привычка работать с ограниченными ресурсами.
  • Внимание к деталям и производительности.
  • Понимание низкоуровневых концепций.

Минусы:

  • Может быть сложно переключиться на высокоуровневые абстракции.
  • Другой подход к обработке ошибок (в embedded часто нет исключений).
  • Другой подход к тестированию (сложнее изолировать зависимости).

Переход с embedded на backend-разработку обычно проходит легче, чем в обратную сторону, потому что embedded-разработчики уже понимают «как работает компьютер».

Джуны: долгосрочная инвестиция

Найм junior-разработчиков — это всегда инвестиция. Компания должна быть готова к:

  • Потере производительности команды на 3–6 месяцев.
  • Необходимости менторства.
  • Риску, что джун не вырастет или уйдёт после обучения.

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

  • Лояльность: разработчики, выросшие внутри компании, обычно более лояльны.
  • Знание бизнеса: они глубоко понимают бизнес-процессы компании.
  • Культура: они впитывают культуру компании с самого начала.
  • Стоимость: на старте они стоят дешевле, чем middle или senior.

Lamoda не берёт джунов регулярно, но это вопрос ресурсов, а не принципа. Когда компания может позволить себе инвестировать в рост, это окупается.

Разработчики с других языков: Python vs. PHP

Интересное наблюдение о том, что Python-разработчики сложнее переучиваются. Это может быть связано с несколькими факторами:

  • Динамическая типизация: Python и PHP — динамически типизированные языки, Go — статически типизированный. Переход требует изменения мышления.
  • Философия языка: Python поощряет «duck typing» и «easier to ask forgiveness than permission». Go поощряет явную обработку ошибок и чёткие интерфейсы.
  • Экосистема: Python-разработчики привыкли к обилию библиотек и фреймворков. Go поощряет использование стандартной библиотеки.

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

Люди из смежных индустрий: недооценённый ресурс

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

Пример: разработчик с опытом в e-commerce будет быстрее понимать задачи Lamoda, чем разработчик с опытом в телекоме, даже если технически они равны.

Гиперлояльность внутренних сотрудников

Люди, выросшие внутри компании, действительно показывают более высокую лояльность. Это объясняется:

  • Эмоциональной привязанностью к команде и проектам.
  • Инвестициями в отношения и репутацию внутри компании.
  • Пониманием культуры и процессов, что снижает стресс при работе.
  • Карьерными возможностями, которые сложно воспроизвести в другой компании.

Вопрос 7. Как влияют образование и возраст кандидата на решение о найме?​

Таймкод: 01:35:38

Ответ собеседника: Правильный. Образование имеет значение в основном для джунов, когда у человека ещё мало опыта и нечего спрашивать. Окончание хорошего вуза говорит о способности концентрироваться на задаче и выдерживать нагрузки. При этом есть разница между вузами, где учиться сложно, и теми, где диплом можно купить. Знание фундаментальных вещей (модель фон Неймана, как устроен компьютер, процессор, память) — это плюс, даже если напрямую не применяется в production-работе. Люди без базовых знаний (например, пришедшие из PHP без понимания того, как работает компьютер) — это ремесленники, которые знают шаблоны, но не понимают сути. Человек, который бросил вуз, может вызвать вопросы, но если он осознанно ушёл — это

Вопрос 8. Зачем нужны несколько секций собеседований вместо одного длинного? Как это влияет на качество оценки и опыт кандидата?​

Таймкод: 01:46:36

Ответ собеседника: Правильный. Разбиение собеседования на несколько секций (алгоритмы, язык/технологии, архитектура, софт-скиллы, беседа с командой) — это осознанный подход. Каждая секция длится около часа, кандидат сам выбирает удобное время. Это гораздо лучше, чем пытаться впихнуть всё в одну сессию на 4–5 часов. Секции позволяют проверить разные компетенции: алгоритмы на платформе, знание языка, архитектурную часть, а также провести беседу с командой для оценки совместимости. Для компании это также вопрос стандартизации — при большом количестве кандидатов и собеседующих нужно обеспечить предсказуемый результат. При этом сам спикер является противником большого количества собеседований — обычно проводит одно, максимум два. Если собеседуют коллеги без него, то для позиций выше джуна просит организовать ещё одно собеседование с ним лично, чтобы оценить, будет ли комфортно работать с этим человеком. Количество секций — это баланс между качеством оценки и удобством для кандидата.

Правильный ответ:

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

Проблема одного длинного собеседования

Формат «марафонского» собеседования на 4–5 часов имеет серьёзные недостатки:

Когнитивная усталость кандидата. После 2 часов интенсивного мышления качество ответов неизбежно падает. Кандидат может знать материал, но не сможет продемонстрировать это из-за усталости. Это увеличивает количество false negative — хороших кандидатов, которые не прошли из-за формата.

Когнитивная усталость интервьюера. Интервьюер тоже человек. После нескольких часов оценки разных людей его способность к объективной оценке снижается. Эффект «ореола» усиливается: если кандидат плохо ответил на первый вопрос, интервьюер может бессознательно занижать оценки последующих ответов.

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

Преимущества многосекционного формата

А. Специализация интервьюеров

Разные люди лучше оценивают разные компетенции. Алгоритмическое мышление лучше оценивает человек, который сам решает алгоритмические задачи. Архитектурное мышление лучше оценит архитектор или senior-разработчик с опытом проектирования. Софт-скиллы лучше оценит тимлид или менеджер.

Б. Снижение стресса для кандидата

Когда кандидат знает, что собеседование длится 1 час, а не 5, уровень стресса значительно ниже. Можно сосредоточиться на одной теме. Если одна секция прошла плохо, есть шанс реабилитироваться в следующей.

В. Гибкость в планировании

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

Г. Стандартизация и сравнимость

Каждая секция имеет свой чек-лист и критерии оценки. Это позволяет сравнивать кандидатов объективно. Фидбэк из каждой секции суммируется, и решение принимается на основе полной картины.

Типичная структура многосекционного собеседования

Секция 1: Алгоритмы и структуры данных (60 минут) Онлайн-платформа или live coding. Проверяет инженерное мышление, способность оценивать сложность, качество кода.

Секция 2: Язык и технологии (60 минут) Вопросы по Go: горутины, каналы, контексты, интерфейсы, обработка ошибок. Вопросы по базам данных, очередям сообщений, кэшированию.

Секция 3: Архитектура и проектирование (60 минут) Для middle+ и senior. Проектирование распределённых систем, выбор технологий, trade-offs.

Секция 4: Софт-скиллы и культурное соответствие (45–60 минут) Поведенческие вопросы, обсуждение прошлого опыта, оценка коммуникативных навыков.

Секция 5: Беседа с командой (30–45 минут) Неформальная беседа с будущими коллегами. Позволяет оценить, будет ли комфортно работать вместе.

Оптимальное количество секций

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

Оптимально — 2–3 секции для junior, 3–4 для middle, 4–5 для senior. Каждая секция должна проверять свою компетенцию, и между секциями должно быть достаточно времени для подготовки фидбэка.

Проблема стоимости собеседований

Собеседование — это дорого. Каждый час интервьюера — это час, когда он не пишет код. Поэтому важно оптимизировать процесс:

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

Личное участие руководителя

Практика, которую описал собеседник — личное собеседование с кандидатами уровня выше junior — это важный элемент. Руководитель лучше понимает команду и может оценить, будет ли новичком комфортно работать с этими людьми. Это снижает риск текучести на ранних этапах.

Вопрос 9. Как правильно составить резюме? На что обратить внимание и каких ошибок избегать?​

Таймкод: 01:56:56

Ответ собеседника: Правильный. Резюме обычно бывает двух типов: либо куча воды, либо сухое «сделал админку», где непонятно что человек делал. Резюме нужно писать серьёзно. На западе существуют сервисы, где можно обратиться к специалисту, который поможет написать резюме — это нормальная практика. Специалист понимает, как показать то, что вы реально знаете, и предостережёт от того, чтобы писать то, что вы знаете плохо, потому что если это всплывёт на собеседовании и человек не сможет ответить — это огромный минус. Резюме должно быть написано с точки зрения работодателя — рекрутеры просматривают сотни резюме и им нужны ключевые моменты, за которые можно зацепиться. Нужно посмотреть на резюме глазами рекрутера. Можно обратиться к карьерному консультанту или менеджеру по подбору персонала. Также стоит учитывать, что для разных позиций нужно писать разные резюме. В целом, если вы крутой специалист, которого знают, резюме может и не понадобиться, но для обычных кандидатов важно уделить внимание качеству резюме.

Правильный ответ:

Резюме — это первый фильтр в процессе найма, и от его качества зависит, получите ли вы приглашение на собеседование. Разберём, как написать резюме, которое работает.

Как работает фильтрация резюме

Прежде чем писать резюме, нужно понять, как его читают. Рекрутер тратит на первичный просмотр резюме 6–10 секунд. За это время он ищет:

  • Позиция и уровень (junior, middle, senior).
  • Технологический стек (Go, PostgreSQL, Kafka и т.д.).
  • Релевантный опыт (сколько лет, в каких компаниях).
  • Ключевые достижения (конкретные результаты).

Если за 10 секунд рекрутер не нашёл нужную информацию — резюме отклоняется.

Два крайних типа плохих резюме

Тип 1: «Вода». Длинный текст без конкретики: «Ответственный, коммуникативный, целеустремлённый. Имею опыт работы в команде. Готов к обучению и развитию.» Это ничего не говорит о реальных навыках.

Тип 2: «Сухой список». «Разработка админки. Интеграция с API. Написание тестов.» Непонятно, что именно делал человек, какие проблемы решал, какие результаты получил.

Структура хорошего резюме

1. Заголовок: имя, контакты, позиция

Укажите желаемую позицию: «Go-разработчик (Middle/Senior)». Это сразу задаёт контекст.

2. Краткое резюме (2–3 предложения)

Не общие фразы, а конкретика: «Go-разработчик с 5-летним опытом. Специализация — высоконагруженные микросервисы. Опыт проектирования систем, обрабатывающих 10k+ RPS.»

3. Технологический стек

Перечислите технологии, с которыми работали. Будьте честны — если указали PostgreSQL, будьте готовы ответить на вопросы о нём.

4. Опыт работы

Для каждого места работы укажите:

  • Компания, период работы, должность.
  • 2–4 ключевых достижения с конкретными цифрами.

Пример плохого: «Разработка микросервисов на Go.»

Пример хорошего: «Спроектировал и реализовал сервис обработки заказов на Go. Снизил latency P99 с 200ms до 50ms за счёт внедрения кэширования в Redis. Сервис обрабатывает 5k RPS.»

5. Образование

Укажите вуз и специальность. Если есть курсы или сертификации — добавьте их.

6. Дополнительно

GitHub, блоги, выступления на конференциях — всё, что показывает вашу увлечённость профессией.

Принцип «с точки зрения работодателя»

Собеседник правильно подчеркнул: резюме нужно писать с точки зрения работодателя. Задайте себе вопрос: «Что работодатель хочет видеть и как я могу это показать?»

Работодатель хочет знать:

  • Можете ли вы решать его проблемы?
  • Какой у вас опыт?
  • Быстро ли вы адаптируетесь?
  • Будете ли вы расти?

Каждый пункт резюме должен отвечать на один из этих вопросов.

Честность в резюме

Это критически важный момент. Если вы указали технологию — будьте готовы ответить на вопросы о ней. Если вы написали «опыт работы с Kafka», а на собеседовании не можете объяснить, что такое партиция или consumer group — это огромный минус.

Лучше написать меньше, но честно, чем больше, но с преувеличением.

Разные резюме для разных позиций

Если вы откликаетесь на разные позиции — адаптируйте резюме. Для senior-позиции акцент на архитектуре и лидерстве. Для middle — на самостоятельности и технических навыках. Для junior — на способности учиться и базовых знаниях.

Профессиональная помощь

Собеседник упомянул сервисы по написанию резюме. Это действительно распространённая практика, особенно на западном рынке. Карьерный консультант или специалист по подбору персонала может:

  • Помочь структурировать информацию.
  • Подобрать правильные формулировки.
  • Указать на слабые места.
  • Адаптировать резюме под конкретную позицию.

Это не обман — это профессиональная помощь в самопрезентации.

Когда резюме не нужно

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

Вопрос 10. Как проводить собеседования с сеньорами? Что важнее — проверить технический уровень или заинтересовать кандидата?​

Таймкод: 02:06:51

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

Правильный ответ:

Собеседование с senior-разработчиком — это принципиально другой процесс, чем с junior или middle. И причина не в том, что senior «лучше», а в том, что экономика этого найма совершенно иная.

Почему сеньоры — это отдельный случай

Редкость. Senior-разработчики — это малый процент рынка. По разным оценкам, соотношение примерно 15–20% senior, 30–40% middle, 40–50% junior. Каждый senior уникален: у него свой опыт, свои сильные стороны, свои ожидания.

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

Конкуренция за таланты. Хорошие senior-разработчики получают несколько предложений одновременно. Компании конкурируют за них, а не наоборот.

Смена баланса сил

На собеседовании с junior компания «оценивает» кандидата. На собеседовании с senior кандидат тоже «оценивает» компанию. Это двусторонний процесс, и это нужно принять.

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

Что важнее: проверить уровень или заинтересовать?

Ответ: и то, и другое, но приоритеты смещаются.

Техническая проверка всё ещё важна, но она другая. С senior не нужно спрашивать «что такое интерфейс» или «напишите бинарный поиск». Вместо этого:

  • Обсуждайте реальные архитектурные решения из его опыта.
  • Задавайте вопросы о trade-offs: «Почему выбрали именно это решение? Какие альтернативы рассматривали?»
  • Проверяйте глубину: «Что будет, если нагрузка вырастет в 10 раз?»
  • Оценивайте широту: понимает ли человек экосистему, а только свой стек.

Если за первый час стало ясно, что технических вопросов нет — не тратьте второй час на избыточную проверку. Переключайтесь на «продажу».

Продажа компании: что это значит

Senior-разработикам важны не только деньги. Конечно, компенсация важна, но она не единственный фактор. Что ещё важно:

Интересные задачи. Senior хочет решать сложные проблемы. Если вы поставите его писать CRUD-эндпоинты, он уйдёт. Покажите, какие технические вызовы ждут его в вашей компании.

Автономия. Senior привык принимать решения. Покажите, что в вашей компании он сможет влиять на технические решения.

Команда. Senior хочет работать с сильными коллегами. Покажите, кто будет в команде, каков уровень разработчиков.

Влияние. Senior хочет видеть результат своей работы. Покажите, как его работа влияет на бизнес.

Культура. Senior ценит зрелые процессы: code review, CI/CD, тестирование, документация.

Практические советы по проведению собеседования с senior

1. Подготовьтесь. Изучите резюме кандидата заранее. Подготовьте вопросы, релевантные его опыту. Не задавайте вопросы, ответы на которые можно найти в его резюме.

2. Начните с рассказа о компании. Расскажите о технических вызовах, о команде, о планах. Дайте кандидату задать вопросы.

3. Обсуждайте, а не экзаменуйте. Формат «вопрос-ответ» работает для junior, но не для senior. Лучше обсуждать реальные проблемы и смотреть, как кандидат рассуждает.

4. Вовлекайте команду. Дайте кандидату пообщаться с будущими коллегами. Это важно для обеих сторон.

5. Будьте честны. Если у вас есть технический долг или сложности — скажите об этом. Senior оценит честность, и лучше он узнает правду до найма, чем после.

6. Не затягивайте процесс. Длительный процесс собеседований (5+ раундов на протяжении месяца) отпугивает senior-кандидатов. Они не будут ждать — примут другое предложение.

Метрика успеха

Для junior метрика успеха собеседования — «нашли ли мы достаточно квалифицированного кандидата». Для senior — «заинтересовали ли мы кандидата настолько, чтобы он принял наше предложение и остался надолго».

Вопрос 11. Как найти первую работу в программировании? Куда идти и как решить проблему отсутствия опыта?​

Таймкод: 02:09:36

Ответ собеседника: Правильный. Проблема первой работы — когда 500 человек хотят получить первую работу, из них нужно выбрать 10, и в таких пропорциях очень тяжело отобрать. Лучшее, что можно делать — показывать прогресс: вот я полгода назад был такой, а сейчас вот такой — вот что я сделал за полгода. Тогда есть хоть какой-то шанс. Можно идти в крупные компании с программами стажировок (Яндекс, Ozon и т.д.) — там можно пройти, научиться. Но людей с опытом берут охотнее, чем без опыта. Самое простое — хвататься за любое предложение формата «приходи, получишь стажировку». Go — довольно хардкорный язык, используется большими компаниями под большими нагрузками, и там проще взять стажёров. Поэтому если человек без опыта и первый язык — Go, ему будет сложнее, но если дали предложение стажировки — нужно хвататься и бежать. Также можно не задирать цену и говорить, что готов учиться и работать за небольшую зарплату ради получения первого опыта.

Правильный ответ:

Проблема «первой работы» — это классическая дилемма «курица или яйцо»: для получения опыта нужна работа, а для получения работы нужен опыт. Разберём стратегии, которые реально работают.

Масштаб проблемы

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

Стратегия 1: Показывать прогресс, а не результат

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

Как показать прогресс:

  • GitHub с историей коммитов. Если видно, что 6 месяцев назад вы писали простые скрипты, а сейчас — многопоточные приложения с тестами, это говорит о скорости роста.
  • Блог или заметки. Публикации о том, что вы изучаете, показывают осознанный подход к обучению.
  • Pet-проекты разной сложности. Покажите эволюцию: от простого CLI-инструмента до полноценного веб-сервиса с базой данных и тестами.

Стратегия 2: Крупные компании с программами стажировок

Крупные компании (Яндекс, Ozon, Тинькофф, Lamoda и др.) имеют структурированные программы стажировок:

  • Они готовы инвестировать в обучение.
  • У них есть менторы и учебные программы.
  • Они нанимают стажёрами десятки или сотни человек одновременно.

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

Стратегия 3: Хвататься за любую возможность

Первая работа — это не про идеальную компанию или зарплату. Это про получение опыта, который откроет двери в будущем.

Что считается «любой возможностью»:

  • Стажировка с низкой или нулевой оплатой.
  • Работа в маленькой компании или стартапе.
  • Фриланс-проекты.
  • Волонтёрская работа (например, разработка сайта для НКО).
  • Open-source контрибьюции.

Каждый из этих вариантов даёт опыт, который можно указать в резюме.

Стратегия 4: Go как первый язык — плюсы и минусы

Go — отличный язык, но он действительно «хардкорнее» для старта, чем Python или JavaScript.

Плюсы Go как первого языка:

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

Минусы Go как первого языка:

  • Меньше вакансий для junior по сравнению с Python или JavaScript.
  • Используется в компаниях, которые часто ожидают опыта.
  • Меньше учебных ресурсов для абсолютных новичков.

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

Стратегия 5: Адекватные зарплатные ожидания

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

Компания понимает, что junior будет непродуктивен первые месяцы. Если при этом он ещё и не требует высокую зарплату, это снижает барьер для найма.

Стратегия 6: Альтернативные способы получения опыта

Если не получается найти работу сразу, создайте опыт самостоятельно:

Open-source контрибьюции. Найдите проект на GitHub, который вам интересен, и начните с малого: исправление багов, улучшение документации, написание тестов. Это реальный опыт работы с чужим кодом, code review, Git.

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

Фриланс. Платформы вроде Upwork или FL.ru могут дать первые проекты. Даже мелкие задачи — это опыт и отзывы.

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

Что писать в резюме без опыта работы

Если у вас нет коммерческого опыта, акцент делайте на:

  • Pet-проекты. Опишите, что делали, какие технологии использовали, какие проблемы решали.
  • Open-source контрибьюции. Укажите проекты и ваш вклад.
  • Образование. Курсы, книги, сертификаты.
  • Алгоритмические задачи. Если вы решаете задачи на LeetCode или Codeforces, укажите свой рейтинг.

Главное правило

Первая работа — это трамплин, а не пункт назначения. Через 1–2 года опыта вы сможете выбирать из множества предложений. Поэтому не бойтесь начинать с малого — главное начать.