Тема «ложь в резюме» обычно подается как моральная проблема кандидатов, но реальный сбой часто происходит раньше: на этапе, где вакансия превращается в набор фильтров. В истории, опубликованной на Habr / Карьера, требование знать сербский язык отсекло сильного кандидата, хотя через полгода на ту же позицию взяли человека без сербского и просто дали ему переводчика. Для русскоязычного IT-рынка это неприятно узнаваемый сюжет: вакансии пишутся как список обязательных условий, а потом бизнес сам же пересматривает половину этих «обязательностей».
Автор текста, HR-директор с многолетним опытом, описывает случай, когда сама не откликнулась на интересную роль из-за языкового требования. Формально решение выглядело рационально: если в вакансии написан сербский, значит без сербского дальше идти бессмысленно. Но практика показала обратное. Позицию в итоге закрыли кандидатом без этого навыка, потому что компания сочла риск управляемым и нашла обходной путь. И здесь ломается привычная логика обсуждения темы «ложь в резюме»: вопрос не только в том, приукрасил ли кандидат свой опыт, а в том, насколько система найма вообще умеет отличать критичные требования от декоративных.
В этом и состоит главный тезис материала. Рынок труда оценивает не опыт сам по себе, а то, как этот опыт прочитали через фильтры вакансии, рекрутера, ATS-системы и менеджера по найму. При этом сами требования в описании роли нередко разной природы. Одни действительно нельзя обойти. Другие нужны скорее для снижения тревожности у компании. Третьи попадают в вакансию по инерции: чтобы «не упустить идеального кандидата», которого, как обычно, не существует. На бумаге это выглядит как строгая спецификация, а на деле больше похоже на чеклист, где часть пунктов можно выкинуть после первого же сильного собеседования.
Какие фильтры реально работают
Автор разбирает типичную вакансию аналитика: 3+ года опыта, Python и SQL, продуктовая аналитика, английский и условный сербский язык. Затем сопоставляет ее с профилем кандидата: 2 года и 4 месяца официального опыта, еще около года через проекты и учебную занятость, активный SQL, частичный Python, участие в продуктовой аналитике без полной ответственности, сербского нет. Формально такой специалист не проходит. Но формальное «не проходит» не отвечает на главный вопрос: сможет ли он выполнять работу.
Здесь полезно разделить фильтры на три типа. Первый тип — формальные. Это годы опыта, даты работы, образование, иногда возраст. Их проще всего проверять автоматически, поэтому они чаще всего становятся жесткими барьерами. Именно поэтому кандидаты нередко пытаются их обходить: округляют стаж, по-своему трактуют проектную занятость, объединяют роли, растягивают даты. Для компании такие маневры выглядят как прямой обман, потому что поле будто бы бинарное: либо три года есть, либо нет. Но парадокс в том, что даже эти фильтры сама система найма потом может отменить, если увидит сильный профиль и решит, что требование было завышено.
Второй тип — надуманные фильтры. В кейсе это сербский язык. Снаружи он выглядит обязательным, но по факту выясняется, что бизнес может жить и с переводчиком. Кандидат заранее этого не знает. Для него вакансия выглядит закрытой. В результате один специалист честно отсеивает себя сам, другой подается «на удачу», третий начинает думать, не стоит ли слегка подправить резюме. Так и возникает поле, где разговор о лжи в резюме подменяет разговор о качестве постановки требований. Если компания сама готова пересматривать условие, значит проблема не в том, что кандидат не подошел, а в том, что фильтр был описан как жесткий без достаточных оснований.
Третий тип — содержательные фильтры, и вот они обычно решают все. Это глубина опыта, масштаб задач, уровень самостоятельности, качество владения инструментом, способность отвечать за результат. Их нельзя надежно проверить по одному числу в анкете. Система видит только слова. Для нее есть большая разница между формулировками «участвовал в анализе данных» и «анализировал поведение пользователей и формировал гипотезы». Фактически человек мог делать похожую работу, но в первом варианте его опыт выглядит вспомогательным, а во втором — осмысленным и применимым к продуктовой роли. Именно здесь сильные кандидаты часто проигрывают: они умеют работать, но не умеют описывать свою работу так, чтобы она была распознана без дополнительных усилий со стороны рекрутера.
Что это значит для IT-рынка
Для разработчиков, аналитиков, продактов и тимлидов вывод довольно приземленный. Большинство проигрывает не на «лжи в резюме» как таковой, а на слабой упаковке реального опыта. На рынке, где первое решение о кандидате нередко принимается за минуты, описание задач и результатов становится частью профессионального инструментария, нравится это кому-то или нет. Если специалист вел A/B-тесты, вытаскивал инсайты из пользовательских данных, влиял на продуктовые решения, но описал все это как «помогал команде с аналитикой», система почти наверняка недооценит профиль. А потом все будут обсуждать дефицит кадров и странности найма, хотя часть проблемы лежит в переводе опыта на язык понятных сигналов.
Для HR и руководителей история еще менее приятная. Если вакансия содержит требования разной строгости, но оформлена как список одинаково обязательных пунктов, компания сама сужает воронку сильнее, чем нужно. Особенно это чувствительно в IT, где роль может меняться уже по ходу поиска, а стек и ожидания доопределяются после первых интервью. Когда бизнес прячет желательные параметры среди обязательных, он стимулирует два вредных сценария. Первый — сильные кандидаты не откликаются. Второй — откликаются те, кто готов агрессивно подгонять резюме под формальные рамки. Ирония в том, что система, созданная для снижения риска ошибки найма, в такой конфигурации сама повышает этот риск.
При этом материал аккуратно проводит важную границу. Адаптировать описание опыта — нормально, если человек может развернуть, объяснить и защитить каждую формулировку на интервью. Придумывать навык, которого не было, — плохая идея, и вскрывается она быстро. Иначе говоря, не вся редактура резюме равна искажению. В российской и русскоязычной IT-практике это особенно актуально для переходов между ролями: из data analyst в product analyst, из backend-разработки в platform engineering, из рекрутинга в HRBP. Формально человек еще «не тот», но по содержанию уже делает значимую часть нужной работы. Если он описывает эту работу точно и предметно, это не обман, а нормальная интерпретация опыта.
На фоне разговоров о дефиците специалистов и росте стоимости найма этот кейс бьет по обеим сторонам рынка. Кандидатам он напоминает, что не стоит заранее отсеивать себя по каждому спорному пункту. Работодателям — что список требований в вакансии не должен быть складом корпоративных страхов. Чем больше найм опирается на ленивые формальные барьеры, тем выше шанс пропустить сильного специалиста, который просто не совпал с шаблоном по одному пункту. И если вокруг темы «ложь в резюме» снова начнется моральная паника, полезно сначала проверить, не врут ли вакансии о собственной строгости.