Я понимаю, что было много дискуссий об этом типе вещей, и они часто превращаются в догму вокруг того, задаете ли вы вопросы типа «100 логических пиратов», или вы заставляете их писать «шипение».
Мне интересно, какие методы и вопросы были эффективны для вас при опросе потенциальных разработчиков для работы.
Одна техника на ответ, чтобы мы могли проголосовать за них, пожалуйста.
Ответы:
Помимо реальных технических вопросов, и обычно в конце интервью я пытаюсь понять их уровень интереса к отрасли и его культуре с помощью таких вопросов, как:
Вы видели что-нибудь недавно связанное с программированием, что вам показалось интересным и которое вы бы хотели порекомендовать другим программистам? Новый язык, инструмент, платформа, техника, сайт?
Можете ли вы назвать кого-либо из известных в нашей отрасли людей, чья работа вам нравится или вдохновляет и почему? (разработчик, основатель сайта, автор, докладчик и т. д.)
Что вы читаете сейчас или какую последнюю книгу о программном обеспечении вы читали?
Какие сайты, посвященные программированию, вы часто посещаете?
Хотя неспособность ответить на эти вопросы вообще (к сожалению, это случается очень часто) не означает, что я не найму, они многое говорят о том, как человек подходит к профессии разработчика программного обеспечения.
Заставьте их написать код, настоящий код.
Интервьюер может позволить вам выбрать язык программирования, который вам наиболее удобен, будь то C ++, Java, C # или любой другой, и попросить вас решить простую задачу, например, выполнить некоторую работу со строкой или двусвязным списком или любым другим. Если у вас есть проблемы с использованием вашего лучшего языка для решения простой проблемы, тогда есть проблема. Пожалуйста, смотрите сообщение в блоге Стива Йегге и, в частности, раздел «Умственная подготовка».
Попросите нескольких человек из вашей команды взять у них интервью. Поделитесь своими мыслями после, не говорите между ними, прежде чем брать у них интервью. Разговор между ними повлияет на ваше мнение, и у вас не будет независимых собраний.
Для технических людей, которые берут у них интервью, заставляют их писать код. Для не технических, не пытайтесь спрашивать вещи, с которыми у вас нет опыта. Удостоверьтесь, что у вас есть хотя бы несколько технических людей, которые берут интервью.
Интервью не должны проводиться только менеджерами, это должно быть чрезвычайно важно для каждого работника, с которым они будут работать в будущем.
Мне нравится, когда собеседник объясняет свои предыдущие проекты и что они сделали. Из этого ответа у меня могут возникнуть дополнительные вопросы: почему они поступили определенным образом, как они решили конкретную проблему, если упомянули одну, но самое главное, какова была цель проекта и какую бизнес-проблему это решило.
Я делаю это, чтобы увидеть, могут ли они сформулировать так, чтобы я понял, что они делают, и посмотреть, поняли ли они, что они делают.
Удивительно, что последний вопрос о цели проекта и о решенной бизнес-задаче сбивает с толку многих людей. Они понятия не имеют, ПОЧЕМУ проект, над которым они работали, вообще выполнялся. Если вы не знаете, почему ваш проект существует в первую очередь, это заставляет меня задуматься, вносите ли вы решения или просто делаете то, что вам говорят.
(Думаю, я добавлю этот вопрос, поскольку все остальные ответы, как правило, носят технический характер. Я хочу, чтобы люди, которые знают, почему они решают проблемы, которые они тоже решают, в противном случае они склонны решать неправильные проблемы, которые не делает конечный пользователь ». не волнует :)
Попросите их принять важное архитектурное решение
Например. Вот программа x, которая одновременно выполняет y подзадач. Что бы вы выбрали, многопроцессную или многопоточную структуру.
Каковы преимущества / недостатки обоих. Насколько хорошо они будут работать и как их можно использовать для использования многоядерной, многопроцессорной платформы, каковы ваши личные предпочтения? Личные предубеждения могут помочь определить, действительно ли им когда-либо приходилось применять знания, и дать им точку отсчета, чтобы поделиться своим опытом?
Есть множество вопросов, которые интервьюер может сформулировать так:
Большинство из этих тем относятся к тем типам, которые предполагают глубокое знание того, как / почему компьютерная система работает так, как она работает. Все они являются проблемами / решениями проблем, на которые нет однозначного ответа, поэтому они дают представление о том, насколько хорошо этот человек способен адаптироваться или преодолевать возникающие проблемы. Не тот тип понятий, который может быть легко подобран без каких-либо реальных практических навыков.
Примечание. Заявитель должен написать какой-нибудь псевдо-код, но этот ответ уже принят.
Просто дайте им некоторый базовый код для работы на доске - например, реализацию связанного списка, сортировку или что-то подобное.
Вы можете судить, насколько они удобны с их языком, без помощи компилятора, и вы можете судить об их мыслительном процессе (особенно если они никогда не реализовывали такую вещь - большинство «новых» программистов никогда не делали).
Поговорите, пусть он плывет и блуждает по техническому и профессиональному маршруту и по пути ищите проницательные или глупые комментарии. Это дает вам 3/4 того, что вам нужно от интервью, оценки: человеческих навыков и личности, общего интеллекта и грубой оценки технических навыков.
Используйте «вопросы» вашего интервью в качестве начала темы и для того, чтобы беседа соответствовала техническим темам - вам может понадобиться время от времени переустанавливать беседу (например, выполнять упражнение по кодированию), чтобы адекватно исследовать области, вызывающие озабоченность / интерес.
Настоящий трюк с этой техникой состоит в том, чтобы убедиться, что они все говорят, в противном случае вы рискуете получить положительную оценку, потому что они заставили вас чувствовать себя умно, слушая / соглашаясь со всем, что вы сказали.