Как мы собеседуем программистов

В основном мы нанимаем разработчиков на rails которые либо уже фулстек либо с потенциалом на фулстек. Но есть важная особенность. Я никогда не был сторонником брать людей, которые работали именно на том стеке, который мне нужен. Установка была всегда нанимать хороших ребят с любых смежных стеков. Например на нашу позицию отлично подходят те кто работали с бекенд фреймворками типа laravel, django, spring boot и другими, но не микрофреймворками. Наши самые успешные кейсы и ребята как раз были такими свитчерами. Эта особенность сильно влияет на само собеседование. Оно делится на три основные части.

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

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

Вторая часть техническая. Как правило все собеседование длится один час и строится вокруг одного рабочего кейса, который предлагается решить. Кейс подобран таким образом, чтобы его можно было бесконечно развивать в разные направления в зависимости от того что человек ответит. Причем сам кейс никак не связан с технологией, он плюс минус одинаково делается на любом бекендовом фреймворке. Чаще всего я спрашиваю такое: “у хекслета есть аккаунт в страйпе, который шлет чеки людям на почту, после оплаты. Почта передается в страйп при первой оплате, при повторных платежах (в случае подписки) страйп использует эту почту. На Хекслете внедрили смену емейла и получилась ситуация, когда емейл в страйпе старый и человек может не получить чек. Как бы реализовали логику обновления емейла в страйпе при изменении емейла на хекслете”. Само решение этой задачи очень короткое, но по пути здесь всплывает очень много интересных моментов, показывающих реальное понимание вещей. На основе этого мы уже принимаем решение о найме.

p.s. Домашнее задание: напишите в комментарии как бы вы решили эту задачу в вашем стеке

2 минуты

30 ноября 2023