По примерным прикидкам за 10+ лет работы в Miro провел порядка 500 интервью. Настало время поделиться сакральным опытом «как за час проверить, что чел шарит, и при этом не превратить интервью в душный допрос». Все написанное ниже является персональным мнением и никак не отражает существующий процесс собеседования в Миро. Никаких гипотетических или абстрактных вопросов типа:— что бы ты сделал, если бы…— как выглядит идеальный…— назови 5 лучших качеств команды— и прочие «кем ты себя видишь через 5 лет» Единственное, что мы отсюда узнаем насколько реалистичные ответы чел умеет генерировать на ходу. ЧатГПТ так тоже может. Есть только один способ достоверно проверить, что кандидат может делать — спросить что и как он уже делал. Поэтому большую часть интервью отстраиваем от копания в прошлом опыте.  Варианты вступления.— в двух словах расскажи про свой самый интересный (самый сложный) проект? В чем суть проекта? Размер команды? Твоя роль? Твой основной вклад? Срок проекта? И т.д… За 3 минуты узнаем общий контекст, а потом проваливаемся в детали, цепляясь за шероховатости. Люди охотно делятся историями про проекты, которыми они гордятся больше всего. Можно сразу понять синьорность кандидата по структурированности ответа и как он определяет проблему. Джуниор:  — Мы переехали с кастомного велосипеда на реакт — Зачем?— Реакт популярный / на нем легче писать / он работает быстрее Мидл: — Наш кастомный велосипед жутко тормозил  и не поддерживал типизацию из-за чего мы тратили кучу времени на фикс багов. В итоге мы решили переехать на реакт. Приложение стало загружаться быстрее и количество багов уменьшилось. Синьор: — Чтобы улучшить тайм ту маркет… бла бла бла 😉 Убеждаемся, что кандидат четко понимает какую задачу он решал, знает в каких попугаях меряли успех. Чем четче в терминах бизнеса сформулирована проблема, тем лучше. Ред флаг, если кандидат выдает кашу вместо постановки. Спрашиваем, что пошло не так и что бы сейчас сделал иначе. Саморефлексия — полезный навык. Кандидат должен все помнить, даже если проект был 5 лет назад. В конце концов мы именно потому спрашиваем про «самый-самый» проект. А если не помнит детали — значит не было самоотдачи или «я просто исполнял приказ». Тут в любом случае глубины нет — для нас ред флаг. Если чел шарит — это сразу чувствуется и беседа получается живой. Особенно классно, если ты не разбираешься в доменной области или использованных технологиях — можно узнать что-то новое. Потому что классный кандидат способен быстро и доступно объяснить суть тому, кто не шарит. Промежуточное итого:— Спрашиваем про прошлое, а не будущее— Копаем вглубь, а не вширь Допустим, на предыдущем этапе все понравилось: — Релевантный опыт есть;— Здравый смысл присутствует;— Мысли излагаются внятно;— А главное, мы поняли грейд кандидата и на какую роль он лучше подойдет; В теории, уже на основе того, как кандидат рассказал про свой опыт, собес можно закруглять. Но, к сожалению, встречаются ребята с подвешенным языком и никудышными техническими скилами. Потому надо проверить, что человек умеет работать свою работу качественно и быстро. И тут программисты дружно договорились устраивать друг другу на собесах кромешный ад, дабы потешить свое ЧСВ максимально дорогим для компании образом. Для этого в бой идут:— Абстрактные алгоритмические задачи, когда мы ищем чела, который должен быстро формочки на реакте клепать;— Проектирование высоконагруженных систем, которых у вас нет;— Многоступенчатый отбор из часового лайвкодинга, потом часового системного дизайна с двумя-тремя интервьюерами на каждом этапе для рядовой позиции мидла или джуна;— И прочие способы сжечь бабло, так и не выяснив умеет ли кандидат работать работу; Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут. Если нанимаем обычного фронтендера, то и просим обычную форму заверстать. Потом валидацию и аксесабилити прикрутить. Смотрим насколько реюзабельно все спроектировано.  И, если кандидат ее сделает, задать пару вопросов в глубину про понимание инструмента (языка, фреймворка). Потому что без глубины нет смысла ожидать скорости или качества. Любая проблема заставит буксовать на месте часами. А если чел шарит, то это сразу видно, и 15 минут на проверку техники более чем достаточно. А если не шарит, то и 2 часа не нужны. В итоге получаем следующую структуру интервью:— 10 минут на интро о себе и продажу команды;— 30 минут общаемся про опыт кандидата;— 15 минут про технику;— 5 минут на вопросы кандидата, или дольше, если кандидат интересный; Осталось рассмотреть, как сравнивать кандидатов между собой.  Сразу оговорюсь, что я не заполняю реальное саммари в указанных ниже попугаях. Но, если разбирать на основе чего формируется саммари, то я оцениваю кандидатов по трем основным навыкам.  Харды и наличие релевантного опыта (хорошо, если человек повидал некоторого дерьма).  Коммуникация. Умение общаться, быстро и структурировано объяснить суть вопроса. Проактивность в обучении и страсть к делу. За каждый навык даем до трех баллов:0 — все плохо1 — с пивом покатит 2 — хорошо 3 — прекрасно  Есть хоть один ноль – сразу до свидания.  Если везде единицы, кандидат слаб по всем фронтам — тоже не интересно. (Отталкиваемся от того, что каждый следующий игрок должен усилять, а не разбавлять команду) А дальше, в зависимости от пропорций, можно решать, какая роль человеку подходит больше всего. Харды: 2Коммуникация: 1-2Обучаемость: 1-2Рядовой разработчик, который может просто работать работу. Берем. Харды: 1-2Коммуникация: 1Обучаемость: 3Идеальный джун. Берем, если готовы вкладывать. Харды: 1Коммуникация: 3Обучаемость: 1-2Менеджер, берем. Харды: 3Коммуникация: 2-3Обучаемость: 1-2Техлид. Берем. При этом следовать любой формальной системе в слепую при работе с людьми не лучший выбор. Формально чел может набрать много баллов, но так же несколько плохо формализируемых тревожных звоночков. В таком случае лучше довериться гатфилингу и сказать нет, чем рисковать с наймом. Или попросить кого-то еще провести доп. интервью, чтобы убедиться, что не показалось. Мы же не безликий станок нанимаем, а живого человека, с которым каждый день взаимодействовать будем.  Справедливости ради, описанный подход годится для тех, кто проводит интервью регулярно, нужна набитая рука, чтобы принимать решение на ходу. Если интервьюить раз в месяц — будет сложно откалиброваться, и тогда лучше позвать больше людей на интервью или сделать больше этапов, чтобы собрать больше мнений. Дороже, но тоже работает. Разумеется, невозможно написать статью на хабр, не оставив ссылку на свой тг-канал.           Подписывайтесь, я там нерегулярно выгружаю разный бред из головы — очень интересно 😅