какие вопросы задать на собеседовании инженеру
Какие вопросы задать на собеседовании инженеру
Группа: Участники форума
Сообщений: 29101
Регистрация: 4.12.2006
Из: 97
Пользователь №: 5032
2. Как вы считаете, почему мы должны выбрать именно вас?
Вам работники вообще нужны? Ну вот он я. Работник. Именно меня стоит выбрать хотя бы потому, что я явно умнее всех тех, кто заливал на эти вопросы стандартную чушь. И умнее вас, между прочим, потому что я никогда таких дурацких вопросов бы не задал.
4. Почему вы ушли с предыдущего места работы?
Предположим, отвечу честно: маленькая зарплата или отсутствие карьерного роста, или бесперспективность, или не сошелся с коллективом, или не понравился собаке начальника. И что? Вы же не знаете, сойдусь ли я с вашим начальником, коллективом и их собакой. И не узнаете, пока не попробуете.
5. Кем вы видите себя через 5 лет в нашей компании?
Вот вам встречный вопрос: какие планы компании на ближайшие 5 лет? Нет таких? Так если вы сами не знаете, что с вами будет через 20 лет, будет ли компания и какую нишу она намеревается занять, то мне-то откуда это знать?
7. Каким бы вы хотели видеть своего начальника?
Я бы хотел его не видеть. Серьезно, мне нет разницы как он выглядит. Главное, чтобы он был начальником: тем, кто может нормально и внятно сформулировать задачи. А в остальном, пусть хоть в красных труселях на белой капибаре разъезжает по офису.
17 обязательных вопросов для технического интервью
Большинство IT рекрутеров знают, что им приходится выходить за рамки технической квалификации кандидата на работу при подборе ИТ-персонала.
Soft скиллы и инициатива, например, являются не менее важными факторами для рассмотрения. И чтобы получить такое понимание, вам нужно будет отложить резюме и придумать такие вопросы для интервью, чтобы грамотно оценить их.
1. Какие интернет-ресурсы вы используете, чтобы помочь вам делать свою работу эффективнее?
Большинство ит специалистов обращаются к таким сайтам, как StackExchange или Github, когда им нужна помощь в чем-то. Серьезные профессионалы будут иметь свой собственный выбор веб-сайтов, онлайн-сообществ, каналов социальных сетей и других ресурсов, специфичных для их интересов. Ответ на этот вопрос даст вам представление о том, насколько кандидат вовлечен в более широкий ИТ мир.
2. Как вы поддерживаете свои технологические навыки в актуальном состоянии?
Технические специалисты упорно работают, чтобы поддерживать свою базу знаний актуальной, читая блоги и форумы, посещая онлайн-курсы, присоединяясь к хакатонам и подключаясь к личным ИТ-проектам. Этот вопрос на интервью может помочь вам оценить энтузиазм кандидата к профессии, а также открыть разговор о профессиональном развитии.
3. Представьте, что я не технарь. Можете ли вы объяснить [соответствующую технологию] в простых терминах?
Он играет решающую роль практически в каждой компании, поэтому умение общаться с не техническими людьми является обязательным. Вы можете оценить коммуникативные навыки кандидатов с помощью этого вопроса. Избегают ли они непонятных аббревиатур и жаргона? Насколько хорошо могут сломать сложный процесс? Попробуйте задать несколько «тупых» последующих вопросов, чтобы получить представление о том, как кандидат будет взаимодействовать с коллегами не из ит сферы.
4. Какие сильные стороны, по вашему мнению, наиболее важны для разработчика [или другой соответствующей ИТ позиции]?
Такой вопрос может показать, как собеседник относится к этой позиции и что, по его мнению, он принесет в нее. Некоторые кандидаты могут сосредоточиться на технических способностях и ИТ сертификациях, в то время как другие могут больше говорить о решении проблем, внимании к деталям, общении и других общих навыках работы. Ищите кандидатов, которые дадут взвешенный ответ.
5. Какие три слова использовали бы ваши коллеги, чтобы описать вас?
Ответ может подсказать вам о чертах личности кандидата, которые не могут быть легко видны через резюме или традиционные вопросы интервью. Это также дает представление о том, как человек воспринимает себя и роль, на которую он претендует. Например, если ответ фокусируется на творческой стороне, но позиция очень аналитична по своей природе, работа может быть не очень подходящей.
6. Можете ли вы рассказать мне о том времени, когда все шло не так, как вы хотели на работе, например, о провалившемся проекте или о том, что вам не дали повышения по службе?
Каждый человек в какой-то момент своей карьеры сталкивается с профессиональными неудачами. То, что вы хотите знать, — это то, как люди справлялись с этими ситуациями и чему они научились. Лучшие сотрудники устойчивы, используя неудачи как трамплин к позитивным изменениям. Поэтому прислушайтесь не только к проблеме, о которой упоминает соискатель, но и к тому, что он сделал после разочарования.
7. Каковы ваши любимые и наименее любимые технологические продукты и почему?
В дополнение к изучению того, нравится ли потенциальным сотрудникам оборудование, операционная система и программное обеспечение, используемые вашей компанией, этот технический вопрос интервью поможет вам оценить энтузиазм и знания. Оживляются ли кандидаты, обсуждая преимущества и недостатки тех или иных инструментов? Восхищаются ли они качеством кода, безупречным дизайном, интуитивно понятным пользовательским интерфейсом или другим аспектом хорошей технологии?
8. Каковы преимущества и недостатки работы по Agile?
Большинство ИТ команд приняли ту или иную форму Agile — в настоящее время излюбленную методологию SDLC — что означает множество быстрых встреч и постоянный поток обратной связи от коллег / членов команды. Ответ кандидата на этот вопрос может рассказать вам не только об уровне его понимания этой методологии, но и об отношении к сотрудничеству и общению.
9. Как вы считаете, дальнейшее развитие технологий повлияет на вашу работу?
Достижения в области технологий продолжают изменять большинство ролей в ИТ. Насколько осведомлен об этом кандидат, с которым вы проводите собеседование? Знают ли они, например, что автоматизированное тестирование является основной частью DevOps, что позволяет ускорить циклы разработки и ускорить развертывание? Кандидат может рассказать об используемых им инструментах автоматизации или проблемах работы с машинным обучением и большими данными. Они также могут обсуждать проекты искусственного интеллекта, над которыми они хотят работать. Этот вопрос, хороший способ начать разговор о тенденциях и достижениях в этой области, а также даст вам представление о том, как кандидат воспринимает свою роль в долгосрочной перспективе.
10. Расскажите мне о техническом проекте, над которым вы работали в свободное время?
Вы хотите нанять ИТ специалиста, который посвящает свое личное время другим проектам. Почему? Это люди целеустремленные и любознательные, что, в свою очередь, сохраняют навыки актуальными. Спросите, как они держут мотивацию, что их интересует в проекте и какова их конечная цель. Если они могут продемонстрировать веб-сайт или приложение, которое они создали, тем лучше.
11. Какой была последняя презентация, которую вы дали?
Сегодняшние соискатели в ит не могут быть одинокими волками. Они должны обсуждать изменения с товарищами по команде, координировать свои действия с другими отделами, отстаивать платформы, которые они предпочитают, и многое другое. Хотя не все должны любить публичные выступления, ваш новый сотрудник должен уметь проводить исследования, составлять солидную презентацию и убеждать заинтересованных лиц, почему X лучше, чем Y.
12. Каковы качества успешного руководителя команды или проекта?
Всегда ищите лидеров, даже если вы не нанимаете человека на руководящую должность. Характер работы в IT означает, что людям часто приходится брать на себя ответственность за реализацию проектов, а это требует лидерских навыков, таких как организованность, позитивность, делегирование полномочий и коммуникация.
14. Чего бы вы хотели достичь в первые шесть месяцев после приема на работу?
Ответ на этот вопрос интервью зависит от роли. Разработчик, например, может надеяться разработать небольшой проект за это время, в то время как технический менеджер может захотеть проанализировать внутренние процессы. Ответ кандидата даст вам представление об общем понимании позиции. Если цели соискателя и амбиции не соответствуют описанию работы, это может быть не самая подходящая должность для него.
15. Как вы справляетесь с работой с сжатыми сроками?
ИТ команды часто сталкиваются с огромными временными ограничениями. Вам нужен кто-то, кто может работать эффективно и точно, когда находится под давлением. Задайте этот вопрос потенциальному сотруднику, и вы, по крайней мере, получите представление о том, как он справляется со стрессом и может ли он идти в ногу с темпами проектов в вашей компании. Вы также можете продолжить, спросив, пропускали ли он когда-либо сроки и, если да, то как справлялся с ситуацией.
17. Почему вы хотите работать у нас?
Люди, которые действительно хотят работать, проведут свои исследования и смогут рассказать о ценностях вашей компании, продуктах и услугах, а также о подходе к технологиям. Если они не могут сформулировать хотя бы несколько причин, по которым ваша компания будет хорошо соответствовать их навыкам и амбициям, значит, они не проявили должной осмотрительности, чтобы подготовиться к собеседованию.
Не забудьте дать кандидатам время в конце собеседования задать вам вопросы. Это не только полезно для соискателей — это также дает вам ключ к тому, что важно для них. Например, вы можете пересмотреть свой интерес к потенциальному сотруднику, если он кажется чрезмерно озабоченным начислением заработной платы и отпусков во время первого собеседования. Или вы можете быть впечатлены, когда услышите вопросы, которые демонстрируют их деловую хватку и глубокое понимание сильных и слабых сторон вашей компании. Техническое интервью со стороны рекрутера должно проходить максимально компетентно!
Собеседование для QA: резюме, вопросы на интервью, переговоры о зарплате + полезные ссылки
Спросили Алексея Петрова pifagor_mc, Head of QA Сбермаркета, про интервью QA-инженеров и записали ответы. А ещё для подготовки прикрепили ссылки, которые он советовал — ищите их в конце статьи.
В тексте говорим только про собеседования:
3 основные рекомендации по составлению резюме для QA
Из каких блоков состоит стандартное интервью
Поделюсь рецептом, который встречаю, и пользуюсь им, когда сам собеседую.
В g-mate — много крутых вакансий для QA. Используйте бот @g_jobbot, чтобы получать вакансии по своему профилю прямо в Telegram.
Самый популярный кейс, чтобы составить представление, что будет на интервью
Открытием для QA этот кейс не станет: тестирование простейшей формочки, формы поиска или авторизации/регистрации. Практика показывает, что очень многие специалисты не могут решить эту задачу в полной мере, сообразно тому, что ожидают IT-компании. Тестировщики подходят к ней с точки зрения теории тестирования, классов эквивалентности, анализа граничных значений, строят графы переходы состояний. При этом забывают о продуктовом тестировании, когда фокус идёт не на комбинаторику и техники типа pairwise, а на сценарии, с которыми сталкивается реальный пользователь.
Наверное, теперь придётся исключить из собеседований этот вопрос! Но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. Я регулярно сталкиваюсь с тем, что забываю пароль от очередного сервиса, и надо его восстанавливать.
По старому тебя не должно пускать, а по новому — должно. Именно по таким кейсам можно посмотреть, как кандидат владеет техниками тест-дизайна, может ли он от них абстрагироваться и думать о продукте не как о наборе кнопочек и формочек, а как о пользовательском сценарии, с которым сталкивается самый обычный пользователь.
В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение. Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.
Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.
Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.
Что спрашивать интервьюеров на собеседовании
Позволю себе отойти в сторону: 50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.
Я призываю всех искренне и прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.
Если говорить про то, что спрашивать интервьюеров — советую задавать вопросы, применимые на практике, не абстрактные. Например, человек собеседуется на позицию специалиста по ручному тестированию, а спрашивает, что в компании с автоматизацией, нагрузочным тестированием, какие перспективы стать тимлидом — хотя сам — джуниор.
Спрашивайте то, что максимально релевантно функциональной нагрузке в будущей компании: как будет проходить испытательный срок, какие будут задачи, как понять, прошли ли вы испытательный срок или нет, есть ли kpi. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.
Soft skills для QA: 3 качества, которые стоит прокачивать в себе по твоему мнению
Центральный навык — самообучаемость. Бесконечно часто бывает, кандидат рассказывает, как хочет погрузиться в специфику мобильного тестирования или автоматизацию, хочет стать тимлидом — а злой и коварный работодатель не даёт ему это сделать. Поэтому он ищет работу, где сможет себя проявить, и ждёт, что его, как в «Волшебнике из страны Оз», возьмут за ручку и по дороге из желтого кирпича поведут в мир новых знаний и компетенций.
Всё-таки хочется, чтобы человек был сам заинтересован в собственном обучении. Конечно, работодатели предоставляют возможности для роста внутри компании: конференции, митапы, посещение профильных мероприятий, бюджеты на обучение и прочее. Но важно, чтобы человек сам делал шаги в этом направлении: пет-проект по автоматизации, ссылка на Github, а там — да, может быть, «карманные» тесты, на основе роликов в Ютубе или курсов Udemy. Но уже это показывает, что инженер не стоит на месте, а обозначил себе цель и идёт ей навстречу, не ждёт чуда.
Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options. ». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое. ». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.
Модная концепция, набирающая обороты в продуктовых командах: есть закреплённый тестировщик, и он единственный и самый компетентный QA в команде. Если на планировании он будет точно так же говорить: «ой, ну не знаю, может, не стоить брать, я могу не успеть» — это не прокатит. Человек должен излучать уверенность: такая черта характера не позволит проскочить багам на уровне «и так сойдет». QA должен убедить коллег, привести аргументы, что так делать не стоит.
Ещё — автономность в работе. Всё чаще в продуктовых командах QA работают в одиночку или в паре. В сервисной модели есть большой отдел тестирования, есть тимлиды — можно забиться в уголок и отсидеться, а проблемы решит старший товарищ, ведущий инженер, тимлид, руководитель группы. В продуктовых так не получится, и компаний с похожим подходом компаний всё больше. Поэтому надо прокачивать уверенность и автономность.
А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.
И всё равно — на одних софт скиллах далеко не уедешь, под ними должна быть техническая подложка. Опытный интервьюер быстро смекнёт, если человек умеет только рассуждать.
Зарплата по грейдам: про какие цифры может идти речь, к чему стремиться
Сразу скажу, что рынок очень сильно поломался ковидом и удалёнкой. География присутствия расширилась, и у многих компаний поменялись установки.
Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.
У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».
Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.
Тимлиды получают от 140 тыс. до 300 тыс., для хэдов я видел вакансии до 500 тысяч рублей. Все цифры называю с учётом налогов.
Как торговаться о зарплате
Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.
Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.
Важно быть честным, если вопрос финансов — определяющий. Неприятные ощущения остаются от беседы с человеком, который всё собеседование бьёт себя пяткой в грудь, говорит про развитие и интерес к продукту, желание работать в продуктовой команде, а потом называет цифру в 140 тыс., при текущей 95 тыс. Про таких невольно думаешь: и рыбку съесть, и косточкой не подавиться.
Здорово, если деньги становятся не самоцелью, а дополнительной наградой, плюс хочется соразмерности. Безусловно, ни для кого не секрет, что переход в другую компанию сопряжен с ростом з/п. Но если это не выпячивается — то вызывает симпатию. И, честно скажу, бывали случаи, когда я давал сверх ожиданий, как дополнительный мотиватор. В тех случаях я понимал, что человек стоит больше, к тому же эта история с Даннингом-Крюгером: часть людей себя недооценивает. Им важно показать, что они классные специалисты, в том числе в финансовом эквиваленте. Поэтому если у меня есть возможность и есть бюджет, я захеджирую свои собственные риски: что через полгода-год, почувствовав уверенность в себе, специалист не пойдет смотреть рынок. Дам ему хорошие деньги — и он будет работать не один год.
Ресурсы для подготовки к собеседованию
У меня и моих бывших коллег есть несколько статей типа «как подготовиться к собеседованию на тестирование бэкенда» или «какие есть требования/ожидания от QA». Они актуальные, очень рекомендую.
Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.
Несмотря на то, что по многим позициям у нас кандидат диктует условия, так или иначе — компании выбирают сотрудников, и вовлечённость играет в этом роль. Поэтому помимо всех этих ссылок — рекомендую изучить, чем занимается компания, что за продукт и какая специфика.
Как собеседовать инженеров-программистов
Мы в компании Triplebyte проводим много собеседований. В реальности за последние два года я собеседовал более 900 инженеров. Насколько это эффективное использование моего времени — здесь можно спорить (иногда я просыпаюсь в холодном поту и сомневаюсь в этом). Но независимо от моих ощущений, главное, что мы стараемся улучшить процедуру собеседований. Для этого мы проводим собеседования без просмотра резюме (background-blind inrterview), определяем навыки программирования, а не оцениваем заслуги и рекомендации. После того, как инженеры прошли наше собеседование, они направляются для финального интервью напрямую в компании, с которыми мы работаем (включая Apple, Facebook, Dropbox и Stripe). Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.
В этой статье я собираюсь показать, что нам удалось понять к настоящему моменту. Технические собеседования во многом неправильно организованы. Это легко сказать, и во многих статьях об этом говорится. Сложнее исправить эти недостатки. Моя задача в этой статье — справиться с этой задачей и изложить конкретные советы для найма менеджеров и технических директоров. Собеседование — сложная вещь. Но я думаю, что многие проблемы можно решить, если тщательно продумать процесс. Здесь я пишу об оценке технических навыков. В будущих статьях мы поговорим о культурном соответствии, поведенческих интервью и оценке нетехнических качеств.
Статус-кво
Большинство собеседований включает в себя два основных этапа:
Многие финальные интервью расширяют стандартный формат и сильно отличаются друг от друга.
39% компаний, с которыми мы работаем, используют доску с маркером.
52% позволяют работать за собственным компьютером (оставшиеся 9% непоследовательны в выборе доски или компьютера).
55% позволяют интервьюеру самому выбрать вопрос (оставшиеся 45% используют стандартный банк вопросов).
40% хотят видеть академические знания по компьютерным наукам, чтобы сделать предложение кандидату.
15% компаний не хотят видеть академические знания по компьютерным наукам (и думают, что академические разговоры о компьютерных науках — признак того, что кандидат будет работать неэффективно).
80% позволяют использовать любой язык программирования на собеседовании (оставшиеся 20% требуют использовать конкретный язык).
5% подробно оценивают каждую мелочь в использовании языка программирования во время собеседования.
Ложноотрицательные и ложноположительные результаты
Так что не так с текущим положением вещей? По крайней мере, доля уволенных не кажется существенной. Чтобы понять проблему, нужно учесть, что собеседование считается неудачным по двум причинам. Или наймут плохого инженера, которого позже придётся уволить (ложноположительный результат). Или интервью дисквалифицирует кандидата, который мог бы хорошо выполнять работу (ложноотрицательный результат). Неудачный найм хорошо заметен и дорого обходится компании (зарплата, расходы на управление и мораль всей команды). Неудачный найм высасывает энергию из команды. А вот кандидаты, которые могли хорошо выполнять работу, но им не дали шанса, наоборот, остаются незаметными. Каждый случай всегда неоднозначный. Из-за такой асимметрии в спорных ситуациях компании сильно склоняются к отказу.
Этот эффект усугубляется из-за «шума» в процедуре собеседования. Оценить навыки программирования за один час исключительно сложно. Добавьте к этому принцип сопоставления с образцом и субъективные «инстинктивные» чувства, а также сложную смесь особенностей каждой компании, которые обсуждались выше — и вы получите сильно зашумлённый сигнал.
Чтобы удержать уровень ложноположительных срабатываний на низком уровне при столь зашумлённом сигнале, компаниям приходится ещё больше склоняться к отказу кандидатам. В результате они лишаются хороших инженеров, по-прежнему выше ценят заслуги, чем реальные навыки, и часто кажутся своенравными и вызывают разочарование у тех, кто участвует в собеседованиях. Если каждый в вашей компании должен будет пройти повторное собеседование на текущую должность, какой процент его пройдёт? Это пугающий вопрос. Ответом однозначно будет цифра гораздо меньше 100%. Кандидаты страдают от того, что их отвергают компании, где они могли бы отлично работать, а компании страдают от того, что не могут найти таланты.
Чтобы внести ясность, я не агитирую за то, чтобы снизить планку на собеседованиях. Отказ — это суть собеседования! Я даже не говорю, что компании зря боятся ложноположительных результатов намного сильнее, чем ложноотрицательных. Неудачный найм обходится дорого. Я только привожу доводы, что зашумлённый сигнал вкупе со страхом неудачных наймов приводят к действительно высокому уровню ложноотрицательных результатов, и это плохо для всех. Решение в том, чтобы улучшить качество сигнала.
Конкретные способы снижения шума при собеседовании
1. Определите, какие навыки вы ищете.
Нет единого набора навыков, которые определяют хорошего программиста. Наоборот, существует целый океан разнообразных наборов навыков. Никакой инженер не может быть силён сразу во всех областях. На самом деле, мы в Triplebyte часто видим отличных, успешных программистов с абсолютно несвязными наборами навыков. Таким образом, первый шаг к проведению хорошего интервью — определить, какой именно набор навыков подходит для данной должности. Рекомендую задать себе несколько вопросов (это вопросы, которые мы задаём, когда принимаем новую компанию на обслуживание в Triplebyte).
Вам нужны быстрые, итеративные программисты или внимательные и скрупулёзные?
Вам нужен тот, кто мотивирован к решению технических проблем или к созданию продукта?
Вам нужны навыки в конкретной технологии или умный программист, который обучится в ходе работы?
Являются ли важными академические знания компьютерных наук, математики, алгоритмов?
Является ли важным знание параллелизма, модели памяти C или HTTP?
На эти вопросы нет правильных ответов. Мы работаем с успешными компаниями, которые выбирают разные варианты в каждом случае. Но самое главное — сделать сознательный выбор на основании ваших потребностей. Нужно избегать случайного выбора вопросов на интервью (или позволяя самому кандидату выбирать). Когда такое происходит, культура программирования в компании может скатиться в направлении, где всё больше и больше разработчиков обладают определённым навыком или подходом к разработке, который не особенно важен для компании, а инженеры без этого навыка (но с другими важными навыками) отвергаются.
2. Задавайте вопросы, максимально приближённые к реальной работе
Профессиональных программистов нанимают для решения больших, разрастающихся проблем на протяжении недель и месяцев. Но у интервьюеров нет недель или месяцев для оценки кандидатов. У каждого из них есть обычно 1 час. А интервьюеры проверяют, насколько быстро кандидаты решают маленькие проблемы, находясь под принуждением. Это другой навык. Да, он имеет отношение к делу (интервью всё-таки не полностью рандомные). Но он не идеально коррелирует с тем, что нужно. Минимизация этой разницы — вот цель разработки вопросов для собеседования.
Этого можно достичь, если вопросы на собеседовании будут максимально приближены к той работе, выполнения которой вы ожидаете от кандидата (или к навыку, который вы пытаетесь оценить). Например, если вы ищете программиста для бэкенда, попросите кандидата разработать конечную точку API и добавить функциональность к ней — это почти наверняка будет лучше, чем решение проблемы обхода графа путём поиска в ширину. Если вас волнует знание алгоритмов, то попросите применить алгоритм к решению конкретной проблемы (например, построить простой поисковый индекс, возможно, с поддержкой BST и HashMap для лучшей производительности при удалении) — это почти наверняка лучше, чем задача на определение, принадлежит ли данная точка вогнутому полигону. А в задачах на отладку почти всегда лучше дать кандидату поработать с реальной кодовой базой, чем просить его решить маленькую проблему на доске.
При этом есть довод и в пользу использования доски с маркером. Как интервьюеру мне не важно, что кандидат помнит наизусть все итераторы из набора itertools в Python. Мне важно, способен ли он найти способ применить эти итераторы для решения проблемы. Когда кандидат чертит на доске, он свободен от ограничений точного синтаксиса и может сконцентрироваться на логике. Но в конечном итоге я думаю, что это неудачный довод, просто потому что не хватает обоснований для использования другого формата. На самом деле вы можете получить все те же преимущества, разрешив кандидату работать на собственном компьютере, но сняв условие на обязательный запуск этого кода (или ещё лучше, проведя собеседование open book, то есть с возможностью искать справочную информацию в Google).
Есть важное предостережение при разработке вопросов, которые отражают реальную работу. Важно, чтобы вопрос был свободен от внешних зависимостей. Например, просьба написать простой веб-скрапер на Ruby кажется хорошей проблемой из реального мира. Однако если кандидату требуется установить Nokogiri (библиотека парсинга на Ruby, которую может быть непросто установить) и ему придётся 30 минут потратить на борьбу с нативными расширениями, то это ужасное собеседование. Не только теряется время, но и уровень стресса у кандидата зашкаливает выше крыши.
3. Задавайте составные вопросы, на которые нельзя быстро ответить
Ещё одно хорошее правило для вопросов на собеседовании — избегать вопросов, на которые существует краткий и полный ответ, то есть существует некий магический фрагмент информации, который кандидат мог заранее прочитать на Glassdoor — и это позволит ему легко ответить на вопрос. Очевидно, это сразу же исключает из числа вопросов головоломки или любые вопросы, требующие озарения. Более того, вопросы должны состоять из нескольких шагов, где каждый последующий шаг основан на предыдущем, а не однократными вопросами о центральной проблеме. Почему ещё это полезно — спросите себя, как вы можете помочь кандидату, который производит общее хорошее впечатление, но застрял на каком-то вопросе. В случае с однократными вопросами, если вы оказываете значительную помощь кандидату, то собеседование провалено. В составной задаче из нескольких частей вы можете помочь на одном этапе, а кандидат успешно пройдёт остальные шаги самостоятельно.
Это важно не только потому что ваши вопросы могут попасть на Glassdoor. Более важно, что составные вопросы снижают уровень шума. Хорошие кандидаты могут из-за стресса застрять на каком-то этапе. Возможность помочь им и наблюдать процесс восстановления — очень существенна. Присутствует значительный шум в том, насколько хорошо кандидат справляется с конкретным кусочком программистской логики, в зависимости от того, сталкивался ли он в последнее время с похожей проблемой, это просто случайная вероятность. Составные задачи из нескольких частей устраняют часть этого шума. Они также дают возможность кандидатам наблюдать, как нарастает эффект. Усилия на одном этапе часто помогают решить задачу на следующем этапе. Это важная динамика реальных процессов разработки, а её изучение во время собеседования уменьшает уровень шума.
Если нужны примеры, то просьба к кандидату реализовать игру «Четыре в ряд» в терминале (серия из многократных шагов), вероятно, будет лучшим заданием, чем просьба повернуть матрицу (единственный шаг, с некоторыми приёмами, которые предельно упрощают задачу). А кластеризация методом k-средних (несколько операций, основанных друг на друге), вероятно, будет лучшим заданием, чем определение крупнейшего прямоугольника, который помещается под гистограммой.
4. Избегайте сложных вопросов
Если кандидат действительно хорошо решил сложную проблему, это много говорит о его способностях. Но поскольку вопрос сложный, большинство кандидатов не смогут хорошо на него ответить. В этом случае ожидаемое количество информации, полученное от вопроса, напрямую зависит от его сложности. Мы пришли к выводу, что оптимальный уровень сложности значительно ниже, чем полагает большинство интервьеров.
Эффект усиливается за счёт того факта, что при собеседовании кандидата есть два источника информации: 1) даёт ли он «правильный» ответ на вопрос и 2) процесс размышления, то есть насколько легко он додумался до этого ответа. Мы в Triplebyte собираем эти показатели (оценка за правильность ответа и оценка за количество усилий, которые ему понадобились для этого, а затем делаем прогноз, какие оценки коррелируют с успехом сотрудника в разных компаниях). То, что мы нашли, — это своеобразный компромисс. Если кандидат отвечает на более сложные вопросы, то мы получаем более сильный сигнал непосредственно от ответа. Для более простых вопросов, наоборот, важнее процесс и то, как сильно мучился кандидат. С учётом обоих источников сигнала оптимум находится ближе к простым вопросам.
На практике выработалось такое правило: сам интервьюер должен решить задачу за 25% того времени, которое он ожидает от кандидата для решения этой задачи. Так что если я разрабатываю новое задание для часового интервью, то мои коллеги (без предупреждения) должны дать правильный ответ за 15 минут. Учитывая факт, что мы предлагаем решать многоступенчатые проблемы из реального мира, оптимальная задача на интервью действительно должна быть довольно понятной и простой.
Чтобы внести ясность, я не агитирую за снижение планки в смысле понижения проходного балла. Я только привожу доводы в пользу простых вопросов и дальнейшей оценки, как кандидаты на них отвечают. Я выступаю за простые вопросы и очень строгую оценку ответов. Вот что лучше всего оптимизирует сигнал, по нашему опыту. Здесь есть и дополнительная польза в снижении уровня стресса для большинства кандидатов.
Приведу примеры. Попросить кандидата создать простой интерфейс командной строки с командами для помещения в хранилище и извлечения оттуда пар ключ-значение (и добавления дополнительной функциональности, если кандидат хорошо справляется), вероятно, будет лучше, чем попросить сделать парсер для арифметических выражений. А вопрос о самых обычных структурах данных (списки, хэши, может быть, деревья), вероятно, лучше, чем вопрос о списках с пропусками, дучах (дерево+куча) или других малоизвестных структурах.
5. Задавайте одинаковые вопросы каждому кандидату
Суть интервью в сравнении кандидатов. Цель — отсортировать кандидатов на тех, кто способен помочь компании и на тех, кто не способен (а в случае заполнения единственной вакансии — выбрать самого лучшего). Учитывая это, совершенно нелогично задавать разные вопросы разным кандидатам. Если вы оцениваете разными способами кандидатов на одну и ту же работу, вы добавляете лишний шум.
Думаю, причина того, что интервьюеры часто выбирают разные вопросы для разных кандидатов — в личных предпочтениях интервьюера. Инженеры в IT-комипаниях обычно не любят проводить собеседования. Это нечто такое, что они делают лишь эпизодически, и это отвлекает от основной работы. Чтобы стандартизировать вопросы для каждого кандидата, интервьюерам придётся потратить больше времени на изучение этих вопросов, усвоить систему оценок и отчётности. И им придётся заново проходить эту процедуру при каждой смене вопроса. И ещё задавать всегда один и тот же вопрос немного более скучно.
К сожалению, единственным выходом для интервьюеров здесь будет приложить больше усилий. Единообразие — ключевой элемент проведения хороших собеседований, а это означает задавать каждому кандидату один и тот же вопрос и стандартизировать отчёты. Здесь просто нет другого варианта.
6. Рассмотрите возможность нескольких путей
Хотя это противоречит предыдущему пункту, но рассмотрите возможность нескольких совершенно разных версий собеседования. С самого начала при разработке интервью подумайте, какие навыки кандидата имеют значение. Но некоторые из ответов могут противоречить друг другу! Например, вполне нормальная ситуация, если компании нужны хорошо разбирающиеся в математике инженеры, но при этом нужны ещё и очень продуктивные/итеративные инженеры (может быть, даже на одну и ту же должность). Для таких случаев рассмотрите несколько путей проведения интервью. Здесь ключевым фактором является то, что масштаб задачи должен позволить полностью стандартизировать каждый из путей. Вот что мы делаем в Triplebyte. Мы пришли к выводу, что можно просто спросить кандидата, какой вариант интервью он предпочитает.
7. Не позволяйте резюме кандидата влиять на вас
Резюме не совсем бессмысленно. Выпускники Массачусетского технологического института и Стэнфорда или с опытом работы в Google и Apple действительно лучше, как группа, чем остальные. Проблема в том, что абсолютное большинство инженеров (включая меня) не принадлежат к этой группе. Так что если компания слишком сильно полагается на эти сигналы, то большинство квалифицированных кандидатов пройдут мимо неё. Учитывать резюме в какой-то степени на этапе предварительной степени может иметь какой-то смысл. Мы в Triplebyte такого не делаем (все наши оценки в «слепых тестах» делаются совершенно без учёта опыта и заслуг человека). Но дать какой-то вес резюме на этапе предварительного отбора имеет смысл.
Но учитывать резюме на этапе собеседования уже совершенно не имеет смысла. А у нас есть данные, что так оно происходит на самом деле. При одинаковых оценках в наших «слепых тестах» кандидаты с дипломом топового университета успешно проходят собеседования в компаниях на 30% чаще, чем кандидаты без брендового названия в резюме. Если интервьюеры знают, что у кандидата есть диплом Массачусетского технологического института, они более склонны закрывать глаза на недочёты во время собеседования.
Это шум, и его следует избегать. Самый простой способ — просто удалить названия университетов и компаний из резюме перед тем, как давать их интервьюерам. Некоторые кандидаты могут упомянуть вуз или компанию во время разговора, но мы всегда проводим интервью, не учитывая эту информацию, и кандидаты очень редко обращают внимание на эти факты в процессе технических тестов.
8. Не издевайтесь над кандидатами
Один из самых мерзких способов провала на собеседовании — когда оно заканчивается издевательским способом. Интервьюеры уже не только оценивают способности кандидата, они также превращаются в участников группы или команды, которая принимает нового члена в свою группу. В этом втором качестве они проводят нечто вроде обряда посвящения. Да, интервью само по себе вызывает стресс, но все мы прошли через этот стресс, так что и кандидатам придётся пройти через него. Ситуация усугубляется, когда кандидат никак не справляется с заданием. В качестве интервьюера вы можете испытать сильное разочарование, наблюдая, как кандидат бьётся головой о стену, решая задачу, где ответ настолько очевиден! Вы можете вспылить и сорваться. Конечно, это только увеличивает стресс для кандидата — и ему становится ещё труднее решить задачу.
Таких ситуаций лучше не допускать ни в коем случае. Решением будет обсудить проблему и обучить интервьюеров, как её преодолеть. Здесь мы используем одну хитрость: когда кандидат вообще не справляется, нужно переключиться из режима оценки, где цель — оценить человека, в режим обучения, где цель — заставить кандидата понять ответ на вопрос. Ментальное переключение из одного режима в другой очень сильно помогает. Когда вы находитесь в режиме обучения, то нет причин скрывать информацию или проявлять какие-то другие эмоции кроме дружелюбия.
9. Принимайте решения на основе максимального навыка, а не среднего или минимального
До сих пор я говорил только об отдельных вопросах, а не о решении на финальном интервью. Здесь мой совет — принимать решение на основании максимального навыка, который продемонстрировал кандидат (среди всех навыков, которые для вас важны), а не на среднем уровне или минимальном.
Вероятно, вы уже поступаете таким образом, умышленно или нет! Окончательное решение принимается на общем собрании всех, кто проводил собеседования, и предложение кандидату делают, если хотя бы один интервьюер настоятельно рекомендует это сделать, а остальные не сильно возражают. Чтобы впечатлился один интервьюер, кандидату достаточно блеснуть на одной секции интервью. Судя по нашим данным, максимальный навык — это атрибут, который сильно коррелирует с тем, чтобы хорошо проявить себя хотя бы на одной секции интервью в компании. Однако, чтобы получить предложение о работе, кандидату также нужно не настроить против себя никого из остальных интервьюеров. Категоричные возражения от них могут появиться, если кандидат выглядел реально глупо при ответе на вопрос.
Здесь мы имеем дело просто с большим уровнем шума. Существует так много областей деятельности высококвалифицированного инженера, что почти ни один человек не способен достичь совершенства во всех областях сразу. Это значит, что если вы зададите правильный (или неправильный) вопрос, то любой инженер может выглядеть глупо. После этого кандидаты получают предложения в том случае, если хотя бы одно собеседование затронуло зону прочных знаний (максимальный навык) и ни одно не затронуло области значительной слабости. Проблема в том, что это увеличивает уровень шума. Один и тот же инженер, проваливший одно интервью, потому что выглядел глупо после вопроса о сетевых технологиях, блестяще проходит остальные интервью, где эта тема не затрагивалась.
По-моему, лучше всего компаниям сконцентрироваться на максимальном навыке и не так сопротивляться найму сотрудников, которые плохо проявили себя в отдельных секциях собеседования. То есть искать сильные аргументы в пользу кандидата и не беспокоиться так сильно о технических областях, где он слаб. Здесь я не хочу быть однозначно категоричным. Конечно, есть технические обалсти, которые просто очень важны для компании. И ваше решение, что все сотрудники должны иметь определённый уровень знаний в этих областях, вполне имеет смысл. Но концентрация именно на максимальных навыках кандидата реально уменьшает шум на собеседовании.
Зачем вообще проводить собеседования?
Последний вопрос, который я хотел бы задать — зачем вообще проводить собеседования? Уверен, что многие читатели уже скрипели зубами, приговаривая: «Какой смысл так подробно обсуждать неэффективную систему? Просто используйте домашние задания! Или просто берите людей на испытательный срок!» В конце концов, некоторые очень успешные компании действительно применяют испытательный срок (где кандидат работает с командой в течение недели) или полностью заменяют личные собеседования домашними заданиями. Испытательный срок во многом имеет смысл. Провести неделю бок о бок с новым сотрудником (или смотреть, как команда с ним выполняет важный проект) почти всегда даёт лучшую оценку навыков кандидата, чем наблюдение в течение всего лишь одного часа, как он решает задачи. Однако есть две проблемы, которые не дают испытательному сроку заменить стандартные собеседования:
Обсуждения опыта работы над прошлыми проектами тоже часто рассматривают как замену техническим собеседованиям. Логика такая: чтобы убедиться, что кандидат успешно выполнит работу в будущем, просто посмотрим, что он делал в прошлом. Мы в Triplebyte пробовали такую методику. К сожалению, она не показала хороших результатов. Выяснилось, что коммуникативная способность (способность продавать себя) оказалась более сильным сигналом, чем технические способности кандидата. Просто слишком часто возникает ситуация, когда умеющий красиво говорить кандидат преувеличивает свою роль (присваивает результат всей команды) или когда скромный человек преуменьшает свои заслуги. При наличии достаточного времени и достаточном количестве вопросов можно докопаться до сути. Однако мы выяснили, что при стандартном ограничении по времени обсуждение прошлого опыта не является универсальной заменой собеседованию. Это хороший способ растопить лёд в начале разговора, понять смысл интересов человека (также оценить коммуникационные способности и культурное соответствие). Но обсуждение прошлого опыта не подходит в качестве полной замены собеседованию.
Кое-что хорошее о программистских собеседованиях!
Хочу закончить эту статью на более приятной ноте. Наряду со всеми недостатками собеседований, они всё-таки приносят большую пользу.
Собеседования — это прямая оценка способностей. У меня есть друзья, которые работают учителями. Они говорят, что интервью учителей — это, в основном, оценка коммуникативной способности (умения продавать себя) и резюме/рекомендации. Судя по всему, такая ситуация во многих, многих профессиях. Кремниевая долина — не идеальная меритократия. Но мы по крайней мере пытаемся напрямую измерить навыки, которые имеют значение, и придерживаемся идеи, что любой человек с такими навыками может стать хорошим профессионалом, независимо от его образования и опыта работы. Оценка резюме часто этому мешает. Но мы в Triplebyte сумели во многом преодолеть эту проблему и помогаем большому количеству людей с нестандартными резюме получить отличную работу в IT. Сомневаюсь, что компания вроде Triplebyte смогла бы работать, например, в юридической сфере. Там слишком сильно полагаются на резюме и рекомендации.
Программисты тоже предпочитают собеседования. Хотя это очень спорная тема (наверняка найдутся программисты с иной точкой зрения), но когда мы проводили эксперименты с альтернативными методами оценки кандидатов, большинство программистов по-прежнему выбирали стандартные собеседования. И мы обнаружили, что только небольшую часть программистов интересуют компании, которые предлагают испытательный срок или домашнее задание. Хорошо это или плохо, но судя по всему, собеседования для программистов никуда не денутся. Другие способы — это хорошее дополнение, но вряд ли они заменят интервью как основной способ оценки программистов. Если неправильно процитировать Черчилля: «Собеседование — самый худший способ оценить инженера, если не считать остальных способов, которые мы иногда пробуем».
Заключение
Собеседование — непростая штука. Человеческие существа безнадёжно сложны. В каком-то смысле попытка оценить возможности человека за 4 часа собеседований кажется дурацкой. Думаю, здесь важно сохранять скромность. Любой процесс собеседования обречён на частые неудачи. Люди просто слишком сложные.
[1] Конечно, здесь есть разные варианты. На противоположных конца спектра находятся компании, которые требуют единогласного положительного решения от каждого интервьюера, и компании, где HR-менеджер единолично принимает решение. ↑
[2] Это цифры из внутренней статистики самих компаний об их собственных кандидатах. И они сильно отличаются в разных компаниях (например, доля уволенных, варьируется от 1% до 30%). У кандидатов Triplebyte цифры значительно лучше. К настоящему моменту наши кандидаты получают предложения о работе после 53% собеседований, а уровень уволенных составляет 2%. ↑