Комментарии 24
Я чуть из другой сферы собеседую, но тоже не прошу писать код на собесе, многих это вгоняет в стресс. Вопросы "а с этим работали, а про это слышали" - мало что показывают. Простой разговор про опыт, про трудности и поиск их решения - о многом говорит. Товарищ сможет где-то похвастаться, а где-то пожаловаться. Конечно же все вопросы про то, с чем придётся работать)
Из кода - на собесе даю какой-то кусок кода на листочке А4, прошу рассказать что код делает и что можно сделать по другому. Сразу видно как быстро может вникнуть в проект, на сколько внимательный и какими порядками мыслит. Этот приём позаимствовал с одного своего собеседования.
А если товарищ на столько качественно привирает что я не замечу - это будет видно на испыталке, но таких пока не встречал.
Как по мне, если разраб способен наврать так что его примут, то его скорее проще принять и научить требуемому. Потому что он явно понимает о чем говорит, хоть и врёт что применял на практике :)
Говорю так, потому что первый год работы именно так и действовал. На собесе наврал полностью. А потом на первом же задании тупил потому что тупо не мог понять как вообще у них устроена архитектура.
Но спустя месяц влился и работал в общем темпе, хотя по началу было 0 знаний
Очень субъективный текст. Сложно с чем-то спорить, не потому, что это неправильно. Оно правильное, но не понятно к чему претензии в итоге.
Например, тестовые задания. У людей, которые пашут по 10-14 часов времени писать ЕЩЁ те товары задания нет. А "типа интересные" вообще нет. Но с другой стороны, что-то нужно дать для проверки навыка программирования и анализа задания. Не слишком сложные, но довольно открытое, чтобы увидеть как думает кандидат. Поэтому даёшь "не интересное" задание. Если человек его решил, то как минимум есть тема для дискуссии и понятно что замотивирован.
Автору могу порекомендовать провести несколько собеседований (если не проводил). И потом послушать обратную связь от респондентов. У всех разные критерии, и разное представление о том, какое должно быть собеседование.
Для меня важно две вещи (при собеседовании джунов и миддлов): первое - как соображает кандидат, как он формулирует свои мысли, как он понимает меня (если мне с ним работать), как рассуждает о вещах, в которых он разбирается. Второе - это как пишет код, насколько быстро ориентируется в простейших конструкциях, насколько задумывается в написании циклов, условий, и тп - показывает, как много человек пишет код, насколько он освоил базу языка.
С синьорами другие критерии - там для меня важна глубина и структурированность знаний, особенно по базовым вопросам (асинхронность, архитектура, и тп), а также системность мышления и коммуникационные навыки - как человек выражает и доносит свои мысли, как объясняет сложные вещи, как рассуждает о вещах, с которыми не знаком (например, каким-то паттернам архитектуры, с которыми не работал непосредственно).
Не надо.
Ваш подход к оценке кандидата - слишком субъективен, а значит - несправедлив.
Попробуйте ДАТЬ обратную связь тем кандидатам которых вы собесили и послушать что они на это скажут
Но собеседование и не должно быть справедливым, и оно должно быть субъективным, особенно если вам предстоит работать с этим человеком. Не все друг другу подходят, и это не значит, что компания плохая или кандидат плохой.
Я даю обратную связь, только если кандидат просит, либо как мягкую форму отказа (вам нужно для этой позиции подучить тото и тото). Ну и никто ничего плохого мне никогда на обратную связь не отвечал. Человек как правило осознаёт свой уровень, и насколько хорошо он отвечал.
Мне пока сложно окончательно принять вашу первую мысль. Мы вроде как хотим объективные результаты (кандидаты одной позиции +- одинаковые по навыкам и взаимозаменяемые) с помощью субъективного алгоритма.
Скорее всего у человека, который провел несколько десятков собеседований уже чуйка на хороших и адекватных специалистов. И ничего страшного, если их знания будут разными, они наоборот в процессе работы усреднятся и подтянут друг друга. Значит, по идее, в процессе собеседования можно вполне обоснованно опираться на свои ощущения.
Но из-за субъективизма у нас появляются миддлы в одной компании, которые с натяжкой считались бы джуном в другой.
Интересный опыт) Жаль, не все могут ответить на вопрос про свежие фичи или хотя бы что вообще нравится в языке.
Когда-то я работала эйчаром и общалась с людьми из пункта как не надо, т.е. по-дружески. Собесы тогда ещё были в офисе: мы с кандидатами пили чай, болтали о жизни и попутно отвечали на вопросы друг друга.
По итогу я получала фидбэк, что приятно человеческое общение, а не отношение к кандидату как к ресурсу.
Это я к чему – все люди разные и хочу предостеречь начинающих рекрутеров от того, что существует единственно верный вариант.
Лайфкодинг фигня собачья
если автору это нравится, большему колличеству людей это только стресс
и кандидат неможет себя показать во всю сили
Лайфкодинг на обязательно подразумевает кодинг. Кандидат может затупить с кодом, но на пальцах объяснить что и как должно работать. Этого бывает достаточно. Это просто ещё один вопрос, ответ на который просто удобнее записать.
В тепличных условиях все код писать готовы. Только хз где есть такая работа без пожаров и прочего.
Особенно забавно, когда в резюме написано 'стрессоустойчивый', а на собеседовании человек чуть в обморок не падает от того, что его просят написать простой код.
Интересная мысль. А как кандидат может показать себя во всю силу? Чтоб и раскрыться и без стресса. Разве что заранее согласовать список вопросов...
Из личного опыта - код на интервью снимает много вопросов по уровню кандидата. Как человек пишет, на чём ошибается, как реагирует на замечания. Даже то, как приступает к работе.
По моему опыту, при собеседованиях на сениорские позиции код писать просят довольно редко. Хотя недавно вот писал :-) Но чаще происходит "беседа двух умных людей", когда по итогам понятно, что ты в теме, работал на таких-то проектах, решал такие-то проблемы.
Лайвкодинг разный бывает и соответственно результаты его прохождения меняются от негативного до полного принятия. Случаи, где тебе предоставляют код на ревью или дописать логику, бывают нечасто. Меня однажды попросили архитектуру приложения описать по заданию. В остальных случаях приходилось код писать с нуля. И вот была загвоздка. Кто-то придирался к каждой мелочи, кто-то требовал получить правильный результат решения задачи, не глядя на процесс, а кто-то требовал реализовать паттерны. Плюс зависит от кандидата. Бывает что человек из-за волнения не может выдать сразу результат. Поэтому это совместное программирование - не панацея.
Собеседований так много, потому что я хотел точнее узнать свою цену.
Скажите пожалуйста, сработала ли тактика? Получили максимальный оффер по своему уровню?
Сработала. Я получил интервал зарплат, которые мне готовы платить. В итоге пошел не на максимальный оффер, а чуть меньше - там проект интереснее.
В итоге пошел не на максимальный оффер, а чуть меньше - там проект интереснее.
Простите, не верю таким обьяснениям. Объясню - почему. Проект интереснее? Может быть. Но всяк проект имеет тенденцию быть законченный, если конечно это не agile-проект (#полушутка). Поэтому это или боязнь чего либо или ещё симптом невзросления или нежелания изменить комфортную ситуацию. Ну там от требования других языков, или незнакомых или запутанных технологий, доп. инвестиций как например покупка машины, когда её не было, подруга/жена не хочет, чтобы чел по долгу не приезжал домой до банальных - до работы будет далеко. Интересности или неинтересности проекта, его возможные подводные камни в реализации вас как специалиста, проекта или вашего роста не возможно после 30 мин. разговора просечь. Единственное, что можно это представление о климате в коллективе, да и то не всегда. Поэтому, такие отговорки это для себя. Не желаю обидеть, но это моё мнение. А чтобы вообще не обидеть, добавлю - но всегда могут быть исключения ;)
Насколько сейчас рынок .нет живой? В свое время ушел с него тк интересных компаний и зарплат не нашел.
Я не стал отвечать «херню несёт», скорее, автор несёт вкусовщину. Задание «на ваше усмотрение», например, может показать работодателю моё умение работать с нечёткими требованиями (такое бывает, к сожалению). Если нет желания пытать «заказчика» вопросами, я всегда могу отметить наличие неоднозначности и явно обозначить свои предположения на этот счёт.
Но как пример частного мнения — было интересно. Постоянно убеждаюсь, что люди очень разные, что хотят они разного, и подстроиться под каждого невозможно. И всё-таки при этом есть люди, которые находят себе подходящие компании, и есть компании, которые находят себе подходящих людей. Не с первого раза зачастую, но находят.
Где тут с "позиции .net разработчика"?
Какие подкасты по dotnet слушаете?
Немного о собеседованиях с позиции .net разработчика