Comments 23
Как с треском провалить скрининг с HR - легко. Хотя вешать скриниг на HR это вообще не верно.
Приведу пример одного из вопросов.
Вопрос по GO - каким методом можно перевести строку в число.
Я вначале зависла, потом у меня в голове возникла строка "aaaaa". И я начинаю тупить. В голове мелькают мысли - а как они хотят чтобы эта строка стала числом. Начинаю говорить про байты.
После ступора и блока, понимаю, что речь идет про строковые числа. Вспомнила библиотеку, но метод забыла, т.к. я его давно не использовала в работе. И вообще было бы странно таким методом пользоваться часто. Ибо это говорит о неверной архитектуре проекта.
Вывод - не всегда заданный вопрос может быть сформулирован корректно. А как итог на разработчика вешается ярлык - этот тупой и ничего не знает.
У меня был как-то блиц опрос от HR. 5 минут, 30 вопросов.
Вопросы уровней от "что такое ООП", до "как в Spring реализовать вложенную транзакцию и на что нужно обратить внимание".
Вроде прошел, было интересно. Но собес это не 100% гарантия. Я подхожу к этому как к казино, иногда может не повезти (не выспался, забыл, не понял вопрос, не работал с такой технологией).
Обычно в таких случаях никто не ставит черную метку, так что будет шанс еще раз попасть в эту же компанию. Но вот на токсичных могут поставить такую метку или тех кто проходил собес с помощью, с наушником или кто активно гуглил))
Пройти 100 собеседований и не умереть) Мемы огонь 🔥
Самое упоротое интервью у меня было, когда собеседующий зачитывал вслух код с рукописного листочка и просил определить что не так с кодом.
Какие-то советы у вас капитанские. Неужели нет ничего конкретного?
Например такого:
В одной компании вместо тестового или лайвкодинга мы предлагали программистам провести ревью заранее подготовленного кусочка кода. На это испытание соглашались все кандидаты. Искать чужие ошибки гораздо приятнее, чем делать свои. Многие в процессе ревью раскрывали свои убеждения и навыки гораздо охотнее, чем во время обычной беседы. В коде были как очевидные ошибки, так и более тонкие, и даже слабому программисту было что сказать по делу. В итоге кандидатам было интересно, а собеседующим сразу видно специалиста, который в первую очередь заметил опасный баг, а не вцепился в код-стайл.
Если ваши кандидаты не хотят делать тестовое, попробуйте предложить им ревью. Кусочек кода должен быть небольшим и содержать разные проблемы. Спрашивайте кандидата как можно было бы избежать проблем, которые он находит (например добавить линтер, написать автотесты). Очень хорошим оказался вопрос: "Это все правки? Релизим?". Неопытные специалисты боялись принять решение и просили ещё время (если вы ищете сеньора, то такие вам не подходят).
Вариант с код ревью - универсален. И для разраба и для лида. Тут согласен.
Не описывал только потому, что хотел конкретные кейсы описать которые мне давали.
На одном из собесов(успешно пройденных кстати) мне дали кусок многопоточного кода. Причем человек который дал задание, хитро улыбнулся и кивнул на другого интервьюера и спросил не узнал ли тот откуда это. Так я понял что ребята готовы показывать и свои фейлы и вообще с юмором подходят к собеседованиям.
Никогда не понимал, почему так много народа считает ревью хорошим форматом собеседования. Ерунда же полная.
Увидеть сделанную ошибку (особенно заведомо зная, что она там есть, нужно только присмотреться) и самому написать правильно с чистого листа - это совершенно разные уровни квалификации.
Чтобы научиться отличать Рембранта от парковой живописи, достаточно пары занятий. Чтобы самому писать как Рембрант - многие годы практики.
Если вам нужен человек, кодирующий задачки с литкода, — лайвкодинг. Если вам нужен человек, который будет готовится к вашему собесу (лояльный), — лайвкодинг. Если ван нужен человек с железными нервами — лайвкодинг. В некоторых компаниях эти навыки важны.
Но если вам нужен программист, который сможет писать запросики в базу, интеграцию по http, автоматизацию всякую, то предложите ему ревью. Он вам на нём и про базовые структуры данных, и про ооп-шаблоны, и про оптимизацию запросов в бд расскажет. А на лайвкодинге он облажается и уйдёт с мыслью, что вы компания тщеславных идиотов (не потому что это так, а потому что он так почувствует).
Не всем нужен Рембрандт :-)
предложите ему ревью. Он вам на нём и про базовые структуры данных, и про ооп-шаблоны, и про оптимизацию запросов в бд расскажет.
Он-то, может быть, действительно что-то расскажет.
Только из этого совершенно не следует, что он будет писать код так же хорошо, как рассказывает. Вообще не следует.
Писать свой код любой дурак может. Вот умение разбираться в чужом - бесценно.
Да, я сменила формат собеседования и очень сильно прокололась, наняли джуна как мидла, на собесе казалось что все норм, по факту делал очень странные ошибки, как будто первый день в профессии :(
Пока для себя поняла, что формат ревью как единственный этап не сработает, надо комбинировать с чем-то другим.
Формат меняла потому что просили уложиться в час, а мне обычно пару часов нужно.
Хорошая статья. Я сам тимлид и считаю что кодинг на интервью это некомфортно и нерепрезентативно. Гораздо важнее понять как устроен человек, какой опыт, как он рассуждает и учится, настроен ли работать.
Интервью когда семеро на одного и где тебе доказывают что ты лох, увы, были и у меня. Неприятно всегда.
У меня вообще был прикол, когда ко мне пришел hr нанимающей компании, по его инициативе и уговорил пройти интервью на тим лида, по итогам которого мне прислали фидбек, что я плохо знаю технологии и мне разрешат пройти повторное интервью не раньше чем через полгода. Умеют унизить ребята. Это ж ваша инициатива была, ало.
Узнал Тиньков и Яндекс в кейсах, моргните, если я прав.
Насчёт написания кода я в целом отношусь спокойно. Если люди хотят проверить кодил ли ты вообще когда-то то это тоже неплохой вариант. Просто не надо от Тим Лида или Руководителя уровнем ещё выше требовать идеального исполнения алгоритма или идеального синтаксиса. Недавно проходил собес на руководителя отдела с 100+ сотрудниками и меня все равно по базе прогнали: перевернуть двусвязный список, удалить дубликаты из базы. Так как я сам иногда такие задачи даю, то сразу честно сказал что это не будет показательно. Мне предложили реализовать то же самое но другим путем, не базовым. Так что тут я сам для себя разнообразие устроил)) А то уж больно скучно начали.
А насчёт того что вам сказали что только через пол года можно, это в целом нормальная практика. Проблема в том как это донести до кандидата. Можно экологично сказать, что на конкретную позицию нужен бОльший опыт работы с технологией, так как именно этого опыта не хватает в команде и нужен эксперт чтобы обучать ей других. Но вы как кандидат очень нам понравились и мы с радостью вернёмся к вам с другой подходящей вакансией. Но это в случаях когда реально такой опыт нужен. Но к сожалению некоторые занимающие менеджеры сами не знают кто им нужен.
А меня в Яндекс зарезали на собесе на лида. Сказали, что второй этап алгоритмов прошел слабовато (но я его прошла). И что я явно завалю дизайн (типа нет смысла проводить). Но вот как алгоритмы связаны с системным дизайном не понятно. Но я не стала настаивать. Как говориться не очень и хотелось.
У профессионала/эксперта нет проблем с предложениями на рынке - вы сами выбираете по своим критериям, точно также у крупных и известных компаний нет проблем с кандидатами. Они стараются сделать процесс универсальным, чтобы сократить расходы и выровнять всех кандидатов под линейку.
Думаю вы знаете что у некоторых компаний есть и "красные флаги", чтобы отсеять сразу некоторую аудиторию, но про это уже и так было много статей. По моему мнению, алгоритмы для проверки умения программировать и дизайнить бизнес-решения не подходят, если только работа не заключается в разработке этих самых алгоритмов, но эту уже куда-то в дата сайенс и математику.
Расскажу о своём худшем собеседовании.
Коротко обо мне на тот момент: проработал Java разработчиком 5 лет, это была моя первая "настоящая" позиция, сразу после универа. Разрабатывали внутреннее приложение на core java (200k строк именно Java). Это приложение использовалась для выполнения симуляций, валидации данных (как input, так и output) и архивирования результатов на нескольких платформах. Особая гордость: Приложение умело в environment as code до того как это стало популярным :-). На этой позиции я закрыл множество тикетов, добавил несколько серьёзных фич и провёл огромный рефакторинг ничего не сломав.
Но вот пришло время искать что-то новое. Вижу в intranet стоит объявление "пропал мальчик нужен java разработчик", все требования совпадают. Отправил резюме. Поскольку это всё происходило внутри компании, то первый контакт был сразу с тимлидом. Пообщались с час, я рассказал чем занимался, с его стороны были скорее поведенческие вопросы. Оба остались вполне довольны.
Следующий этап - техинтервью. Помимо нас двоих пришли ещё 4 человека. Тоже все представились. Ну, начинаем. Техлид говорит расшарь экран и открой твою любимую IDE. (сомнительно, но оокээээй) Делаю. Угу, так, хорошо. Давай начнём с простого "напиши функцию которую можно будет вызвать через REST, возвращающую hello world".
И тут я: "Ээээм, что-то типа Spring или аналог питоновского fastapi в Java?". Техлид: "Ну да". Я (несколько в ступоре): "Не поймите меня неправильно, но я не знаю как это делается. Тем более у меня здесь ничего не настроено.". Теперь уже ступор у них. Я говорю, нет я конечно понимаю как api работает, я так же разрабатываю consumer для нескольких сервисов как раз на restapi, но как именно организовать REST с обратной стороны я не знаю. Там ничего сложного, но не доводилось ещё просто".
Ребятки попросили несколько минут. Потом вернулись и говорят вынуждены дать отказ, им нужен человек именно с опытом разработки API. Говорю, да, жалко, именно в разработке API у меня нет опыта, но могу быстро разобраться. Тем более первое интервью хорошо прошло. Их тимлид, похоже, был тоже фрустрирован и выдал "Да, прости, неловко вышло. Я думал ты умеешь программировать". Я смотрю на него через экран и думаю "пипец".
Вывод: не стесняйтесь в объявлении среди требований "Java и ещё 20 технологий" указать что именно из джавы вас интересует. Если уже хотите live coding на стороне соискателя проводить, то тоже предупредите, чтобы кандидат настроил свою IDE под таски. Ну и обдумайте стоит ли всю тиму звать на первое техническое интервью.
Фигово, ну или может наоборот к лучшему. В таких случаях лучше сразу узнать о коллегах и их принципах. Не придется потом себя ломать под команду. Я тоже "Обожаю" когда по знанию какой-то специфичной библиотеки судят по опыту человека. Раньше сам таким страдал и спрашивал про подкапотные особенности Spring. Если в целом есть дофига кандидатов то можно повыбирать кто в этом шарит больше всех. Но вот сейчас становится слишком много однотипных фреймворков, технологий, поэтому такой подход становится не актуальным.
Где сейчас работаю принято даже брать синьоров без знания конкретного языка, если человек готов переучиться. Потому что синьоров нормальных попробуй найди, а если с такими доп требованиями то искать пол года придется. За это время проще нанять сильного инженера и пусть он выучит тот язык, который нужен.
На всякий случай напишу, что сейчас как раз ищу к себе в отдел Тим Лида кросфункциональной команды. Обещаю рациональный подход к собеседованию, много челленджей и хорошие условия)
И все равно лучшим вариантом остаётся доступный и интересный гитхаб с опенсорсом, в который вместо резюме посмотрит тот CTO, с которым имеет смысл разговаривать.
А все, кому нужны резюме, лайвкодинг и ревью — сразу останутся вне сферы моих интересов.
Как (не) пройти собес с пользой