На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"?
Я — помню, и помню, что страшно гордился тем, как я хорош. Помню, как я читал эти слова в резюме кандидата, когда первый раз в жизни оказался в роли нанимающего менеджера. Много думал, после чего уже не так собой гордился.
Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни.
Добро пожаловать под кат.
Про типовой технический собес
А какие есть скрытые резервы в техническом собесе?
А вдруг можно ещё лучше?
Модель STAR(AR)
Что все это дает нам на практике?
Про типовой технический собес
Давайте начнем с того, для чего вообще нужно техническое собеседование.
Самая распространенная версия — для оценки технических навыков. И с этим сразу же начинаются проблемы. Если вы ищете не совсем начинающего джуна, то требуемый объем знаний и опыта практически невозможно полноценно оценить за час-полтора. Но как-то это сделать нужно, поэтому собеседование превращается в некоторое подобие экзамена с быстрыми короткими вопросами-ответами. Думаю, мало кому в принципе нравилось сдавать экзамены, а если ещё и экзаменатор вдруг решит на тебе отыграться за невкусный утренний кофе?
Наверняка, каждый хоть раз попадал в подобную ситуацию. Экзамен казался приемлемым в годы учебы, но во взрослой жизни это уже не выглядит, как что-то нормальное. А ведь ожидается, что люди, сидящие по разные стороны стола на собесе, должны будут каким-то образом потом вместе работать.
Но есть в этом и что-то хорошее для кандидата: если на собеседовании ты встречаешь въедливого и придирчивого садиста-экзаменатора, который в перспективе должен стать твоим руководителем, принять решение не в пользу этой компании очень легко.
Что можно получить в итоге такого собеседования? Какое впечатление сложится об испытуемом и о таком экзаменаторе?
С одной стороны, вы скорее всего увидите агрессивного и необщительного человека с нервным тиком; с другой стороны, вас будут считать садистом-маньяком с манией величия. Психотерапевты, прием которых включен в программу медицинского страхования, на этом моменте радостно потирают руки.
Допустим, каким-то чудом вы смогли договориться и найти того самого, кто пойдет дальше технического собеседования — на HR интервью. Не знаю точно, что там происходит, но вердикт HR-а для неподготовленного человека выглядит, как краткое описание тяговой лошади:
в меру весел,
морально неустойчив,
есть задел на лидерские качества,
при должном стимулировании обучаем,
зубы целые,
взгляд загадочен.
Что с этим делать, как это должно помочь принять решение о найме, а главное, как эти качества будут проявлять себя в процессе работы - вопросы остаются открытыми.
Думаю, основную идею вы уловили — собеседование в виде экзамена не помогает ни компании, ни кандидату.
А какие есть скрытые резервы в техническом собесе?
Допустим, вы ищете инженера с опытом администрирования Linux, и вам будет достаточно следующих умений:
работать в консоли (команды навигации, работа с файлами);
уметь обращаться с логами;
менять настройки стандартных системных сервисов.
Теперь представим, что к вам на собеседование пришел кандидат, который утверждает, что все это умеет. Естественно, вы хотите это проверить и задаете вопросы, начиная с самых базовых. Какие это могут быть вопросы?
Про стандартные консольные команды навигации и работы с файлами (cd, mkdir, cp, mv …. плюс дежурная шутка про то, как выйти из vi);
Про то, где находятся логи разных сервисов (syslog, error_log/error.log ….);
Про то, где находятся файлы конфигураций разных сервисов (httpd.conf/apache2.conf, php.ini, my.cnf и т.д.).
Таким образом, мы узнаем, что у кандидата есть, как минимум, теоретические знания по каждому пункту. В то же время, не факт, что знания подкреплены практикой, и он умеет ими пользоваться в реальных задачах. В каких-то случаях этого будет достаточно, но чаще мы ожидаем от кандидата знаний, подкрепленных практическим опытом.
Для связи теории и практики можно пойти другим, более прикладным путем. Попробуем дать задачку, решение которой так или иначе продемонстрирует нужные знания:
Пользователи вашего проекта на PHP жалуются, что не могут загрузить файлик размера больше двух мегабайт. Расскажите пошагово, как будете исследовать проблему и чинить её?
В ответ есть вероятность услышать что-то вроде:
Включу нужные опции в секции Error handling and logging файла конфига php.ini, там же посмотрю опцию error_log, чтобы найти, где хранятся логи.
В логе найду ошибку о том, что The uploaded file exceeds the upload_max_filesize directive in php.ini, после чего поправлю соответствующую опцию в php.ini, задав нужный разумный предел.
Таким образом, кандидат продемонстрировал, что кроме знания отдельных вопросов, умеет решать и более комплексные задачи.
Казалось бы, это то, что надо! Но…
А вдруг можно ещё лучше?
Давайте зададим кандидату вопрос в следующем ключе:
Расскажите о ситуации из вашего опыта, когда вам понадобилось исследовать проблему и удалось исправить её, поменяв настройки системных сервисов.
Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?
Пофантазируем, какой рассказ мы могли бы получить в ответ.
Проблема: Из отдела маркетинга пожаловались, что они не могут разместить на корпоративном сайте pdf с бренд-буком через стандартную форму загрузки файлов. Из-за этого приходится разбивать pdf на отдельные картинки и загружать их по одной.
Задача: Понять причину проблемы с загрузкой файлов в формате pdf, предложить способ её решения.
Решение: Путем курения логов наш кандидат выяснил, что виноват не формат файла, а его размер. Поразбирался в настройках php.ini и пришел к решению установить директивы upload_max_filesize = 20M и post_max_size = 20M. Это решило проблему. Поправленные настройки кандидат добавил в инструкции по деплою и настройке продакшн сервера.
Таким ответом кандидат не только показал необходимые знания и умения, но и он продемонстрировал похвальное небезразличие к проблемам смежных отделов.
Мы можем сделать вывод, что он способен самостоятельно найти и починить проблему, и, как вишенка на тортике, кандидат проявил заботу о коллегах, т.к. сохранил ценную информацию в документации. А это позволит коллегам решить аналогичную проблему в будущем.
Это ли не чудо?
В то же время, кто-то может справедливо заметить, что без спроса менять что-то на продакшн сервере — это сомнительная инициатива. В некоторых ситуациях это даже может быть засчитано за безответственность.
Таким образом, помимо подтверждения технических навыков, мы коснулись и софт скиллов кандидата. Тот самый фидбек от HRов “отзывчив, инициативен, проактивен” обретает смысл и вполне реальные очертания. Становится намного проще ответить на вопрос:
Хотите ли вы, чтобы человек с таким набором знаний, умений и качеств работал с вами в команде?
А теперь давайте разберем, как мы это добились.
Модель STAR(AR)
Напомню, вопрос кандидату звучал как:
Расскажите о ситуации из вашего опыта, когда вам понадобилось исследовать проблему и удалось исправить её, поменяв настройки системных сервисов.
Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?
Для вопроса мы использовали модель STAR(AR). Эта модель состоит из четырех (либо пяти) важных составляющих:
Situation (ситуация).
Task (задача).
Actions (действия).
Results (результаты).
Alternative Results (альтернативные результаты).
Схема позволяет как задать четкий вопрос, так и предлагает структуру, которая помогает кандидату дать ответ по существу.
Но и это ещё не все! Незаметные глазу нюансы — вопрос, обращенный к реальному опыту с большей вероятностью покажет, как кандидат привык действовать в реальной жизни. А это как раз то, с чем вы столкнетесь, когда (и если) он перейдет из категории “кандидат” в категорию “коллега”.
Дополнительный приятный бонус скрывается в пункте Alternative Results. Вопрос “как бы вы поступили в такой же ситуации сейчас?” может показать, чему кандидат научился с тех пор, как рассказанная ситуация случилась в его жизни. А это уже намекнет вам на способность переосмысливать свой опыт, учиться и делать выводы, даже если изначальное решение было неоптимальным, а то и вовсе неправильным.
Давайте представим, как наш кандидат мог бы ответить на этот вопрос, пусть это будет:
Сейчас я бы установил директиву post_max_size = 60M, т.к. сама форма загрузки позволяла загружать до 3 файлов одновременно.
Готово, вы восхитительны! Похоже, что наш кандидат нам подходит.
Что все это дает нам на практике?
Не теряя в качестве оценки технических навыков мы приобретаем возможность узнать кандидата ближе именно с позиции личностных качеств. В примерах мы рассмотрели преимущественно положительные качества, реальность же полна разочарований. Поэтому я советую продумывать свои вопросы таким образом, чтобы иметь возможность в ответах найти паттерны поведения, которые вы хотели бы видеть у своего будущего коллеги (или наоборот — не хотели бы).
Даже если кандидат в своем ответе не покажет паттерн в явном виде, из ответа вы получаете больше контекста об опыте кандидата. А это позволяет задать нужные вам уточняющие вопросы.
Бонусный уровень
Потренировавшись находить маркеры поведения в ответах на технические вопросы, вы сможете целенаправленно задавать вопросы, направленные на те или иные софт скиллы кандидата. Стоит упомянуть, что не стоит доверять или разочаровываться первым же ответом. В идеале каждый замеченный вами паттерн должен быть проверен как минимум дважды. Т.е. вопросов, раскрывающих то или иное поведение стоит заготовить больше, чтобы дать возможность кандидату закрепить свой успех в ваших глазах.
Все это даст вам качественную всестороннюю оценку, а значит уменьшит вероятность ошибки, когда грамотный с технической точки зрения специалист не подходит в вашу команду просто потому, что вы ожидали от него одних качеств, а получили совсем другие.
А как вы оцениваете софт скиллы? Какие техники или методы используете для этого?
