Когда я работал разработчиком и тимлидом, я прошел много собеседований. Со временем накопился список странных и бессмысленных вопросов. Их много, но здесь только те, что запомнились сильнее остальных. Я не пытаюсь объяснить мотивы интервьюеров. Я просто хочу показать, как эти вопросы звучат в разговоре и какое ощущение оставляют.

Пассивно-агрессивные ловушки

• Вы не боитесь, что не справитесь с нашей динамикой?
• Не кажется ли вам, что вы переквалифицированы для этой роли?
• Чем объясняются длинные паузы в вашей карьере?
• Сколько вы зарабатывали раньше?

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

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

Странные вопросы

• Какой у вас любимый цвет и почему?
• С каким животным вы себя ассоциируете?
• Как бы вы описали свой идеальный день?

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

Почти психология

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

Такие вопросы выглядят как попытка понять зрелость и самоосознанность. На практике они переводят разговор в режим личной рефлексии под наблюдением. У кандидата нет времени, чтобы спокойно подумать или уточнить контекст. Он пришел обсуждать работу, а попадает в ситуацию, где нужно быстро объяснять собственные реакции и мотивы. Без подготовленных ответов человек пытается уловить ожидаемый образ. Это вынуждает его импровизировать. В итоге собеседование оценивает не пригодность к задаче, а устойчивость к подобным вопросам.

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

• Почему вы считаете, что подходите под эту роль?
• Чем ваш опыт может быть полезен нашей команде?
• Почему вы хотите работать именно у нас?
• Какие ценности нашей компании вам близки?

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

Фокус на последнем месте работы

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

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

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

В конце собеседования остаётся простой вопрос: понял ли ты человека, и понял ли он тебя?

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

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

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

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

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

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

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

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