Как проходить собеседования: этапы, подготовка, поведение, вопросы работодателю

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

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

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

Как процесс выглядит со стороны компании

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

Три следствия из этой картинки.

Первое: на верхних этапах вас отсеивают не за качество, а за неопределённость. Скрининг резюме — это 10–60 секунд на кандидата. Никто не восстанавливает по вашему резюме глубину вашего мышления. Ищут ответ на вопрос «есть ли смысл тратить час». Расплывчатое резюме проигрывает не потому, что вы слабый, а потому, что оно дороже читать.

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

Третье: отказ — почти всегда сравнение, а не приговор. «Мы выбрали другого кандидата» означает ровно то, что написано. У компании была одна позиция и четыре финалиста.

Кто на самом деле принимает решение

Роли в найме размазаны, и кандидат часто разговаривает не с теми, кто решает.

Что здесь важно кандидату:

• Рекрутер — не враг и не судья. Его KPI — закрытые вакансии, то есть он заинтересован в вашем успехе. Но он не оценивает вашу техническую глубину и обычно не может её оценить. Не спорьте с рекрутером о технологиях — берегите это на секцию.
• Нанимающий менеджер — главный человек в процессе. Обычно это тимлид или руководитель группы. Он платит за ошибку найма своим временем. Если он на вашей стороне, многое прощается.
• Интервьюеры пишут текст, а не ставят оценку. В зрелых компаниях фидбек — это структурированный документ с примерами. Именно поэтому «я вроде хорошо поговорил» и итоговый вердикт могут расходиться: в фидбеке важно не ощущение от беседы, а конкретика.
• Комитет / согласование уровня — там, где вы уже не участвуете. Здесь решается ваш грейд, а значит, вилка. Про то, что такое грейд и почему он не про годы опыта, — Грейды.

Жизненный цикл вас в системе найма

Вы в ATS (applicant tracking system — Huntflow, Greenhouse, Workable, «Хантфлоу» и подобные) существуете как карточка со статусом. Полезно знать эти статусы, потому что они объясняют паузы.

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

Этапы: что реально оценивают

1. Резюме и отклик

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

Основная болезнь резюме джуна — список технологий вместо списка результатов:

React, Redux, TypeScript, Node.js, PostgreSQL, Docker, Git, Jira, Agile

Это не сообщает ничего: перечислить можно и после прочтения документации. Сравните:

Внутренняя админка для складского учёта (React + TS, ~15 экранов, 3 разработчика). Отвечал за модуль инвентаризации: формы, валидация, интеграция с REST API склада. Переписал таблицу остатков на виртуализированный список — страница с 20k строк перестала подвешивать браузер.

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

Практические правила, которые реально влияют на конверсию:

• Одна–две страницы. У джуна — одна. Длина резюме не коррелирует с силой кандидата, зато коррелирует с раздражением читателя.
• Обратный хронологический порядок, свежее — подробнее.
• Пишите «я», а не «мы». «Мы разработали микросервисную платформу» — красный флаг: непонятен ваш вклад. Интервьюер всё равно спросит, а вы будете оправдываться.
• Цифры там, где они есть, и никаких выдуманных. «Ускорил на 40%» без понимания, что и как мерили, — ловушка: спросят методику.
• Учебные проекты — это нормально, если они настоящие. Клон таск-трекера, доведённый до деплоя, с тестами и README, говорит больше, чем три курса в списке. Пятнадцатый туториальный todo-list не говорит ничего.
• Ключевые слова из вакансии — не для «обмана ATS», а потому, что рекрутер ищет по ним глазами. Если в вакансии «Kubernetes», а у вас «k8s», напишите оба раза.
• Сопроводительное письмо работает только если оно конкретное: одна фраза о том, почему именно эта компания/продукт, и одна — почему вы подходите. Шаблон на 400 слов не читают.

2. Скрининг рекрутера (20–30 минут)

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

Что подготовить заранее:

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

Что спросить у рекрутера (это экономит вам недели): сколько этапов и в каком формате, кто будет интервьюером, есть ли тестовое и сколько оно занимает, какой ожидаемый срок решения, вакансия новая или на замену.

3. Техническое интервью: три разных жанра

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

Жанр «основы». Вопросы вида «чем отличается процесс от потока», «что такое индекс в БД и когда он не помогает», «что произойдёт при N+1 запросе». Проверяют, есть ли под вашим фреймворком фундамент. Джунов здесь топят не незнанием экзотики, а провалами в базе: как работает HTTP, что такое транзакция, чем список отличается от словаря по сложности операций. Материал ровно на эту базу — треки Структуры данных, Операционные системы и Базы данных.

Главная ошибка — отвечать заученной формулировкой, не понимая её. Интервьюер задаёт второй вопрос вглубь, и заученное рассыпается. Лучше сказать «точное определение не назову, но на практике это выглядит так…» и объяснить своими словами. Это оценивается выше.

Жанр «живой код». Задача на 30–60 минут: разбор строки, обход дерева, работа со словарём, иногда небольшая реализация класса или обработчика. У большинства компаний за пределами бигтеха это не олимпиадные задачи, а «умеет ли человек писать код руками». Подготовка — трек Алгоритмы, но с важной оговоркой ниже про дозировку.

Жанр «опыт и системы». Для джуна — глубокий разбор вашего же проекта: почему так сделали, что бы поменяли, где было больно. Для мидла и выше — дизайн системы: «спроектируйте сокращалку ссылок / ленту / систему уведомлений». Здесь ценится не знание модных технологий, а умение задавать уточняющие вопросы, называть компромиссы и явно говорить о том, что вы упрощаете. Основа — System design.

4. Тестовое задание

Тестовые бывают трёх видов, и они очень разного качества.

Что реально смотрят в тестовом: читается ли код, есть ли структура, обработаны ли ошибки, есть ли хоть какие-то тесты, есть ли README с запуском и с явным списком «что я сознательно не сделал и почему». Последний пункт недооценён: он превращает недостатки в осознанные решения. Идеальной архитектуры от вас не ждут — ждут инженерной аккуратности. Стандарты, по которым это оценивают, разбирались в Разработка.

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

5. Финал: команда, менеджер, «культурное соответствие»

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

Здесь работает структура STAR (Situation, Task, Action, Result) — способ рассказать историю так, чтобы из неё был извлекаем сигнал:

• Situation — контекст в двух предложениях. Где, какой продукт, какая роль.
• Task — что конкретно было вашей задачей/проблемой.
• Action — что сделали вы (не команда), в деталях и с альтернативами, которые отвергли.
• Result — что вышло, включая числа, и чему научились.

Плохой ответ на «расскажите про факап»: «у нас однажды упал прод, но мы быстро починили». Хороший — конкретика с признанием своей роли: что вы сделали не так, как это обнаружили, что изменили в процессе, чтобы не повторилось. Про то, как разбор инцидента устроен в реальности, — Релиз и эксплуатация. Ссылаться на blameless postmortem в ответе — сильный ход, если вы правда понимаете, что это.

Заранее заготовьте 5–7 историй и переиспользуйте их под разные вопросы: сложная задача, конфликт, ошибка, срочный дедлайн, случай, когда вы кого-то научили, случай, когда вы поменяли своё мнение под давлением фактов. Большинство поведенческих вопросов — это переформулировки этого набора.

Подготовка: что даёт результат, а что нет

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

Разумный план на четыре недели, если вы совмещаете подготовку с работой или учёбой:

Ключевые приёмы, которые сильно повышают КПД:

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

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

Первыми откликайтесь в компании, которые вам не очень нужны. Первые 2–3 собеседования уходят на снятие паники и калибровку. Тратить на это компанию мечты — расточительство.

Мок-интервью. Друг-разработчик, ментор, сообщества, платные сервисы. Один прогон с обратной связью полезнее десяти самостоятельно решённых задач, потому что вскрывает слепые зоны: бормотание, длинные паузы, привычку молча гуглить.

Не зубрите ответы. Заученный ответ на «расскажите о себе» слышно, и он вызывает недоверие. Заучивать надо структуру, а не текст.

Поведение в живой секции

Здесь ломается больше кандидатов, чем на незнании. Разберём механику.

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

1. Сначала уточняйте, потом кодьте. Задача почти всегда сформулирована неполно — часто намеренно. «Найдите дубликаты в списке» — а какого размера список? влезает в память? что считать дубликатом для строк с разным регистром? нужен ли порядок? можно ли менять вход? Три-четыре хороших уточняющих вопроса — это отдельный положительный сигнал, и он же экономит вам 20 минут работы не над той задачей. Этот навык — тот же самый, что и в Требования и аналитика: реальные задачи в трекере тоже приходят недоформулированными.

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

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

# Живая секция: сначала простое и рабочее, вслух проговаривая инварианты.
def first_duplicate(items: list[str]) -> str | None:
    """Возвращает первый элемент, встретившийся повторно, иначе None.

    Время O(n), память O(n). Альтернатива без доп. памяти —
    отсортировать копию за O(n log n), но тогда теряется порядок появления.
    """
    seen: set[str] = set()
    for item in items:
        if item in seen:      # первое повторение — сразу выходим
            return item
        seen.add(item)
    return None


# Краевые случаи проговариваем ВСЛУХ и проверяем сами, не дожидаясь подсказки:
assert first_duplicate([]) is None            # пустой вход
assert first_duplicate(["a"]) is None         # один элемент
assert first_duplicate(["a", "b", "a"]) == "a"
assert first_duplicate(["a", "a", "a"]) == "a"  # несколько повторов

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

5. Подсказка — это не провал, это часть процесса. Интервьюер подсказывает, чтобы секция не встала. Правильная реакция — взять подсказку, сказать «а, точно, тогда…» и двигаться. Неправильная — упрямо защищать своё решение или, наоборот, сдуться. Как кандидат реагирует на новую информацию — это, между прочим, прямая проверка того, как он будет вести себя на код-ревью.

6. «Я не знаю» — легальный ответ, если он не единственный. Сильная форма: «В проде с этим не работал. Знаю, что задача решается примерно так; проверил бы вот это и почитал бы вот тут». Слабая форма — молчание или выдумывание. Блеф вскрывается одним уточняющим вопросом и стоит дороже, чем незнание, потому что переносится на доверие ко всему остальному, что вы рассказали.

7. Если завис — скажите об этом. «Я застрял: вижу, что нужно кэшировать, но не соображу ключ. Можно я вслух перечислю варианты?» Это не слабость. Молчаливая пятиминутная пауза — вот это проблема, потому что интервьюер не знает, думаете вы или паникуете.

8. Технические мелочи, которые портят впечатление зря. Проверьте камеру, микрофон и интернет заранее; закройте лишние вкладки; договоритесь дома, что вас не трогают; подготовьте редактор, если код пишется у вас. Если используется общий редактор без подсветки и автодополнения — потренируйтесь в таком заранее, отсутствие IDE выбивает многих.

9. Про использование ИИ-ассистентов. Правила разные и их надо уточнить прямо в начале: «у вас можно пользоваться автодополнением/ассистентом?» Тихо пользоваться, когда не разрешали, — это обнаруживается (по паузам, по стилю кода, по неспособности объяснить собственную строку) и трактуется как обман. Если разрешено — показывайте, что вы проверяете вывод, а не доверяете ему слепо: это ровно то, что сейчас проверяют.

Типичные ошибки кандидатов

Список из практики, отсортированный по частоте, а не по тяжести.

1. Молчание в живой секции. Разобрали выше. Самая дорогая ошибка.
2. Ответ «мы» на вопрос «что делали вы». Интервьюер не может засчитать чужой вклад.
3. Пересказ технологий вместо задач. «Работал с Kafka» — а что вы с ней делали, какие были проблемы с порядком сообщений, что происходило при переобработке?
4. Неготовность объяснить свой же код в резюме/на GitHub. Если проект указан — его будут спрашивать. Всё, чего вы не понимаете, лучше убрать.
5. Преувеличение уровня владения. «Питон — 9 из 10» гарантированно ведёт к вопросам, на которые 9 из 10 обязано отвечать.
6. Спор с интервьюером ради победы. Отстаивать позицию аргументами — хорошо; не слышать контраргумент — плохо. Разница видна мгновенно.
7. Критика прошлых работодателей. Даже заслуженная звучит как «этот человек и про нас так расскажет».
8. Отсутствие вопросов в конце. Читается как безразличие к работе. Об этом — следующий раздел.
9. Слишком раннее и жёсткое обсуждение денег. Называть цифру нужно тогда, когда спросили, и не превращать это в единственную тему до оффера.
10. Опоздания и внезапные переносы. Мелочь, которая портит впечатление сильнее, чем кажется, потому что это единственный доступный компании факт о вашей надёжности.
11. Подготовка только к техчасти. Половина отказов на финале — не про код.
12. Согласие на любые условия из страха. Про это подробно — Переговоры об оффере.

Вопросы работодателю: ваша половина собеседования

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

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

Готовый набор, привязанный к темам этого трека:

Про процесс разработки (см. Разработка):

• Как выглядит путь задачи от постановки до продакшена? Кто участвует на каждом шаге?
• Сколько времени в среднем живёт ветка? Насколько большие пул-реквесты?
• Есть ли Definition of Done, и что в него входит?
• Кто пишет тесты и когда? (см. Тестирование)

Про релизы и эксплуатацию (см. Релиз и эксплуатация):

• Как часто вы релизите и сколько занимает деплой?
• Есть ли дежурства? Как устроены, оплачиваются ли, часто ли будят ночью?
• Что было последним серьёзным инцидентом и что после него изменилось?

Про качество и техдолг (см. Поддержка и техдолг):

• Какая доля времени команды уходит на поддержку и багфиксы против новой функциональности?
• Есть ли легаси, с которым придётся работать, и есть ли план по нему?

Про людей и рост (см. Как расти):

• Как устроен онбординг? Когда обычно первый коммит в прод?
• Есть ли ревью производительности и как часто? Как принимается решение о повышении грейда?
• Кто будет моим ментором/наставником и сколько у него на это времени?

Про контекст решения (см. Кто есть кто в команде):

• Кто решает, что попадает в спринт? Насколько команда влияет на приоритеты?
• Почему открыта эта вакансия — рост или замена? Если замена, почему ушёл человек?

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

Красные флаги, которые слышно на собеседовании

Не приговор по отдельности, но повод копать глубже:

• Не могут внятно описать процесс. Значит, его нет, и вы будете жить в хаосе без плюсов стартапа.
• «У нас все как семья» — часто маркер размытых границ и переработок «за идею».
• Не могут назвать ни одного инцидента или неудачного проекта. Либо не рефлексируют, либо не говорят правду.
• Собеседование состоит из вопросов на память и головоломок без связи с работой. Обычно предсказывает такое же отношение к процессу внутри.
• Процесс тянется месяцами, теряются письма, переносят интервью без предупреждения. Это лучшая доступная вам выборка того, как компания обращается со своими людьми.
• Давят срочностью: «оффер действителен 24 часа». Обоснованная спешка бывает, но это чаще давление, чем реальный дедлайн.
• Про деньги отвечают уклончиво до самого оффера, а на прямой вопрос про вилку переводят тему.

Энтерпрайз и стартап: процессы найма отличаются

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

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

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

Отказы: как их читать и что с ними делать

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

Что делать полезного:

• Просите обратную связь, но правильно. Не «почему отказали?», а конкретно: «Что в моей секции по системе было слабым местом? На что мне стоит потратить следующие два месяца?» На конкретный вопрос отвечают охотнее. Многие компании по юридическим и репутационным причинам не дают развёрнутый фидбек — не давите.
• Ведите свой журнал. Таблица: компания, дата, этапы, вопросы, что не смог ответить, что почувствовал. После пяти собеседований в ней проступает система: одни и те же три темы, на которых вы плывёте. Это ваш личный, честный план подготовки — куда точнее любого списка «100 вопросов на собеседовании».
• Разбирайте секцию сразу после неё, пока помните. Двадцать минут в тот же вечер.
• Различайте типы отказов. «Не хватило глубины по X» — работать. «Взяли кандидата с опытом в нашем домене» — не работать, вы ничего не могли сделать. «Не сошлись по деньгам» — вопрос к калибровке ожиданий и к тому, каким компаниям вы пишете.
• Уточняйте, можно ли вернуться. У многих компаний есть cooldown 6–12 месяцев. Вернуться после отказа и получить оффер — совершенно обычная история.

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

Этика: чего не стоит делать никогда

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

• Не врите в резюме о фактах. Даты, компании, должности проверяются. Преувеличенный уровень владения технологией вскроется на первом же собеседовании; выдуманное место работы — при проверке рекомендаций и может стоить оффера уже после подписания.
• Не показывайте код бывшего работодателя. Даже кусками, даже «просто чтобы объяснить». Это нарушение NDA, и грамотный интервьюер это заметит и сделает выводы о вас, а не о вашем прошлом работодателе. Рассказывать про архитектуру и проблемы в обезличенном виде — можно; выкладывать исходники — нет.
• Не используйте оффер, который не собираетесь принимать, как рычаг. Иногда работает, но это разовый ход с долгим следом. Разница между «у меня есть другой процесс, и мне нужно решить до пятницы» (нормально) и выдуманным оффером (нет) — существенна.
• Не пропадайте. Если передумали — напишите одну строку. Молчаливое исчезновение после назначенного интервью запоминается сильнее, чем любой отказ.

Мини-итог

• Собеседование — двусторонняя проверка гипотезы при неполной информации, а не экзамен. Держите в голове, что вы тоже собеседуете компанию.
• Верхние этапы воронки отсеивают за неопределённость и несовпадение ожиданий, нижние — за глубину. Разные этапы требуют разной подготовки.
• Ваш вклад важнее вашего стека: говорите «я», приводите детали, объясняйте решения.
• В живой секции оценивается наблюдаемый процесс. Думайте вслух: уточните, предложите план, назовите сложность, начните с простого, проверьте краевые случаи.
• «Не знаю, но вот как бы разбирался» сильнее блефа. Подсказка — часть процесса, а не провал.
• Готовьте 5–7 историй по STAR и рассказ о себе на 90 секунд: это дёшево и встречается всегда.
• Вопросы работодателю — про факты и процессы, а не про самооценку компании. Ответ на «как задача попадает в прод» невозможно подделать.
• Отказ — чаще сравнение или внутренние причины компании, чем приговор. Ведите журнал собеседований: он даст точный план подготовки.

Что почитать

• Gayle Laakmann McDowell, Cracking the Coding Interview — про формат алгоритмических секций; читать выборочно, целиком актуально только для бигтеха. https://www.crackingthecodinginterview.com/
• Alex Xu, System Design Interview — разбор типовых дизайн-задач. https://bytebytego.com/
• Google, How we hire — публичное описание процесса найма крупной компании, полезно как образец структуры. https://www.google.com/about/careers/applications/how-we-hire/
• Joel Spolsky, The Guerrilla Guide to Interviewing — классический текст со стороны интервьюера, объясняет, откуда взялись многие практики. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
• Behavioral interviewing / STAR — методика структурирования историй, описана в большинстве HR-руководств; см. например материалы MIT CAPD. https://capd.mit.edu/resources/the-star-method-for-behavioral-interviews/
• Хабр Карьера — вилки и отзывы о компаниях: https://career.habr.com/
• getmatch — вилки в публикуемых вакансиях: https://getmatch.ru/
• levels.fyi — компенсации в международных компаниях: https://www.levels.fyi/
• Материалы портала: Требования и аналитика, Разработка, System design, Команда и коммуникация.

Что дальше

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

Как проводить собеседования: структура, оценка, предвзятость, обратная связь