Сообщение администратору
Имя:
Почта:
Сообщение:
Вход на сайт
Логин:
Пароль:

Поддержка  •  Дневник  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate  •  Рекомендованное  •  Написать администратору Гости: 24    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
RSS-лента
Поделиться ссылкой:
Каталог


Начало » Общество, люди » Недушные интервью разработчиков

Недушные интервью разработчиков


Добавлено: Сб 10.08.2024 • Sergeant
Автор: Олег Плотников
Источник: источник
Просмотров: 31
Комментарии: 0


По примерным прикидкам за 10+ лет работы в Miro провел порядка 500 интервью. Настало время поделиться сакральным опытом «как за час проверить, что чел шарит, и при этом не превратить интервью в душный допрос».

Все написанное ниже является персональным мнением и никак не отражает существующий процесс собеседования в Миро.

Копаем вглубь

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

Единственное, что мы отсюда узнаем насколько реалистичные ответы чел умеет генерировать на ходу. ЧатГПТ так тоже может.

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

Варианты вступления.
в двух словах расскажи про свой самый интересный (самый сложный) проект? В чем суть проекта? Размер команды? Твоя роль? Твой основной вклад? Срок проекта? И т. д…

За 3 минуты узнаем общий контекст, а потом проваливаемся в детали, цепляясь за шероховатости.

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

Джуниор:

Мы переехали с кастомного велосипеда на реакт.
Зачем?
Реакт популярный / на нем легче писать / он работает быстрее.

Мидл:

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

Синьор:

Чтобы улучшить тайм ту маркет… бла бла бла 😉

Убеждаемся, что кандидат четко понимает какую задачу он решал, знает в каких попугаях меряли успех. Чем четче в терминах бизнеса сформулирована проблема, тем лучше. Ред флаг, если кандидат выдает кашу вместо постановки.

Спрашиваем, что пошло не так и что бы сейчас сделал иначе. Саморефлексия — полезный навык.

Кандидат должен все помнить, даже если проект был 5 лет назад. В конце концов мы именно потому спрашиваем про «самый-самый» проект.

А если не помнит детали — значит не было самоотдачи или «я просто исполнял приказ». Тут в любом случае глубины нет — для нас ред флаг.

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

Промежуточное итого:
— Спрашиваем про прошлое, а не будущее.
— Копаем вглубь, а не вширь.

Чекаем харды за 15 минут

Допустим, на предыдущем этапе все понравилось:
— Релевантный опыт есть;
— Здравый смысл присутствует;
— Мысли излагаются внятно;
— А главное, мы поняли грейд кандидата и на какую роль он лучше подойдет;

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

Потому надо проверить, что человек умеет работать свою работу качественно и быстро.

И тут программисты дружно договорились устраивать друг другу на собесах кромешный ад, дабы потешить свое ЧСВ максимально дорогим для компании образом.

Для этого в бой идут:
— Абстрактные алгоритмические задачи, когда мы ищем чела, который должен быстро формочки на реакте клепать;
— Проектирование высоконагруженных систем, которых у вас нет;
— Многоступенчатый отбор из часового лайвкодинга, потом часового системного дизайна с двумя-тремя интервьюерами на каждом этапе для рядовой позиции мидла или джуна;
— И прочие способы сжечь бабло, так и не выяснив умеет ли кандидат работать работу;

Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут.

Если нанимаем обычного фронтендера, то и просим обычную форму заверстать. Потом валидацию и аксесабилити прикрутить. Смотрим насколько реюзабельно все спроектировано.

И, если кандидат ее сделает, задать пару вопросов в глубину про понимание инструмента (языка, фреймворка). Потому что без глубины нет смысла ожидать скорости или качества. Любая проблема заставит буксовать на месте часами.

А если чел шарит, то это сразу видно, и 15 минут на проверку техники более чем достаточно. А если не шарит, то и 2 часа не нужны.

В каких попугаях оценивать

В итоге получаем следующую структуру интервью:
— 10 минут на интро о себе и продажу команды;
— 30 минут общаемся про опыт кандидата;
— 15 минут про технику;
— 5 минут на вопросы кандидата, или дольше, если кандидат интересный;

Осталось рассмотреть, как сравнивать кандидатов между собой.

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

1. Харды и наличие релевантного опыта (хорошо, если человек повидал некоторого дерьма).

2. Коммуникация. Умение общаться, быстро и структурировано объяснить суть вопроса.

3. Проактивность в обучении и страсть к делу.

За каждый навык даем до трех баллов:
0 — все плохо
1 — с пивом покатит
2 — хорошо
3 — прекрасно

Есть хоть один ноль – сразу до свидания.

Если везде единицы, кандидат слаб по всем фронтам — тоже не интересно. (Отталкиваемся от того, что каждый следующий игрок должен усилять, а не разбавлять команду)

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

Харды: 2
Коммуникация: 1-2
Обучаемость: 1-2
Рядовой разработчик, который может просто работать работу. Берем.

Харды: 1-2
Коммуникация: 1
Обучаемость: 3
Идеальный джун. Берем, если готовы вкладывать.

Харды: 1
Коммуникация: 3
Обучаемость: 1-2
Менеджер, берем.

Харды: 3
Коммуникация: 2-3
Обучаемость: 1-2
Техлид. Берем.

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

В таком случае лучше довериться гатфилингу и сказать нет, чем рисковать с наймом. Или попросить кого-то еще провести доп. интервью, чтобы убедиться, что не показалось. Мы же не безликий станок нанимаем, а живого человека, с которым каждый день взаимодействовать будем.

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

Схема найма



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
Разработано на основе BlackNight CMS
Release v.2024-09-19
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка
МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контентРекомендованное