День 3. Всем привет! будем говорить про одну из самых холиварных тем - собеседованиях.
Начну со своих личных ощущений. Внезапно, для меня намного комфортнее собеседоваться, а не собеседовать. Когда ты собеседуешься, на тебе вообще нет никакой отвественности. Тебе задают вопросы, ты задаешь свои ответы. Рассказываешь про опыт, а рассказывать я люблю.
Если ты где то ошибся, ну что же бывает, все знать не возможно, если тебе задают исключительно те вопросы, ответы на которые ты не знаешь, это повод порефлексировать. Либо твои знания не актуальны, либо интервьюер не адекватный.
В любом случае, отсутствие офера не проблема. Можно пойти на следующий собес уже сегодня. Если очень нравится компания, то можно вернуть через пол года и скорее всего ты уже пройдешь.
Когда ты собеседуешь все по другому. На тебе ответственность. Ты можешь нанять человека с которым будет не комфортно работать. Можешь наоборот не нанять хорошего специалиста. Можешь оставить не верное впечатление о компании. В общем это сложно)
Сделаю ремарку, говорить я буду только про техническую часть собеседования, всякие собеседования на общую адекватность, соответствие культурным ценностям, разговоры с менеджерами это оставим за кадром. А вот про тестовое поговорим как про часть собеседования.
И так какие виды и этапы собеседований я знаю:
- Экзамена, где задается огромное количество технических вопросов.
- Разговор по душам, где в формате беседы нужно ненавязчиво узнать опыт кандидата
- Белая доска, где кандидат пытается что то написать без помощи гугла и ide
- Решение алгоритмических задачь
- Решение логических задачь
- Проектирование решения какой то задачи
- Тестовое задание
- Поиск ошибок, где кандидату дается проект низкого качества и он должен рассказать почему он не очень, найти и исправить технические ошибки.
Если я что то упустил, пишите в реплаях)
Начнем с тестового задания, так как оно дается еще до собеседования. Для компании это хороший способ посмотреть как кандидат пишет код не в стрессовой ситуации, а у себя дома. Казалось бы ситуация win-win, и компании хорошо и кандидат показывает навык не под давлением.
Но на самом деле тут куча минусов. Не понятно как выполнять это ТЗ. МОжно написать быстро, лишь бы работало, но тогда не оценить скилл. Можно написать всунув в этот небольшой кусочек все что только знаешь, но это время, да и опять же не понятно, понимает ли кандидат зачем
Он все эти вещи всовывает, может он их и потом везде всовывать будет. К тому что тестовые делать никто не любит, они отнимают время и вот это вот все. И самая экзотическая проблема, ты никогда не можешь быть уверен что ТЗ выполнил именно кандидат.
И если вы сейчас подумали что кейс, когда тестовое делает кто то другой, очень редкий, то вы ошибаетесь. В ИТ сейчас есть деньги и много людей пойдут на все что угодно, лишь бы эти деньги получить.
В общем сейчас куча споров, на тему должны ли давать ТЗ, должны ли его оплачивать. И я честно говоря не знаю кто тут прав. Если всем оплачивать можно без денег остаться) А то набежит кучу людей, что бы написать откровенную фигню, и денег за это получить)
Если оплачивать тем кто сделал его хорошо, тогда почему бы их просто не нанять? Если человек выполнил задание хорошо, но не настолько что бы его нанять, то кто будет оценивать, достойно ли ТЗ оплаты? В общем одни вопросы.
Сам я все таки предпочитаю ТЗ не давать. Лучше спросить у кандидата, может у него есть код, который он может показать и как он считает в полной мере покажет его возможности как разработчика.
Я не просто так упомянул о том что код должен показывать возможности кандидата. Потому что не любой его код на это способен. Сейчас любят говорить, по том что у всех должен быть гитхаб. Но гитхаб тоже не показатель.
Человек мог комитить туда 5 лет назад и с тех пор сильно вырости. Или мог делать в свободное время и не концентрироваться на хорошем коде. В общем опять одни вопросы и никаких ответов.
Формат экзамена, наверное самый распространенный формат. Он самый простой и для собеседующего, а часто и для собеседуемого. За минимальное время, задаем максимальное количество вопросов, а потом оцениваем на сколько канидат шарит.
Звучит вроде бы не плохо. Но на самом деле тут тоже полно нюансов. На простые вопросы скорее всего отвечать будет большенство, не нанимать же каждого. На более сложные вопросы, можно что не ответит никто.
Действительно, у нас любят спрашивать такие вещи, которые в повседневной разработке вообще никогда не всплывают или всплывают очень редко. В итоге к эти вопросам надо именно готовиться.
В итоге что ты точно можешь сказать после такого собеседования?
- Программирует ли в принципе кандидат.
- Готовился ли он к собеседованию.
- Интересуется ли он вещами за пределом его повседневных задач.
Не в целом, хорошо отсеять совсем зеленых джунов или натолкнуться на подкованного эксперта. Но что делать с тем большинством которое посередине? Ну не знает человек что то про многопоточку, он плохой специалист? Или про бд (в мобилках это не частый кейс)? Или про алгоритмы?
Или про анимации? Или то как там ссылки в языке устроены?
Я не знаю. Бывает разговариваешь с человеком, он производит хорошее впечатление, но не знает почти ничего. Плохой ли он?
В целом я понимаю что того что он знает, хватает для той работы которую он выполняет на текущем месте. Но думается что он мог бы и покопать что то за пределами своих обязанностей. С другой стороны зачем? Ему заняться что ли нечем? Возможно он во всем разберется за месяц.
А возможно и не разберется. В общем, очень сложно делать выводы. И я например каждый раз очень сильно задумываюсь что бы сделать выбор. Да и в целом стараюсь не давить на какие то особенные вопросы, а спрашивать то что необходимо для работы.
Есть еще тонкий момент, что некоторые кандидаты довольно неплохо натренировались проходить собеседования. И легко отвечают на такие вопросы. Но при этому код они пишут с ощутимым скрипом. В общем, никаких гарантий.
Разговор по душам, когда то был моим любимым вариантом. Впрочем я и сейчас предпочитаю, что бы кандидат рассказал о себе сам, а не сидел на допросе. Но тут тоже все не просто. Редко попадается канидидат, жизненный опыт позволяет рассказать кучу крутых историй.
Большенство все таки решают стандартные проблемы, стандартными, простыми вариантами. Но я все равно начинаю собеседование с просьбы рассказать самую сложную/интересную/просто запомнившуюся задачу на который кандидат работал.
И как правило люди испытают трудности с тем что бы ответить. Приходится несколько раз уточнять, что это может быть совершенно любая задача, даже максимально простая и они все равно очень долго думают.
Бывает что кандидат вообще не может ничего сказать кроме как "ну я пишу код, он работает". И все попытки что то нащупать сводятся к тому что человеку реально нечего рассказать. Он просто на работе каждый день делает ровно одно и тоже. И по сути его три года опыта равны неделе
Кстати сравнивать три года и неделю не совсем корректно, но об этом поговорим позже)
Бывает и такое что кандидат начинает увлеченно рассказывать что то что мало что говорит о его навыках. А бывает что он увлеченно рассказывает о том как разбирался и с тем и с другим, но поверхностно потому что не было такой задачи или времени.
Какие выводы тут можно сделать? Что ему интересно то что он делает, это плюс. Но не понятно, будет ли он разбираться в нюансах если время ему дать. А может оно и было у него, просто он считает что его было не достаточно.
Конечно в разговоре можно оценить такие вещи как общую адекватность, способность рассуждать, мыслить логически. Это все реально важные поинты. И когда то я топил именно за эти качества.
Но позже я на опыте убедился, что если человек грамотно рассуждает это ничего не значит. К сожалению есть люди которые максимально крутые на словах, но ничего не могут на деле. И этому есть разные причины. Да банально он может быть лентяем, я таких реально встречал.
whiteboard это конечно общее название для написания кода на бумажке или специальном сервисе. Не знаю как я к этому отношусь. С одной стороны поинт крутой, если ты программист то код ты напишешь. Может он конечно не скомпилируется, но в целом будет понятна его идея.
С другой стороны смотря какой код ты должен написать. Не секрет что есть разные задачи, разные подходы и так далее. И человеку намного проще сделать то что он делает на работе.
Например написать fiz biz довольно легко, там нет никакой специфики и он очень похож на то что мы пишем каждый день. А вот сортировку даже пузырьком написать уже сложнее, хотя все еще в рамках допустимого.
Или вот задача объединения двух отсортированных массивов. С одной стороны она простая. С другой стороны там используются такие методы обхода массива, которые обычный программист в работе не использует. В конце концов, что мы там делаем с массивом кроме как foreach?
Должен ли хороший программист такую задачу решить? Конечно должен. Но вот должен ли он сделать это на собесе, сколько у него уйдет времени это вопрос.
Все таки ситуация стрессовая. На тебя смотрят, а тебе думать надо. Может запросто переклинить. И если человек не справился, значит ли что он не подходит? Не знаю. Скорее это зависит от того на сколько он не справился. И опять тут есть простор для размышлений и сомнений.
Решение алгоритмических задач (сюда же идет знание структур данных) это холивар в холиваре. Постоянно все набрасывают надо или не надо. И я считаю что алгоритмы знать надо. Но только те которые близки твоему стеку.
Например знать массив, хэштаблицу, стек, очередь, дерево (что это такое) нужно. В конце концов мы с этим работаем. Так жу нужно знать сложность операций с этими структурами и откуда она берется.
Так же я думаю, что любой разработчик должен быть в состоянии написать односвязный список или очередь или дерево (не сбалансированное). Ну хоть как то написать. Потому что кажется что это все элементарно и не требует какой то специальной подготовки.
Обходы деревьев из той же оперы. При этом я не говорю что надо уметь еще и какие то операции для них реализовывать типо слияния или поиска. И уж тем более обычный программист не должен в любой момент времени написать оптимальный алгоритм поиска.
По этому я очень расстраиваюсь если встречаю человека который не может объяснить как он выбираем между массивом (array, list) или словарем (map, dictionary) или не знает что словарь не упорядочен (в swift это так). Потому что это же вот прямо базовые вещи как по мне.
А вот логические задачки я не люблю. У меня в детстве была книга, сборник таких задач. И когда мне нечего было делать я их решал. В целом все они строятся на каких то общих принципах. И если их порешать, то можно развить скил. Но упорно не понимаю что это дает.
То есть то что человек умеет решать логические задачи скорее всего означает только то что человек уже решал логические задачи. Так как у нас в работе этот навык бесполезен, то и проверять его наличие бесполезно ИМХО
Тоже один из моих любимых вариантов это ревью заранее подготовленного проекта. Кандидату дается проект, не лучшего качества. А он должен рассказать что ему там не нравится.
Тут мы можем посмотреть на то как кандидат работает с кодом, как думает, как он хотел бы написать этот код. Но при этом, не заставляем его ничего писать самого.
Очень крутой поинт, потому он сильно синхронизирует вас. Может оказаться что то на словах у вас возникла мискомуникация. И то что вам не понравилось в словах кандидата, на деле как раз то что вам нужно, ну или наоборот.
Самое сложное в этом, необходимость подготовить проект, как правило все на этом и сыпятся) Я сам сейчас так не делаю как раз по этой причине) Надо бы выделить время и написать))
Ну и последнее это словесное проектирование. Кандидату описывается задача, а он на словах рассказывает как бы он ее решал. Довольно хорошая методика. Но опять же бывает мискомуникация. Слова они все таки слова.
То что кандидат опишет, у собеседущего в голове может сложить не так.
В целом не одна из этих метод не дает возможности точно оценит кандидата. Потому что главное это все таки уметь думать, а не знать какие то вещи. И вот это очень очень сложно проверить. Человек всегда может наговорить такого, чего он никогда делать не будет.
Он мог просто очень долго готовится, очень много читать и слушать, но банально не умеет писать код или не хочет или делает это медленно. В обратную сторону это тоже работает он мог стрессовать наговорить чушь. А еще собеседующий мог задавать не вопросы и тоже не то понять
У меня кстати есть пара знакомых которые любят копаться в кишках разработки. Изучать все от алгоритмов до языков, в разговоре они дадут многим 100 очков вперед, но при этом терпеть не могут пилить фичи, потому что для них скучно делать что то для проекта.
Еще один поинт, что часто на собеседованиях кандидат который знает только то что нужно для решения простых повседневных задач считается плохим. Но мы просто забываем как это когда ты вообще не умеешь программировать.
Я долгое время учу людей программировать. И вижу как для новичков сложно пользоваться массивами, циклами, условиями. Они буквально пасуют когда нужно положить в массив не строку, а какой то набор данных, объединить это в класс для них высший пилотаж. Наследование темный лес.
Ваш любимый фреймворк для них темная магия, они могут только повторять код из статьи но реально не понимают как он работает хотя бы приблизительно.
Общаясь с такими людьми ты понимаешь что если человек не знает что такое евент луп потому что не посчитал нужным разобраться это не так уж и страшно. Да и черт с ним если он даже не понимает как там работает словарь в вашем языке.
Если он не боится создавать переменные, классы и базово понимает как работает фреймворк то это уже неплохой разработчик. Подумайте, возможно вам его и хватит, ну на крайний случай остальному его можно будет научить)
Я в этом треде написал что человек три года делая одно и тоже имеет опыт равный неделе. Но я так же написал что это не совсем корректно. Да он не знает многое, очень многое. Но он три года развивал скил писать код.
Тот самый простой код, который мы вообще не замечаем и считаем его чем то само собой разумеющимся. А на самом деле это тоже навык и это тоже сложно.
Я конечно не предлагаю сейчас все бросить нанимать людей которые умеют только в базовые вещи, но понимать что это тоже не просто и тоже навык все таки неплохо.
На этом у меня все на сегодня. До завтра)