Re: Собеседование разработчика (альтернатива/дополнение)

Не мог пройти мимо топика "Вопросы на собеседование 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 внезапно, но я сам еще не проводил собеседований (проходил достаточно), но думаю, скоро буду, и попробую сделать что-то в этом роде. Вот так вот, сам не пробовал, но вам советую. Критика приветсвуется, хотя я уверен, что все будут говорить, что на такое собеседование нужно много времени. У меня есть для вас аргумент — лучше потратить немного больше времени на этапе собеседования.

UPD: Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата
Поделиться публикацией

Комментарии 35

    0
    Хм. Так и делаю, когда требуется отсобеседовать человека. Просто скидываю краткое описание одного старого проекта и прошу рассказать, как эта вся хрень должна работать. Без кода, просто как сделать в теории. Собеседую в основном на Друпал, так что тут заодно и степень погружения можно проверить — насколько человек ориентируется вообще, а не просто долбит код. Проект такой, что местами надо юзать готовые модули (свои писать долго и дорого), а что-то однозначно надо дописать самому. Вот как-то так оно и происходит.

    Иногда, кстати, кандидаты выдают довольно неожиданные решения.
      +12
      Ваш подход немного отличается от предложенного мной, но это отличие важно. Суть в том, что обсуждается реальный проект, который вы вот прямо сейчас открыли на экране и этот проект делали не вы. Это достаточно сильно меняет вещи. Мало кто захочет обсужадть ваш старый проект, по которому вы все знаете и своего мнения по его реализации скорее всего не измените, а кандидат должен быстренько вникнуть и угадать, как вы что в нем сделали, чтобы ответ вам понравился.

      Ставьте друг друга в равные положения и обретете понимание в беседе :)

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

      Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата
        0
        Это да, такая опасность есть. Но стараюсь избегать.

        Я вообще стараюсь на соискателя не давить в этом плане. Мне просто интересно оценить потенциальную работоспособность того, что он предложит. Я также спрашиваю о возможных подводных камнях, которые в его решении, возможно, не учтены, или о которых он не упомянул. Мне интересен подход к реализации, я не требую полного решения задачи. Одни пытаются использовать чистый РНР, другие комбинируют это с уже известными решениями на Друпале (причём сами используемые решения могут быть довольно разными).

        И да, после того, как я понял, что и как человек предлагает сделать, я предлагаю тот подход, который реально задействован на том проекте (естессна, я не говорю, что это делал я) и прошу оценить такой вариант. Вы знаете, пару косяков уже нашёл :)

        Кстати, по чужому проекту у того, кто проводит собеседование, зачастую тоже уже есть своё мнение, так что в этом плане подход не особо отличается.
          0
          Тогда хорошо :) Вообще надо избегать предвзятости везде, не только на собеседованиях, понятно, что опыт за плечами и все такое, но лучше быть открытым к диалогу.
      –2
      Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!

      Сам в том месяце как раз устраивался по вакансии этой. Многие работодатели как раз задавали вопросы вроде: «А вот в том-то приложении есть то-то и то-то. Смогли бы вы сделать это? Если да, то как? Какие сроки? Поддержка какой версии Андройд?» Довольно неплохой подход к собеседованию.

      Про Android при собеседовании стоит отдельно поговорить о поддержке разных версий Android. Какими средствами этого добиться? Поговорить о support library, о других либах для поддержки старых устройств вроде ActionBarSherlock.
        +7
        «Андройд» резко сокращает шансы кандидата вплоть до нуля.
          –2
          Если работодатель оценивает не способности кандидата, то да.
        +1
        Сам часто спрашиваю такие вопросы на собеседованиях, но только после знания «платформы». Как сделаете — вопрос, больше подходящий для Senior-позиций. Если человек «плавает» в знании платформы, то как он сможет принять адекватные решения при проектировании?
          0
          ИМХО При Вашем подходе получается, что нужно нанимать человека под конкретную задачу с конкретными требованиями, и, по окончании проекта, расставаться с ним. Я, конечно, утрирую, но Вы предлагаете что-то вроде такого: «специалист по отрисовке красных параллельных линий на синем фоне». Почему расставаться? Потому что на желтом фоне он уже не сможет ничего нарисовать…
          Ситуация может поменяться, вплоть до смены языка программирования, платформы, операционной системы и т.д. (со мной был такой случай, когда изначально стояла задача писать ПО под Windows (C#/.NET4.0), а вышло под Linux (C++/Qt)). Поэтому, я считаю, что важнее гибкость мышления и быстрая обучаемость, нежели доскональное знание платформы и языка.
            +1
            С другой стороны, если человек глубоко изучил один инструмент, то это хороший признак того, что он в будущем сможет изучить и другие инструменты.
              0
              Ну для «вышло» существует контрактная форма взаимоотношений.
                0
                А при чем тут это? При Вашем подходе я просто потерял бы работу. А получилось все очень хорошо: компания получила продукт, я получил бесценный опыт… Плюс, как и написал Shedal выше, переписать проект из C# в Qt вышло не так уж и сложно.
                А непредвиденные ситуации бывают, тут уж ничего не поделаешь, и если прятаться за контракт, подавать в суд и т.д., ИМХО с таким человеком мало кто будет работать…
            +1
            Вы не боитесь, что при данном подходе вы откажетесь от кандидата, который имеет не самый большой опыт на данной платформе, но способен хорошо и быстро обучаться?
            Условно говоря, платформе Андроид не так уж много лет исполнилось.
            И не от всех программистов следует ждать досконального знания фрагментов и апи-левелов — многие из них последние 5 лет работали не для андроида.
            Если вам соискатель скажет: «я не программировал на андроиде вообще, но 5 лет назад со мной был случай — мне поручили такое приложение написать на WinCE, и я впервые увидев эту платорму написал это за X месяцев — вот оно — смотрите»
              –1
              Чаще бывает другой случай — кандидат приходит и говорит, что он — Гуру вообще и пишет под платформу технологию последние 26 лет, но вот чем абстрактный класс отличается от интерфейса© не знает.
                +5
                Если вам соискатель скажет: «я не программировал на андроиде вообще, но 5 лет назад со мной был случай — мне поручили такое приложение написать на WinCE, и я впервые увидев эту платорму написал это за X месяцев — вот оно — смотрите»

                А можно нанять программиста, последние 3 года писавшего под Android, который это же приложение сделает за неделю. Я утрирую конечно, но всё же…

                Тут важен опыт. Если человек не работал с платформой, но быстро учится, то да, он может быстро освоиться, даже написать приложение какое-то, вот только он не знает ничего о подводных камнях и т.д.

                Поэтому человек с опытом и хорош, так как он знает о многих подводных камнях, особенностях, возможностях платформы и т.п.
                  0
                  Вы серьезно считаете, что человек который писал под разные платформы будет очень долго учиться кодить под андроид? Качество кода и хорошие привычки (типа написания тестов и тд). похоже не сильно котируются сейчас. Зато человек, который «х*як-х*як и в продакшен» всегда на коне =)
                    0
                    Я считаю, что человек, который пишет преимущественно под одну платформу (и разбирается в ней) лучше, чем человек, «который писал под разные платформы», но не достиг высокого уровня ни в одной.
                      +1
                      но не достиг высокого уровня ни в одной


                      Такого я не говорил.
                      Просто я вижу что вызубренные API андроида больше котируются, чем умение писать поддерживаемый код.
                      +1
                      Согласен) В сегодняшних реалиях разработка — это бизнес, поэтому требуется максимально быстро создать продукт, а приоритет отдается визуальной оболочке, нежели качеству кода…
                  +2
                  Звездная команда не всегда нужна, иногда это плохо. Если все проектировщики, все очень общительные -> постояные споры. Нужен один два проектировщика, остальные — реализаторы. Реализатор не обязательно тупой и не может проектировать, но обязательно умеющий реализовывать любую придуманую архитектуру, обучаем и покладист. Может быть даже ни разу не социальным, главное управляем.
                    +10
                    Еще с женой, детьми и ипотекой, чтобы далеко не убежал.
                    0
                    IMHO, не очень хорошая идея. Придет человек вроде меня и спросит: а такое «Вконтакте»? Вот я понятия не имею, что там за приложение, зачем оно нужно и что от него требуется. Конечно же если вы собираетесь делать подобное приложение, то вам и не подойдет такой программист. Поэтому если и использовать подобный подход, то не «берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение», а берем именно то приложение, функциональность которого схожа с будущими задачами для этого программиста.
                      0
                      Когда я устраивался на работу, собеседование тоже начиналось со стандартного листочка с вопросами по языку и вариантами ответов. Но на каждый вопрос задавали дополнительные вопросы — «Почему именно этот вариант?», «А как бы вы это реализовали?», «А почему дизайнеры языка решили это сделать именно так, а не иначе?», «Может знаете, как с этим дела в других языках?» и даже самый банальный вопрос разворачивался в довольно интересное обсуждение
                        0
                        Поддерживаю автора, но обычно я давал такие задания кандидатам на дом, неделя максимум, потом собеседовал по написанному коду. Очень помогает отсеивать некомпетентных разработчиков. Единственное, я немного не согласен с тем, что надо давать большое приложение — у многих уже есть работа, а если еще есть дети или другие интересы, очень сложно выкроить время. На Западе на это вообще смотрят очень категорично, и отказываются делать задание, если оно в сумме отнимет много времени на разработку. Так что для себя я выбрал критерий — если я смог бы это сделать менее чем за 8 часов, тогда можно давать — сутки кандидат сможет выкроить.

                        Еще бы я добавил в задание немного методологических нюансов, как например, потребовать чтобы кандидат залил свой проект на DVCS-хостинг (github, bitbucket etc), и чтобы было покрытие юнит-тестами (не обязательно 100%, но как минимум backend-функционал). Если это библиотека, можно потребовать автогенерируемую документацию. Т.е. посмотреть, насколько качественно умеет кандидат делать приложения, не только внутренний код, но и другие вещи, являющиеся атрибутами хорошо разработанного продукта.
                          +1
                          Самое главное — архитектура ПО, а кодеров хоть г… на. Некоторые умеют и очень даже красиво писать код и бить себя в грудь, но то что они делают с архитектурой, это полное дилетантство.
                          А некоторые архитекторы, не могут так быстро кликать по клаве и нормально излагать свои мысли в речи, но то что они творят с архитектурой — это одно совершенство.

                          Так что все эти собеседования — это одно большое недоразумение. Надо смотреть по портфолио и работе.

                          Алмаз — тяжело найти. А г всегда много, иногда даже в очень неплохой упаковке
                            0
                            И если компания набирает проект «по собеседованию» Пипец такому проекту.
                            Я бы никогда не набирал так команду. Всегда надо анализ. В компании MS вообще 30% состава программеров — это аутисты, которые два слова связать не могут, зато они любую задачу развяжут в несколько раз быстрее, элегантнее и с меньшим количеством не нужного кода. (в google тоже таких любят)
                              0
                              По портфолио и работе разве что в исходники смотреть, бывают внешне нормальные приложения, а в исходники заглянешь — тьма тьмущая и сразу понятно, почему функционал внедряется медленно и тд и тп. К тому же, как вы поймете, какю роль человек играл в реализации проекта из портфолио, приукрасить в любят.

                              Поэтому и предлагаю обсуждать на примере реального проекта архитектурные моменты + реализации определённых, интересующих вас вещей.

                              Качество кода — тестовое задание, небольшой проект на день работы, как по мне — оптимальный вариант.
                                0
                                Да портфолио и чужое можно взять (вы не поняли суть моего поста), лучше уже «знать» того кого хочешь. Переманить.
                                Тогда можно твердо быть уверенным, что проект получиться не хуже чем у конкурента, у которого переманили архитектора.

                                А собеседование можно проводить на прием секретарш.
                                Когда я набираю персонал я уже знаю кого беру. И результаты проектов всегда прогнозируемые.
                              0
                              Спасибо за подборку вопросов, очень ценно! Осталось теперь каким-нибудь образом всему этому научиться…

                              Идея, я считаю, в целом очень правильная.
                                0
                                Не понял, а чем плох robospice?
                                Или «серьезные» android программисты должны сами иметь/разработать свою библиотеку для REST?
                                  0
                                  Я же не говорил, что он плох, я написал:
                                  Сразу обговорите по поводу серьезных библиотек, которые разработчик хочет затащить в проект (про серьезные, я имею в виду те, которые жестко связывают руки в дальнейшем, например Robospice, ActionBarSherlock (я в курсе про ActionBarCompat), AndroidAnnotations, etc)


                                  Я не против его использования, но только если оно аргументированно. Просто так затаскивать такую библиотеку в проект не стоит, т.к. потом сменить ее на что-то другое (если потребуется) будет очень проблематично, вот и все :)

                                  Могу вас успокоить, у нас в проектах robospice используется. Но скажем, я обычно сам пишу работу с сетью и кешем запросов, т.к. уже не раз наталкивался на особенности работы серверной стороны, то gzip для определенных запросов, то заголовки подменить и т.д. и т.п., ну и кеш, соответственно, тоже часто надо тюнить под проект, естественно, у меня для этого есть свои наработки.

                                  Из накипевшего, под windows phone недавно вообще пришлось запилить свою библиотеку для загрузки и кеша картинок: https://github.com/artem-zinnatullin/jet-image-loader/ (это к фразе о своих библиотеках)
                                    0
                                    Ясно.
                                    Я спросил, потому что на сам смотрю в сторону robospice. И не хотелось бы после того как освою плеваться и выпиливать её)
                                      0
                                      Она вполне нормальная, со своими прибамбасами, но нормальная, попробовать однозначно стоит, хотя бы для расширения кругозора :)

                                      Правда я не люблю, когда библиотеки вносят «магию» в проект, уж лучше самому написать обертки для подобных вещей, это не сложно.
                                        0
                                        Ну буду пробовать пока не перерасту её и не пойму что конкретно мне нужно, тогда и свою можно будет написать с кешированием и многопоточностью, в духе жанра)
                                  0
                                  Ещё лучше — обсудить с кандидатом его собственный код.
                                  Собеседование это итак стресс, а тут ещё и чужое приложение придумывать.
                                  Все те советы из статьи — только не на чужом коде, а на коде который уже написал кандидат. Т.е. просишь прислать примеры работ и их же с ним обсуждаешь. И тестовое не нужно — т.к. код уже есть. И есть что обсуждать, не растекания мыслью по древу — код уже есть.

                                  Я так собеседую по скайпу, уходит минут 20, очень эффективно.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое