Скрининг – дар или проклятье?

Довольно часто от опытных разработчиков можно услышать: “Скрининг?! Это даже и близко не имеет никакого отношения к трудовым реалиям! Дайте задачку – я решу.”

“Не понимаю, почему мне не позволяют писать программное обеспечение – существует фундаментальное несоответствие между публичными утверждениями, что компании отчаянно ищут инженеров-программистов, и жестокой реальностью отсеивания кандидатов.”

Звучит резонно, но существующие стандарты крупных компаний по отбору кандидатов оспаривать не приходится. Очевидно, им нужны толковые специалисты, и необходим метод оценки профессиональных качеств. Но так ли эффективны выбранные вопросы для скрининга, релевантные ли знания они оценивают? Есть теория, будто практики пришли из именитых компаний-гигантов, число претендентов занять должность в которых настолько велико, что даже сотню лучших из лучших необходимо “прочесать” до 10.

“Вокруг прохождения собеседований существует смежная индустрия. Все эти задачки на алгоритмы начались с популярных компаний, таких как Google. Потом несколько инженеров из этих компаний создали материал для подготовки к собеседованиям. Две популярные книги: «Взлом интервью по кодированию» и «Элементы собеседований по программированию» предлагают материал для подготовки к интервью. Проблема в том, что индустрия получила доступ к этим книгам и адаптировала свои интервью к их материалу. Но когда люди начали массово отвечать на основные вопросы, изложенные в этих книгах, компании поняли, что фильтрация сотрудников перестала работать. Поэтому они написали новые, более сложные вопросы на алгоритмы, чтобы выделиться и нанимать «более квалифицированных кандидатов из всех, казалось бы, квалифицированных». Существует множество историй о нынешних и бывших инженерах высшего звена в конкретных компаниях, которые утверждают, что процесс собеседования стал настолько трудным, что они сами никогда не прошли бы его сейчас.”

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

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

Сколько чемпионов сошли с дистанции в начале пути?

В силах рекрутера немного помочь: можно озвучить основные темы предстоящих вопросов или предложить материал для подготовки.

“Сейчас компании больше боятся нанять плохого кандидата, чем радуются возможности нанять отличного. False negatives are okay. Вот ты гениален и тебя не наняли — и фиг с ним. Лишь бы не получилось false positive — когда ты бревно, а тебя наняли.”

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