Пособеседуем...

Добавил немного «желтого-Alizar-style» в заголовок.

С подачи Макса Ищенко, термин «сеньор» может вскорости обрести новое семантическое значение и стать широко известным в узких круга, а также занять достойное место среди таких нарицательных как КотЭ, Капитан Очевидность, Мопед, Гном и пр. И будет он означать не что иное, как «сеньор 80 уровня в 23 года».

Но пост не об этом. Ниже я бы хотел поделиться с уважаемыми читателями ДОУ личным опытом проведения собеседований.

Фото: Shutterstock

За свою карьеру я успел поработать в трёх городах (Донецк, Харьков, Киев) и в различных компаниях: бухгалтерское ПО, торговые и финансовые инструменты, игрострой, аутсорс, авиа-симуляторы, промышленное 3D. Много раз интервьюировал и был интервьюируемым, видел много схем и различных подходов. И на текущий момент всё это «синергетировалось» и «выпало в сухой остаток» в форме следующего алгоритма работы с соискателями ( С ).

Первый этап — очное или заочное общение

«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень».

Оценка:

1. Объем (строки, количество файлов)
2. Структурная организация (папки, файлы, именование)
3. Комментарии кода.
4. Соглашения по именованию.

Что позволяет узнать/оценить:

1. Подходы С в части командного взаимодействии — погружение «стороннего» человека (интервьюера) в свой программный код.
2. «Стиль» программирования.
3. Используемые технологии/фреймворки/библиотеки/велосипеды.

Второй этап — очное общение

Оценка:

1. Слаженность в движении мысли, последовательность изложения.
2. Умение слушать и слышать собеседника/оппонента.

Что позволяет узнать/оценить:

1. Уровень владения UML, количество типов диаграмм в арсенале С.
2. Владение паттернами проектирования.
3. Способность перемещаться по архитектуре вниз-вверх, вправо-влево, вперёд-назад, переход от общего к частному и наоборот.
4. Реакцию С критику со стороны и как следствие стадию «звёздной болезни».

В процессе обсуждения заостряю внимание на технических деталях и прощупываю базу: «А почему здесь наследование, а не композиция?», «Здесь не появится срезка?», «Почему не использовали boost::bind?» и пр.

Плюсы:

1. Мы разговариваем о том, что соискатель знает, а не о том что он не знает. Пусть 1 — универсум, который, Вы хотите проверить q — это то, что С знает, n — то что, не знает. Как следствие q + n = 1. Я всегда предпочитаю общаться на тему q.
2. Разговор идёт «естественным» путём, который подходит обоим участникам.
3. «Симулятор/Эмулятор» командной работы.
4. Возможность в любой момент поставить логическую точку в собеседовании, без необходимости выполнения «30 тестов за 1 час».

Минусы:

1. Недостаточный уровень формализма. Для большИх компаний количество бумажных артефактов должно быть больше и они должны быть структурированы, так как они могут/будут использоваться для повторного интервьюирования и/или как входные данные для эвалюэйшенов.
2. Данный подход трудно (но можно) адаптировать для интервьюирования Junior/Middle разработчиков, для которых важным критерием оценки являются всё-таки именно «энциклопедические знания».

Время:

USP:

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU