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

Был на 65+ собеседованиях Golang. Выводы

· 11 мин. чтения

Сегодня мы разберём расшифровку выступления Захара — опытного разработчика, прошедшего более 65 технических собеседований в компании уровня Google, Ozon, Goldman Sachs и другие. Он делится практическими советами о том, что действительно помогает успешно пройти алгоритмические секции, системный дизайн и живое кодирование, а также рассказывает, почему игнорировал домашние задания, как правильно оформлять резюме и использовать LinkedIn для выхода на международный рынок.

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

Таймкод: 00:00:49

Ответ собеседника: Правильный. Названы три ключевых навыка: решение задач на LeetCode (рекомендуется решить 100–300 задач), умение лайфкодить на собеседовании (навык приходит с практикой прохождения собеседований), глубокое знание теории (язык программирования, базы данных, компьютерные сети, DevOps, CI/CD). Также упомянут английский язык как фактор, расширяющий рынок и увеличивающий зарплату на 1000+ долларов.

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

Ответ кандидата покрывает основные направления, но стоит структурировать и дополнить картину.

1. Алгоритмы и структуры данных (LeetCode-подготовка)

Это фундамент технических интервью в крупных компаниях (FAANG и аналоги). Рекомендуемый объём — 150–300 задач с фокусом на паттерны, а не на количество. Ключевые темы:

  • Массивы и строки (two pointers, sliding window)
  • Хеш-таблицы и множества
  • Деревья и графы (DFS, BFS, обходы)
  • Динамическое программирование
  • Сортировки и бинарный поиск
  • Стек, очередь, приоритетная очередь

Важно не просто решать, а уметь объяснять выбор подхода, оценивать сложность по времени и памяти, предлагать альтернативы.

2. Навык лайфкодинга (Live Coding)

Это отдельный soft skill, который тренируется специально:

  • Думать вслух — интервьюер оценивает ход мысли, а не только финальный код
  • Начинать с brute force, затем оптимизировать, объясняя каждый шаг
  • Уточнять требования — граничные случаи, ограничения на входные данные, ожидаемая сложность
  • Писать чистый код — осмысленные имена переменных, отступы, структурирование
  • Тестировать на месте — прогнать пример руками, проверить edge cases

Практика через mock-интервiews (Pramp, interviewing.io, друзья-разработчики) критически важна. Обычно требуется 5–10 тренировочных сессий, чтобы перестать теряться под давлением.

3. Глубокое знание стека технологий

Для Golang-разработчика это включает:

  • Язык Go: горутины, каналы, контексты, интерфейсы, сборка мусора, escape analysis, профилирование (pprof), ключевые пакеты стандартной библиотеки
  • Базы данных: SQL (индексы, планы выполнения, нормализация, транзакции и уровни изоляции), NoSQL (Redis, MongoDB — когда и почему выбирать)
  • Сети: HTTP/HTTPS, TCP/UDP, gRPC, REST vs GraphQL, TLS
  • Инфраструктура: Docker, Kubernetes, CI/CD (GitLab CI, GitHub Actions), мониторинг (Prometheus, Grafana)
  • Системный дизайн (для middle+/senior): проектирование распределённых систем, балансировка нагрузки, кэширование, очереди сообщений, шардирование, репликация

4. Коммуникация и английский язык

Английский — это не просто «плюс», а часто обязательное требование для работы в международных компаниях. Он открывает доступ к рынку US/EU, где зарплатные вилки существенно выше. На собеседовании важно уметь:

  • Чётко формулировать мысли на английском
  • Обсуждать архитектурные решения
  • Задавать уточняющие вопросы
  • Аргументировать свой выбор технологий

5. Системный дизайн (System Design)

Для позиций уровня middle и выше добавляется блок проектирования систем. Нужно уметь спроектировать сервис «с нуля»: от требований и capacity estimation до выбора хранилища, API, стратегии кэширования и обработки отказов.

6. Знание проектного опыта (Behavioral / STAR-метод)

Техническая часть — это половина успеха. Вторая половина — умение рассказать о своём опыте структурированно: контекст, задача, действия, результат (STAR-формат). Интервьюеры оценивают глубину владения прошлыми проектами, способность принимать решения и учиться на ошибках.

Вопрос 2. Стоит ли выполнять домашние тестовые задания (take-home assignments), которые компании дают до основного собеседования?

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

Ответ собеседника: Правильный. Лучше не делать домашние задания, а вместо этого ходить на живые собеседования. Домашки занимают много времени (до 6 часов), после их отправки часто нет ответа, а техническая проверка всё равно будет на собеседовании. Лайфкодинг на собеседовании занимает всего 1 час. Однако если других предложений нет, можно и решать тестовые.

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

Кандидат верно обозначил основные риски take-home assignments. Дополним картину и добавим нюансы.

1. Главные проблемы домашних заданий

  • Большие временные затраты: типичное задание занимает 4–8 часов, а некоторые компании дают задачи на 15–20 часов. Это непропорционально по сравнению с live coding (45–60 минут).
  • Высокий «процент молчания»: многие компании не дают обратную связь после отправки, даже если решение было хорошим. Кандидат тратит время и не получает ничего взамен.
  • Дублирование проверки: даже после успешного тестового вас скорее всего ждёт полноценный технический раунд, где те же компетенции проверят заново.
  • Риск неоплачиваемого труда: недобросовестные компании могут давать задачи, которые реально нужны для бизнеса, а не для оценки навыков.

2. Когда имеет смысл делать

  • У вас мало опыта или слабое резюме — тестовое может компенсировать это, показав реальный код
  • Компания из сферы, которая вам очень интересна, и вы готовы инвестировать время
  • Задание адекватно по объёму (2–3 часа максимум) и чётко сформулировано
  • Компания предоставляет обратную связь вне зависимости от результата

3. Как оценить, стоит ли браться

Перед тем как соглашаться, задайте рекрутеру несколько вопросов:

  • Сколько часов вы оцениваете на выполнение?
  • Будет ли обратная связь по результату?
  • Какие следующие этапы после тестового?
  • Оплачивается ли это задание? (Некоторые компании платят за серьёзные take-home)

Если рекрутер не может ответить на эти вопросы — это красный флаг.

4. Если всё-таки делаете — делайте качественно

Если вы решили выполнить тестовое, используйте его как возможность показать свой уровень:

  • Чистая архитектура проекта, понятная структура каталогов
  • README с инструкцией по запуску и описанием решений
  • Тесты (unit, интеграционные)
  • Dockerfile и docker-compose для удобного развёртывания
  • Graceful shutdown, обработка ошибок, логирование
  • Комментарии к ключевым решениям в коде
// Пример структуры проекта для тестового
//
// my-assignment/
// ├── cmd/
// │ └── server/
// │ └── main.go
// ├── internal/
// │ ├── handler/
// │ ├── service/
// │ └── repository/
// ├── migrations/
// ├── Dockerfile
// ├── docker-compose.yml
// ├── Makefile
// ├── go.mod
// └── README.md

5. Стратегия для опытных разработчиков

Если у вас уже есть сильное резюме и опыт, лучше настаивать на live coding вместо take-home. Можно вежливо предложить альтернативу:

> «Я ценю ваше время и хочу показать свои навыки. Могу ли я вместо домашнего задания пройти технический раунд с live coding? Так мы оба сэкономим время.»

Многие компании соглашаются, и это сразу показывает вашу уверенность и сильную позицию на переговорах.

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

Таймкод: 00:08:19

Ответ собеседника: Правильный. Резюме должно быть на одну страницу, лаконичным, без самооценок. Структура: имя, список мест работы с указанием продолжительности и технологий. Можно адаптировать резюме под конкретную компанию. Рекомендуется использовать шаблоны из Headhunter или Google Docs. Важно прокачать LinkedIn-профиль. Если у рекрутеров возникают вопросы по резюме — его нужно переработать.

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

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

1. Формат и длина

  • Одна страница — для опыта до 10 лет. Две страницы допустимы для 10+ лет опыта, но первая страница должна содержать самое важное.
  • PDF-формат — всегда отправляйте в PDF, чтобы верстка не поехала.
  • Чистый дизайн — без фото (для международного рынка), без цветных рамок, без иконок. ATS-системы (Applicant Tracking Systems) должны корректно парсить файл. Лучше использовать одноцветный минималистичный шаблон.

2. Структура резюме для Golang-разработчика

Контактная информация (шапка):

  • Имя и фамилия
  • Город и страна (или «Открыт к релокации»)
  • Email, телефон
  • LinkedIn, GitHub
  • Технический блог (если есть)

Summary (2–3 строки) — опционально, но полезно: Кратко обозначьте свой уровень, ключевую специализацию и главное достижение. Не «крутой разработчик», а конкретика:

> «Golang-разработчик с 5 годами опыта. Специализация — высоконагруженные микросервисы. Построил систему обработки 10K RPS с латентностью p99 < 50ms.»

Опыт работы (в обратном хронологическом порядке):

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

  • Название компании, период работы, должность
  • Контекст: чем занимается компания (1 строка)
  • Достижения в виде буллетов с метриками, а не просто список обязанностей

Слабый пример: > «Разрабатывал микросервисы на Go, писал SQL-запросы, работал с Docker.»

Сильный пример: > «Спроектировал и реализовал сервис нотификаций на Go, обрабатывающий 50K сообщений/сек с гарантией доставки at-least-once.» > «Оптимизировал SQL-запросы и добавил составные индексы, сократив время ответа API с 2с до 200мс (в 10 раз).» > «Внедрил distributed tracing через Jaeger, сократив среднее время поиска инцидентов с 4 часов до 30 минут.» > «Мигрировал монолитный модуль на микросервисную архитектуру, что позволило команде сократить цикл деплоя с 2 дней до 2 часов.»

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

Languages: Go, Python, SQL
Frameworks: gin, gRPC, echo
Databases: PostgreSQL, Redis, ClickHouse, MongoDB
Infrastructure: Docker, Kubernetes, AWS/GCP, Terraform
Messaging: Kafka, RabbitMQ
Monitoring: Prometheus, Grafana, Jaeger

Образование: Университет, специальность, год выпуска. Если есть релевантные сертификаты (CKA, AWS) — укажите кратко.

3. Адаптация под вакансию

Это критически важно. Перед отправкой:

  • Изучите описание вакансии и выделите ключевые технологии
  • Переупорядочьте технологический стек так, чтобы релевантные шли первыми
  • Если в вакансии упоминается Kafka, а у есть опыт с ней — убедитесь, что это видно в достижениях
  • Используйте ту же терминологию, что в вакансии (если они пишут «event-driven architecture», а вы написали «асинхронная обработка» — замените)

4. LinkedIn

  • Заполните все секции: headline, about, experience, skills, recommendations
  • Headline — не «Ищу работу», а «Golang Developer | Microservices | Highload Systems»
  • Добавьте минимум 500 контактов (алгоритм LinkedIn показывает профиль чаще)
  • Публикуйте технические посты — это привлекает рекрутеров
  • Open to Work — включите видимость только для рекрутеров (чтобы текущий работодатель не видел)

5. GitHub-профиль

Для разработчика GitHub — это второе резюме. Убедитесь, что:

  • Есть 2–3 качественных репозитория (не форки, а свои проекты)
  • Каждый репозиторий с README, понятной структурой, тестами
  • Профиль pinned-репозитории отражают ваш лучший код
  • Если вносите вклад в open-source — это большой плюс

6. Красные флаги в резюме, которых нужно избегать

  • Самооценки: «ответственный, коммуникабельный, быстро учусь»
  • Кликбейт: «эксперт во всём»
  • Пустые места в таймлайне без объяснения
  • Слишком много мест работы с короткими периодами (менее 6 месяцев) без пояснений
  • Уровень владения технологиями в виде звёздочек или процентов (неинформативно)
  • Опечатки и грамматические ошибки — это сразу минус

Вопрос 4. Как эффективно добиваться более высокой зарплаты на собеседованиях?

Таймкод: 00:13:32

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

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

Кандидат затронул важный принцип — наличие конкурирующего оффера как рычага. Раскроем тему системно.

1. Никогда не называйте зарплату первыми

Это золотое правило переговоров. Кто называет число первым — тот проигрывает. Когда рекрутер спрашивает о зарплатных ожиданиях:

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

2. Имейте на руках конкурирующий оффер (Competing Offer)

Это самый мощный инструмент на переговорах:

  • Параллельно проходите собеседования в нескольких компаниях
  • Когда получили оффер от компании А, сообщите компании Б: «У меня есть оффер с компенсацией $X. Я очень заинтересован в вашей команде, но разница существенная. Есть ли возможность пересмотреть предложение?»
  • Это не шантаж, а нормальная рыночная практика. Компании к этому привыкли
  • Разница в 20–40% между офферами — это нормально, и компании часто могут подтянуть предложение

3. Знайте свою рыночную стоимость

Перед переговорами проведите исследование:

  • Glassdoor, Levels.fyi, Blind — зарплаты по компаниям и уровням
  • Хабр Карьера, Telegram-каналы — российский и СНГ-рынок
  • Otta, Wellfound (AngelList) — стартапы
  • Опросите коллег и знакомых (в индустрии это нормальная практика)

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

4. Обосновывайте ценность, а не потребности

Слабая позиция: «Мне нужно больше, потому что дорого жить в Москве.» Сильная позиция: «За последний год я реализовал систему, которая экономит компании 500Kвгоднаинфраструктуре.Ясчитаю,чтокомпенсацияв500K в год на инфраструктуре. Я считаю, что компенсация в X отражает этот вклад.»

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

  • Сколько денег вы сэкономили или заработали компании
  • Какую сложность вы закрыли
  • Какой эффект оказали на команду (менторинг, код-ревью, архитектурные решения)

5. Обсуждайте полный пакет (Total Compensation)

Зарплата — это только часть картины:

  • Базовая зарплата — фиксированная часть
  • Годовой бонус — 10–30% от базовой
  • Опционы/RSU — особенно важны в публичных компаниях (Google, Meta и т.д.)
  • Sign-on bonus — единовременная выплата при выходе, часто 5K5K–20K
  • Релокационный пакет — если переезд
  • Бенефиты — ДМС, обучение, оборудование, гибкий график
  • Удалёнка — сама по себе имеет денежный эквивалент

Если компания не может поднять базовую зарплату, можно попросить увеличить sign-on bonus или количество RSU.

6. Техника переговоров

  • Молчание после оффера: когда рекрутер называет число — помолчите 10–15 секунд. Это создаёт давление и часто рекрутер сам начинает улучшать условия.
  • «Я в восторге от возможности работать с вами, но компенсация ниже моих ожиданий. Есть ли гибкость в этом вопросе?» — позитивный тон, но чёткая позиция.
  • Всегда переговорите: даже если оффер хороший, спросите: «Это лучшее предложение, которое вы можете сделать?» В 30–40% случаев рекрутер вернётся с улучшенной версией.
  • Получите оффер в письменном виде — устные обещания ничего не стоят.

7. Распространённые ошибки

  • Благодарить и сразу соглашаться на первое предложение
  • Называть слишком низкую цифру из страха «спугнуть» компанию
  • Не готовиться к переговорам и импровизировать
  • Обсуждать зарплату до технических раундов (у вас нет рычага)
  • Лгать о других офферах — это легко проверяется и разрушает доверие