Всем привет! Меня зовут Александр Григоренко, я ведущий фронтенд-разработчик в одном из крупнейших банков РФ. За свою карьеру я участвовал в сотнях самых разнообразных собеседований — как в качестве того, кого собеседуют, так и в качестве собеседующего. Мне всегда было интересно определить самые оптимальные форматы для найма хороших технических специалистов. Я проанализировал свой опыт и делюсь им в виде рекомендаций для проведения собеседований и для того, чтобы вы могли понять, насколько грамотно собеседуют вас.

Так как от инженеров разных грейдов ожидаются разные знания и навыки, я разбил свою классификацию форматов собеседований именно по грейдам — junior, middle и senior. Классификация не привязана к конкретной IT-специальности, но основана на моём личном опыте участия в технических собеседованиях на позицию фронтенд-разработчика.

Junior-разработчик (джун)

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

Хард-скиллы. Сюда входят: умение работать с git, знание основных конструкций языка, фреймворка, среды исполнения кода, базовых структур данных и алгоритмов, ключевых принципов и паттернов программирования.

Решение типовых задач, приближенных к боевым. Здесь будет важно активное участие собеседующего. В тех местах, где джун увидит знакомые шаблоны, он сможет напрямую показать свои знания, тогда как в более сложных моментах понадобится помощь того, «об кого» можно подумать. Для собеседующего важен не столько правильный ответ, сколько сам процесс мышления кандидата и активная позиция в поиске ответов. Хороший джун задаёт как можно больше вопросов, но старается самостоятельно найти конечный ответ.

Middle-разработчик (мидл)

Мидл — это достаточно опытный разработчик, который стабильно хорошо пишет код. Чаще всего ему не нужна помощь в решении задач — ему нужны сами задачи. Мидл хорошо знает текущий стек на проекте и хочет писать как можно больше кода именно на нём. В какой-то момент он почувствует себя достаточно уверенно, чтобы брать больше ответственности, но сперва будет стараться зарекомендовать себя как хорошего исполнителя. Качество кода, стабильность и исполнительность — основные навыки мидла для проверки на собеседовании.

Лайв-кодинг. Здесь стоит сконцентрироваться на решении задач, максимально приближенных к боевым. Стоит подбирать задачи, в которых можно протестировать углубленное понимание концепций языка, фреймворка и среды исполнения. Очень важно следить за ходом размышлений соискателя в процессе решения задач. Необходимо ставить перед кандидатом сложные проблемы, чтобы проверить навык подходить к решению задач творчески, а не шаблонно, побудить искать лучшие ответы, а не самые очевидные.

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

Senior-разработчик (сеньор)

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

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

System design interview. Полноценное собеседование на проверку навыка системного мышления и проектирования сложных автоматизированных систем. Можно предложить сеньору интересную и достаточно сложную проблему для решения, например: «как бы ты спроектировал риалтайм-приложение с бесконечным канвасом типа Miro или Figma?» Важно останавливаться на основных частях системы, углубляться в детали, предлагать в виде проблем не только технические челленджи, но и задачи конечных пользователей и даже вызовы со стороны бизнеса. Чтобы более подробно разобраться в system design interviews предлагаю ознакомиться с этой отличной статьёй.

Личное мнение про алгоритмические собеседования

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

Поделитесь, какие форматы проведения технических собеседований вы считаете самыми лучшими? А какие форматы считаете совершенно неподходящими?


Приглашаю вас подписаться на мой телеграм-канал: https://t.me/alexgriss, в котором я пишу о фронтенд-разработке, публикую полезные материалы, делюсь своим профессиональным мнением и рассматриваю темы, важные для карьеры разработчика.

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


  1. default_g00se
    27.12.2023 17:25

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


    1. AlexGriss Автор
      27.12.2023 17:25

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


  1. Nurked
    27.12.2023 17:25

    Александр, подобная статья требует такого же отвественного отношения как и ваша статья про HTML dialog. Вам надо серьёзно заняться качеством того, что вы написали. Больше подробностей и примеров.


  1. dalerank
    27.12.2023 17:25

    да что-же вы всё телеграм каналы рекламируете вместо написания технических статей, разве сложно подготовить материал для статьи, привести примеры, добавить ситуаций из практики? Из сотен собесов должно было что-то интересное запомниться. Извините, но судя по качеству статьи - по верхушкам и то немноШко, и в канале я увижу тоже самое. Вам бы хотелось читать канал, где все небольшое и уже сотню раз обсуждено? Крупнейший банк то хоть не зеленый?
    К нам в студию на собес в 2017 пришел както на должность программиста графики дядька лет под 50 с котом, кот был офигенный. Большой, спокойный и такой рыжий в белую полоску. Я всякое видел за собесы, но чтобы с котом - это было первый раз. Когда пришло время тестовых задачек, то кот забрался на стол рядом с клавой. На нескольких задачах кот клал лапу на руку хозяина и смотрел на него, знаете что делал человек? Он смотрел на кота, потом стирал решение и писал заново. Это все происходило в тишине, потому что мы сидели молча в недоумении и смотрели как они это делают вдвоем. А за окном переговорки уже начали собираться коллеги и кто-то фоткал как кодер и котер кодили код. Я не знаю, может он своему коту чатгпт подсадил в мозг, настолько это выглядело сюром. Дядька оказался суперский, жаль студия по деньгам его не потянула тогда.