Несколько моментов, которые вроде еще не упоминали:
Джун интересен не тем что он делает (немного),а тем что он быстро растет и его можно переучить под себя (если не сбежит через год). Свежего выпускника переучивать проще, чем 40+
По факту вы целитесь в позицию мидла (может самостоятельно закрывать тикеты) , со знанием определенных последних технологий, но без опыта работы. Значит, надо либо получить опыт работы, либо найти компанию который нужен специалист с базовыми, но готовыми знаниями по этим технологиям.
Дважды нанимал разработчиков перешедших в IT из другой области. Правда уже не на джунов. Общая вменяемость + знание технологии на которую у меня на тот момент специалистов не было. Знания оба приобрели сами на индивидуальных или полу-индивидуальных (один программист в непрограммистской компании) проектах.
Естественным образом вы конкурируете со свежми выпускниками профильных вузов. Чтобы их обойти в поисках первой работы надо либо выбирать не самые популярные технологии (cobol ;) ну или хотя бы aws) или области где опыт работы, общения с клиентами, ответственность и вменяемость важнее быстрого роста. программист в непрограммистской компании, QA automation, CM.... Выбирать стек технологий которые изучают в университетском курсе рисково.
Отсутсвие профильного образования + опыта работы = резюме почти автоматически не рассматривается (разве что совсем кандидатов нет). После того как получили знания, надо искать рекомендации. Проще всего кто-то работающий в этой компании. Если нет, то просить рекомендовать преподавателей курсов, ходить на митапы и общаться, пытаться что-то сделать из услышанного, показывать и обсуждать...
По описанию проблемы разработчик обладает достаточной квалификацией, но на проекте откровенно заскучал. Проектные задачи неинтересны, пытается сам найти что-то для себя — способ реализации, инфраструктурные задачи, обсуждения других проектов…
Если хочется сохранить (высокая квалификация, много полезного сделал раньше..), надо обсуждать какие задачи ему были бы интересны и попытаться перевести в другую команду. Ну или искать замену.
Да нет там схватки хищников. И торговли тоже почти нет. С точки зрения нанимающего менеджера, процесс найма это система последовательных фильтров. Резюме-телефонное интервью-техническое интервью-разговор за жизнь-оффер. Причем, прямо в процессе можно(приходится) настраивать сложность и процент переходящих на следующий этап. Если в конце остаются два хороших кандидата из которых надо выбрать, то это счастье. Но обычно хорошего кандидата прошедшего все фильтры надо хватать сразу и не тянуть.
С точки зрения кандидата, такая же воронка — вакансия- интересен ли проект — поговорил с начальником- посмотрел офис — оффер.
Классическое собеседование процесс не совсем естестевнный, но наверное оптимальный по соотношению затрат времени к результату. Уволить/уйти можно и потом, но это будет сложнее и дороже.
Работал (менеджером) в комании где в собеседования не верили и нанимали в основном по результатам тестового задания + двухнедельной стажировки. Соответсвенно был нефиговый отсев после стажировки. Мне казалось что это отсеивает многих хороших кандидатов, а часть отсеянных после стажировки можно было бы поймать еще на собеседовании. Но костяк программистов там был действительно сильный.
В другой компании пробовали вместо классического собеседования давать задачу и рабочее место на день. Сложнее в организации и тоже не очень показательно.
В описанном экстремальном варианте должен получаться весьма грязный код с кучей мертвых веток. Причем, нетривиально понять какая из веток реально уже не нужна.
В менее экстремальном варианте встречается почти на всех больших проектах. Большие изменения первый раз релизятся под feature flag, в следующий релиз этот flag обращают. — новая ветка становится основной. А потом (когда-нибудь и если) вычищают старый код.
Когда-то ( в очередной раз) обсуждая результаты интервью поняли что лучше всего отвечают на наши вопросы либо вчерашние хорошие студенты, либо(еще лучше) их преподаватели. При этом ни те ни другие из-за отсутствия опыта реальных проектов не являются идеальными кандидатами.
Здесь по-моему очень похожая ситуация. Правильные теоретические вопросы о которых редко задумываются в реальных проектах. Если стоит задача нанять внутреннего эксперта по Go, то вопросы правильные. Но тогда надо искать среди спикеров конференций и других увлеченных теоретической информатикой людей. Если кандидату предстоит вести реальные проекты, то лучше проводить case-интервью. А как вы решали такую проблему, а чем лучше/хуже было бы сделать так… На примере предыдущих проектов кандидата, либо на реальных задачах из своей компании. Получается достаточно показательно.
Несколько моментов, которые вроде еще не упоминали:
Джун интересен не тем что он делает (немного),а тем что он быстро растет и его можно переучить под себя (если не сбежит через год). Свежего выпускника переучивать проще, чем 40+
По факту вы целитесь в позицию мидла (может самостоятельно закрывать тикеты) , со знанием определенных последних технологий, но без опыта работы. Значит, надо либо получить опыт работы, либо найти компанию который нужен специалист с базовыми, но готовыми знаниями по этим технологиям.
Дважды нанимал разработчиков перешедших в IT из другой области. Правда уже не на джунов. Общая вменяемость + знание технологии на которую у меня на тот момент специалистов не было. Знания оба приобрели сами на индивидуальных или полу-индивидуальных (один программист в непрограммистской компании) проектах.
Естественным образом вы конкурируете со свежми выпускниками профильных вузов. Чтобы их обойти в поисках первой работы надо либо выбирать не самые популярные технологии (cobol ;) ну или хотя бы aws) или области где опыт работы, общения с клиентами, ответственность и вменяемость важнее быстрого роста. программист в непрограммистской компании, QA automation, CM.... Выбирать стек технологий которые изучают в университетском курсе рисково.
Отсутсвие профильного образования + опыта работы = резюме почти автоматически не рассматривается (разве что совсем кандидатов нет). После того как получили знания, надо искать рекомендации. Проще всего кто-то работающий в этой компании. Если нет, то просить рекомендовать преподавателей курсов, ходить на митапы и общаться, пытаться что-то сделать из услышанного, показывать и обсуждать...
Трюки симпатичные, но наверное стоит указать что есть стандартные реализации этого подхода (long double, double-double, float128 в зависимости от реализации) https://en.m.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic
Если хочется сохранить (высокая квалификация, много полезного сделал раньше..), надо обсуждать какие задачи ему были бы интересны и попытаться перевести в другую команду. Ну или искать замену.
С точки зрения кандидата, такая же воронка — вакансия- интересен ли проект — поговорил с начальником- посмотрел офис — оффер.
Классическое собеседование процесс не совсем естестевнный, но наверное оптимальный по соотношению затрат времени к результату. Уволить/уйти можно и потом, но это будет сложнее и дороже.
Работал (менеджером) в комании где в собеседования не верили и нанимали в основном по результатам тестового задания + двухнедельной стажировки. Соответсвенно был нефиговый отсев после стажировки. Мне казалось что это отсеивает многих хороших кандидатов, а часть отсеянных после стажировки можно было бы поймать еще на собеседовании. Но костяк программистов там был действительно сильный.
В другой компании пробовали вместо классического собеседования давать задачу и рабочее место на день. Сложнее в организации и тоже не очень показательно.
В менее экстремальном варианте встречается почти на всех больших проектах. Большие изменения первый раз релизятся под feature flag, в следующий релиз этот flag обращают. — новая ветка становится основной. А потом (когда-нибудь и если) вычищают старый код.
Здесь по-моему очень похожая ситуация. Правильные теоретические вопросы о которых редко задумываются в реальных проектах. Если стоит задача нанять внутреннего эксперта по Go, то вопросы правильные. Но тогда надо искать среди спикеров конференций и других увлеченных теоретической информатикой людей. Если кандидату предстоит вести реальные проекты, то лучше проводить case-интервью. А как вы решали такую проблему, а чем лучше/хуже было бы сделать так… На примере предыдущих проектов кандидата, либо на реальных задачах из своей компании. Получается достаточно показательно.