Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.
Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»
Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.
К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.
Что ты предлагаешь, чувак?
Давайте рассмотрим на примере android разработчика (адаптировать можно для любой области, но вы же понимаете, что без конкретики эту статью просто раскритиковали бы, так что поговорим об android).
Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!
Почему это хороший вариант? Вы сможете достаточно точно оценить уровень разработчика в проектировании и реализации ПО, его знание платформы и другие важные вам ньюансы, а так же просто приятно провести время (в случае с компетентным кандидатом, да и ему будет интереснее чем на типичном собеседовании). + Вы сможете понять, насколько человек общителен, как вольется в вашу команду, сможет ли он объяснять свои решения другим?
Разбор листочка с кодом или заученные ответы на подковыристые вопросы не дадут вам понять, как потом этот человек справится с реальными задачами на реальном проекте (но я не говорю, что не надо спрашивать этого, можно, но это не должно быть основой собеседования).
Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).
Еще раз, я предлагаю обсуждать реализацию проекта, который уже запущен, работает и по нему есть, о чем поговорить. Не просто абстрактно потрещать о канонах ООП и грамотной архитектуре коня в вакууме, а взять конкретное приложение/веб-сервис/подставьте_свое и обсудить интересующие вас аспекты его проектирования и реализации. Надеюсь, вы уловили эту мысль.
Вы увидите, что выводы, которые я буду делать после каждого раздела «О чем будем говорить» универсальны и подойдут для многих областей разработки ПО (вы всегда можете все адаптировать для своей сферы).
И как же провести такое собеседование?
Я бы открыл приложение/сайт/etc на девайсе (не абстрактно же все обсуждать) и, собственно, начал бы беседу: «Представь, что тебе необходимо реализовать такое приложение, давай обсудим, как бы ты это сделал?» и поехали по вопросам. Открываете какой-то экран и спрашиваете: «а как бы ты сделал...»
О чем будем говорить?
(Разработка под android — это просто пример)
1. Архитектурные моменты
- Как организуем походы в сеть? (сервис или асинктаски, или и то и другое? Может быть свой пул потоков)
- Как сделаем БД (ORM, чистый sql, как кстати многопоточные проблемы будем разруливать? а может вообще NoSQL засунуть??)
- Что с кешированием данных? (что можно на файлах, а что в БД, что с инвалидацией, ограничением размера кеша)
- Как реализовать уровень api? (тут просто о том, какие подходы будут применены, скажем все модели ответов сервера наследуют базовую, обработка сетевых ошибок, обработка ошибок от api)
Следует уделить этому вопросу большое внимание, т.к. такие вещи, как реализация серверного api потом используется по всему проекту, поэтому она должна быть простой, при этом готовой для улучшений/изменений в будущем (KISS в общем)
- Сразу обговорите по поводу серьезных библиотек, которые разработчик хочет затащить в проект (про серьезные, я имею в виду те, которые жестко связывают руки в дальнейшем, например Robospice, ActionBarSherlock (я в курсе про ActionBarCompat), AndroidAnnotations, etc)
После данных вопросов вы поймете, какие проекты доводилось делать этому разработчику и какую роль он в них играл, какой опыт в проектировании приложений у него за плечами.
2. Специфика платформы
- Фрагменты! (вы ведь все делаете на них, а почему? где и как использовали бы, тут можно открыть NavigationDrawer во Вконтакте и спросить как устроена top-level навигация в приложении, почему ее сделали такой и так далее)
- Жизненный цикл компонентов android приложения (task, activity, fragment, service)
- Подходы к организации responsive-ui приложения (верстка, стили-темы, анимации, dp, sp, как они устроены, как в них верстать)
- Важные отличия API level < 11 и API level > 11
После этих вопросов вы поймете уровень скиллов по разработке под конретную платформу (в данном случае — android)
3. Общая грамотность в программировании и разработке (у многих такая каша в голове по этой теме...)
- Типы данных (где и какие он бы применил в приложении? как хранить в памяти список новостей, список контактов, знание реализаций и контрактов List, Map, Set, понимание того, где какую структуру применить, сложности операций
- Алгоритмы (знание сложностей базовых алгоритмов сортировки, например список контактов можно сортировать по разным критериям? другие специфичные для вакансии алгоритмы)
- Архитектура
от артура: ООП (наследование, инкапсуляция, полиморфизм, абстракция, зачем эти штуки и как они взаимосвязаны?), (паттерны, зачем они, если есть предыдущие 4 штуки? какие знает? а какие умеет? отношение к ним), ради интереса ФП (что знает, может пробовал, в чем суть)
После этих вопросов вы узнаете насколько кандидат силен в разработке, как в науке, практические знания — это отлично, но без теории он не сможет «творить свое», а только копировать чье-то, при этом, как правило, ухудшая реализацию.
4. Оценка сроков исполнения, потенциальной командной работы
- Грубая оценка реализации бета версии такого приложения (Вконтакте) если разработчик только он один + дизайнер и тестировщик (я бы сказал, от полугода фулл тайм работы всех участников команды, субъективщина, зависит от скиллов, естественно, но позволит понять насколько он близок к реальности)
- Если добавить еще разработчиков, как бы он распределил работу над приложением (тут можно понять, как разработчик в целом представляет себе командную работу)
После этих вопросов вы сможете прикинуть, как он вольется в ваш коллектив и справится с работой в вашей компании, можете обсудить ваши подходы к организации разработки
Вот и все. Важные замечания и имхо автора
Этот подход НЕ подойдет компаниям, у которых набор персонала поставлен на поток и на каждое собеседование жесткие 15-20 минут времени. Но он может хорошо подойти для небольшой команды профессионалов, которым потребовался дополнительный человек-профессионал.
+ При таком подходе к собеседованию вы можете случайно пропусть любителя поговорить, который в итоге зафейлит ваш проект, т.к. на словах он Лев Толстой, а на деле… Так вот, что бы такого не было, я предлагаю давать тестовые задания (сейчас 99% скажет, что это фигня полная, времени надо и все такое. НО это единственный нормальный способ, не считая Open Source проектов, проверить качество кода, который выдает разработчик, его отношение к срокам и к истолкованию требований, релизации, к работе с VCS и т.д., ну вы поняли).
Что думаете? По мне — этот подход интереснен для обоих сторон и эффективный, тоже для обоих сторон. Сразу понятно, в чем пробелы у кандидата (а возможно и у интервьюэра), и кандидату понятно, какой скилл от него требуется, чего он знает, чего не знает. Прекрасно ведь. Самый эпик, когда ты корпел на собеседовании 2 часа отвечая на тонну вопросов от SQL до Java и C, а потом через неделю тебе говорят, что ты вроде ничего, но мы тебя не возьмем бебебе. А ты сидишь и думаешь, в чем же я накосячил?
Я не говорю «вы все делаете это неправильно», я предлагаю альтернативу/дополнение для текущих подходов и хотел бы услышать ваше мнение, надеюсь, вы не зря потратили время и вынесли что-нибудь полезное для себя, спасибо.
P.S. такой подход к собеседованию может убрать эти идиотские требования к стажу работы по конкретному профилю. Знаете, я немало повидал программистов со стажем 3+, 5+, 10+ и видел даже 15+, но программировать они так и не научились, то что они дают на выходе — такая какашка, что хочется выбросить, забиться в угол и поплакать, а ведь эти люди получают свои 100k+ и думают, что они одаренные. Если вы публикуете вакансию, пожалуйста, поставьте в графу стаж работы: «не важно, лишь бы программировал хорошо» или «от года» и не отсеивайте кандидатов по этому признаку.
P.P.S внезапно, но я сам еще не проводил собеседований (проходил достаточно), но думаю, скоро буду, и попробую сделать что-то в этом роде. Вот так вот, сам не пробовал, но вам советую. Критика приветсвуется, хотя я уверен, что все будут говорить, что на такое собеседование нужно много времени. У меня есть для вас аргумент — лучше потратить немного больше времени на этапе собеседования.
Автор: Artem_zin
