Комментарии 20
Интересный подход, лайк. Единственное что немного смутило — учебные проекты поставили рядом с пет-проджектами (да еще и в категорию «джунов») — комон, можно иметь пет-проджект, который представляет собой обособленное решение конкретных потребностей, на скромных 100k+LoC в открытом доступе, и который не перерос статус пет-проджекта чисто потому, что лень заниматься его монетизацией:) Да и в принципе пункт 2 немного спорный, как по мне.
Вообще для любого сеньора и даже миддла наличие пет-проджекта — это плюс, т.к. именно там он может опробовать какие-то вещи, которые непозволительны для рабочего проекта. А вот если ни одного пет-проджекта нет — это тема для разговора. Почему нет, что мешает? Может времени не хватает, может потребности нет, может интереса мало, причин может быть крайне много и крайне разных, и это всё интересная информация о кандидате.
Вообще для любого сеньора и даже миддла наличие пет-проджекта — это плюс, т.к. именно там он может опробовать какие-то вещи, которые непозволительны для рабочего проекта. А вот если ни одного пет-проджекта нет — это тема для разговора. Почему нет, что мешает? Может времени не хватает, может потребности нет, может интереса мало, причин может быть крайне много и крайне разных, и это всё интересная информация о кандидате.
heilage полностью согласен. Скорее всего я немного поспешил и не уточнил что у мидла и сеньера тоже надо спрашивать про пет проджекты. По себе знаю что они очень хорошо прокачивают.
Я согласен с вами, надо было отделить учебные проекты для джуна от пет проджектов для остальных.
Я согласен с вами, надо было отделить учебные проекты для джуна от пет проджектов для остальных.
А вот если ни одного пет-проджекта нет — это тема для разговора. Почему нет, что мешает?
«Вот представь, приходишь домой, а там станки, станки, станки...»
Почему вы считаете, что хобби (а пет-проект — это хобби) — это релевантная информация о кандидате?
Как минимум это дает понять отношение человека к профессии. Ну и опять же, это не решающий фактор — но прекрасная тема для разговора по душам.
Ну по душам можно говорить о чем угодно, не очень понятно какое отношение это имеет к работе. И, опять же, я не вижу, почему хобби и профессия должны быть смешаны. Представьте себе, как у хирурга спрашивают, режет ли он своих родственников на дому и почему нет.
Я бы ушел в этом вопросе от понятия хобби к понятию увлеченность. В случае с хирургом увлеченность = желание лечить людей, помогать. Отлично, если это желание совпало с умением и платой за труд.
Увлечённость — палка о двух концах.
Если у человека главная мотивация — это интерес, то он будет показывать хороший результат только в том, что ему интересно. Такому начнёшь давать реальные задачи реального бизнеса — он через месяц перегорит.
Или, например, человек потащит в продакшн какую-нибудь модную технологию не потому, что она тут реально к месту, а потому что было интересно с ней поработать.
Если у человека главная мотивация — это интерес, то он будет показывать хороший результат только в том, что ему интересно. Такому начнёшь давать реальные задачи реального бизнеса — он через месяц перегорит.
Или, например, человек потащит в продакшн какую-нибудь модную технологию не потому, что она тут реально к месту, а потому что было интересно с ней поработать.
Часто разработчики делают пет-проджекты для изучения какой-нибудь новой технологии/библиотеки/подхода/etc. По крайней мере во фронтенде часто так. Как в других направлениях — хз :))
Но я согласен, не стоит забирать «баллы» за отсутствие домашнего проекта.
Но я согласен, не стоит забирать «баллы» за отсутствие домашнего проекта.
Подход «код ревью» действительно может много сказать о кандидате. Сам пользуюсь этим методом как одним из этапов в собеседовании. Единственная проблема — это придумать сам код, который нужно будет посмотреть. Очень трудно сделать его одновременно и лаконичный, и насыщенным проблемами.
Я теперь тоже буду его использовать, так как только вчера мне подкинули эту идею. А вот по поводу того, что трудно придумать одновременно лаконичный и насыщенный проблемами, я согласен. Я думаю, начну давать код из своих пет проджектов или из боевых задач. Хотя бы просто посмотреть на ход размышлений.
Из вступления к статье хорошо виден уровень большинства современных «тимлидов». Не умея проводить собеседования, собирают команду, задавая вопросы «как собеседовать». Пока человек не умеет собеседовать, эти пункты очень мало что ему могут дать, тк он не знает, на что обращать внимание.
Вот с этим вопросом ко мне и обратились. Новоиспеченный тимлид боялся взять на работу «не того» и наоборот, отшить «хорошего». Я решил дать пару советов на что именно я смотрел при собесе и с чем сталкивался как рядовой кодер. Главный поинт был в том, что надо уделять внимание софт скиллам. Так как я очень часто вижу что люди собеседуют чисто по задачкам из головы, которые явно оторваны от реальной жизни.
А как же улучшение своих софтскиллс практикой трудного общения?
Второй пункт — это вообще полный треш наряду с вопросами про самую сложную задачу или про то, чем ты можешь гордиться.
Даже если не принимать во внимание интравертность многих кандидатов, такие вопросы вообще ни о чем не говорят и часто дают ложное впечатление, потому, что кто-то будет говорить, что проектировал высоконагруженную систему реального времени и прочее, хотя, на самом деле был туда вовлечен как наблюдатель, а другой скажет, что ничего сильно сложного не делал и не скажет, например, про какую-то сложную опенсорс либу, которую сам сделал у которой сотни тысяч скачиваний в неделю или прочие задачи, которые тому же интервьюеру будут не по зубам еще долгое время. Почему не скажет, да потому, что ему оно не показалось сложным или выдающимся. Про NDA я вообще молчу.
И правильно, наверное, все же, когда человек просто делает работу и любая сложная задача — это просто задача, а не подвиг.
И как рассказать про «прошлый опыт» синьору, у которого уже куча лет и проектов за плечами, там, если даже поверхностно про все рассказывать — никакого таймбокса не хватит, а что важно для новой позиции обычно вообще непонятно. Вот кандидат рассказал о каком-то интересном опыте, но он оказался не очень интересным в данном проекте, хотя интересующий их опыт у него тоже есть, просто про него неинтересно рассказывать.
Как по мне — самое важное — понять, насколько хорошо кандидат умеет решать поставленные задачи, с гуглом, подсказками, чем угодно и как он умеет схватывать/учиться.
Я сейчас написал, конечно же, только про позиции dev/qa/devops/…
Даже если не принимать во внимание интравертность многих кандидатов, такие вопросы вообще ни о чем не говорят и часто дают ложное впечатление, потому, что кто-то будет говорить, что проектировал высоконагруженную систему реального времени и прочее, хотя, на самом деле был туда вовлечен как наблюдатель, а другой скажет, что ничего сильно сложного не делал и не скажет, например, про какую-то сложную опенсорс либу, которую сам сделал у которой сотни тысяч скачиваний в неделю или прочие задачи, которые тому же интервьюеру будут не по зубам еще долгое время. Почему не скажет, да потому, что ему оно не показалось сложным или выдающимся. Про NDA я вообще молчу.
И правильно, наверное, все же, когда человек просто делает работу и любая сложная задача — это просто задача, а не подвиг.
И как рассказать про «прошлый опыт» синьору, у которого уже куча лет и проектов за плечами, там, если даже поверхностно про все рассказывать — никакого таймбокса не хватит, а что важно для новой позиции обычно вообще непонятно. Вот кандидат рассказал о каком-то интересном опыте, но он оказался не очень интересным в данном проекте, хотя интересующий их опыт у него тоже есть, просто про него неинтересно рассказывать.
Как по мне — самое важное — понять, насколько хорошо кандидат умеет решать поставленные задачи, с гуглом, подсказками, чем угодно и как он умеет схватывать/учиться.
Я сейчас написал, конечно же, только про позиции dev/qa/devops/…
Как по мне — самое важное — понять, насколько хорошо кандидат умеет решать поставленные задачи, с гуглом, подсказками, чем угодно и как он умеет схватывать/учиться.
Какие методы это понять вы предлагаете?
Да методов много — как вариант — просто задачки по тем областям, которые нужны на позиции и по которым кандидат считает себя специалистом. Любые задачки — можно дать ноутбук со средой разработки и интернетом и поставить задачу, можно на листике и даже псевдокодом, можно вместе с интервьюерами, можно без — как будет всем удобно. Ну и дальше можно комментировать и разбирать решение, если необходимо.
Или спросить, как бы он решал какую-то задачу (нужно заранее продумать, какую) и по общению, обычно, становится все довольно понятно. Еще понятно становится, что человек знает/не знает, а на что не то отвечает по причине того, что стрессовая ситуация.
Или спросить, как бы он решал какую-то задачу (нужно заранее продумать, какую) и по общению, обычно, становится все довольно понятно. Еще понятно становится, что человек знает/не знает, а на что не то отвечает по причине того, что стрессовая ситуация.
Так а кто-нить пробывал подсунуть кандидату его же код?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проводить собеседования разработчиков