Безусловно, есть масса методик по проведению собеседований. И любой наёмный работник со стажем наверняка испытал на "своей шкуре" много того, о чём я даже не читал. Тут я не буду углубляться в теорию вопроса, а просто опишу тот метод, что выработал для себя сам.
О чём не стоит спрашивать
Не стоит задавать "олимпиадных" задач. Реальные проекты очень редко требуют от программиста знания пяти способов сортировки массивов и трёх способов обхода бинарного дерева. Все давно есть в библиотеках, а "велосипеды" часто оказываются бомбами замедленного действия в вашем проекте. Также не стоит обращать внимания на титулы и громкие "ранее занимаемые" должности. Крутые сертификаты означают, по моему, только то, что кандидат давно думает о смене места работы и умеет готовиться к экзаменам.
Что стоит узнать о кандидате за час до собеседования
E-mail и краткое резюме. Остальное расскажет Google. Работа программиста такова, что он поневоле "засвечивается" в самых разных местах. По его e-mail можно найти все его актуальные резюме на сайтах, большую часть его аккаунтов в социальных сетях, его блог, его посты на форумах, в конце концов, его проекты. Они могут рассказать о человеке больше чем он сам.
Что спрашивать
Первый вопрос: "Расскажите о своём последнем проекте. Или о другом проекте, которым вы гордитесь". Тут главное заставить человека разговориться. Во-первых, так мы проверяем правда ли написана в его резюме. Можно перечислить в резюме пару десятков популярных сайтов, но ведь прийдётся рассказывать, как именно они написаны... Во-вторых появляется представление о том, что умеет кандидат. Иногда люди ищут совсем не ту вакансию, которая им подходит по квалификации. Я однажды собеседовал специалиста по юзабилити который был очень слаб в этой сфере, но отлично умел верстать и писать javascript. И в качестве верстальщика и javascript-программиста он с успехом проработал полтора года. Но самое главное в ответе на этот вопрос не в том, что говорит кандидат. Главное - КАК он это говорит. Он должен увлекаться. Он должен гордиться своим кодом, своими реализациями, своими, пусть даже "непромышленными" решениями. Я, возможно, неправ, но мне категорически не нравятся девелоперы с десятилетним стажем, которым "всё равно что писать"... Такие люди похожи на станки. Они включаются в 9.00 и выключаются в 17.30. С одной стороны в них нужно вставлять идеально оформленное ТЗ, а с другой у них выходит идеально документированный и покрытый тестами код. Выходит, конечно, медленно... И часто, когда выходит, то уже никому не нужен. И в первую очередь самим программистам. Им не станет стыдно, если у них найдут баг. Они не останутся на ночь, чтобы его исправить. Просто аргументируют перенос сроков. Когда-нибудь, наверное, IT станет такой же медленной и консервативной отраслью как, к примеру металлургия, и такие "станки" будут лучшим выбором. Но, надеюсь, это будет ещё не скоро.
Второй вопрос: "Что лучше, XXXX или YYYY"? Варианты могут быть любыми: jQuery или Prototype, MsSQL или Sybase, Windows или Linux в конце концов. Поспорьте с ним. Во-первых кандидат должен иметь своё мнение. Пусть даже неправильное на ваш взгляд. И он должен уметь его аргументировать. И не бояться сделать это. И не быть в то же время совсем уж фанатичным. Хороший холивар - неплохой тест на интеллект и способность к общению.
Задача этого этапа собеседования выяснить что может делать кандидат и КАК он это будет делать. А третий вопрос следует задать себе. "Приятно ли мне будет с ним работать"? Я не считаю, что замкнутость, дефекты речи или физическое уродство должны быть решающими факторами при принятии решения. Но свои 20% баллов третий вопрос должен положить на весы. Вам работать с этим человеком. Вам его прикрывать от порой "слишком энергичного" начальства, вам доверять ему свою репутацию, свой код, свой проект. Если вам не захочется делать это - это плохо отразится на работе. Лучше исключить такие проблемы в самом начале.
Это не всё
Есть ещё пару десятков вопросов, которые стоит задать. Если в ответах почувствуете неуверенность, стоит дать предельно простую задачу, из тех, что можно "запрограммировать" на словах. Можно долго "пытать" кандидата на тему уровней изоляции транзакций, если для вашего проекта это так важно. Но всё это менее важно чем три главных вопроса.
