Если вы сами никого не нанимали, то точно нанимали вас, наверняка кто-то встречал необычные подходы. Я говорю о тех случаях, когда не технарь нанимает технаря. Спрашивать о том, чего не знаешь сам, как минимум - выглядеть беспомощно, как максимум, уважающий себя разработчик может встать и уйти.
Что я уже слышал:
1) Всё что связано с портфолио, посмотреть работы, их количество и качество, спросить контакты предыдущего работодателя, таким образом можно проверить ответственность;
2) Привлечение в рамках консалтинга опытного специалиста;
3) Специализированные хантеры;
4) Подготовленные шаблоны с логическими задачами;
5) Обращать внимание на мелочи;
6) Выполнение тестовых заданий, непосредственно относящихся к вакансии.
Адекватность, мотивацию, черты характера и ценности частично понять можно, несмотря на то, что большинство программистов интроверты, но как быть с навыками техническими. Каким образом можно сэкономить себе время и деньги, отсеивая слабых кандидатов до испытательного срока самостоятельно?
Так разберитесь хотя бы на базовом уровне в той работе, на которую нанимаете, тогда и будет понятно о чем спрашивать!
Иначе следующим вашим вопросом, с который вы будете ко всем приставать - будет :
Как контролировать качество работы специалиста, если я не понимаю что и для чего он делает? :)
Глупости. В чем он должен разобраться, чтобы проверить? За какой срок? За 5 лет? Как у вас все просто. В айти и так проблема с тем, что недостаточно квалифицированные разработчики, которые оказываются на ведущих должностях в небольших компаниях, не способны проверить реальный уровень квалификации кандидатов, а вы говорите человеку без технического бэкграунда, чтобы он сам разобрался, будто там делов на два дня с перерывами на нетфликс. Вы даже не знаете что за проект, сколько областей он охватывает. Я прям вижу как не технарь проверяет, умею ли я в архитектуру, понимаю ли как организовать работу транзакций в распределенных системах, правильно ли проектирую базу данных и миллион других вещей.
Ну почему сразу глупости, если речь идет о создании MVP, то в нем качество, как правило, отходит на 2й-3й план, а в основах разработки можно (и нужно) разобраться.
В последнем предложении автор спрашивает, как отсеивать слабых кандидатов. Полагаю, смысл найма хорошего программиста в том, чтобы потом не проходить этот путь с нуля, увольняя первого. Даже программисты с большим опытом в айти компаниях не всегда могут отличить сильного кандидата от слабого на собеседовании, подвешенный язык способен на многое, поэтому я просто не верю что человек без большого опыта в разработке сможет отличить сильного кандидата от слабого, то что он потратит время на поверхностное ознакомление с областью это, безусловно, полезно в целом, не бесполезно для цели отсеивать слабых кандидатов.
В контексте предыдущего поста автора, где он спрашивает насчет программиста за долю в проекте, есть предположение, что он сам толком не знает, чего хочет, ну т.е. знает чего хочет, но не понимает, каким путем этого быстрее/правильнее достичь
Полагаю, смысл найма хорошего программиста в том, чтобы потом не проходить этот путь с нуля, увольняя первого.Возможно, для MVP правильнее взять любого программиста, который сможет его хоть как-то реализовать, а если в дальнейшем гипотезы (спроса и другие) подтвердятся, то уже переделать все по новому, с привлечением грамотных и высокооплачиваемых кадров.
Я отвечал на вопрос "как отличить сильного разработчика от слабого не технарю", так сказать в отрыве от контекста. Нужен ли стартаперу этот сильный разработчик для мвп? В большинстве случаев нет, поэтому полностью согласен со сказанным
взять любого программиста, который сможет его хоть как-то реализовать, а если в дальнейшем гипотезы (спроса и другие) подтвердятся, то уже переделать все по новому, с привлечением грамотных и высокооплачиваемых кадровНу ок. Пусть автор тогда и не пытается ни в чем разобраться сам, т.к. по вашему для него это невозможно в принципе, и нанимает себе непонятно кого и платит ему непонятно за что.