Недавно в SEOmoz состоялись собеседования с кандидатами на должность веб-разработчика. Готовясь к интервью, автор статьи составил список технических вопросов, которые, на его взгляд, было бы уместно задать. После собеседований он решил суммировать результаты и составить более обширный список вопросов, который может пригодиться как интервьюерам, так и интервьюируемым.
Получившийся перечень не ориентирован на какую-то конкретную должность, он сбалансирован, с одной стороны, между дизайном, HTML и юзабилити, с другой – между бэк-эндом, базами данных и программированием. Фокус немного смещен в сторону веб-разработки, поэтому здесь нет вопросов типа «Почему вы хотите работать в такой-то компании?» (порядок вопросов в данном списке произволен).
1. Какие профессиональные сайты и блоги вы регулярно читаете?
Этот вопрос поможет вам составить представление о том, насколько человек осведомлен об актуальных тенденциях, а также – насколько ему вообще интересна данная тематика. Вы сможете отделить людей, для которых это не только работа, но и хобби, от тех, кто просто пытается гнаться за высокой зарплатой.
2. Что вы предпочитаете – работать в одиночку или в команде?
Ответ на этот вопрос важен в зависимости от предполагаемого рабочего окружения. Если ваш проект подразумевает тесное взаимодействие между разработчиками, очень хорошо, если новый человек будет иметь опыт продуктивной командной работы. С другой стороны, у многих разработчиков всё получается гораздо лучше, если они трудятся сольно. Постарайтесь найти человека, который в этом смысле отвечал бы вашим ожиданиям.
3. Насколько уверенно вы чувствуете себя, если приходится писать HTML «от руки»? (+задание)
Несмотря на то, что человек может написать в резюме, что он эксперт в HTML, на деле может оказаться, что писать на HTML с нуля он и не умеет. Такие люди полагаются на сторонние программы или на то, что всегда смогут подглядеть в мануал. Любой сколько-нибудь стоящий разработчик просто обязан быть в состоянии написать простой HTML-код, никуда не подглядывая. Несложное задание может заключаться в том, что вы чертите схему фейкового сайта и просите написать соответствующий HTML-код. Усложнять не надо – вы должны просто убедиться, что человек в курсе самого главного, а также обратить внимание на такие ошибки, как пропуск тегов
<head> </head><image src="/some/image.gif">4. Что такое w3c?
Это стандарты веб-разработки, в соответствии с которыми (хотелось бы верить) все делается. Не надо требовать цитат по поводу миссии w3c, но человек должен, как минимум, представлять, что это такое.
5. Можете ли вы написать безтабличный XHTML? Валидируете ли вы свой код?
Искореняйте старомодный табличный дизайн! Найдите такого разработчика, который использует элементы HTML так, как они были задуманы изначально. Также бывают разработчики, которые говорят, что могут писать без таблиц, но в реальности – по привычке или из удобства – все равно их используют. Можно нарисовать простое навигационное меню или статью и попросить создать под нарисованное HTML-код. Можно схитрить и представить данные как бы в табличном виде – будет бонусом, если человек догадается, что при таком раскладе таблица как раз вполне уместна.
6. Какой инструмент разработки нравится вам больше всего и почему?
Если человек скажет, что Notepad, вы, наверно, разговариваете не с тем человеком. Такой вопрос не только позволит вам «прощупать» уровень компетентности, но и понять, насколько органично инструментарий соискателя соотносится с тем, что используется у вас.
7. Опишите или покажите, что вы умеете в *nix shell?
Обратите внимание на то, как человек работает без привычного ему интерфейса. Задайте пару вопросов вроде того, как рекурсивно скопировать директорию или как сделать файл доступным для чтения только владельцу. Выясните, с какими операционными системами человек умеет работать.
8. Какие умения и технологии вам больше всего хотелось бы усвоить или усовершенствовать?
Прозондируйте почву на предмет того, насколько планы собеседника соответствуют тому, что от него ожидается на данном рабочем месте или в компании в целом.
9. Покажите мне ваше портфолио!
Портфолио может многое рассказать о разработчике. Есть ли у него вкус? Что для него более важно – креатив или логика? Важнее всего обращать внимание на солидные, масштабные, ЗАВЕРШЕННЫЕ проекты. Пяток-другой набросков и хакнутых скриптов – признак неопытности и некомпетентности.
10. С сайтами каких масштабов вам приходилось работать?
Ищите разработчика, у которого есть опыт с сайтами сходных с вашим масштабов. Человек, умеющий справляться с большим трафиком и большими размерами, может оказаться беспомощным в простой настройке Apache или оптимизации тяжелых SQL-запросов. С другой стороны, разработчики, которые обычно занимаются мелкими сайтами, могут подмечать вещи, которые их «более крупным» коллегам недоступны. Допустим, речь может идти об элементарной визуальной привлекательности решения.
11. Покажите мне ваш код!
Архаичный HTML или навороченный Ruby on Rails? Неважно! Все равно просите показать образцы кода. Исходники могут многое рассказать о привычках человека, гораздо больше, чем вы думаете. Чистый, элегантный код часто может указывать на методичного, мощного разработчика. В резюме может быть написано, что у человека более 7-лет опыта в написании скриптов на perl, но это может быть 7 лет плохой работы. Также постарайтесь получить много исходников, а не просто кусочки HTML. 20-30 строк к собеседованию подготовить может каждый, вам же важно видеть положение дел в целом. Не надо требовать кода полных работающих приложений, просто он должен отвечать на все ваши вопросы.
12. Перечислите несколько сайтов, которые вас по-настоящему восхищают (с точки зрения разработки)?
Поймите, что человека вдохновляет. Это не обязательно должно быть из серии «должен знать каждый», но у хорошего разработчика всегда есть несколько фаворитов.
13. Исправьте это, пожалуйста…
Дайте человеку код, написанный на языке, на котором у вас ведется разработка, который требуется знать на предлагаемой должности. Пусть соискатель пройдет этот код построчно и укажет на все ошибки.
14. Я только что открыл созданный вами сайт, а у меня показывает пустую страницу. Продемонстрируйте мне пошагово, что вы будете делать, чтобы решить проблему...
Это отличный вопрос для того, чтобы определить, как кандидат в целом может применять свои умения. Здесь станут ясны способности в смысле саппорта, от самых основных до решения проблем с сервером.
15. Какой ваш любимый язык разработки и почему? Какие возможности вы хотели бы добавить к этому языку?
Вопрос о дополнительных возможностях исключительно полезен – он выявляет то, насколько человек опытен в программировании вообще.
16. Есть ли какой-нибудь язык, который вас пугает?
Когда проясняется одна загадка, за ней открывается десять других. Если собеседник расскажет вам о своих неудачах, это поможет понять, сколько он на самом деле знает.
17. Время аббревиатур
Некоторые могут заявить, что знание аббревиатур – это чепуха, но есть некоторые такие сокращения, которые должны быть вшиты в мозг разработчика (допустим, HTML и CSS). Это вопрос из серии телефонных, который помогает отсеивать неподходящих людей еще на подступах к вашей компании.
18. Каким браузером вы пользуетесь?
Правильный ответ: всеми. Компетентный разработчик должен быть знаком с понятием кроссбраузерной совместимости, причем — знаком на деле. Ясно, что у каждого есть любимый браузер, который используется для серфинга, но ответ на этот вопрос может помочь плавно перейти к теме кроссбраузинга. Кроме того, если речь идет о должности, связанной с CSS/HTML, полезно поинтересоваться установленными тулбарами.
19. Оцените по шкале от 1 до 5, насколько вам интересны следующие задачи (1 – совсем не интересно, 5 – чрезвычайно интересно)
Предложите список задач на данной позиции. Когда вы увидите рейтинг, это поможет вам понять, насколько человек подходит на место.
20. Какие собственные проекты вы собираетесь продолжать?
Почти у каждого разработчика есть персональные проекты, которыми ему нравится заниматься на досуге. Это еще один вопрос, который помогает отделить страстных разработчиков от тех, кто привык работать строго в режиме с девяти до пяти. Это также хороший вопрос для завершения собеседования (потому что ответ на него обычно легкий и приятный).
Автор перевода — Давиденко Вячеслав, основатель компании MBA Consult.
KIVagant
В целом хорошие, здравые советы.
Но вот позиция «пишите от руки и не смотрите в мануал» может быть оправдана только для действительно простых вещей.
Особенно умиляет, когда на собеседованиях просят написать SQL-запросы с вложенными селектами, having и так далее «от руки». Современный веб разработчик не существует без доступа к документации, stackoverflow и google. Не просите писать код, просите выполнить задачу и смотрите на выбранный способ решения, даже если этот способ выбран готовым. Лучше предложите объяснить, почему сделано так и какие могут быть альтернативы.
KIVagant
Кстати, если уж снова поднять холивар о собеседованиях, то я бы вынес на первое место следующий универсальный совет. Он не про техническую составляющую, но как по мне, куда более важен.
1. Проводите все этапы собеседования быстро. Максимум с паузой в два дня между очередным человеком в компании, который хочет задать какие-то вопросы.
Я как раз нахожусь в процессе поиска работы и могу точно сказать, что невнимание ко времени кандидатов — крайне распространённое явление. Собеседовать человека месяц и более (каждый следующий понедельник), а потом ещё две недели не присылать ответ считается вполне уместным.
r3verser
Это у нас сейчас так (Киев)? А на какую должность/зарплату претендуете если не секрет?