Вне зависимости от роли и квалификации, на собеседовании я задаю кандидатам вопросы по трем группам.
1. Владение средой, о компетенции в которой заявляет специалист
2. Аналитическое мышление и опыт программирования
3. Адекватность и лояльность

Палю тему.

Разговор длится обычно не более 15-30 минут.

Владение матчастью

Есть наблюдение, что каждый действительно опытный специалист увлекается основами, базисом и азбукой в той среде (ЯП, фреймворку, библиотекам, IDE, технологиями), в которой он действительно разбирается.

Не уверен точно в причинах, но сотни раз обращал внимание на следующее. Многочисленные коллеги, с которыми мне пришлось так или иначе контактировать на протяжении собственной карьеры, личным примером это наблюдение подтверждают. Каждый опытный разработчик каким-то мистическим образом идеально помнит:
— типы данных, от точного количества в актуальной версии языка до приведения типов и все основные действия с ними (от конкатенации до маршализации);
— сможет на пальцах объяснить, как работают регулярки;
— что именно серьезного изменилось при последнем глобальном обновлении среды (например, PHP4-PHP5 для PHP-разработчиков);
— операторы языка и их применение, от циклов и условных ветвлений до тернарных операторов и S-конструкций;
— основные архитектурные решения;
— другие пункты из первой главы учебника по ЯП.

Выборочно задаю 3-5 элементарнейших вопросов — сразу выясняется уровень владения. Если опыт кандидата ограничен выполнением нескольких учебных заданий — он как правило «плавает», и не может соориентироваться в основах.
Удивительно, но еще ни разу никто не попытался обмануть, попросту зазубрив статьи вроде php.su/learnphp. Это было бы просто.

Если от кандидата ожидаются архитектурные решения, он, естественно, должен быть с ними знаком. Понимание терминов вроде «бизнес-логика» или «события» не может ограничиваться одним-двумя предложениями. У опытного кандидата, даже если он еще студент, но потратил достаточно внимания и личного времени на работу с учебными задачами, всегда есть личные впечатления, которыми он не прочь поделиться и обсуждать их. Честное слово.

Есть важный и опасный момент, который я несколько раз наблюдал у своих коллег-руководителей, которым приходится участвовать в HR. Часто собеседуемые выражают мнения, не совпадающие с мненим интервьюирующего. Итог зависит исключительно от культуры последнего.
Например, лично я понимаю и ценю свежий привнесенный опыт, полярные точки зрения, диалектику и даже соревновательность. Возможны очень хорошие результаты, именно благодаря «разности потенциалов» между коллегами. Если они принципиально адекватны, конечно.

Но многие коллеги не думают об этом, а ревнительно реагируют, когда услышанное входит в противоречие с их убеждениями.
ИМХО, называть что-то «правильным» или «не правильным» — не самый эффективный подход. Есть применимость решения, которое имеет полное право варьировать обстоятельства в зависимости от специфики конкретной задачи.
Но, если мы говорим о методиках, которые являются академическими, и по природе своей вариантов не предусматривают — конечно будут сомнения в компетенции кандидата, если он даже википедию не читал по основам тех сфер, специалистом в которых себя называет.

Если позиция не стажерская, поинтересуюсь о знакомстве с технологиями тестирования и отладки, попрошу рассказать примеры из личного опыта.

Анализ

Есть два типа разработчиков. Те, кто ищут все решения в гугле, не включая мозг. И те, кто тоже использует гугль в качестве основного рабочего инструмента, но делают это с включенным /dev/brain, и оттого последний систематично прокачивается. Как мышцы у спортсмена — у успешных программистов аналитическая зона мозга хорошо разработана.
Несложно понять, сможет ли очередной кандидат помочь в проектировании и разработке решений, или будет пассажиром висеть на плечах продвинутых коллег, или хуже того, пассивно «быдлокодить».

Для этого достаточно предложить с помощью бумаги и авторучки решить 2-3 задачи. Я никогда не даю сложных задач. Простые и элементарные, но допускающие возможность подумать и продемонстрировать опыт и умение прорабатывать решения.

Пример 1. Как в повер поинте — надпись вылетает из-за левого верхнего угла экрана, и останавливается в центре.
Решение: Сначала определиться, откуда и куда двигать, потом — как двигать. Определить размеры надписи и экрана, найти их центры (для того, чтобы не выглядело криво, необходимо учитывать смещение локальных систем координат надписи и экрана — перемещаться должен именно центр надписи, и именно от угла экрана до его центра). Да, двигать конечно в цикле, но количество шагов будет точно определено — в общем случае скорее будет задана продолжительность анимации. Ключевой константой выступит FPS, и ее конечно можно определить заранее, например 25 кадров в секунду. С полученными данными легко высчитывается и размер шага по горизонтали и вертикали, и количество шагов.
Если бы вы знали, сколько экзотики мне пришлось выслушать в качестве решения этой простой задачки…

Пример 2. Расширение предыдущей задачи, изобразить траекторию спирали (волны, мухи, варианты)
Решение. Действительно, сначала определить траекторию, затем движение по ней. Траектория может выглядеть спонтанной, но не обязана быть ломаной. Вариантов успешного решения много: от применения тригонометрических функций, до простейших квадратичных. Безье — круто, хоти и излишне сложно. Также для программирования движения будет необходимо найти длину траектории, что позволит при заданном числе FPS за заданное время пройти ее.

Пример 3. На поле есть множество танков, которые имеют коммуникации друг с другом без командного центра. Танки могут спонтанно прибывать и удаляться. Как это запрограммировать?
Решение. Как всегда, ответ уже заложен в вопросе. Раз командного центра нет, а программировать надо — можно предположить, что на всех танках установлена одинаковая копия программы. Естественно, она должна принимать и отдавать данные. Данные удобно упаковывать в пакеты. И сделать пакеты двух типов — пакеты с данными и отчеты о доставке. На тройку — все пакеты путешествуют по всей сети, пока не найдут адресатов.
На пятерку. Принимать и отдавать данные — не без кешей/стеков. В пакетах с отчетами о доставке можно логгировать путь — таким образом, отправитель может анализировать полученные отчеты, и легко находить кратчайший маршрут, проверяя его актуальность (наличие и качество связи). Это снизит нагрузку на сеть и многократно увеличит эффективность коммуникаций.

И тому подобное. Даже джуниор, умеющий анализировать и выдавать простые решения, будет более полезен в качестве однополчанина, чем регалийный коллега, сосредоточенный на своей крутизне, маниакально ищущий сложные пути, и, как следствие — испытывающий затруднения в решении простых задач.

Совсем простые задачи:
— пагинация для блога;
— подгружать игровой мир фрагментами в зависимости от положения героя, чтобы лишний раз не показывать игроку заставку «Загрузка»;
— элементарные операции с массивами и фокусы с приведением типов в «реальных» ситуациях;
— оптимизация «реальных», но элементарных алгоритмов.
Это не радует, на самом деле, но даже с простыми задачами отсеивается до 90% кандидатов.
Давать сложные задачи, и тем более «тестовое задание» особого смысла не вижу — отнимается много времени и у кандидата, и у интервьюирующего. Кроме того, кандидаты и без того чувствуют себя неловко — зачем еще сильнее напрягать людей?

Адекватность и лояльность

Тут помогут вопросы о карьерном пути и о личных стратегических планах. Вранье, которое предназначается для нивелирования непрофессиональной (читай — несерьезной) жизненной позиции видно сразу.
Интересно, как кандидат рассказывает о своем успешном и нетривиальном опыте. «Расскажите о решениях, которыми вы гордитесь. Какие интересные задачи вы решали?»

Во-первых, большое значение имеет как таковое наличие этого опыта. Если вся профессиональная культура ограничивается решением узкого спектра исключительно учебных задач — возможно, кандидат еще даже не определился с собственной профессией. Хотя он может быть хорошо подготовлен, но есть огромная вероятность, что он «сдуется» и свалит с корабля перед первой же бурей. Понадеетесь на такого — а по факту грести придется одному за двоих.

Во-вторых, яркие впечатления и подробности в таких рассказах дают понять о профессиональной вовлеченности специалиста. Простые уточнения «ой, а расскажите, как вы вот это сделали?» дают возможность выявить дилетанта или врунишку.

Спасибо за внимание и удачи вам!