Провести техническое интервью — задача сама по себе непростая. А если вам нужно сделать это впервые, она усложняется вдвойне. Как готовиться к собеседованию? Какие вопросы задавать кандидату во время интервью? Как вести себя в нестандартных ситуациях? Как оценивать уровень соискателей и принимать решение?

Все эти вопросы мы задали техническому интервьюеру из EPAM Ахрору Рустамову. Он собеседует JavaScript-разработчиков в компанию. Несмотря на то, что за спиной Ахрора больше сотни интервью, он до сих пор очень тщательно готовится к каждому собеседованию.




Что делать перед собеседованием


За несколько дней до интервью стоит внимательно изучить резюме соискателя, составить примерный список вопросов и освежить собственные знания.

Изучите резюме кандидата


Я всегда читаю анкету кандидата с карандашом: отмечаю, сколько лет он занимается разработкой, на каких проектах работал, какие технологии использовал и в какой области считает себя экспертом.

Затем, после общего исследования резюме, я фокусируюсь на деталях и начинаю делать заметки в блокноте. Например, если человеку 30-35 лет и он всё время писал только на jQuery, фиксирую этот момент. Если вижу, что синьор-разработчик не работал два года по специальности, отмечаю и это.

Подготовьте список вопросов


Опросник для кандидата на должность JS-разработчика я обычно делю на четыре части: вопросы о карьере, технические вопросы, вопросы на проверку уровня soft skills и практические задания.

— Вопросы о карьере


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

— Вопросы на проверку уровня технических знаний


В первую очередь мне нужно понять, насколько хорошо кандидат знает базовые вещи: основы JavaScript, HTML/CSS, React/Redux и основные фреймворки.

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



От базовых вопросов по JS я перехожу к более специализированным. И вновь обращаюсь к своим записям и заметкам. Вижу, например, что в резюме человек указал, что изучал Webpack. Значит обязательно спрошу, чем Webpack 3 отличается от Webpack 4.

Я могу пропустить блок базовых вопросов, если соискатель претендует на позицию senior-разработчика и выше.

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

— Вопросы на проверку уровня soft skills


Несмотря на то что моя главная задача – оценить технические знания кандидата, я обязательно задаю вопросы, связанные с soft skills. На наших проектах мы работаем в командах, а быть командным игроком без навыков межличностного общения (умения задавать вопросы, слушать и слышать другого, аргументированно высказывать своё мнение) очень сложно.

Вот что я обычно спрашиваю:

  • Работал(a) ли по Agile, Scrum?
  • Был ли опыт управления, менторинга, интересно ли это?
  • Как расставить приоритеты в работе, если у вас есть несколько надвигающихся дедлайнов?
  • Вы считаете, что ваш коллега или менеджер в чем-то не прав. Что вы сделаете?

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

— Практическое задание


Я всегда готовлю для кандидата несколько задач, которые можно решить за 10-15 минут. Если собеседую junior-разработчика, могу дать ему несколько подсказок. Инженерам уровня middle и выше обычно не подсказываю.

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

Освежите собственные знания


Если в резюме кандидат отметил отличные знания в области, в которой лично я ориентируюсь плохо, стараюсь подтянуть эту тему – перед интервью читаю статьи, смотрю ролики.

Помню, на подготовку к своему первому собеседованию в качестве интервьюера я потратил целый день. Несколько часов провел на learn.javascript.ru, просмотрел серию книг «You don’t know JS» и освежил знания HTML и CSS.

Что делать во время интервью


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

Обычно я всегда озвучиваю кандидату наш план действий. Я делю собеседование на три этапа:

  • короткий рассказ кандидата о себе;
  • мои вопросы: о карьере, технический блок, вопросы про soft skills и практические задачи;
  • вопросы от кандидата.

Этап первый: послушать рассказ кандидата о себе


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

Этап второй: задать свои вопросы


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

Бывает, человек начинают отвечать не на тот вопрос. Я задаю ему теоретический вопрос на знание технологии, а он переключается на свой опыт работы с ней. В таких ситуациях я прошу вернуться к вопросу и предлагаю обсудить его опыт в конце встречи.

Интересно наблюдать, как кандидат реагирует на вопросы, в которых плохо владеет материалом. По поведению можно понять, как он будет действовать в схожей ситуации на проекте.

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

Этап третий: дать возможность кандидату задать вопросы


Теперь очередь соискателя задавать вам вопросы. Обычно люди спрашивают о будущих задачах, возможностях роста и развития, а также о бенефитах, которые предоставляет компания.

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

Вот мой личный список того, чего ещё нельзя делать на собеседовании:

  • Говорить кандидату, что тот отвечает неверно. Человек может впасть в ступор и ему будет тяжело собраться и ответить на остальные вопросы.
  • Обращаться к кандидату на «ты» без разрешения. Если собеседнику комфортнее перейти на «ты», он сам об этом скажет.
  • Использовать повелительный тон в общении. Если человек делает что-то не так, сообщите об этом максимально вежливо.
  • Затягивать собеседование. Старайтесь уложиться в час, максимум – в полтора. Не забывайте, что кандидат может испытывать стресс: не нужно держать его в этом состоянии чересчур долго.

Как вести себя в нестандартных ситуациях на интервью


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

Рассказываю, что делать в нестандартных ситуациях.

Ситуация: кандидат растерялся и на все вопросы отвечает «я не знаю»


Начните заходить со стороны и задавать дополнительные, уточняющие вопросы. Похвалите человека, если он смог сказать что-то по теме. Похвала поможет кандидату почувствовать себя более уверенно. У меня был случай, когда соискатель думал, что не знает ответ на вопрос. Я успокоил его, подбодрил. После этого он расслабился и стал спокойно отвечать. Многие хорошие специалисты довольно самокритичны — думают, что недостаточно хорошо знают тему. В большинстве случаев это не так.

Ситуация: кандидат занял агрессивную позицию — пассивную или активную


Если все шло гладко, а потом человек резко поменял свое поведение, попытайтесь аккуратно выяснить, в чем дело. Возможно, после вашего вопроса он вспомнил какой-то свой негативный опыт или его элементарно начал раздражать шумящий в переговорке кондиционер.

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

Что делать после собеседования


После собеседования я советую заполнить небольшую анкету, выписать рекомендации для кандидата и прийти к выводу — подходит специалист вашей компании или нет. Сделать все это желательно в течение нескольких дней — пока в вашей памяти не стерлись впечатления об интервью.

Заполните анкету по итогам интервью


У меня есть небольшая заготовка анкеты, которую я использую прямо во время интервью. Она представляет собой список тем, напротив которых я ставлю «+» или «–» в зависимости от того, верно или неверно человек ответил на вопрос по этой теме. Я также вписываю туда свои наблюдения прямо во время разговора. Мне остается только все проанализировать и сделать вывод. Обычно на это уходит не больше 15 минут.



Напишите рекомендации для кандидата


У нас в компании после собеседования принято давать кандидату обратную связь. Каждый специалист получает от меня довольно подробный фидбек – что было хорошо, а что стоит подтянуть. Я также делюсь с человеком списком полезных материалов.

Примите решение


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

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

И ещё…


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

Что читать начинающим интервьюерам



Технические ресурсы


Фото: unsplash.comfirestock.ru.

Комментарии (16)


  1. JustDont
    26.09.2019 12:31
    +1

    «Если человек ходит по собеседованиям пачками и/или в недавнем прошлом прочитал про аргументы bind и про специфику поведения box-sizing — то он существенно более крутой специалист, чем тот который не ходит и не прочитал».

    Я правильно понял один из главных тезисов статьи?


    1. farafonoff
      26.09.2019 14:43

      Нет, неправильно. Приведенная форма это просто конспект интервью, нет такого критерия, что должны быть отвечены все вопросы. Тем не менее, человек который не владеет bind/call/apply, не знает каррирование и не понимает как работает event loop имеет хорошие шансы получить отказ.


      1. markmariner
        26.09.2019 14:52

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

        И я не имею ни какого представления, что такое Event loop, а про bind/call/apply и каррирование прочитал в какой-то статье однажды и забыл, потому, что никогда не использовал на работе. (Ну ладно, bind использовал).

        По вашей методике я даже на джуна не потяну. Как же так?


        1. farafonoff
          26.09.2019 15:45

          очевидно вы не подходите для позиции junior/middle/senior front-end developer. Ищите вакансию на которой не нужно работать с кодом непосредственно.


          1. markmariner
            26.09.2019 15:47

            Под словом разработал я подразумевал, что я не только придумал, но и сам и написал всю эту основу. Вот прямо на JS.

            Суть в том, что я, например, использую то же каррирование и event loop, только я не знал, что они так называются.


            1. farafonoff
              26.09.2019 16:06

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


      1. JustDont
        26.09.2019 18:33

        Тем не менее, человек который не владеет bind/call/apply, не знает каррирование и не понимает как работает event loop имеет хорошие шансы получить отказ.

        Ну то есть я таки понял всё правильно. Спасибо.

        А мой верхний коммент вот о чём: найм — это в общем случае процесс выбора максимально пригодного для работы кандидата среди имеющихся. И для выяснения пригодности — берется некоторое количество критериев, ранжируется по релевантности, и налагается на кандидатов. А дальше всё просто: если кандидаты на определенном уровне релевантности одинаково сильны (= «при прочих равных»), то спускаемся ниже и смотрим на менее релевантные вещи, и так далее.

        Что из этого мы видим в статье? Да нифига не видим, автор уже куда-то потерялся на ранжировании. Если кандидат знает аргументы bind и event loop, но не может написать кода — это лучше или хуже кандидата, который теорию не знает, но код пишет? Судя по тому, что автор статьи в своей анкете запихал написание кода в самый конец — я прям готов предположить, что для него главное, чтоб аргументы bind посреди ночи рассказывали на память.

        PS: Из всех нормальных процессов найма, виденных лично мной (с обоих сторон), самые адекватные из них следовали простому и нехитрому пути:
        1) убедиться в том, что кандидат общечеловечески адекватен и плюс-минус подходит коллективу;
        2) убедиться в том, что он может сам писать код в необходимой области;
        3) на оставшееся время — поговорить за жизнь и поотвечать на вопросы, уменьшая шансы того, что в недалёком будущем чего-то резко не сложится.
        4) если всё ок — нанять на испытательный срок и смотреть на результаты работы.


        1. farafonoff
          26.09.2019 21:56

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


          1. JustDont
            26.09.2019 23:43

            Если кандидат не знает теорию, но код пишет, то вовсе не очевидно, что код он пишет правильно, наилучшим образом, и при этом понимает что именно он пишет.

            Ну да. Зато если уж аргументы у bind все знает — то наверное пишет всё правильно, наилучшим образом, и при этом всё-всё понимает ^_^

            Теорию не выспросить в нормальном объеме за часик собеседования. Даже если вы очень-очень хорошо себе представляете, какой именно объем теории будет релевантен для ваших задач (обычно не представляют).

            Нормальное знание синтаксиса и внутренней логики фреймворка позволяет отлаживать сложные баги

            А незнание граничных наворотов синтаксиса и внутренней логики фреймворка — позволяет писать простой тупой код с высоким bus factor, который легко читается и отлично поддерживается ^_^

            Но на самом деле соль даже не в этом. От того, что кандидат не знает, что bind можно применять для каррирования — его код в подавляющем большинстве случаев (>98%) будет не хуже. От того, что он знает каррирование и лепит его куда не попадя — хуже будет в десятки раз сильнее. Нет ничего печальнее умников, делающих красно-чёрные деревья, хэшмапы, собственные сортировки, каррирование, и прочую муть там, где достаточно банальных простых переборов, массивов, .sort(), и последовательного вызова пары методов.


        1. DenisSel
          27.09.2019 10:57

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


  1. DenisSel
    26.09.2019 18:02

    Работаю 5 лет на фронте. Сменил три работы и прошел очень большое количество интервью. Постоянная проблема, это техническая часть интервью, там где она есть я ее постоянно заваливаю, там где не спрашивают получаю приглашение и хорошо работаю. Я не могу написать пузырьковую сортировку в течении 5 мин или рассказать каким способом я реализую паттерны проектирования в верстке приложений (вообще не представляю как отвечать на данный вопрос). Event loop для меня темный лес. ПОЧЕМУ на собеседованиях никто не спрашивает по тем задачам которые тебе действительно необходимо будет решать на своем рабочем месте? Вы вообще часто пишете свою реализацию сортировки в продакшен?


    1. kimisa
      26.09.2019 21:20

      Вот обычно я так же и отвечаю на собеседовании. Зачем изобретать велосипед, если он есть? Я за всё время программирования ни разу её не использовала. И если я её сходу не сформулирую, это значит я не спец? Ну прочитала пару раз и я про неё и забыла, т.к. в работе она мне просто не нужна (я про само знание алгоритма веду речь).


      1. farafonoff
        26.09.2019 22:21

        Фронтэнд такая же инженерная специальность, как и другие. Почему-то C++ или java инженеры не стесняются знать модель памяти x86 процессора и сложность основных алгоритмов, а фронты за 5 лет ни разу не открывают MDN чтобы понять в каком порядке приходят асинхронные коллбэки.


        1. DenisSel
          27.09.2019 10:16

          Я не уверен что все специалисты С++ или java знают модели памяти х86 и сложность основных алгоритмов. Если знают — отлично, если не знают и в работе не используют то ничего страшного в этом не вижу. Я работаю на фронтенде хорошо знаю UX/UI, отлично верстку имею компетенции в маркетинге и выводе продукта на рынок. Я прекрасно осознаю слабость своих знаний в области JS, но я и не претендую на должность синьора. При этом моя ценность для компании может быть очень высока. Обычно интервью никак не учитывает софт скилы и как следствие компании теряют хороших специалистов на стыке специализаций.


      1. OnYourLips
        28.09.2019 13:21

        Я поэтому спрашиваю не "расскажите мне, что такое <умный термин>", а "как в <ваш основной фреймворк> работает <очень важный компонент> внутри".


        На такой вопрос поможет ответить только опыт, а не натаскивание на собеседования. Причем опыт, который непосредственно связан с трудовыми обязанностями и непосредственно влияющий на качество результата. Который постепенно нарабатывался при решении проблем; чем больше разных проблем было решено, тем больше и опыта.


        Поэтому даже если вы не изобретаете велосипед, вы все равно в какой-то степени знаете его устройство. И объем этого знания неразрывно связано с качеством вашей работы и, следовательно, вашей зарплатой.


    1. Kanut
      27.09.2019 12:48

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


      Просто потом всегда либо находились либо какие-то другие проблемы(с той или другой стороны) или просто по какой-то причине я выбирал другие фирмы.


      И не то чтобы это было прямо показательно или на основании этого стоит выводить глобальные правила для всех. Но для меня это интересный факт :)