В ближайшие несколько дней меня попросили присутствовать на доске для собеседований в качестве технического специалиста, чтобы попытаться понять, подходят ли кандидаты технически для нашей должности. Единственная проблема в том, что вопросы для собеседования заданы (их нельзя изменить или дополнить), и ни один из вопросов не является техническим.
Мне кажется неправильным давать техническое заключение о ком-то, кому я не смог задать технический вопрос. Кто бы ни делал это интервью, параметры будут одинаковыми. Из-за этого я бы предпочел не уходить в отставку, поскольку следующему человеку все равно придется делать то же самое, что и мне.
Поскольку я впервые на доске для собеседований, мне было интересно, есть ли что-нибудь еще, на что я могу посмотреть, чтобы попробовать, и понять, компетентны ли они?
Этот процесс собеседования немного отличается от того, что большинство людей считают нормальным, поэтому я немного объясню этот процесс.
В ходе этого процесса кандидаты уже прошли несколько тестов и собеседований с другими людьми. Все их учетные данные (например, школьное образование) были подтверждены до этого момента. Это означает, что у них есть необходимый опыт и образование, чтобы получить работу. Мы должны провести собеседование с заданными вопросами и следовать оценочной рубрике для каждого кандидата, чтобы определить, попадут ли они в пул, из которого можно будет нанять позже. Поскольку этот процесс очень строгий, никакие вопросы не могут быть изменены. Большая часть вопросов вращается вокруг объяснения нам, как вы решаете проблему или как вы взаимодействуете с клиентами.
Какой идиотский процесс собеседования! Предполагая, что в заданном списке нет вопросов даже отдаленно технического характера, тогда вам придется бороться.
Вы сможете комментировать все, что говорит кандидат, либо в ответ на один из заданных вопросов, либо добровольно, я полагаю, но это просто удача, скажут ли они что-нибудь полезное.
Если вы сможете объяснить это другим членам комиссии по собеседованиям, и они с пониманием отнесутся к вашему мнению, то они, возможно, помогут направить кандидата в сторону предоставления технических ответов — например, если в списке есть вопросы, задающие вопросы. кандидат приводит примеры того, что он сделал: «Опишите случай, когда вы преодолели особенно сложную проблему на работе» или что-то в этом роде, тогда вы можете заставить того, кто представляет доску, сказать что-то вроде
Это Провисший Руфус, наш технический эксперт.
а затем попросите вас задать вопросы, на которые могут быть технические ответы - это должно привести к тому, что кандидат ожидает дать технический ответ.
Мне кажется неправильным давать техническое заключение о ком-то, кому я не смог задать технический вопрос.
Это неправильно. И это не кажется очень умным.
Поскольку я впервые на доске для собеседований, мне было интересно, есть ли что-нибудь еще, на что я могу посмотреть, чтобы попробовать, и понять, компетентны ли они?
Вы можете основывать свое мнение только на том, что видите, слышите и читаете.
Если вы можете составить свое мнение только на основе того, что вы услышали в ответ на заранее определенный набор вопросов, вы могли бы судить о них по технической тщательности их ответов, техническому жаргону, который они используют (используют ли они его в правильный контекст с правильными значениями) и т. д.
Если в конце интервью вы не получили достаточно информации, то, надеюсь, рубрика позволит вам ответить «Неприменимо» столько, сколько необходимо.
С другой стороны, если вы можете прочитать, что этот кандидат написал вне процесса собеседования (блог, технические документы, форумы вопросов и ответов и т. д.), вы сможете дать гораздо лучшую оценку.
Это очень зависит от типа сообщения и его требований, но если вы ищете разработчика среднего уровня или выше, я бы сказал, что вы можете избежать грубого технического теста. Это моя точка зрения как человека, который прошел через них, и я действительно думаю, что самой важной части моих интервью там не было.
Допустим, одним из ваших главных требований является то, что они освоят фреймворк X. ИМХО, лучший способ протестировать их — это задать им задачу и попросить их ответить, как бы они структурировали свой код, используя фреймворк.
Другой способ, немного более общий, — спросить их, как бы они справились с конкретной проблемой (например, проблемой проектирования базы данных), но остаться расплывчатым в требованиях. Что я ожидаю от кого-то с достаточным опытом:
Это то, что я делаю, когда описываю недостаточно конкретную проблему.
В основном они показывают, что:
Конечно, этот способ требует, чтобы ваши вопросы были адаптированы таким образом, чтобы можно было дать несколько хороших ответов в зависимости от проблемы.
Наконец, я действительно не нашел технических тестов, но некоторые базовые проверки, например, могут ли они понять рекурсию, структуры данных, сложность, межпроцессное взаимодействие, всегда стоят.
Скорее всего, это вопрос типа «Опишите мне случай, когда вы столкнулись с проблемами в проекте и как вы их решили?» Для меня это был бы хороший вопрос, чтобы оценить их технические возможности. Интервьюируемый, вероятно, подробно расскажет о проекте, а затем, возможно, опишет его технический аспект, с которым у него возникла проблема, и объяснит, как он ее решил.
Но, по сути, невозможно оценить чьи-то технические навыки, не спросив их или не заставив их показать вам.
Дэвид К.
Бернхард Баркер
ПровисаниеRufus
Блрфл
Вальфрат