О себе и опыте

Кратко о теме

Блок «расскажите о себе» — это не светская беседа и не разминка. Интервьюер решает три задачи одновременно: понять уровень (какие решения вы принимали сами, а какие вам приносили готовыми), понять релевантность (насколько ваш контекст похож на их контекст — нагрузка, домен, размер команды, зрелость процессов) и понять как вы думаете и говорите (умеете ли структурировать, отличаете ли свою работу от работы команды, признаёте ли ограничения). Почти каждый вопрос из этого раздела — это одна из трёх задач, задетая с другой стороны. Поэтому готовиться нужно не к 68 вопросам, а к 5–6 заготовкам, которые вы умеете рассказывать в разной длине и под разным углом.

Базовая заготовка — питч на 90 секунд: кто вы по специализации и сколько лет в ней, где работаете сейчас и что за продукт (одна фраза бизнес-смысла плюс одна фраза масштаба), 2–3 задачи, которые вы решали лично, стек, и почему вы сейчас разговариваете с этой компанией. Всё. Не хронология с первого курса, не перечисление всех работодателей, не список из тридцати технологий. Хронология уместна, только если вас об этом прямо попросили («начиная с последнего места»), и тогда идти надо от последнего к первому, уделяя последнему месту 70% времени.

Вторая заготовка — портфель из 4–5 историй, каждая по схеме STAR (Situation → Task → Action → Result) или CARL (Context → Action → Result → Learning). STAR лучше для «расскажите про задачу/фичу/конфликт», CARL — для «расскажите про факап/ошибку», потому что в нём есть явное место под выводы. Хорошая история занимает 2–4 минуты, содержит один-два числовых факта и заканчивается результатом, а не описанием процесса. Полезно, чтобы истории покрывали разные грани: сложная техническая задача, задача с неопределённостью и переговорами, инцидент/факап, вещь, которую вы инициировали сами, и проект «с нуля». Тогда почти любой вопрос из этого раздела — это одна из пяти историй, повёрнутая нужной стороной.

Отдельно про измеримый результат — на нём валится большинство кандидатов. Правило: называйте метрику, направление и базу сравнения. «Ускорил ручку» — ничто; «p99 ручки каталога упал с 1.4 с до 180 мс при том же RPS, замеряли по гистограмме Prometheus за неделю до и после» — это ответ уровня «человек действительно это делал». Если точных цифр не помните, честнее сказать «порядок величины — примерно втрое, точных цифр по памяти не назову», чем выдумать красивое число: следующий вопрос обычно «а как вы это измеряли», и там выдумка рассыпается. Не-технические метрики тоже считаются: сокращение времени релиза, количество ручных часов в неделю, число инцидентов в квартал, стоимость инфраструктуры в месяц, доля флаки-тестов.

Ключевые правила языка: говорите «я», когда делали вы, и «мы», когда делала команда, — интервьюеры целенаправленно ловят кандидатов, которые за счёт «мы» присваивают чужую работу; уточняющий вопрос «а что конкретно делали вы?» звучит почти всегда. Не притворяйтесь, что знали ответ сразу, — правильная форма «сначала пробовали X, оказалось не то, потому что…, в итоге сделали Y». И следите за NDA: домен, масштаб и архитектуру описывать можно, конкретные цифры выручки, имена клиентов и куски кода — нет; фраза «детали под NDA, расскажу на уровне архитектуры» воспринимается как плюс, а не как уклонение.

Вопросы и ответы

Как вы попали в IT и почему?

Коротко. Интервьюер проверяет не биографию, а связность: осознанный ли это выбор, есть ли внутренняя мотивация помимо денег, и не рассыплетесь ли вы при первом же открытом вопросе. Сильный ответ — это короткая арка из трёх точек: точка входа (что зацепило), точка перелома (когда хобби/учёба стали профессией), точка «сегодня» (чем занимаетесь и что в этом нравится), всё за 60–90 секунд.

Глубже. Каркас формулировки: «Пришёл в IT из <исходная область/учёбы> — первый контакт был <что именно: курс, олимпиада, автоматизация рутины на работе>. Понял, что мне нравится <конкретика: видеть, как код превращается в работающий сервис / разбираться, почему система тормозит>. Первый коммерческий опыт получил в <год/компания-тип>, дальше сознательно ушёл в <бэкенд/Go>, потому что <причина, связанная с задачами, а не с зарплатой>. Сейчас <текущая роль> и мне интереснее всего <тип задач>». Важно: причина смены сферы должна быть «к чему-то», а не «от чего-то» — «в бэкенде мне нравится, что результат измеряется цифрами» звучит на порядок лучше, чем «в прежней профессии платили мало». Про деньги как один из мотивов говорить нормально, но не первым и не единственным пунктом.

Красные флаги: рассказ дольше трёх минут с подробностями школы; «случайно попал, друг позвал» без продолжения — это читается как отсутствие интереса к профессии; агрессивный негатив к прошлой сфере или прошлым работодателям; нестыковка дат с резюме (интервьюер держит его перед глазами). Типичная ошибка — сделать из ответа исповедь о выгорании: тему сложного пути можно упомянуть одной фразой, но фокус держите на том, что вас в профессии удерживает сейчас.

Опишите основной продукт, над которым вы работали. Какие конкретные задачи вы решали?

Коротко. Проверяется, понимаете ли вы бизнес-смысл того, что пишете, и умеете ли отделить свою работу от работы команды. Ответ строится из четырёх блоков: что за продукт и кому он нужен (1–2 фразы) → масштаб в цифрах → как устроено технически (крупными мазками) → 2–3 задачи лично ваших с результатом.

Глубже. Шаблон: «<Продукт> — это <что делает> для <кто пользователь>. Зарабатывает на <модель>, поэтому ключевая метрика для нас была <метрика>. По масштабу: активных пользователей, в пике, <объём данных> в <БД>, сервисов, команда человек. Технически: <язык/фреймворк>, <база>, <брокер>, <оркестрация>. Я отвечал за <домен/сервис> — три вещи, которыми занимался: во-первых, <задача> — <что сделал> — <результат в цифрах>; во-вторых, …».

Цифры масштаба важнее, чем кажется: они за две секунды сообщают, в какой лиге вы играли. Если реального хайлоада не было — не надо его придумывать, скажите честно «нагрузка небольшая, десятки RPS, но данные критичные, поэтому основная сложность была в консистентности и точности расчётов». Это нормальный и уважаемый ответ. Красные флаги: рассказ только про технологии без единого слова о том, что продукт делает («ну, микросервисы на Go с кафкой») — так отвечают люди, которым не давали контекста или которые им не интересовались; отсутствие «я» — сплошное «мы сделали»; пересказ всего роадмапа компании вместо своей зоны. Оставьте в ответе 1–2 крючка (например, «была нетривиальная история с идемпотентностью платежей») — интервьюер за них потянет, и разговор пойдёт по территории, которую вы готовили.

Какие задачи решали с помощью FFmpeg?

Коротко. Вопрос обычно возникает, если FFmpeg упомянут в резюме, и проверяет реальность этого пункта: делали вы транскодинг в проде или один раз вызвали ffmpeg из скрипта. Отвечать надо по схеме: класс задачи → как именно интегрировали (CLI-процесс, C-биндинги, отдельный воркер) → какой нетривиальный случай пришлось разбирать → границы своего знания.

Глубже. Типовые классы задач, вокруг которых строится честный ответ, если у вас такой опыт есть: транскодинг загруженного пользователями видео в набор рендишенов (-c:v libx264 -preset/-crf, отдельно аудио-дорожка); нарезка HLS/DASH (-f hls, длительность сегмента, плейлисты); генерация превью и спрайтов таймлайна (-vf fps=1/N,scale=); ремукс без перекодирования (-c copy) как дешёвая операция; извлечение и нормализация аудио; наложение водяных знаков и склейка (concat); чтение метаданных через ffprobe -show_streams -print_format json.

Каркас формулировки: «В <проект> пользователи загружали <тип медиа>. Я отвечал за пайплайн обработки: задача попадала в <очередь>, воркер на Go скачивал исходник в <хранилище>, запускал ffmpeg как отдельный процесс через exec.CommandContext с таймаутом, парсил прогресс из stderr и складывал результат в <S3/хранилище>, статус — в <БД>. Из нетривиального: <например, битые входные файлы, которые надо было отсеивать через ffprobe до постановки в очередь / контроль CPU, потому что транскодинг съедал все ядра и мешал остальным сервисам / подбор параметров, чтобы уложиться в бюджет по размеру файла>».

Что стоит проговорить как инженерные детали, они и есть предмет проверки: FFmpeg — это внешний процесс, а значит нужны таймаут и контекст, ограничение параллелизма (транскодинг CPU-bound, семафор на число воркеров ≈ числу ядер, -threads внутри самого ffmpeg), корректное убийство процесса при отмене (иначе зомби и утечка CPU), потоковая обработка вместо чтения файла целиком в память, и идемпотентность — повторная обработка задачи после ретрая не должна плодить дубликаты. Красный флаг: рассказывать про libav* и биндинги, если вы вызывали только CLI. Если опыт был поверхностный, так и скажите: «использовал как CLI-утилиту для <задача>, глубоко в кодеки не погружался» — это честная и нормальная позиция.

Что было самым интересным в других проектах?

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

Глубже. Каркас: «В <проект N-1> самым интересным было <задача>. Интересно потому, что <причина: пришлось разбираться в незнакомой области / не было готового решения / нужно было сначала измерить, а потом чинить>. Коротко: <2–3 фразы по STAR> и в итоге <результат>». Причина — самая ценная часть ответа: она сообщает интервьюеру ваш профиль. «Интересно было докопаться, почему сервис деградировал раз в сутки» — профиль человека, который любит диагностику. «Интересно было спроектировать схему данных так, чтобы новые типы тарифов добавлялись без миграций» — профиль проектировщика. Дальше вас будут звать на такие задачи, поэтому называйте то, что вам правда нравится.

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

Чем вы занимались на последнем проекте и какую роль выполняли?

Коротко. Проверяется зона ответственности и уровень самостоятельности: писали по готовым тикетам, сами декомпозировали задачи или отвечали за домен целиком. Ответ = роль формально + роль фактически (это разные вещи) + 2–3 конкретных задачи + за что вы отвечали единолично.

Глубже. Каркас: «Формально — <Middle/Senior Go-разработчик> в команде из человек (<состав: бэк, фронт, QA, PM>). Фактически отвечал за <сервис/домен> end-to-end: от обсуждения требований с <продактом/аналитиком> до выката и дежурства по нему. Из задач: <фича> — <что сделал>; <технический проект> — <что сделал>; плюс постоянный поток <саппорт/инциденты/ревью>. Единолично отвечал за <что-то конкретное: схему БД сервиса, контракт API, миграцию с X на Y>».

Отдельно проговорите «шапки», которые носили сверх кода: код-ревью, онбординг новичков, дежурство on-call, участие в грумингах, написание RFC/дизайн-доков, общение со смежными командами. Для позиций от Senior это ровно то, что отличает вас от Middle, и об этом забывают сказать. Уровень самостоятельности удобно показывать через глаголы: «предложил и защитил», «спроектировал», «декомпозировал и раздал» — это другой уровень, чем «реализовал по задаче». Красные флаги: неспособность назвать конкретный сервис или домен («я по всему проекту понемногу»); присвоение роли, которой не было («я был тимлидом» при отсутствии подчинённых и ответственности — уточняющие вопросы это вскроют за минуту); описание процесса вместо результата («ходил на дейли, брал задачи из джиры»).

Расскажите о вашем предыдущем месте работы и проекте, над которым вы работали;

Коротко. По сути повтор предыдущего вопроса, но про предыдущее (не текущее) место — здесь дополнительно проверяют динамику: вырос ли ваш масштаб ответственности от места к месту. Дайте компанию одной фразой (домен, размер), продукт одной фразой, свою роль и 2–3 задачи, и обязательно чем это место отличалось от нынешнего.

Глубже. См. выше каркас про продукт и роль. Отличие в акцентах: про прошлое место говорить надо короче (полторы–две минуты), и полезно закончить мостиком «оттуда я унёс <навык/подход>, а ушёл, потому что <нейтральная причина роста>». Причину ухода формулируйте через дефицит возможностей, а не через дефекты людей: «продукт вышел в поддерживающий режим, новых технических задач почти не осталось» — рабочая формулировка; «тимлид был некомпетентный» — почти гарантированный минус, даже если это правда. Если мест было много и они короткие, соберите их в одну обобщающую фразу («до этого три года в аутсорсе, десяток проектов, в основном интеграции и API»), иначе рассказ превратится в перечисление.

С какими базами данных вы работали?

Коротко. Проверяется не список названий, а глубина: отличаете ли вы «использовал через ORM» от «понимаю, как оно себя ведёт под нагрузкой». Отвечайте уровнями: основная БД, с которой работали плотно (и сразу одна деталь, показывающая глубину), затем остальные — одной строкой с указанием, для чего и насколько глубоко.

Глубже. Каркас: «Основная — : лет, писал SQL руками, проектировал схемы и индексы, разбирал планы через EXPLAIN (ANALYZE, BUFFERS), чинил <конкретика: блокировки при миграциях, распухание таблицы из-за долгих транзакций, неверный индекс на составном условии>. Из специфики использовал <партиционирование / JSONB / advisory locks / logical replication>. Также работал с — <кэш, распределённые блокировки, rate limiting>, с — <аналитика, N млрд строк>, с — <поверхностно, поддерживал legacy-сервис>».

Ключевой приём — честная градация: «плотно / использовал / трогал». Интервьюер почти всегда идёт вглубь по первой названной БД, поэтому первой называйте ту, где вам не страшно ответить на «как работает индекс», «что такое MVCC и почему таблица растёт», «что будет при SELECT ... FOR UPDATE в двух транзакциях». Красные флаги: перечислить восемь СУБД и посыпаться на вопросе про уровни изоляции; сказать «работал с PostgreSQL», имея в виду «ORM сам генерировал запросы» — за этим сразу идёт вопрос про план запроса. Хорошая практика — упомянуть одну проблему и как вы её диагностировали: это переводит разговор из режима «список» в режим «опыт».

Tell us about your experience in back-end development. Languages, projects. Participation in open source. GitHub activity

Коротко. Это питч, но с явным требованием покрыть четыре пункта. Отвечайте по ним же: языки с указанием уровня и лет, 2–3 проекта с масштабом, open source честно (contribution ≠ звёздочки), GitHub — что там можно посмотреть. Если open-source активности нет, скажите об этом прямо и переведите на то, что есть: pet-проекты, внутренние библиотеки, доклады.

Глубже. Каркас на английском, раз вопрос задан по-английски: «I’ve been doing backend for years. Primary language is Go — years in production; before that for years, so I’m comfortable reading it but wouldn’t call myself current. Main projects: — , <scale: RPS / data volume>, I owned ; and — . As for open source: I contributed <a fix to : / I maintain — it does , used internally by teams>. My GitHub has <what’s actually there: pet projects, solutions, forks>; the day-job code is in a private <GitLab/GitHub Enterprise>, so public activity doesn’t reflect my main work».

Последняя фраза важна: у большинства коммерческих разработчиков зелёный график пустой, и это нормально — не оправдывайтесь, просто объясните. Красные флаги: назвать в вклад в open source «ставил звёзды / форкнул репозиторий»; заявить владение пятью языками на одном уровне; дать ссылку на GitHub, где лежит один заброшенный туториал трёхлетней давности — если ссылку даёте, заранее посмотрите на профиль глазами интервьюера и приведите в порядок README у 1–2 репозиториев. Если пишете на английском не свободно — заранее отрепетируйте именно этот ответ, потому что часть таких интервью проверяет ровно язык, а не содержание.

What interesting/challenging tasks have you solved?

Коротко. Классический запрос на STAR-историю. Возьмите одну задачу, объясните, почему она была сложной (сложность должна быть инженерной: неопределённость, ограничения, масштаб — а не «было много кода»), опишите свои действия и назовите измеримый результат.

Глубже. Каркас: «The most challenging one was at . Situation: <what was broken / what the constraint was>. Task: I had to without <constraint: downtime / breaking the public API / extra hardware>. Action: first I <measured / reproduced> — ; the root cause turned out to be ; I , and to be safe we <flag / gradual rollout / shadow traffic>. Result: went from to , measured by ; the change has been in production for months».

Полезно заранее выбрать историю, где были: (1) неочевидная диагностика, (2) выбор между двумя вариантами с явными трейд-оффами, (3) проверяемый результат. Это три вещи, которые интервьюер оценивает в такой истории. Ошибки: назвать сложной задачу, которая сложна только из-за плохой организации («сложно было, потому что требования менялись каждый день») — если это ваша история, обязательно добавьте, что вы сделали с этим процессом; уйти в 10-минутный монолог с деталями, которые слушателю не нужны; закончить на «в итоге сделали» без результата. Держите наготове укороченную версию на 60 секунд: если вопрос идёт в скрининге, длинная версия неуместна.

Рассказать о себе: чем занимался, что нравится в айти?

Коротко. Две части: короткий питч (см. ниже вопрос «Расскажите о себе») плюс явная просьба назвать мотивацию. Второй части посвятите 2–3 фразы и сделайте их конкретными: не «нравится развиваться», а «нравится, что результат работы измерим — можно посмотреть на график и увидеть, стало лучше или нет».

Глубже. Каркас второй части: «В IT мне нравится <причина>. Конкретно это проявляется так: <пример из работы, где эта мотивация сработала>». Рабочие варианты причин, каждая из которых что-то говорит о вас: измеримость результата (профиль оптимизатора), возможность автоматизировать рутину (профиль инженера-инструментальщика), понимание, как система устроена внутри (профиль исследователя), влияние на продукт и пользователей (профиль продуктового разработчика), скорость обратной связи и постоянное обучение. Выберите ту, что правда ваша, и подкрепите примером — пример превращает шаблонную фразу в достоверную.

Красные флаги: только деньги и удалёнка; абстракции без примера («люблю сложные интересные задачи»); мотивация, которая противоречит вакансии (рассказывать про любовь к исследованиям и рефакторингу на позиции, где надо быстро катить продуктовые фичи, — прямой путь к «не подходит по ожиданиям»).

Расскажи о себе, чем занимаешься?

Коротко. См. ниже развёрнутый каркас в вопросе «Расскажите о себе». Отличие формулировки — акцент на настоящем времени: больше половины ответа должно быть про то, чем вы заняты сейчас, а не про карьерный путь.

Глубже. Практическая подсказка: начните с одной фразы-визитки («Go-разработчик, лет в бэкенде, сейчас в <домен>»), затем сразу переходите к текущим задачам этой недели-месяца — это звучит живо и сразу даёт интервьюеру материал для технических вопросов. Заканчивайте вопросом-мостиком: «Рассказать подробнее про <сервис> или про то, как у нас устроено <процесс>?» — так вы отдаёте управление разговором обратно, вместо того чтобы гадать, достаточно ли сказали.

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

Коротко. Вопрос наполовину технический: проверяют, писали ли вы SQL руками и есть ли у вас осмысленная позиция по слою доступа к данным, а не «взял GORM, потому что все берут». Сильный ответ: назвать инструменты, которыми пользовались, объяснить свой выбор через трейд-оффы и показать, как у вас организована граница между доменом и БД.

Глубже. Ландшафт, в котором надо ориентироваться: database/sql + драйвер (lib/pq, jackc/pgx — pgx v5 умеет и как драйвер database/sql, и в родном режиме с бинарным протоколом, пулом pgxpool, CopyFrom для батчей); sqlx — тонкая надстройка со сканированием в структуры; sqlc — генерация типобезопасного Go-кода из SQL-файлов на этапе сборки; squirrel/goqu — построители запросов для динамических фильтров; полноценные ORM — GORM, ent, bun.

Каркас ответа: «Основной подход — SQL пишу руками, а к Go-коду его привязываю через <sqlc / sqlx / pgx напрямую>. Причина: запросы к — это то, что чаще всего надо читать и оптимизировать, и мне важно видеть их дословно и уметь скопировать в EXPLAIN ANALYZE без реверс-инжиниринга. ORM использовал в <проект> для <CRUD-части/админки>, там он экономит время, но на горячих ручках мы всё равно спускались до сырого SQL. Слой доступа организую как репозитории по агрегатам: интерфейс объявляю в пакете, который им пользуется (сервисный слой), реализацию — в internal/storage/postgres; наружу репозиторий отдаёт доменные структуры, а не строки БД. Транзакции прокидываю <через явный тип-обёртку / через контекст с извлечением *sql.Tx>, чтобы юзкейс мог собрать несколько операций в одну транзакцию, не зная про SQL».

Что стоит упомянуть как признак практики: обязательный QueryRowContext/QueryContext с контекстом и таймаутом; закрытие rows через defer rows.Close() и проверка rows.Err() после цикла (забытая проверка — классический источник тихих потерь данных); только параметризованные запросы ($1, ?) — конкатенация строк это SQL-инъекция; настройка пула (SetMaxOpenConns, SetMaxIdleConns, SetConnMaxLifetime) с оглядкой на max_connections СУБД и наличие PgBouncer; миграции отдельным инструментом (goose, golang-migrate, atlas) и правило «сначала совместимое изменение схемы, потом код»; батчи через CopyFrom или многострочный INSERT вместо цикла с одиночными вставками; тесты репозиториев на реальной БД через testcontainers-go, а не на моках.

Красные флаги: «всегда ORM, SQL не нужен» и симметричное «ORM — зло, всегда только руками» — обе позиции без трейд-оффов читаются как отсутствие опыта; отсутствие ответа на «как вы делаете транзакцию через несколько репозиториев»; невозможность объяснить, что происходит при N+1 запросах в ORM.

Расскажите о вашем опыте работы с Golang, начиная с последнего места: какие задачи вы решали?

Коротко. Здесь прямо просят хронологию в обратном порядке — значит, идите строго так: последнее место подробно (60–70% времени), предыдущее короче, более ранние — одной фразой. По каждому месту: что за система, какие задачи на Go лично вы делали, какие технологии из го-экосистемы применяли.

Глубже. Каркас на одно место: «<Компания-тип>, <период>. Сервис <название/назначение> на Go: <что делает>, <масштаб>. Мои задачи: <1> — например, вынес <функциональность> из монолита в отдельный сервис, спроектировал gRPC-контракт и сделал бесшовный перевод трафика; <2> — реализовал <асинхронный пайплайн> на воркерах с <Kafka/NATS>, обработка сообщений в сутки; <3> — занимался производительностью: профилировал через pprof, нашёл <аллокации в горячем пути / лишние сериализации>, снизил <метрика> на %. Из инструментов Go: <стандартная библиотека, context, errgroup, sync, генерики с 1.18, net/http, grpc-go, zap/slog, testify, golangci-lint, go test -race, бенчмарки>».

Полезно явно назвать «уровень погружения в язык»: работали ли с горутинами и синхронизацией руками, писали ли что-то, где важна была работа с памятью и GC, трогали ли unsafe/reflect, писали ли генерики, свои линтеры или кодогенерацию через go:generate. Это отделяет «пишу CRUD на Go» от «понимаю рантайм». Уместно упомянуть свежие версии: перевод сервисов на Go 1.22+ и то, как изменившаяся семантика переменной цикла убрала целый класс багов с горутинами в for; переход на log/slog вместо самописного логгера; range-over-func-итераторы из 1.23 в своей библиотеке; обновление на 1.24, где map переехал на Swiss Tables и часть сервисов бесплатно получила прирост. Только не выдумывайте — говорите про то, что реально делали.

Красные флаги: хронология вперемешку, кандидат сам теряется в датах; невозможность назвать ни одной задачи, специфичной для Go (значит, язык был декорацией); пересказ обязанностей из вакансии вместо задач.

Над каким проектом сейчас работаете? Какие задачи решаете?

Коротко. Проверяют актуальность навыков и то, насколько вы вовлечены прямо сейчас. Отвечайте в настоящем времени: продукт одной фразой, ваша текущая зона, 2–3 задачи, над которыми работаете буквально в этом спринте, и одна проблема, которую сейчас решаете.

Глубже. См. выше каркас про продукт. Отличие: здесь особенно хорошо работает «задача, которая у меня открыта прямо сейчас» — «сейчас переписываю <компонент>, потому что <причина>, самое неприятное там — <конкретная сложность>». Это невозможно сымитировать, и интервьюер это чувствует. Если вы не работаете сейчас — так и скажите: «сейчас в поиске, последний проект был <когда>, в паузе делаю <pet-проект/изучаю X>». Пауза в резюме не проблема, проблема — попытка её замаскировать. Помните про NDA: если проект закрытый, описывайте задачу в обобщённых терминах («сервис расчёта лимитов»), без внутренних названий и цифр.

Как оцениваете свои навыки в проектировании?

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

Глубже. Каркас: «Могу самостоятельно спроектировать <масштаб: отдельный сервис среднего размера с БД, очередью и внешними интеграциями> — делал это раз, последний — <проект>: <что проектировал: контракты, схему данных, схему отказоустойчивости, план миграции>. Уверенно себя чувствую в <декомпозиции по доменам, проектировании API и схемы БД, выборе между синхронным и асинхронным взаимодействием, идемпотентности и семантике повторов>. Меньше опыта в <например: проектирование под нагрузку в сотни тысяч RPS, мультирегиональные развёртывания, сложная консистентность между хранилищами> — там я опираюсь на чужой опыт и валидирую решение с более опытными коллегами. Проектирую документом: пишу <RFC/дизайн-док> с вариантами и трейд-оффами, выношу на обсуждение, потом уже код».

Именно последняя часть — про процесс — часто ценится выше самих навыков: она показывает, что вы умеете делать решения обсуждаемыми и обратимыми. Полезно назвать критерии, по которым вы принимаете решения: требования к согласованности, допустимая задержка, стоимость, сложность эксплуатации, обратимость. Красные флаги: «10 из 10, спроектирую что угодно»; заниженная самооценка без опоры на факты («ну, наверное, слабо») — интервьюер поверит; неспособность назвать хоть один трейд-офф из своего решения. Готовьте заранее один пример «мы выбрали X вместо Y, потому что …, и вот чем за это заплатили» — вопрос про проектирование почти всегда упирается в этот пример.

Какие книги по программированию читали?

Коротко. Проверяют не эрудицию, а привычку к системному обучению: важнее назвать 2–3 книги, которые вы правда прочитали и можете обсудить, чем список из пятнадцати корешков. Обязательно к каждой — одна фраза о том, что вы из неё применили.

Глубже. Реальный список, по которому обычно ведут разговор с Go-бэкендером: Донован и Керниган «The Go Programming Language» (базовая книга по языку), Тейва Харсаньи «100 Go Mistakes and How to Avoid Them» (очень удобно цитировать конкретные ошибки), Клеппман «Designing Data-Intensive Applications» (репликация, консистентность, стриминг — де-факто обязательная), Мартин Фаулер «Patterns of Enterprise Application Architecture» и «Refactoring», Эванс «Domain-Driven Design», «Чистая архитектура» Мартина (полезно упомянуть с оговоркой, что применяете выборочно), Ричардсон «Microservices Patterns», Бейер и др. «Site Reliability Engineering» (Google, доступна бесплатно), Рогов «PostgreSQL изнутри», Таненбаум «Современные операционные системы», Кормен и др. «Алгоритмы: построение и анализ», Хопкрофт/«Компьютерные сети» Таненбаума для сетевой базы.

Каркас: «Из последнего читал <книга> — оттуда взял <конкретика: понял, зачем нужен уровень изоляции snapshot, и перестал вешать SERIALIZABLE везде подряд>. Раньше — <книга>, из неё в работе использую <паттерн/подход>. Постоянно возвращаюсь к <книга> как к справочнику». Красные флаги: перечислить классику, которую явно не читали (следующий вопрос — «а что там про X?»); сказать «книг не читаю, всё есть в интернете» без объяснения, чем вы их заменяете; назвать только книги десятилетней давности и ничего современного. Абсолютно нормально ответить «книги читаю редко, учусь по документации, исходникам и докладам» — но тогда назовите конкретные источники, иначе ответ выглядит как отговорка.

Какая задача была сложной, но интересной и успешно реализованной?

Коротко. Главный STAR-вопрос этого блока. Возьмите историю, где сложность была инженерной, ваш вклад — определяющим, а результат — измеримым, и уложите её в 3 минуты по схеме: контекст и ограничения → в чём была неочевидность → что вы делали и какие варианты отбросили → результат в цифрах → что бы сделали иначе.

Глубже. Развёрнутый каркас, который стоит записать и проговорить вслух:

• Situation (20 сек). «<Сервис> отвечал за <функцию>. Проблема: <симптом — например, при пиковой нагрузке росли таймауты и клиенты получали 5xx>, бизнес терял <последствие>».
• Task (10 сек). «Мне поставили задачу <цель> при ограничениях: <без даунтайма / за две недели / без нового железа>».
• Action (60–90 сек), самая важная часть. «Начал с измерения: <как воспроизвёл, какие метрики снял — pprof, трейсы, логи, нагрузочный тест>. Первая гипотеза была , она не подтвердилась, потому что <факт>. Оказалось, что <настоящая причина>. Рассматривал два варианта: — быстро, но <минус>; — дороже, но <плюс>. Выбрал , потому что <критерий>. Реализовал <что именно>, выкатывал <через фиче-флаг / канареечно на 5% трафика>, следил за <метрика>».
• Result (20 сек). «<Метрика> изменилась с до , <вторая метрика> — <как>. Решение живёт в проде месяцев, повторных инцидентов не было».
• Learning (10 сек). «Вынес для себя: <вывод>; после этого мы добавили <алерт/тест/дашборд>, чтобы ловить это раньше».

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

Любимая база данных и почему?

Коротко. Вопрос-провокация на догматизм: правильный ответ — «PostgreSQL как выбор по умолчанию, потому что <причины>, но выбор зависит от профиля нагрузки». Назовите одну БД, дайте 2–3 технические причины и сразу пример, когда бы вы её не взяли.

Глубже. Каркас: «По умолчанию беру PostgreSQL: транзакции и понятная семантика MVCC, богатый SQL с оконными функциями и CTE, JSONB там, где схема плавает, расширения (pg_stat_statements, PostGIS, pgvector), зрелая экосистема миграций и бэкапов, и главное — предсказуемость: я умею читать его планы и знаю, где у него больно (долгие транзакции и bloat, блокировки при DDL, вакуум). Не возьму его для <аналитики по миллиардам строк — там ClickHouse; для кэша и rate limiting — Redis; для полнотекстового поиска с фасетами — Elasticsearch/OpenSearch; для временных рядов — TimescaleDB/Victoria Metrics>».

Хорошо звучит вторая часть — «а что мне в ней не нравится»: способность назвать слабости любимого инструмента отличает практика от фаната. Для Postgres это, например, отсутствие встроенного шардирования, тяжёлые соединения (процесс на коннект → нужен пулер), поведение вакуума на больших горячих таблицах, боль с блокировками при некоторых ALTER TABLE на старых версиях. Красные флаги: «MongoDB, потому что не надо думать о схеме»; «NoSQL быстрее, чем SQL» без уточнения профиля нагрузки; ответ «любимой нет, работаю с любой» — это уклонение, интервьюер хочет увидеть аргументацию, а не универсальность.

Какие проблемы приходилось решать на бекенде?

Коротко. Открытый вопрос-каталог: назовите 3–4 класса проблем, с которыми реально сталкивались, и по одной из них пройдите вглубь. Отвечать надо классами (производительность, консистентность, отказоустойчивость, эксплуатация), а не отдельными тикетами.

Глубже. Классы, из которых стоит выбрать свои: производительность (медленные запросы к БД и неверные индексы, N+1, лишние аллокации и GC-давление, блокировки на мьютексах, неверные таймауты и размер пула соединений); консистентность (идемпотентность обработки платежей и вебхуков, дубли из-за at-least-once доставки в брокере, состояние гонки при параллельном обновлении, распределённые транзакции и паттерн outbox); отказоустойчивость (ретраи с экспоненциальной задержкой и джиттером, circuit breaker, деградация при недоступности зависимости, graceful shutdown и потеря запросов при деплое); эксплуатация (нехватка наблюдаемости — «упало, а почему, непонятно», алерты на симптомы вместо причин, миграции схемы без даунтайма, обратная совместимость API); данные (рост таблиц, партиционирование, архивация, миграции больших объёмов).

Каркас: «Из повторяющихся — три класса. Первый: <класс>, самый показательный случай — <краткая история и результат>. Второй: <класс> — <одна фраза>. Третий: <класс> — <одна фраза>. Про первый могу рассказать подробнее». Дальше держите готовую STAR-историю по первому классу. Красный флаг: ответ уровня «ну, баги фиксил»; перечисление проблем, которые вы читали в статьях, но не проживали — это вскрывается вопросом «а как именно вы это диагностировали?».

Have you had to run a profiler in production?

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

Глубже. Техническая канва, на которой строится достоверный ответ для Go. net/http/pprof вешается на служебный порт (никогда не на публичный — это утечка данных и вектор DoS), даёт /debug/pprof/heap, /profile?seconds=30 (CPU), /goroutine?debug=2 (полные стеки — первое, что смотрят при подозрении на утечку горутин), /mutex, /block, /allocs. CPU-профиль работает через сэмплирование по сигналу (по умолчанию 100 Гц), оверхед обычно единицы процентов и его допустимо снимать в проде на одном инстансе; heap-профиль почти бесплатен, потому что сэмплируется каждые ~512 КБ аллокаций (runtime.MemProfileRate); а вот mutex и block профили включаются явно (runtime.SetMutexProfileFraction, runtime.SetBlockProfileRate) и стоят заметно дороже — их включают точечно и выключают. Для «а что было час назад» существует непрерывное профилирование: Pyroscope/Grafana Phlare, Datadog Continuous Profiler, Google Cloud Profiler. Дополняют картину GODEBUG=gctrace=1, runtime/trace (для планировщика, задержек и блокировок) и, с Go 1.21+, PGO — сохранённый прод-профиль (default.pgo) кладут в репозиторий, и компилятор использует его для инлайнинга и девиртуализации, типичный выигрыш единицы процентов CPU.

Каркас: «Yes. In we had <symptom: memory growing until OOM kill every ~6 hours>. We exposed net/http/pprof on an internal-only port, took a heap profile from a live pod and compared it with a baseline via go tool pprof -base. It pointed at <cause: goroutines blocked on a channel nobody read from / a slice retained by a long-lived cache / unclosed HTTP response bodies>. Confirmed with the goroutine profile: goroutines stuck in . Fixed by , memory flattened at MB, restarts stopped». Если такого опыта нет, скажите: «In production — no; I profiled locally and in the load-testing environment, using . I know how it’s set up in prod and what the overhead is, but I haven’t been the one running it there». Красные флаги: заявить прод-профилирование и не суметь ответить, какой оверхед у CPU-профиля и почему heap-профиль не показывает всё подряд; путать heap (живые объекты по умолчанию, inuse_space) и allocs (все аллокации за время жизни процесса).

Какие интересные или технически сложные задачи решал?

Коротко. См. выше «Какая задача была сложной, но интересной». Отличие — множественное число: назовите 2–3 задачи по одному предложению, дайте интервьюеру выбрать, и разверните ту, которую он выберет.

Глубже. Приём «меню» экономит время обоим: «Могу рассказать про три: <миграция с X на Y без даунтайма>, <разбор деградации по хвостовым задержкам> и <проектирование идемпотентного платёжного пайплайна>. Что интереснее?». Это заодно демонстрирует, что у вас правда есть несколько историй, а не одна вызубренная. Держите в меню задачи из разных областей (данные, конкурентность, интеграции, эксплуатация) — так выше шанс попасть в то, что интересно этой команде.

С какими проблемами при длительном продукте приходилось сталкиваться в практике?

Коротко. Вопрос про legacy и эволюцию системы: проверяют, работали ли вы с кодом, который живёт годами, или только со стартапами «с нуля». Назовите 3–4 характерные проблемы долгоживущего продукта и то, как вы с ними обращались — не «переписали всё», а как управляли изменениями.

Глубже. Что действительно болит в долгоживущих системах и о чём стоит говорить: накопленный технический долг и отсутствующие знания — авторы ушли, документации нет, поведение выясняется чтением кода и логов; несовместимые изменения — API, которым пользуются десятки клиентов, нельзя просто поменять, нужны версионирование, deprecated-период и телеметрия по использованию старых полей; миграции данных на больших таблицах — ALTER TABLE с блокировкой на терабайтной таблице, миграции в несколько шагов (добавить колонку → бэкфилл батчами → переключить чтение → переключить запись → удалить старое), инструменты вроде pg_repack; эрозия схемы — поля, значение которых менялось со временем, «мусорные» статусы, данные, которые нельзя удалить из-за неизвестных потребителей; рост зависимостей и обновления — застрявшая версия Go или библиотеки, уязвимости (govulncheck), болезненный апгрейд; производительность, которая деградирует незаметно — таблица росла годами и однажды индекс перестал влезать в память; тесты — либо их нет, либо они флаки, и любой рефакторинг превращается в лотерею; организационное — сменилось несколько команд-владельцев, границы ответственности размыты.

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

Какой был самый интересный проект, который вы разрабатывали?

Коротко. См. выше «Что было самым интересным в других проектах». Отличие в масштабе единицы рассказа: здесь речь про проект целиком, а не про задачу, поэтому добавьте, чем проект был интересен как система (архитектура, домен, масштаб), а не только чем интересна была ваша задача.

Глубже. Каркас: «<Проект> — <что делал>. Интересен был тем, что <нестандартная составляющая: жёсткие требования по задержке / необычный домен, в котором пришлось разбираться / строили с нуля и все решения были нашими>. Моя часть — <зона>. Самое запомнившееся — <история на 3–4 фразы>». Обязательно скажите, чем этот опыт полезен для позиции, на которую вы собеседуетесь, — это превращает ностальгию в аргумент.

Работали ли вы с масштабированием баз данных?

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

Глубже. Лестница масштабирования, по которой удобно себя разместить: (1) оптимизация в пределах одного инстанса — индексы, переписывание запросов, денормализация, батчинг, снижение числа запросов, настройка work_mem/пула, PgBouncer в transaction-режиме; (2) вертикальное масштабирование — просто больше железа, самый дешёвый по сложности шаг; (3) чтение с реплик — асинхронная репликация, проблема отставания реплики (replication lag) и «прочитал свою запись» — типовое решение: писать и читать критичные вещи с мастера, остальное с реплик; (4) кэш — Redis/локальный, инвалидация, проблема «cache stampede» и singleflight; (5) партиционирование — секционирование по времени или по ключу, отсечение партиций в планах, автоматическое создание и архивация; (6) шардирование — выбор ключа шардирования, ресолвинг шарда в приложении или через прокси (Citus, Vitess), боль с кросс-шардовыми запросами и уникальностью; (7) вынос профиля нагрузки в другое хранилище — аналитика в ClickHouse, поиск в Elasticsearch, счётчики в Redis, CDC через Debezium.

Каркас: «Полноценным шардированием не занимался — скажу честно. Из реального: <партиционировал таблицу событий по месяцам, что позволило удалять старые данные через DETACH PARTITION вместо DELETE и убрало распухание>; <развёл чтение по репликам, отдельно решив проблему отставания для сценария <какого>>; <настроил PgBouncer и пул на стороне приложения, после чего перестали упираться в max_connections>. Понимаю, как устроено шардирование и какие с ним проблемы, но в проде его не внедрял». Такой ответ сильнее, чем размытое «да, работал» с последующим провалом на вопросе «как выбирали ключ шардирования». Красные флаги: называть «масштабированием» добавление индекса; утверждать, что реплики решают проблему записи; не знать про отставание реплик и его последствия.

Какая была самая большая фича? Были ли задачи более чем на один спринт?

Коротко. Проверяют, умеете ли вы работать с крупной задачей: декомпозировать, оценивать, вести её через несколько итераций и не сорвать сроки. Ответ: масштаб фичи (в неделях/спринтах и людях), как вы её разбили, как выкатывали и что было самым рискованным.

Глубже. Каркас: «Самая крупная — <фича>, заняла спринтов, участвовало человек, я был <роль: ответственным за бэкенд-часть>. Начал с <дизайн-док/RFC>, где описал <контракты, схему данных, этапы>. Разбил на этапов так, чтобы каждый выкатывался в прод самостоятельно и был бесполезен, но безопасен: сначала <схема БД и запись данных без чтения>, потом <API за фиче-флагом>, потом <включение на внутренних пользователях>, потом <раскатка на 100%>. Риски: <зависимость от смежной команды / неопределённость в требованиях>; закрывал их <как: договорились о контракте заранее и замокали, пока их часть не готова>. По срокам: <уложились / сдвинулись на N дней из-за <причина>, о чём предупредил за <срок> до дедлайна>».

Здесь ценится не героизм, а управляемость: фиче-флаги, обратная совместимость, промежуточные выкаты, ранняя эскалация проблем со сроками. Отдельный плюс — честный рассказ про сдвиг сроков: «предупредил заранее, предложил урезать скоуп до <минимума>» — это поведение сеньора. Красные флаги: «фича на полгода, катили одним куском в конце» без объяснения, почему нельзя было иначе; «сроков не было, делали пока не сделали»; неспособность назвать, как вы её декомпозировали.

Расскажите о себе, о команде и т. д.

Коротко. Составной вопрос: питч плюс контекст команды. Про себя — стандартные 90 секунд (см. «Расскажите о себе»), про команду — состав, ваша роль в нём, процессы и как принимаются решения. Интервьюер прикидывает, впишетесь ли вы в их устройство.

Глубже. Каркас про команду: «Команда человек: бэкенд, фронт, QA <есть/нет>, аналитик, продакт, тимлид. Я <позиция в команде: один из двух сеньоров, менторю двоих джунов>. Процессы: <двухнедельные спринты со скрам-церемониями / канбан с WIP-лимитами>, задачи приходят от <продакта/аналитики>, оценку даём <как>. Код-ревью обязательное, апрува, CI гоняет <тесты, линтеры, интеграционные>. Релизим <как часто>, выкат <через ArgoCD/CI, канареечно>. Дежурство <есть/нет>, я <участвую/нет>. Решения по архитектуре принимаем <через дизайн-док и обсуждение / тимлид решает>». Такой ответ заодно показывает вашу инженерную культуру: если вы говорите про фиче-флаги, дежурства и дизайн-доки, это считывается сразу.

Красные флаги: рассказ о команде через жалобы; неспособность описать процесс («ну, как-то работаем»); противоречие с ответами на другие вопросы (сказали «релизим раз в две недели», а потом «катим по десять раз в день»). Полезно закончить фразой о том, какая среда вам подходит, — это честная взаимная калибровка: «мне комфортно, когда есть код-ревью и понятная зона ответственности; полностью без процессов работать могу, но считаю это временным состоянием».

Расскажи самую сложную или интересную инженерную задачу, которую приходилось решать

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

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

Какую самую сложную инженерную задачу вы решали?

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

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

Чем занимаешься на текущем месте?

Коротко. См. выше «Над каким проектом сейчас работаете». Разница только в неформальности тона: ответ короче, 60–90 секунд, в настоящем времени, с 2–3 конкретными задачами.

Глубже. Для короткого формата работает схема «зона → задача недели → чуть о команде»: «Отвечаю за <сервис>, это <одна фраза>. На этой неделе занимаюсь <задача>. Кроме кода — ревью, дежурство раз в <период> и участие в проектировании <чего>». Не забудьте оставить крючок для следующего вопроса.

Как попал в первую компанию?

Коротко. Проверяют настойчивость и адекватность старта: как искали, что предъявили без опыта, как прошли отбор. Хороший ответ — короткая фактическая история с одной деталью, которая показывает вашу инициативу.

Глубже. Каркас: «Искал <как: через стажировку/джоб-борды/знакомых/митап>. К моменту поиска у меня было <что предъявить: пет-проект, курсовые, вклад в open source, домашнее задание>. Прошёл <сколько-то> собеседований, получил оффер в <тип компании>. Взяли, как я понимаю, за <что: базу по алгоритмам / то, что притащил рабочий проект / готовность быстро учиться>. Первые полгода занимался <что>». Даже если попали «по знакомству» — это нормально и говорить об этом честно можно, важно добавить, что было дальше: «позвал знакомый, но собеседование было общее, и первые задачи мне никто не облегчал».

Красные флаги: длинная сага о десятках отказов с обидой; «взяли, потому что больше никого не было» (самоуничижение); нестыковка с датами в резюме. Для кандидатов с 8+ годами опыта этот вопрос обычно просто разминка — не тратьте на него больше минуты.

Расскажи про опыт с базами данных?

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

Глубже. Полезно сразу задать структуру ответа самому: «Разложу по трём вещам: где использовал, что проектировал сам, что чинил». Третий пункт — про починку — самый ценный: «переписал запрос, который делал seq scan на 40 млн строк, добавив составной индекс под условие и сортировку — время упало с до »; «нашёл, что таблица распухала из-за долгих транзакций в аналитическом сервисе, вынес его на реплику»; «поймал дедлок из-за разного порядка блокировки строк в двух транзакциях, зафиксировали порядок обновления». Каждая такая фраза — приглашение к техническому разговору, в котором вы сильны.

Какие ресурсы используешь для своего развития?

Коротко. Проверяют, есть ли у вас система обучения и не остановились ли вы. Назовите 3–5 конкретных источников разного типа (документация и исходники, книги, конференции/доклады, рассылки/блоги, практика) и добавьте, что из последнего прочитанного применили.

Глубже. Конкретика, которую можно называть Go-разработчику, не выдумывая: официальный блог go.dev/blog и release notes к каждой версии, golang.org/x/... и исходники стандартной библиотеки (лучший источник по идиомам), Go Wiki и CodeReviewComments, GopherCon и русскоязычные конференции (GolangConf, HighLoad++), подкасты и рассылки (Go Weekly), качественные блоги по рантайму и производительности, документация PostgreSQL и книга Рогова, статьи в инженерных блогах компаний, курсы по системному дизайну, чтение чужих PR в популярных репозиториях. Отдельная категория — практика: pet-проекты, разбор чужого кода, воспроизведение проблем в песочнице, участие в внутреннем клубе разбора инцидентов.

Каркас: «Основа — документация и исходники: когда что-то непонятно, иду в код стандартной библиотеки, это быстрее статей. Слежу за релизами Go — читаю release notes к каждой версии. Из регулярного — <рассылка/подкаст/блог>. Раз в <период> читаю книгу — последняя была <название>, из неё применил <что>. Плюс практика: <pet-проект / участие в open source / выступление с докладом>, потому что читать без применения у меня не работает». Красные флаги: «смотрю ютуб» без конкретики; список из двадцати курсов без единого результата; «развиваюсь на рабочих задачах» как единственный ответ — это допустимо, но добавьте, как вы выходите за пределы того, что попадает в тикеты.

Вопросы про текущее место работы, опыт, команду и процессы.

Коротко. Это не один вопрос, а обозначение блока: интервьюер будет спрашивать про продукт, вашу роль, команду, процессы разработки и релизов. Готовьте четыре коротких блока — продукт, я, команда, процессы — по 30–60 секунд каждый и соединяйте по запросу.

Глубже. Блок «процессы» готовят реже всего, а спрашивают часто. Что стоит уметь описать: как задача проходит путь от идеи до прода (кто ставит, как оценивается, как декомпозируется); правила код-ревью (сколько апрувов, что блокирует мёрдж, есть ли договорённости по стилю и линтерам); тестирование (какие уровни есть, кто пишет, есть ли QA, что гоняется в CI); ветвление и релизы (trunk-based или git-flow, как часто катите, есть ли откат в один клик, фиче-флаги); инциденты (есть ли дежурство, как заводится инцидент, пишете ли постмортемы); документация (RFC, ADR, README сервисов). Отвечайте фактами, как есть, включая слабые места: «постмортемы у нас пишутся не всегда, я это считаю проблемой и на паре инцидентов писал сам» — такой ответ и честный, и показывает инициативу. Красный флаг — идеализированное описание процессов, которое разваливается при уточняющем вопросе «а сколько времени у вас проходит от мёрджа до прода?».

Какие задачи вы выполняли на предыдущем месте работы?

Коротко. См. выше «Расскажите о вашем предыдущем месте работы». Здесь фокус узкий — именно задачи: назовите 3–4 типовых и 1–2 выделяющихся, с результатом.

Глубже. Удобный приём — разделить на «поток» и «проекты»: «Поток — это <продуктовые фичи в домене X, поддержка и разбор инцидентов, ревью>, примерно <60>% времени. Проекты — крупные вещи, которые вёл: <1>, <2>. Плюс инициативы, которые я сам предложил: <3>». Такое разделение сразу отвечает на невысказанный вопрос «а он только тикеты закрывает или что-то двигает?».

Над каким самым интересным проектом вы работали? Какие интересные фичи вы реализовали?

Коротко. См. выше «Какой был самый интересный проект». Вторая часть требует конкретных фич — назовите 2–3, каждую с одной технической деталью, за которую можно зацепиться.

Глубже. Каркас на фичу: «<Фича> — <что даёт пользователю>. Технически интересна тем, что <деталь: нужно было отдавать результат за мс, поэтому считали заранее и держали в <кэше> / требовалась строгая идемпотентность, потому что клиент ретраил по таймауту / данные приходили из трёх источников с разной свежестью и надо было согласовать>. Реализовал <что именно я сделал>, результат — <метрика/эффект>». Отбирайте фичи не по «крутизне» для пользователя, а по инженерной начинке: интервьюеру интересно, где вы принимали решения. Ошибка — рассказывать про фичу с точки зрения продакта («мы сделали красивую страницу профиля») без единой инженерной детали.

Насколько вы следите за обновлениями языка, нововведениями и т.д.?

Коротко. Проверка на «застрял в Go 1.13»: назовите, как именно следите (release notes, блог, рассылки), и приведите 2–3 конкретных нововведения последних версий с оценкой, что из этого вы реально используете.

Глубже. Фактура по свежим версиям, которую стоит держать в голове (Go 1.22–1.24): 1.22 — переменная цикла for теперь создаётся на каждой итерации, что убирает классический баг с захватом переменной в горутинах и замыканиях; math/rand/v2; расширенные шаблоны в net/http.ServeMux (методы и wildcards в путях); улучшения PGO. 1.23 — итераторы: range по функциям (iter.Seq, iter.Seq2) и пакет slices/maps с итераторными функциями; пакет unique для интернирования значений; изменения в time.Timer/Ticker (таймеры собираются GC без Stop, каналы больше не буферизованы), опциональная телеметрия тулчейна. 1.24 — реализация map переехала на Swiss Tables (быстрее и экономнее по памяти, без изменения семантики), обобщённые псевдонимы типов, пакет weak и runtime.AddCleanup вместо SetFinalizer, os.Root для операций внутри каталога, testing.B.Loop для корректных бенчмарков, директива tool в go.mod вместо tools.go, omitzero в тегах encoding/json.

Каркас: «Читаю release notes к каждому релизу и обновляюсь без долгих пауз. Из последнего, что реально повлияло на код: с 1.22 перестал писать x := x в циклах перед запуском горутин; на 1.24 обновились и получили <прирост> просто от новой реализации map; сейчас присматриваюсь к <итераторам / omitzero>, но в бой ещё не тащил, потому что <причина>». Правило: говорите отдельно про «знаю» и «применяю» — попытка выдать список из release notes за личный опыт вскрывается первым уточняющим вопросом. Красный флаг: «не слежу, язык же стабильный» — стабильность обратной совместимости не отменяет того, что вы должны знать, чем писать сегодня.

Расскажи про свой опыт.

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

Глубже. Каркас: « лет в бэкенде, из них на Go. Последнее место — <домен, размер компании>, отвечал за <зона>, масштаб <цифры>. До этого — <домен>, там делал <одна фраза>. Стек, с которым работаю постоянно: <Go, PostgreSQL, Redis, Kafka, Docker/Kubernetes, gRPC/REST, Prometheus/Grafana>. Сильнее всего я в <конкретика: проектирование сервисов с асинхронной обработкой и требованиями к идемпотентности / диагностика проблем производительности>. Куда интереснее углубиться — в последний проект или в технические детали?». Держите в голове три длительности одного и того же питча: 30 секунд (скрининг рекрутера), 90 секунд (техническое интервью), 3–4 минуты (если явно попросили подробно). Тренируйте вслух с секундомером — на бумаге все тексты кажутся короткими.

Над каким последним проектом вы работали?

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

Глубже. Финал проекта — часть ответа, которую забывают: «выкатили в прод, сейчас обслуживает <нагрузка>» или «проект закрыли на этапе <какой>, потому что <причина>». Закрытые проекты — не стыдно, стыдно не уметь сказать, что вы из них вынесли. Каркас для такого случая: «Проект остановили, потому что <бизнес-причина>. Технически мы успели <что>, и я вынес <вывод: раньше проверять гипотезу дешёвым прототипом, чем строить полноценную платформу>».

Каких значимых результатов вы достигли на проекте?

Коротко. Прямой запрос на цифры. Назовите 2–3 результата в формате «что было → что стало → как измеряли», и хотя бы один из них должен быть бизнесовым, а не только техническим.

Глубже. Категории результатов и как их формулировать: производительность — «p95 ответа <ручка> с до при том же трафике, по гистограмме Prometheus»; надёжность — «число инцидентов по нашему сервису с до в квартал», «доступность % за полугодие», «MTTR с до после того, как добавили <алерты/раннбук>»; деньги — «стоимость инфраструктуры сервиса упала на % после <оптимизации/перехода на <решение>>»; скорость команды — «время прохождения CI с до минут», «релизы с раз в две недели до ежедневных»; продукт — «конверсия шага выросла на п.п. по A/B-тесту»; устранение ручного труда — «убрал ручную процедуру, которая занимала часов в неделю».

Каркас: «Три вещи, которыми могу подтвердить пользу. Первое — <результат с цифрой> — это была моя инициатива, я <что сделал>. Второе — <результат>. Третье — не измеряется цифрой, но важно: <например, вырастил джуна до самостоятельной работы / оставил после себя документацию и тесты, после чего онбординг новых людей в сервис перестал требовать моего участия>». Важная оговорка про честность: если результат командный, так и скажите — «команда снизила X, мой вклад — <конкретная часть>». Обратите внимание на разницу процентных пунктов и процентов: «конверсия выросла на 2 п.п. с 10% до 12%» — корректно, «выросла на 2%» — нет. Красные флаги: результаты без базы сравнения; приписывание себе эффекта, который дал не ваш код (например, рост выручки на фоне маркетинговой кампании); полное отсутствие цифр — тогда хотя бы дайте порядок величины и скажите, чем измеряли.

Какая задача за последнее время? Которая изначально показалась сложной, но потом вы ее решили?

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

Глубже. Каркас: «Задача выглядела страшно, потому что <причина: незнакомая область / чужой код без документации / жёсткий дедлайн / никто в команде этого раньше не делал>. Первое, что сделал, — <разбил на части и нашёл самую неопределённую / собрал минимальный воспроизводящий пример / прочитал <спецификацию/исходники>>. Выяснилось, что реальная сложность была только в <узкая часть>, остальное — рутина. Дальше <что делал>. В итоге <результат>, заняло <срок> вместо оценённых <срок>». Ценный элемент — рассказать, как вы снижали неопределённость: прототип на день, спайк, разговор с тем, кто знает, чтение исходников библиотеки. Ошибка — превратить ответ в «я гений, всё оказалось легко»: подчеркните метод, а не одарённость. Вторая ошибка — выбрать задачу, которая была сложной только из-за незнания базовых вещей («сложно было настроить Docker») — это снижает воспринимаемый уровень.

Что вы инициировали на проекте?

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

Глубже. Каркас: «Заметил, что <проблема: половина инцидентов приходила от пользователей, а не от мониторинга / деплой занимал два часа ручных шагов / у нас не было единого способа обрабатывать ошибки и трассировка обрывалась>. Посчитал стоимость: <N часов в неделю / M инцидентов в квартал>. Предложил <решение> на <командной встрече / в виде дизайн-дока>, договорился с <тимлидом/смежниками> и получил <время/приоритет>. Сделал <что именно>, в том числе убедил <кого> в <чём>. Результат: <цифра>. Сейчас этим пользуются <кто> и это часть <процесса>».

Хорошие примеры инициатив, которые звучат достоверно: настройка алертинга по симптомам с раннбуками; внедрение линтера и единых правил ревью; переход на структурированное логирование и трассировку; шаблон нового сервиса, чтобы не копипастить; контрактные тесты со смежной командой; регулярный разбор инцидентов; автоматизация ручной операции; сокращение времени CI. Обратите внимание: половина ценности ответа — в том, как вы согласовали инициативу, а не только реализовали. Красные флаги: «я всё сделал по-своему, никого не спросив»; инициатива, которая осталась в личной ветке; невозможность оценить эффект. Если инициатив не было — не выдумывайте, скажите: «крупных инициатив не было, приоритеты приходили сверху; из небольшого — <что-то реальное>» и добавьте, что хотели бы больше пространства для этого, — это ещё и ответ про мотивацию.

Чем бы вы хотели похвастаться?

Коротко. Неформальная версия вопроса про достижения. Возьмите один результат, которым правда гордитесь, объясните за 30 секунд, в чём он состоял, и в чём была ваша роль — без ложной скромности и без бахвальства.

Глубже. Каркас: «Больше всего горжусь <что>. Не потому, что технически сложно, а потому что <причина: до этого <проблема> считалась неизбежной / результатом пользуются каждый день <кто> / это пережило меня в проекте и до сих пор работает>. Моя роль — <конкретно>». Хорошо работает гордость за вещи с длинным эффектом: инструмент, которым пользуется команда; сервис, который два года не падал; человек, которого вы вырастили. Красные флаги: ответ «нечем хвастаться» (звучит как отсутствие результатов, даже если это скромность — переформулируйте в «громких достижений нет, но есть <вещь>»); хвастовство количеством написанного кода или переработками («три ночи не спал и вытащил релиз» — для зрелого интервьюера это красный флаг про планирование, а не подвиг); присвоение командного результата.

Расскажите о себе.

Коротко. Главный вопрос всего блока. Формула: настоящее (кто вы, где, чем занимаетесь) → релевантное прошлое (2–3 места/проекта с масштабом) → сильные стороны и стек → зачем вы здесь. 90 секунд, без хронологии с университета, с одной цифрой масштаба и одним крючком для продолжения.

Глубже. Развёрнутый шаблон:

«Я <имя>, бэкенд-разработчик, лет в разработке, из них пишу на Go. Сейчас работаю в <компания-тип: продуктовая компания в домене X> — отвечаю за <сервис/домен>, это <одна фраза, что делает>, нагрузка <цифра>. Из последнего, чем занимался: <задача 1> и <задача 2>. До этого лет в <компания-тип>, там <одна фраза>. Стек, в котором чувствую себя уверенно: <Go, PostgreSQL, Kafka, Kubernetes, gRPC>. Сильная сторона — <конкретика: довожу задачи до прода и умею разбираться в незнакомой системе по коду и метрикам>. Ищу <что: продукт с реальной нагрузкой / больше влияния на архитектуру>, поэтому и откликнулся к вам — у вас <что-то конкретное из вакансии>. Готов рассказать подробнее про <крючок> или ответить на вопросы».

Три правила, которые чаще всего нарушают: (1) не начинайте с «родился, учился» — образование упоминается одной фразой и только если релевантно; (2) не перечисляйте технологии списком без контекста — «Go, Postgres, Kafka, Redis, Docker, k8s, gRPC, Kafka, Elastic…» звучит как чтение резюме вслух; (3) не говорите дольше двух минут без паузы — сделайте паузу после первой части и посмотрите на реакцию. Полезно адаптировать питч под вакансию: если в описании упор на highload — вперёд выносите нагрузку и оптимизации, если на продукт — вперёд выносите работу с продактом и метрики.

Красные флаги: рассказ, из которого непонятно, чем вы отличаетесь от любого другого кандидата; негатив про текущее место в первой минуте; ответ «а что рассказать?» — переброс мяча обратно интервьюеру читается как неподготовленность (уточнить формат можно, но одной фразой: «расскажу коротко про опыт и последний проект, минуты за две — так подойдёт?»).

Какие задачи вы решали на последнем проекте?

Коротко. См. выше «Чем вы занимались на последнем проекте» и «Какие задачи вы выполняли на предыдущем месте работы». Формулировка «на последнем проекте» сужает до одного проекта — не растекайтесь на всю карьеру.

Глубже. Полезно называть задачи с типом сложности, а не просто список: «продуктовые фичи — <пример>; технические — <пример: перевод сервиса с синхронного вызова на очередь>; эксплуатационные — <пример: разбор деградации>; организационные — <пример: описал контракт со смежной командой>». Такая раскладка за 40 секунд показывает широту, а дальше интервьюер сам выберет, куда углубиться.

Занимались ли вы машинным обучением?

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

Глубже. Что бэкендер часто делает рядом с ML и что можно честно назвать, если это было: сервис-обёртка над моделью (Go-сервис принимает запрос, ходит в инференс на Python/Triton/ONNX Runtime, отвечает с таймаутом и деградацией), пайплайн подготовки данных и фичей, батчевые расчёты и выгрузки, векторный поиск (pgvector, Qdrant) под RAG-сценарии, A/B-тесты и метрики качества, MLOps-часть (доставка моделей, версионирование, канареечная раскатка модели). Каркас: «Моделей сам не обучал — это не моя специализация. Рядом работал: <в проекте X я делал инференс-сервис на Go поверх модели, которую готовили дата-сайентисты: очередь, батчинг запросов, таймауты, фолбэк на предыдущую версию модели, метрики задержки и доли фолбэков>. Понимаю, где проходит граница между моей ответственностью и их. Если задача потребует — готов разобраться в <конкретике>». Красные флаги: «да, занимался», а следом невозможность объяснить, что такое обучающая выборка или чем инференс отличается от обучения; преувеличение вклада («я делал рекомендательную систему», когда вы писали к ней API).

Расскажите о вашем последнем или наиболее интересном проекте. Какую роль вы в нем выполняли?

Коротко. Комбинация «проект + роль». См. выше каркасы «Опишите основной продукт» и «Чем вы занимались на последнем проекте». Обязательно разделите «что делала команда» и «что делал я» — вопрос про роль задан явно, и на нём проверяют именно это.

Глубже. Приём, который хорошо работает: описать проект «сверху» за 30 секунд, а потом сказать «моя зона на этой схеме — вот эта» и назвать конкретные компоненты. Если есть возможность рисовать (онлайн-доска, лист бумаги) — нарисуйте квадратики и стрелки: интервьюеры это ценят, и разговор сразу переходит в предметный. Обозначьте также границы: «за <фронт/инфраструктуру/ML-часть> отвечали другие, я взаимодействовал с ними через <контракт>».

Какие последние задачи проходилось решать?

Коротко. См. выше «Чем занимаешься на текущем месте». Ключевое слово «последние» — берите задачи из последних недель, они звучат достовернее всего и вы помните детали.

Глубже. Формула на одну задачу: «<что за задача> — <зачем бизнесу> — <в чём была техническая суть> — <чем закончилось/на какой стадии>». Три такие задачи за полторы минуты — идеальный объём. Если последние недели были заполнены рутиной, не стесняйтесь: «последний месяц в основном поддержка и мелкие фичи, из содержательного — <одна вещь>» честнее, чем натужный поиск подвига.

Расскажи о себе;

Коротко. См. выше «Расскажите о себе» — тот же питч на 90 секунд.

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

Что больше всего бесит в Го?

Коротко. Проверка на зрелость: интервьюер хочет услышать осознанную критику с пониманием, почему язык так сделан, а не эмоции. Назовите 1–2 реальные болячки, объясните мотивацию авторов и скажите, как вы с этим живёте на практике.

Глубже. Что можно назвать честно и содержательно: многословная обработка ошибок — if err != nil занимает заметную долю кода; предложения по улучшению (try, ?) команда Go отклоняла, а в 2024-м официально закрыла тему упрощённого синтаксиса; смягчается обёртыванием через fmt.Errorf("...: %w", err), errors.Is/As и правилом не логировать и возвращать одновременно. nil-интерфейс с не-nil типом — классическая ловушка: интерфейс, содержащий типизированный nil-указатель, не равен nil; следствие — правило «не возвращайте конкретный тип ошибки в переменной типа error». Нулевые значения и отсутствие опциональности — нельзя отличить «не задано» от «ноль» без указателей или sql.Null*/omitzero. Ограниченные генерики — нет методов с параметрами типа, нет вывода в некоторых случаях, нет суммарных типов/enum. Пакетная система и циклические импорты — иногда заставляют вводить искусственные пакеты. context.Context первым аргументом везде — цена явности. GC-паузы и отсутствие контроля над памятью — редко, но бывает больно; частично лечится GOGC, GOMEMLIMIT (с 1.19), пулами. Многословие в целом — Go осознанно меняет краткость на читаемость чужого кода.

Каркас: «Больше всего раздражает <пункт>. Понимаю, зачем так сделано: <причина — явность, простота компилятора, читаемость>, и в целом согласен с трейд-оффом, но в <конкретном сценарии> это стоит мне <что>. Обхожу так: <практика>». Красные флаги: «ничего не бесит, идеальный язык» — читается как поверхностность; агрессивная критика по пунктам, которые давно не актуальны (например, «нет генериков» — они с 1.18); критика с непониманием причины («тупой язык для тупых задач»); жалоба на то, что Go — не Rust/не Python, вместо конкретики.

Пробовал ли писать свои пакеты на Го? Какие?

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

Глубже. Что обычно живёт как внутренняя библиотека и о чём можно рассказать: обёртка над логированием/трассировкой с едиными полями; клиент к внутреннему сервису с ретраями, таймаутами и метриками; пакет с общими типами ошибок и маппингом на HTTP/gRPC-коды; middleware для аутентификации; helper для транзакций; кодогенерация из спецификации; тестовые хелперы поверх testcontainers.

Каркас: «Да, писал <internal-библиотеку X>, потому что <проблема: в пяти сервисах копипастили один и тот же клиент, и каждый чинил баги у себя>. Что решал при проектировании: минимальная публичная поверхность — экспортировал только типов; конфигурация через функциональные опции, чтобы можно было добавлять параметры без ломки сигнатуры; никаких глобальных переменных и init(); context первым аргументом во всех методах; ошибки — свои типы с errors.Is-совместимостью; версионирование по semver, ломающие изменения — только с мажорной версией и /v2 в пути модуля. Покрыл тестами и написал README с примерами. Пользуются команд». Полезно упомянуть инструменты: go mod и правила именования модуля, go doc-комментарии по конвенции (// PackageName does ...), примеры в example_test.go, которые заодно исполняются как тесты. Если публичных пакетов нет — говорите про внутренние, это полностью засчитывается. Красный флаг: назвать «своим пакетом» директорию utils внутри монолита.

Что представляют из себя строки? Как посчитать количество символов?

Коротко. Строка в Go — неизменяемая последовательность байт (заголовок из указателя на массив байт и длины), по соглашению хранящая текст в UTF-8. len(s) даёт число байт, а не символов; количество кодовых точек считается через utf8.RuneCountInString(s), и оно тоже не всегда совпадает с числом «символов», которые видит человек, — для этого нужны кластеры графем.

Глубже. В рантайме строка — это структура из двух слов: указатель на данные и длина (reflect.StringHeader, а с Go 1.20+ рекомендуется unsafe.String/unsafe.StringData). Неизменяемость даёт дешёвое копирование и безопасное совместное использование: срез s[a:b] не копирует данные, а создаёт новый заголовок на тот же массив (в отличие от []byte(s), который копирует). Индексация s[i] возвращает byte, а не символ; for i, r := range s итерируется по рунам, где i — байтовое смещение начала руны, а r — rune (то есть int32, кодовая точка Unicode); некорректные UTF-8-последовательности при таком обходе дают utf8.RuneError (U+FFFD) шириной 1 байт.

package main

import (
  "fmt"
  "unicode/utf8"
)

func main() {
  s := "Привет, 世界🙂"

  fmt.Println(len(s))                    // байты
  fmt.Println(utf8.RuneCountInString(s)) // кодовые точки (руны)
  fmt.Println(len([]rune(s)))            // то же самое, но с аллокацией слайса

  n := 0
  for range s { // range по строке идёт по рунам
    n++
  }
  fmt.Println(n)
}

Тонкости, которые и являются предметом вопроса. Первое: utf8.RuneCountInString не аллоцирует и работает за один проход, а len([]rune(s)) выделяет слайс рун — на горячем пути это лишняя аллокация. Второе: руна ≠ видимый символ. Эмодзи с модификаторами (флаги, семьи, тон кожи) и символы с комбинирующими диакритиками состоят из нескольких кодовых точек: "é" может быть одной руной (U+00E9) или двумя (e + U+0301) — визуально одинаково, RuneCount разный. Если нужно именно число «символов, как их видит пользователь», считают кластеры графем (github.com/rivo/uniseg), а перед сравнением строк применяют нормализацию golang.org/x/text/unicode/norm (NFC). Третье: strings.ToUpper/ToLower и сравнение регистронезависимо (strings.EqualFold) тоже работают по Unicode и могут менять длину. Четвёртое, практическое: конкатенация в цикле через + квадратична по копированию — используйте strings.Builder; конверсии string(b []byte) и []byte(s) копируют, но компилятор умеет оптимизировать частные случаи (например, string(b) как ключ в map-лукапе или сравнение — без аллокации).

Расскажи о своей компании и чем ты сам лично занимался, твои функции в проекте?

Коротко. См. выше «Опишите основной продукт» и «Чем вы занимались на последнем проекте». Здесь явный акцент на слове «лично» — интервьюер заранее страхуется от рассказа в стиле «мы».

Глубже. Простое правило исполнения: первую половину ответа говорите «в компании/в команде», вторую — только «я». Помогает формулировка-переключатель: «Это про команду. Теперь конкретно моя часть: …». Дальше 3–4 пункта в первом лице с глаголами действия: спроектировал, реализовал, отладил, вынес, договорился, задокументировал, отдежурил. И один пункт про то, за что вы отвечали единолично — то, что сломается, если вас нет. Красный флаг: невозможность назвать такую зону — значит, вас воспримут как исполнителя чужих решений вне зависимости от лет опыта.

Что делаешь в свободное время?

Коротко. Вопрос на человеческую совместимость и на устойчивость: интервьюер смотрит, есть ли у вас жизнь помимо работы (это косвенный признак низкого риска выгорания) и нет ли конфликтующих обязательств. Отвечайте коротко и честно: 2–3 занятия, из них хотя бы одно не про программирование.

Глубже. Каркас: «Из регулярного — <спорт/музыка/путешествия/настолки/чтение>. Из околопрофессионального — <пет-проект/чтение исходников/участие в сообществе>, но без фанатизма: часов в неделю. И <что-то бытовое: семья, дети, ремонт> — это тоже занимает время». Хороший ответ содержит и «профессиональное», и «непрофессиональное»: только код 24/7 читается как риск выгорания, а полное отсутствие интереса к профессии вне работы — как отсутствие драйва (хотя это спорная позиция, и многие сильные инженеры сознательно не программируют вне работы — тогда просто скажите об этом прямо, без оправданий). Красные флаги: слишком личные подробности; политика и религия; ответ «ничего, только работаю»; упоминание параллельной подработки на конкурента (это уже вопрос конфликта интересов, а не хобби).

Что если дадут 1 млн долларов, какой проект бы сделал?

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

Глубже. Каркас: «Сделал бы <идея> — потому что сам сталкиваюсь с <проблема>. Начал бы не с кода, а с <проверки гипотезы: поговорить с потенциальными пользователями, собрать прототип на коленке>, и только если подтвердится, вложил бы деньги в <команду/инфраструктуру>. Технически там интересно <одна деталь>». Вариант «раздал бы долги и купил квартиру» тоже допустим как шутка, но обязательно доведите до содержательной части — иначе ответ пустой. Красные флаги: полное отсутствие идей («не знаю, не думал»); идея, которая противоречит тому, что делает компания, куда вы собеседуетесь; неспособность объяснить, кому это нужно. Хорошо звучат идеи, выросшие из вашей же боли на работе, — они заодно показывают, что вы видите проблемы вокруг себя.

Как ты представляешь себя на рабочем месте?

Коротко. Вопрос про ожидания от формата работы и про самоорганизацию. Отвечайте по трём осям: формат (офис/удалёнка/гибрид и почему), режим и коммуникация (как планируете день, как предпочитаете получать задачи), поведение в команде (как просите помощь и как её оказываете).

Глубже. Каркас: «Работаю продуктивнее всего, когда есть <2–3 часа непрерывного времени без встреч> — стараюсь собирать встречи в блок. Задачи предпочитаю получать <с описанным контекстом и критерием готовности; если контекста нет, иду и уточняю сам>. По формату: <удалёнка/гибрид>, готов приезжать <как часто> — привык к <асинхронной коммуникации: подробные сообщения, решения фиксируются письменно>. Если застреваю больше <часа-двух>, иду спрашивать, а не молча копаю — но перед этим формулирую, что уже проверил. Даю и принимаю код-ревью по делу, без пассивной агрессии». Если формулировка вопроса подразумевала «кем ты себя видишь» — уточните, что имеется в виду, и в случае про карьеру отвечайте по горизонту 1–3 года (см. подтему «Мотивация и ожидания»). Красный флаг: требования без гибкости («работаю только с 12 до 18 и без созвонов») до того, как разговор дошёл до оффера; и обратная крайность — «мне всё равно, как скажете», которая читается как отсутствие позиции.

Как у тебя проходит обучение на рабочем месте, посещал ли митапы?

Коротко. Смесь вопроса про саморазвитие и про вовлечённость в сообщество. Ответьте, как учитесь в рабочем процессе (это главное), и отдельно — про митапы/конференции честно: посещали, выступали или нет.

Глубже. Каркас: «На работе учусь тремя способами: <1> разбираю чужой код на ревью и задаю вопросы, <2> беру задачи в незнакомой области и закладываю время на изучение, <3> после инцидентов пишу/читаю постмортемы. Компания даёт <бюджет на обучение/дни на конференции/внутренние курсы> — использовал на <что>. Митапы: <был на <название/тип>, из последнего — <тема>; выступал внутри команды с <докладом про X> / публично не выступал, но хочу попробовать>». Внутренние выступления и написание документации считаются полноценным ответом — не обесценивайте их. Красные флаги: «на работе не учусь, там некогда» без продолжения; фантазии про конференции, названия которых вы не вспомните; презрение к сообществу («митапы — тусовки ради нетворкинга»).

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

Коротко. Питч с явным разрешением упомянуть образование. Дайте образование одной-двумя фразами (вуз, специальность, что из этого пригодилось), затем стандартную структуру: места и задачи, технологии.

Глубже. Как говорить про образование в зависимости от ситуации: профильное — «<вуз>, <специальность>; из полезного в работе — <дискретная математика и алгоритмы / сети / базы данных>, остальное подтягивал сам». Непрофильное — «образование <какое>, в разработку пришёл через <путь>; из образования пригодилось <умение работать с формальными моделями / статистика>». Без высшего — «высшего нет, учился сам и на практике; базу по <алгоритмам, сетям, ОС> закрывал целенаправленно по <источники>». Ни один из вариантов не является проблемой сам по себе — проблема только в оправданиях и в попытке приукрасить. Дальше идут задачи и технологии; технологии называйте не списком, а привязанными к задачам: «Kafka — под <какой сценарий>, Redis — под <какой>» — так видно, что вы понимаете, зачем каждая.

Чем занимался последнее время, какие технологии использовал?

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

Глубже. Полезный приём — самостоятельно разметить стек по уровням: «уверенно и ежедневно: <Go, PostgreSQL, Docker>; применял в проде, но не эксперт: <Kafka, Kubernetes, gRPC>; трогал/читал: <ClickHouse, Temporal>». Такая честная раскладка снимает половину дальнейших уточняющих вопросов и повышает доверие: интервьюер точно знает, где можно копать глубоко, а где вы сразу обозначили границу. Красный флаг — перечислить двадцать технологий одним потоком: почти гарантированно последуют вопросы по самой экзотической.

Больше нравится кодить или заниматься управлением?

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

Глубже. Полезно разложить «управление» на составляющие и сказать, что из этого вам близко: техническое лидерство (архитектурные решения, ревью, стандарты), координация (разрезание задач, стыковка команд, сроки), работа с людьми (найм, 1-на-1, оценка, увольнения), продуктовая работа (приоритеты, метрики). Многие инженеры хотят первое и второе и совсем не хотят третье — так и скажите. Каркас: «Основное для меня — инженерная работа, руки в коде должны оставаться. При этом мне нравится <проектирование и менторство>, и я готов брать роль <техлида/владельца домена> — то есть отвечать за технические решения и за то, чтобы команда их согласованно применяла. Полноценный менеджмент людей — <не мой интерес сейчас / рассматриваю в горизонте лет>». Красные флаги: «хочу поменьше кодить и побольше руководить» на вакансии разработчика; заявленный интерес к менеджменту без единого примера, где вы брали ответственность за других; ответ «мне всё равно» — по нему невозможно спланировать вашу роль. Если вы всерьёз хотите в менеджмент, узнайте заранее, есть ли в компании такой трек, — иначе рискуете получить отказ по несовпадению ожиданий (см. также подтему «Мотивация и ожидания»).

Какой самый серьезный факап произошел в вашей карьере?

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

Глубже. Каркас:

• Context. «<Когда>, в <проект>, я <что сделал: выкатил миграцию, которая заблокировала таблицу на проде в час пик / удалил не тот индекс / развернул конфиг с продовым адресом в тестовом окружении и наоборот>».
• Action. «Заметил через <сколько> по <алерту/жалобе>. Сразу <сообщил в канал инцидентов и позвал дежурного — не пытался тихо починить сам>. Остановили <что>, откатили <как>, восстановили за <время>».
• Result. «Влияние: минут деградации, <что именно не работало>, данные <не пострадали / восстановили из <бэкапа/лога>>».
• Learning. «Разобрали на постмортеме без поиска виноватых. Причина была не только в моей невнимательности: <не было проверки в CI / отсутствовал ревью-чеклист для миграций / деплой не имел подтверждения для прод-окружения>. После этого мы <добавили линтер на опасные DDL / внедрили правило: миграции только в окно и только с lock_timeout / сделали отдельный шаг подтверждения>. С тех пор такого класса ошибок не повторялось».

Что оценивается: признаёте ли вы ответственность без перекладывания и без самобичевания; как быстро эскалировали (тихая попытка починить самому — худший из ответов); измеряете ли ущерб; и делаете ли системный вывод, а не «стал внимательнее» (внимательность не масштабируется, процессы масштабируются). Красные флаги: «серьёзных факапов не было» — либо неопытность, либо неоткровенность, оба варианта плохи; история, где виноват кто-то другой; факап уровня «однажды опечатался в логе»; и обратная крайность — история, из которой следует, что вам нельзя доверять прод (например, вы регулярно катите без тестов).

Какова идеальная структура проекта на Go по вашему опыту

Коротко. Правильный ответ начинается с «идеальной универсальной структуры нет, она зависит от размера и срока жизни сервиса», а дальше — ваши принципы: начинать плоско, резать по доменам, а не по техническим слоям, использовать internal/ для сокрытия и cmd/ для точек входа, а зависимости направлять внутрь.

Глубже. Опорные факты: официальная рекомендация Go-команды — документ «Organizing a Go module» (go.dev/doc/modules/layout); популярный репозиторий golang-standards/project-layout не является официальным стандартом и регулярно критикуется, в том числе участниками команды Go, — знать про него полезно, но ссылаться как на канон не стоит. Каталог internal/ — единственная структурная конструкция, у которой есть смысл на уровне компилятора: пакеты внутри internal/ импортируются только из поддерева родителя, что даёт реальный контроль публичной поверхности. Каталог cmd/<binary>/main.go нужен, когда бинарников несколько; для одного бинарника main.go в корне абсолютно нормален. Каталог pkg/ — спорный: он ничего не даёт технически и часто просто добавляет уровень вложенности.

Каркас ответа: «Начинаю плоско: main.go, пара пакетов, и усложняю только когда становится больно. Для сервиса среднего размера прихожу примерно к такому:

cmd/api/main.go          — сборка зависимостей и запуск
internal/config          — конфиг из env, валидация на старте
internal/<domain>        — доменная логика и типы, без импорта БД/HTTP
internal/<domain>/service — юзкейсы, интерфейсы репозиториев объявлены здесь
internal/storage/postgres — реализация репозиториев, SQL, миграции рядом
internal/transport/http   — хендлеры, роутинг, DTO и их маппинг в домен
internal/transport/grpc   — то же для gRPC
internal/platform/...     — логгер, метрики, трассировка, клиенты внешних API
migrations/               — SQL-миграции

Принципы, которые я держу: пакеты называю по домену (order, billing), а не по слою (models, services, handlers) и никогда не завожу utils/common — это свалка; интерфейсы объявляю на стороне потребителя, а не рядом с реализацией — так internal/storage ни от кого не зависит; зависимости собираю в main явно, без магии DI-контейнеров (или через wire, если сборка разрослась); циклические импорты лечу выделением доменных типов, а не пакетом types; всё, что не предназначено для внешнего использования, держу под internal/. Отдельно: структура должна выдерживать проверку “новый человек за пять минут находит, где лежит логика начисления скидки” — если не выдерживает, она неправильная, какой бы канонической ни была».

Красные флаги: механическое воспроизведение «чистой архитектуры» с четырьмя слоями в сервисе на тысячу строк; утверждение, что golang-standards/project-layout — официальный стандарт; пакеты models, utils, helpers; невозможность объяснить, что даёт internal/.

Какие задачи вы решали на последнем месте работы? Какие алгоритмы и подходы использовали?

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

Глубже. Что честно относится к «алгоритмам и подходам» в бэкенде: структуры данных под задачу (хеш-таблица против отсортированного среза, префиксное дерево для поиска по префиксу, heap для приоритетной очереди, множество для дедупликации); алгоритмы на данных (потоковая агрегация, скользящее окно, top-K через heap, HyperLogLog для приблизительного счёта уникальных, Bloom-фильтр для отсечения промахов кэша); конкурентные паттерны (worker pool с ограничением, fan-in/fan-out, errgroup с лимитом, пайплайны на каналах, singleflight против дублирующих запросов); алгоритмы устойчивости (экспоненциальные ретраи с джиттером, token bucket / leaky bucket для rate limiting, circuit breaker, backpressure); работа с БД (пагинация по ключу вместо OFFSET, батчинг, upsert, оптимистические блокировки по версии); распределённые вещи (консистентное хеширование, идемпотентные ключи, outbox, saga, кворумы, векторные часы — если правда трогали).

Каркас: «Учебные алгоритмы в чистом виде почти не пишу — они в стандартной библиотеке. Из того, что применял осознанно: <например, заменил линейный поиск по срезу на map, когда профиль показал, что функция съедает 30% CPU>; <сделал rate limiter на token bucket через golang.org/x/time/rate, потому что нужен был всплеск до с последующим сглаживанием>; <для дедупликации входящих событий использовал <Bloom-фильтр/Redis SET с TTL>, потому что <причина>>; <перевёл пагинацию с OFFSET на keyset, потому что на глубоких страницах запрос деградировал>. Сложность оцениваю, когда объёмы растут, — обычно вопрос не в O-большом, а в количестве round-trip до БД». Красный флаг: рассказ про quicksort и обход графа в проекте, где ничего похожего быть не могло.

Насколько глубок ваш опыт в DevOps? Какие инструменты и практики применяли регулярно?

Коротко. Проверяют, насколько вы самостоятельны в доставке и эксплуатации своего кода. Отвечайте по границе: что делаете сами регулярно, что умеете, но делаете редко, и что за вас делает платформенная команда.

Глубже. Разложение по областям для честной самооценки: контейнеризация — пишете ли Dockerfile сами, multi-stage сборки, минимальные образы (distroless/alpine/scratch), непривилегированный пользователь, кэширование слоёв; CI — настраивали ли пайплайны (GitLab CI, GitHub Actions, TeamCity, Jenkins): тесты, -race, линтеры, сборка, публикация образа, кэш модулей; CD и Kubernetes — умеете ли писать/править манифесты и Helm-чарты, понимаете ли readiness/liveness-пробы, requests/limits, HPA, rolling update и почему без graceful shutdown раскатка теряет запросы; ArgoCD/Flux и GitOps; IaC — Terraform/Ansible: писали сами или читали чужое; наблюдаемость — Prometheus и правила алертинга, дашборды Grafana, логи (Loki/ELK) со структурированным логированием, трассировка (OpenTelemetry/Jaeger), SLI/SLO; эксплуатация — дежурство, разбор инцидентов, раннбуки, работа с секретами (Vault), сетевые вопросы (ingress, TLS, service mesh).

Каркас: «Я не платформенный инженер, но свой сервис довожу до прода сам. Регулярно: пишу Dockerfile (multi-stage, статическая сборка, non-root), настраиваю пайплайн в , правлю манифесты/values.yaml для своего сервиса, настраиваю пробы и лимиты, завожу метрики и алерты, читаю логи и трейсы при разборе. Реже, но делал: <Terraform для <ресурса>, настройка ArgoCD-приложения>. За кластер, сеть и базовые компоненты у нас отвечает <платформенная команда> — с ними взаимодействую через <тикеты/PR в их репозиторий>. Из практик считаю обязательными для себя: graceful shutdown с обработкой SIGTERM и учётом terminationGracePeriodSeconds, health-пробы, версионирование образов по коммиту, откат в один шаг, алерты на симптомы (задержка, ошибки, насыщение), а не на CPU». Красные флаги: «DevOps — это не моя работа»; заявленный Kubernetes-опыт без понимания, почему под убивают по OOM или чем readiness отличается от liveness; список инструментов, которыми «пользовались», не умея объяснить, что они делают.

На каких проектах вы работали, какие технологии применяли?

Коротко. См. выше «Расскажи про свой опыт» и «Чем занимался последнее время». Формат — таблица в голове: проект → домен → масштаб → ваша роль → стек, по 20–30 секунд на проект, начиная с последнего.

Глубже. Если проектов много (аутсорс, консалтинг), не идите по всем: возьмите 2–3 самых релевантных вакансии, а остальные сверните в одну фразу («ещё около десятка коротких проектов в аутсорсе — в основном интеграции и REST API»). Признак хорошего ответа — интервьюер после него может назвать ваш профиль одним предложением. Признак плохого — у него в голове каша из названий. Полезно заранее спросить: «У вас в вакансии <технология/домен> — рассказать в первую очередь про проекты, где это было?».

Писали ли вы самостоятельно запросы?

Коротко. Проверка, что за словами «работал с PostgreSQL» стоит реальный SQL, а не только ORM. Ответ: да/нет честно, плюс сразу пример нетривиального запроса и того, как вы проверяли его план.

Глубже. Что показывает уровень: пишете ли JOIN на несколько таблиц и понимаете ли разницу типов соединений; используете ли CTE и оконные функции (ROW_NUMBER, LAG, SUM() OVER), понимаете ли, что CTE в PostgreSQL с 12-й версии по умолчанию инлайнятся (перестали быть барьером оптимизации, если не указано MATERIALIZED); умеете ли INSERT ... ON CONFLICT DO UPDATE; знаете ли FOR UPDATE/SKIP LOCKED (типовой приём для очереди в таблице); читаете ли EXPLAIN (ANALYZE, BUFFERS) и отличаете ли Seq Scan от Index Scan/Bitmap Heap Scan, видите ли расхождение оценки и факта по строкам; понимаете ли, почему функция от колонки в WHERE убивает индекс и как это лечится выражением-индексом.

Каркас: «Да, SQL пишу руками и считаю это базовым навыком. Из последнего нетривиального: <запрос с оконной функцией для расчёта <метрики> по пользователю за скользящее окно>; <очередь на таблице через SELECT ... FOR UPDATE SKIP LOCKED с батчем по >; <агрегирующий отчёт, который я переписал с трёх подзапросов на один проход с FILTER, время с до >. Планы смотрю через EXPLAIN (ANALYZE, BUFFERS), медленные запросы нахожу через pg_stat_statements». Красные флаги: «запросы генерирует ORM, я в них не лезу»; неспособность объяснить, чем LEFT JOIN отличается от INNER JOIN в присутствии WHERE по правой таблице; уверенность, что «индекс всегда ускоряет».

Какой у вас опыт работы с базами данных?

Коротко. См. выше «С какими базами данных вы работали» и «Расскажи про опыт с базами данных» — тот же ответ по уровням: основная БД глубоко, остальные с честной пометкой уровня.

Глубже. Если этот вопрос задают уже после других про БД (а он часто дублируется между этапами), не повторяйте дословно — сместите акцент на проектирование: «Кроме использования, проектировал схемы с нуля: <пример — схема для <домена> с таблицами, решения по нормализации, по хранению истории (append-only таблица событий вместо перезаписи), по индексам под конкретные запросы, по стратегии удаления старых данных>». Умение проектировать схему ценится выше умения писать запросы и почти всегда становится темой отдельного разговора.

Есть ли опыт проектирования с нуля?

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

Глубже. Каркас: «Да: <сервис/подсистема> проектировал с нуля. Начал с требований: <функциональные — что должен делать; нефункциональные — сколько RPS, какая допустимая задержка, требования к консистентности и к сохранности данных>. Из решений: <выбрал синхронный API + асинхронную обработку через очередь, потому что <причина>>; <схема данных — <ключевое решение>>; <границы сервиса провёл по <домену>, чтобы <причина>>; <для отказоустойчивости заложил <ретраи, идемпотентные ключи, dead-letter queue>>. Оформил как <дизайн-док> и обсудил с <командой/архитектором> — по итогам поменял <что>. Сейчас, оглядываясь, сделал бы иначе <что и почему> — например, <не выносил бы это в отдельный сервис сразу, монолитный модуль справился бы, а эксплуатации было бы меньше>».

Последний пункт — рефлексия — отличает человека, который проектировал и потом эксплуатировал, от человека, который нарисовал схему и ушёл. Если опыта «с нуля» нет, честный ответ: «целиком систему с нуля не проектировал; проектировал новые модули и сервисы внутри существующей системы — <пример>; ограничение было в том, что <часть решений уже была задана>». Красные флаги: «проектировал с нуля» про проект, где вы реализовали чужой дизайн; отсутствие нефункциональных требований в рассказе (проектирование без нагрузки, задержки и требований к данным — это рисование квадратиков); ни одного «сделал бы иначе».

Самая сложная или интересная задача? Опишите решение.

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

Глубже. Структура для этой формулировки: 20% — контекст и ограничения, 50% — решение (что именно построили: компоненты, потоки данных, структуры, алгоритмы, как обеспечили корректность), 20% — как проверяли (тесты, нагрузочный прогон, теневой трафик, сравнение с эталоном), 10% — результат и выводы. Обязательно приготовьте ответы на три уточняющих вопроса, которые прозвучат почти наверняка: «почему не сделали проще?», «что будет, если <нагрузка вырастет в 10 раз / этот компонент недоступен>?», «как вы убедились, что решение корректно?». Если можете нарисовать схему — рисуйте: устный рассказ про распределённое решение почти всегда проигрывает пяти квадратикам со стрелками. И держите наготове признание границ: «здесь мы сознательно приняли ограничение <какое>, при <условии> оно перестанет работать, и тогда следующим шагом был бы <что>» — это ответ уровня Senior.

Частые ошибки на собесе

• «Мы» вместо «я». Рассказ, в котором невозможно понять личный вклад, — самая частая причина понижения грейда по итогам интервью. Правило: команда — «мы», ваши действия — «я», и хотя бы одна зона, за которую вы отвечали единолично.
• Отсутствие цифр. «Ускорили», «стало стабильнее», «нагрузка была высокая» — пустые слова. Нужны метрика, значение до и после и способ измерения; если точных цифр нет, честно дайте порядок величины.
• Хронология вместо питча. Рассказ «о себе» с первого курса на пять минут: интервьюер теряет нить и перестаёт слушать до того, как вы дойдёте до релевантного.
• Список технологий без контекста. Перечисление двадцати инструментов вместо «эту брали для такой задачи, потому что» — за этим следуют вопросы по самой экзотической позиции списка, и обычно неудачно.
• Приукрашивание опыта. «Занимался шардированием / профилировал прод / писал ML» без реальной практики вскрывается вторым уточняющим вопросом и обнуляет доверие ко всему остальному рассказу, включая правдивые части.
• Негатив о бывших коллегах и работодателях. Даже обоснованный. Причины ухода формулируются через дефицит возможностей, а не через дефекты людей.
• «Факапов не было», «слабых сторон нет», «в Go всё идеально». Отказ признавать ограничения читается как незрелость либо как неоткровенность, и оба варианта хуже, чем честный ответ.
• Монолог без пауз. Ответ длиннее трёх-четырёх минут без проверки «нужны ли подробности» — интервьюер уже давно хочет уточнить, но не может вставить слово.
• Разные версии одной истории на разных этапах. Интервьюеры сверяются между собой; «плавающие» цифры и детали портят впечатление сильнее, чем скромный результат.

Что почитать

• Go Wiki и официальный блог go.dev — release notes к 1.22, 1.23 и 1.24: https://go.dev/doc/devel/release — чтобы уверенно отвечать на вопросы про новинки языка.
• «Organizing a Go module» — официальный гайд по структуре проекта: https://go.dev/doc/modules/layout (и internal-правило в спецификации команд go).
• «Profiling Go Programs» и документация net/http/pprof: https://go.dev/blog/pprof, https://pkg.go.dev/net/http/pprof — фактура для вопроса про профилирование в проде.
• The Amazon/Google interview-style guides по поведенческим вопросам и STAR: Google re:Work «Structured interviewing» — https://rework.withgoogle.com/guides/hiring-use-structured-interviewing/ — объясняет, что именно оценивает интервьюер в поведенческом блоке.
• «Site Reliability Engineering» (Google, бесплатно на https://sre.google/books/) — главы про постмортемы и SLI/SLO: язык, на котором стоит рассказывать про инциденты и факапы.
• Мартин Клеппман, «Designing Data-Intensive Applications» — словарь для ответов про базы данных, масштабирование и консистентность.

---

Список исходных вопросов с привязкой к компаниям: ../questions/about-you.md