Из 40-50 команд, с которыми автору исходного текста довелось работать за карьеру, только 3-4 действительно требовали глубокого разговора про алгоритмы и низкоуровневые оптимизации. Но алгоритмические собеседования до сих пор остаются стандартом даже там, где будущая работа сводится не к графам и индексам, а к API, формам, запросам и поддержке продуктовой логики. Для российского IT-рынка это важный сигнал: многие компании продолжают копировать практики бигтеха, не задавая себе простой вопрос, зачем они вообще это делают.
Об этом пишет Habr / Карьера в колонке с нарочито грубым, но предельно понятным тезисом: значительная часть интервью для разработчиков давно превратилась не в проверку реальных рабочих навыков, а в прокси-тест на общую сообразительность. В тексте бывший руководитель из крупного русскоязычного бигтеха объясняет происхождение этого формата без романтики и без священных коров. По его версии, задача с сортировкой пузырьком на собеседовании возникла не потому, что бизнесу срочно нужны люди, готовые писать сортировку пузырьком в проде, а потому, что крупной компании нужен был единый, дешевый и понятный способ сравнивать очень разных кандидатов между собой.
Логика бигтеха в этой схеме довольно приземленная. Когда у тебя сотни команд, тысячи инженеров, разные внутренние стеки, разные процессы и разные менеджеры, возникает потребность в унифицированной линейке оценки. Неважно, идет человек в продуктовый Python, в системный Go или в мобильную разработку: на входе нужно понять, насколько быстро он соображает, способен ли разложить задачу на шаги и можно ли его потом доучить внутри компании. Алгоритмы оказались удобным универсальным заменителем такого теста. Они знакомы выпускникам технических вузов, относительно стандартизированы, не требуют знания конкретного домена и позволяют быстро отделить тех, кто уверенно мыслит в абстрактных конструкциях, от тех, кто теряется уже на базовом уровне.
Проблема в том, что этот подход исторически объясним, но далеко не всегда оправдан. Автор материала напоминает: формат абстрактных задач на интервью пришел не из инженерной необходимости, а из управленческой практики. Еще в 1960-х McKinsey использовала кейсы на логику и структуру мышления, а в 2000-х Google адаптировала эту механику для разработчиков, заменив бизнес-задачи на алгоритмические. Позже, в 2015 году, бывший вице-президент Google по People Operations Ласло Бок в книге Work Rules! прямо признавал, что brainteasers плохо предсказывают результативность сотрудника. Но даже после таких признаний алгоритмические собеседования не исчезли. Причина не в том, что они идеальны, а в том, что они удобны для массового найма.
На масштабе корпорации это действительно может работать терпимо. Кандидат, который быстро рассуждает про сортировки, префиксные структуры и графы, скорее всего, разберется и с внутренним зоопарком сервисов, и с корпоративными фреймворками, и с не самым дружелюбным наследием. Да, на адаптацию может уйти до полугода, но для большой компании это допустимая цена. Более того, за последние 3-4 года в крупных организациях стали чаще добавлять профильные секции: по Go и PostgreSQL, по Flutter и кроссплатформенной архитектуре, по платформенным ограничениям конкретного стека. Это уже похоже на движение в сторону здравого смысла, потому что общий интеллект мобильного разработчика логичнее проверять в разговоре про мобильную архитектуру, а не через абстрактную задачу из учебника первого курса.
Самая жесткая часть критики адресована не бигтеху, а компаниям среднего размера, которые воспроизводят эту модель как ритуал. Если организация нанимает не “куда-нибудь в империю”, а в конкретную команду с понятным бэклогом и понятными задачами, у нее нет рациональной причины устраивать многоступенчатую пытку на алгоритмы ради вакансии, где основная работа связана с веб-сервисами, интеграциями, интерфейсами или бизнес-логикой. В такой ситуации полезнее дать кандидату небольшую задачу, похожую на реальную работу, обсудить существующую проблему команды или попросить разобрать архитектурный компромисс. Если этого не происходит, автор называет причину без дипломатии: слабая квалификация нанимающего и карго-культ, в котором форма давно победила смысл.
Это особенно чувствительно для российского рынка, где многие команды по привычке пытаются выглядеть “как в больших компаниях”, хотя живут в совершенно других условиях. У среднего бизнеса нет запаса в шесть месяцев на раскачку человека, нет сотен однородных вакансий в год и нет особой пользы от унифицированного фильтра, если разработчик нужен под конкретный стек и конкретный набор задач. В такой среде алгоритмические собеседования часто превращаются в дорогую ошибку: сильные кандидаты отваливаются из-за бессмысленного барьера, а слабый процесс найма маскируется под якобы высокую планку. В результате компания не улучшает качество подбора, а просто удлиняет цикл найма и повышает риск промаха.
При этом сам автор не предлагает выбросить алгоритмы на свалку целиком. Он делает важную оговорку: примерно 10% команд действительно решают задачи, где разговор про оптимизации, сложность, структуры данных и низкоуровневое поведение системы нужен не для декора, а по делу. В пример приводятся команды, работающие с нагруженными экранами, тяжелыми кешами, сложной распределенной логикой, шардированием по географии или собственными механизмами репликации. Для компаний уровня Databricks, которые строят платформы для обработки больших данных, любовь к таким секциям тоже выглядит объяснимо. Но это именно исключение, а не норма для любой вакансии разработчика.
Главный вывод из этой истории неприятен, но полезен. Алгоритмические собеседования не являются сакральной проверкой “настоящего инженера” и уж точно не гарантируют качество найма сами по себе. Это инструмент, придуманный под задачи крупного масштаба, и за пределами этого масштаба он слишком часто превращается в соломенный самолет, вокруг которого все дружно прыгают с серьезными лицами. Для разработчиков это повод трезво оценивать компании еще на этапе интервью, а для руководителей команд — наконец перестать путать жесткость процесса с его пользой.