Всем привет! Меня зовут Меньшиков Илья, я тимлид в Бизнес-юните классифайдов в VK.
Вместе с командой мы работали над сервисом быстрого поиска вакансий и сотрудников на основе геолокации – VK Работа. Рост продукта сопровождался ростом команды, поэтому мне довелось провести достаточно много собеседований на позиции разработчиков и накопить немалый опыт. Несколько раз мы перестраивали процесс найма в команду, убирая излишние шаги. В этой статье я хочу поделиться тем, как мы в итоге выстроили процесс собеседований: что меняли, от чего отказывались и что получилось в итоге.
Важное замечание
Этот текст я хотел написать давно, но всё не доходили руки. Сейчас VK пересматривает приоритеты и сосредотачивает усилия на главных для пользователей сервисах и продуктах. Пришлось закрыть некоторые проекты. Одним из таких продуктов стала VK Работа. Несмотря на это, наш подход к собеседованиям я буду внедрять дальше – в работе в других направлениях. В итоге решил, что не стоит убирать готовую статью в стол и захотел поделиться ей с вами.
Нарушаем общепринятые правила IT-собеседований
Собеседования в нашу команду разработки достаточно сильно отличаются от тех, которые я видел лично или о которых знаю из своего окружения и коммьюнити. Более того, мы даже нарушали некоторые «общепринятые правила» IT-собеседований.
Три отличительные особенности наших собеседований:
Количество людей на собеседовании. На одной встрече с кандидатом присутствуют сразу 4-5 участников команды.
Нет кода на собеседовании. Мы не используем лайфкодинг, не даем алгоритмических задач прямо на встрече – то, что вы могли встречать почти на каждом инженерном собесе в другие компании.
Нет стандартного список вопросов. У нас нет списка вопросов с заранее известными правильными ответами, по которым мы собеседуем каждого кандидата.
Чтобы объяснить, почему наши собеседования построены так, я сделаю отступление и предлагаю для начала разобраться: А какая вообще цель собеседования?
Зачем вообще нужны люди в продукте?
Представим, что есть у нас вакансия «Разработчик Java». Мы хотим найти человека. Зачем нам нужно собеседование? Казалось бы, ответ на этот вопрос очевиден: собеседование нужно, чтобы найти java-разработчика.
Однако, джависта можно найти и без собеседования:
открываем работный сайт;
фильтруем резюме по критериям – необходимому опыту, ключевым словам;
находим нужные CV и контакты, а затем просто рассылаем офферы.
Звучит абсурдно, не так ли? Можно сказать, что цель собеседования – выбрать людей из потока кандидатов. Для этого, в общем-то, тоже есть и другие способы, кроме собеседования: от создания алгоритма скоринга резюме до боя подушками и взятия на работу победителя.
Получается, что цель собеседования – найти нового члена команды, а не просто человека, соответствующего формальным критериям.
Важно помнить, что мы ищем не функцию, мы ищем человека. Почему? Я рассуждаю так: можно набрать много людей, которые «работают работу», поставить над ними погонщика с кнутом, раздающего задания и контролировать их выполнение.
Однако это не эффективно – об этом уже написано немало книг и проведено немало исследований. Со мной согласны и Daniel Graziotin, который провёл много исследований продуктивности разработчиков, и Daniel Pink со своим бестселлером про мотивацию, да и эмпирический опыт подтверждает эту мысль. Кроме того, жёсткая, контролирующая обстановка гасит творческое мышление, как демонстрирует нам Sam Glucksberg в своих экспериментах. При этом работа в IT всё-таки творческая.
Вторая проблема – подобный подход к работе провоцирует «опухоли команд» – они появляются, когда резко начинают набирать сотни разработчиков, которые тратят своё время в основном на решение проблем этого гигантизма. Об этом уже вышло немало статей из серии «Как вырасти в три раза за квартал и перестроить процессы под этот рост», без объяснения – а нафига такой рост вообще был нужен?.
Я сторонник идеи, что если каждый новый сотрудник – это мотивированный, хорошо работающий профессионал, то вам не надо набирать кучу людей, чтобы достичь тех же результатов, которые показывают большие команды. Вы постепенно набираете новых сотрудников, влияние каждого из которых значимо, а эффективность работы выше.
Скиллы, которые мы проверяем на собеседовании
«То, что надо! Отправляем ей или ему оффер!» – в чем нужно убедиться на собеседовании, чтобы тимлид написал эту фразу рекрутеру? Разумеется ответ зависит от компании и конкретной команды, но лично я выделяю для себя несколько основных моментов:
1. Умение думать.
Как ни странно, по этому скиллу срезается довольно много людей. Они способны выучить названия функций, способны заучить паттерны, способны перекладывать json из одного места в другое одинаковым способом. А вот рассуждать, думать, строить гипотезы, осмыслять то, что они делают – не всегда. Если взять такого человека в команду, вероятно он сможет успешно выполнять однотипные задания, которые ему показали как делать. А что-то за их пределами – как показывает мой опыт – вряд ли. Даже кажущаяся на поверхности типичной задача зачастую таит в себе подводные камни.
Как мы проверяем этот навык? Задаем вопросы «на подумать», дискутируем с кандидатом во время интервью на разные темы, слушаем, как он строит аргументацию. Вместо вопросов «Как?» чаще спрашиваем «Почему?» и «Зачем?». Например, на некоторых собесах я слышал, как просят расшифровать акроним SOLID, но мало кто спрашивал «А как ты думаешь, зачем оно вообще? Всем ли это нужно? Согласен ли ты с этими принципами, или может ты мог бы сформулировать свои?».
2. Любознательность и насмотренность. В идеале, чтобы человек укрепил и усилил вашу команду, ему должно быть искренне интересно то, чем он занимается. Как это проявляется? Увлеченные люди читают статьи, интересуются происходящем в мире технологий, пробуют применять эти знания. Человек, который не развивается за пределами вашей компании, вряд ли будет развиваться и у вас. Кстати, вопрос нацеленности на рост освещен в книге про Growth mindset – Mindset by Carol S. Dweck.
Чтобы проверить этот навык мы обсуждаем с кандидатом его взгляд на развитие технологий, говорим о новых трендах, интересуемся, что интересного он читал за последнее время.
3. Продуктовое мышление. Мы не нанимаем людей писать «абстрактный код в вакууме», мы берем людей, которые будут развивать наш продукт своей работой. Безусловно, чтобы влиять на продукт и определять путь его развития, есть продакт и продуктовые аналитики, но каждый разработчик также планирует и выполняет свою работу в соответствии с целями продукта. Люди, не погруженные в продукт, не могут дать конкретную и полезную обратную связь по фичам, предложить альтернативные решения тех же задач. Для разработчика важно понимать, как новая фича может повлиять на какие-то другие части продукта, замечать узкие места в своих решениях, не останавливаться на посредственных результатах.
Его наличие становится понятно исходя из того, как кандидат рассказывает о своём прошлом опыте – говорит ли он только о технологиях или нет? Понимает ли, «о чём» был его прошлый продукт, кто были его пользователи, какие проблемы он решал?
4. Адекватность.
Тут просто: базовая адекватность – это способность работать в команде. Я сразу откажу, если человек хамит, считает, что «всю проприетарщину надо срочно сжечь», или раздаёт оценки в стиле «продакты и продажники – тупые люди, которые только и ждут излияния мудрости от разработчика». Если у вас в компании есть место, куда можно посадить очень умного, скилового социопата, так чтобы он работал, но не пересекался с другими людьми – смело берите его на работу. В противном случае – один такой человек может стоить вам целой команды.
Пункт со звездочкой.
Для сеньоров есть ещё один важный критерий, который я называю «повидал дерьма» :) Человек, который поработал в разных продуктах, решал разные проблемы, сталкивался с разными сложностями. Одним словом, человек, который получил и структурировал у себя в голове разносторонний опыт, принесёт гораздо больше пользы, чем человек, всю карьеру делавший примерно одно и то же.
Как можно заметить, базовый фильтр в найме – что-то из серии core-skills или даже черт характера. Среди критериев отбора кандидатов нет пунктов «знание последних фич фреймворка», «умение вращать деревья» или ещё чего-то подобного.
Гипотеза в том, что если человек соответствует критериям из списка выше, то он будет способен разобраться в технических вопросах и использовать знания на практике, если это будет полезно для продукта.
Мой опыт показал, что лучше взять обучаемого человека и обучить, чем взять необучаемого, который знает то, что вы используете сегодня, а завтра не сможет освоить новые вещи и начнет сопротивляться изменениям.
Как раз о практике собеседований в нашу команду разработки, я расскажу дальше.
Готовим собеседование в команду разработки
Собеседование у нас – это встреча, которую можно условно поделить на несколько частей.
Сначала – знакомство. Мы знакомим кандидата в команду с продуктом и компанией, кандидат нас – с собой, рассказывая о своем опыте. Пока ничего необычного? Есть нюанс: на собеседование с кандидатом приходит обычно сразу четыре-пять человек, представителей разных команд. Один из них будет вести встречу. В начале он рассказывает немного о компании, после чего просит кандидата рассказать о себе. Из рассказа об опыте кандидата чаще всего можно получить стартовые темы для обсуждения: что и как делал наш собеседник на прошлом месте, почему он делал что-то именно так, как работал продукт и т.д. Часто уже на этом этапе получается поговорить на важные темы и получить оценку по критериям выше.
Если за время обсуждения опыта кандидата не удалось составить представление о нём, то мы обычно переходим к стандартным областям: говорим немного про язык, про архитектуру кода и приложения, про базы данных, тестирование.
В каждой теме есть пара стартовых «заходов», от них можно отталкиваться и развивать разговор. Но зачастую этого не приходиться делать. Вопросы задаём не наперебой, по какой-то теме больше говорит один из нас, остальные задают уточняющие вопросы или вносят полезные комментарии. Мы стараемся придерживаться непринужденной обстановки на встрече, чтобы кандидату было комфортно и спокойно.
Формат собеседования – не «вопрос-ответ», а беседа, в которой мы говорим и узнаём мнение и слушаем рассуждения кандидата, дискутируем с ним. Что важно: мнение кандидата не обязано совпадать с мнением собеседующего. Мы принимали решение пригласить в нашу команду и людей, у которых абсолютно другие взгляды на предметную область. Главное, чтобы у кандидата были мысли и понимание, аргументированная точка зрения. За время этого разговора мы получаем возможность оценить кандидата на соответствие вышеперечисленным критериям, а также понять – может ли он подойти в одну из наших команд.
В конце собеседования обязательно оставляем достаточно времени для ответа на вопросы кандидата, если они у него появились. Вопросы – это интерес к продукту и к нам, а значит их наличие – это хороший знак. Да и просто это уважительно по отношению к кандидату, ведь он тоже выбирает себе команду.
А как же код, спросите вы?
Он отсутствует во время собеседования. Да, мы можем попросить показать пример кода после. Но такое случается редко, в основном если рассматриваем кандидатов на миддл или джуниор грейд, и только если после интервью остались какие-то сомнения. Это может быть open source или pet, который человек делал, что-то из рабочего проекта, откуда можно легко вычистить всё важное – без нарушения NDA. Если у кандидата ну совсем ничего нет, можем предложить ему сделать супер мелкое тестовое, на час-два работы. Код в процессе собеседования, на мой взгляд, показывает не очень много, но кое-что показывает: например, как человек проектирует интерфейсы, как тестирует, как оформляет код. И все же от практики тестовых заданий или проверки кода мы стараемся уйти. Я расцениваю это так: если нам потребовалось просить кандидата сделать тестовое, то это наша недоработка на встрече, а не какие-то проблемы в кандидате.
Почему на собеседовании с нашей стороны сразу так много людей?
Во-первых, это возможность посмотреть кандидата сразу в несколько команд. Как уже пояснял, мы нацелены получить не человека-функцию, а человека-члена-команды. Поэтому наш кандидат может вполне подходить в одну команду, и не так хорошо – в другую.
Во-вторых, кандидат может посмотреть на всех нас, и понять, к кому в команду он готов, а к кому не готов идти, чьи взгляды, манера общения или что-то ещё – ближе.
Ну и в третьих, у нас внутри тоже нет единого мнения по всем вопросам. Кандидат может получить более разностороннюю картину того, как обстоят дела у нас.
Каждый новый рекрутер приходя к нам ужасается количеству людей на собеседовании. Но потом, послушав отзывы кандидатов, меняет свое мнение о командном интервью. Мы стараемся создать атмосферу непринужденной беседы, и почти всегда это получается.
Как нам удаётся достигать этой ламповой атмосферы? Я выделил несколько факторов:
1) Культура ценности сотрудника. Мы создали эту культуру еще на первых этапах создания продукта и смогли пронести её сквозь года. Мы прожили активную фазу роста, но атмосфера в команде осталась неизменной. Мы нанимали людей, руководствуясь принципом culture match, многие приходили в команду именно из-за культуры. Так мы прожили расширение, не утратив наш культурный код.
2) Внимание тимлидов. Все наши лиды понимают, что их результат – это результат работы их команд. Как бы они не были перегружены, все согласны, что на собеседования нужно выделять время и силы, поскольку это важнейшая часть работы лида. Наберёшь не тех людей или отпугнёшь кандидата на собеседовании своей раздражительностью – твой «корабль» никуда дальше не поплывёт.
Конклюжн
Что нам даёт такой подход к собеседованиям?
Во-первых, мы получаем классный матч.
За последние 3 года у нас было 0 людей, не прошедших испытательный срок, и всего один человек, который решил во время первых 3 месяцев перейти в другую компанию. Те, кто приходил, оставались с нами надолго – за эти же три года команду продукта VK Работа покинуло меньше 10 человек, а мы наняли плюс 25 разработчиков в проект.
Во-вторых, кандидатам нравятся наши собесы.
Даже если мы друг другу не подошли: и наша команда, и кандидаты уходят с интервью с новыми мыслями и идеями. Не бывает бесполезных собеседований: мы узнаем, как иначе можно смотреть на вопросы, на которые мы уже по-своему ответили, налаживаем полезные связи с ИТ-комьюнити, поддерживаем общение. Здорово, что и кандидаты рассказывают своим знакомым, что у нас интересно, рекомендуют попробовать пойти к нам.
Если мне удалось показать вам плюсы нашего подхода, и вы задумались о внедрении похожих принципов у вас, возможно прямо сейчас вы задаете себе вопрос:
А как сделать так, чтобы собеседования в нашу команду были такими? Для этого прежде всего нужно вложить силы в развитие командной культуры. Первая и главная часть такой культуры – утверждение «Люди важны». Если вы уже живете так, то осмелюсь предположить, что вам давно не нужны две стадии алгоритмических сессий, лайвкод и озвучивание вопросов из «списка вопросов для собеседования language name».
Ну и последнее. Я люблю и горжусь своей командой. Возможно, это именно тот ингредиент, которого не хватает многим компаниям. Добавьте себе в культуру любви, и вы сможете построить именно ту команду, которую хотите.
Комментарии (93)
Alexsey
25.05.2022 23:47+6Меня вполне устроило если бы шаг с кодингом был опциональным если у человека есть код на гитхабе. Понравилось резюме? Потрать 5 минут и пролистай код в репозитории, а не насилуй мозги на собеседовании. Возможно к моменту прихода человека на собеседование у тебя кроме "поговорить за жизнь" никаких вопросов к нему уже и не останется.
unkmas Автор
26.05.2022 07:47+3Кстати да, это забыл в статье написать - гитхаб смотрим перед собесом, конечно, если есть - и на собесе как раз можно обсудить что-то, что там увидел. Но, честно говоря, хороший гитхаб мало у кого есть
kibizoidus
26.05.2022 03:13Вы нанимаете программиста или "человека в коллектив с разносторонним опытом и умением общаться на любые темы от принципов ООП до международной политики и способов высадки полей огурцов методом коврового бомбометания семян"?
Проще говоря - вам шашечки или ехать?
Если первое - вы садите человека писать код, следите за его размышлениями и НЕ МЕШАЕТЕ указаниями того, что бы вы считали правильным.
Если второе - не говорите, что нанимаете программиста.
moonster
26.05.2022 06:07+3Вот да.
Программист должен уметь читать и писать код (именно в таком порядке).
Читать - это не только понимать, что делает конкретное выражение, но и уметь видеть за кодом смысл, строить гипотезы, зачем это было написано, почему именно так, осознавать культурные традиции проекта.
Я не встречал не "начитанного" программиста, который бы мог писать простой код, который легко читать и поддерживать.
Читать и писать код на собеседовании можно и должно. )
rjhdby
26.05.2022 09:59Программист должен уметь читать и писать код (именно в таком порядке).
В первую очередь программист должен уметь думать и учиться
ruomserg
26.05.2022 10:16Это относится не только к программистам. Теоретически, любой взрослый человек должен уметь думать и учиться. На практике — не любой… :-(
moonster
26.05.2022 14:13+1Ничто так не демонстрирует способность думать и обучаться, как наличие навыков, которые могли появиться только в результате размышлений и обучения.
WraithOW
27.05.2022 11:11Ваш комментарий неявно подразумевает, что от программиста требуется только писать код. Это так, если у вас поточная разработка, где разработчику приходят причёсанные задачи, а он должен делать как написано. В остальных случаях наличие социальных навыков таки тоже нужно.
Femistoklov
28.05.2022 07:51ТС же ясно сказал, что ему не нужен "человек-функция", у которого на входе - ТЗ, на выходе - код.
ruomserg
26.05.2022 06:34+15А теперь представьте, что дирижер в оркестр так нанимает музыкантов? «Вам сыграть? // Нет, возможно позже — расскажите пока какие книги вы прочитали за последний месяц?».
В этом смысле мне гораздо больше нравится идея — дать человеку кусок кода, и пропросить сказать свое мнение: что эта штука делает и какие к ней есть мысли по-поводу (покажите, что и как вы бы поправили). Прикол программирования заключается в том, что ~70% времени мы ЧИТАЕМ код (свой, чужой, примеры...), а не пишем. Потом уже можно поговорить про начитанность, софт-скиллы, и т.д.
TimsTims
26.05.2022 23:23+3Музыканты - пример внекорректный. Они ничего не строят. Их труд оценивают только те, кто сидят в зале, а не весь город или весь мир. От того, как они сыграют никто не умрёт, не заболеет, не покалечится, а об их труде максимум напишут в газетах, или покажут по телевизору, и будут просить снова и снова повторить сыграть тоже самое, изо дня в день (а программисты, как мы знаем, ек любят писать один и тот же код).
Правильней будет представлять разработчиков со строителями. Как обычно, мы можем дать тестовый день поработать на стройке, кирпичи потаскать, и оценить насколько он сильный и выносливый, и умеет ли правильно класть кирпичи.
А можем поспрашивать про архитектуру, где и как работал, какие косяки других рабочих исправлял, и как придумывал это делать. Какие здания строил и для чего, как быстро с этим справлялся. От его будущих действий зависит безопасность конструкции, и вообще качество здания.
edo1h
27.05.2022 07:32А можем поспрашивать про архитектуру
строителя?
TimsTims
27.05.2022 09:08Почему нет? В разработке же тоже есть отдельная должность архитектор, а есть разработчик. Почему разработчиков тогда спрашивают про архитектуру, а строителя нельзя?)
edo1h
27.05.2022 09:25Может быть потому, что типичный архитектур имеет высшее образование, а типичный каменщик не факт, что пту закончил.
И да, разработчик по мере роста решает всё больше архитектурных задач. Каменщик как клал кирпичи, так и будет класть.
Хотя разумное зерно в вашем вопросе есть, почему каменщика при приёме на работу не просят положить десяток кирпичей? Наверное, потому что в офисе этим не будешь заниматься, грязно.
TimsTims
27.05.2022 10:56+1архитектур имеет высшее образование
Так и сейчас много разработчиков без образования, и вообще есть тренд "у нужно ли оно".
типичный каменщик
Если берём каменщиков, то давайте брать не разработчиков, а кодеров, которым много мозга не надо - пиши вот тут, копипасти так, перекладывай джсоны.
Каменщик как клал кирпичи, так и будет класть.
У нас же здесь аналогии? Если проводить аналогии, то мы берём опытного строителя, которому дали задачу построить дом. Обычный такой домишко на 1 этаж. И вот этому вашему строителю нужно выбрать место, инструменты, технологии, продумать архитектуру, а потом начать всё это строить и закончить проект.
И вот возвращаясь к оригинальной тематике, мы можем дать тестовое задание - потаскать кирпичи, посмотреть как он кладёт кирпичи. Но правильней будет спросить сколько домов он построил, и как он это сделал, с какими трудностями боролся.
edo1h
27.05.2022 13:53И да, и нет.
Архитектор не кладёт кирпичи руками. А миддл пишет код руками.
Впрочем, «напиши код» — это больше про джунов. А вот предложенное выше «сделай ревью куску кода» мне очень понравилось, это к любому уровню кандидата можно подобрать.
ruomserg
27.05.2022 09:30Вот музыканты сейчас на вас обидятся!.. Одно и то же из дня в день — играет механическая шкатулка. Музыкант же должен сыграть таким образом, чтобы у зрителя возникли чувства и эмоции, которые заложил в мелодию композитор. Если вы послушаете одно и то же произведение в исполнении разных оркестров под управлением разных дирижеров — то удивитесь, насколько по-разному они воспринимаются…
С другой стороны, справедливо — никакие две професси нельзя сравнивать по прямой аналогии. Я беру музыкантов в первую очередь по той причине, что там для успеха требуется как природный талант, так и большая работа по его развитию (невозможно стать музыкантом, занимаясь строго по расписанию в муз.школе или училище). Аналогично и у программистов — насколько я могу судить, если у человека нет природной склонности в этом направлении и ОДНОВРЕМЕННО он не чувствует тяги и потребности программировать (для себя/других/whatever) в свое свободное время — ему следует искать себе другую профессию.
Помимо этого, работа программиста имеет довольно странную особенность — мы работаем материальными предметами (клавиатура, экран — и аналогично музыкант работает с клавиатурой, смычком, барабанной палочкой) — но цель работы программиста находится далеко за пределами этих предметов. Манипулируя клавишами и трекпадом — мы оперируем совершенно абстрактными понятиями, пытаясь передать машине наши мысли и идеи по поводу тех или иных проблем окружающего мира. Аналогично, музыкант должен передать эмоции публике через посредство тех инструментов, которые ему даны. Пожалуй вот еще математики точно также работают с абстракциями при помощи записей формул и текстов на бумаге/экране.
Что касается инженерии и архитектуры — тут тоже аналогия справедлива только отчасти. Если вы разрабатываете редуктор — то вы можете его увидеть (сначала на экране CAD, потом в виде макета, потом в виде изделия). Аналогично и архитектор — как правило может увидеть то, что было задумано. Что касается программиста — вы никогда не сможете потрогать синглтон, пощупать стратегию, осмотреть command object. Вы можете взаимодействовать с ними только абстрактно, через среду разработки, отладчик, следы в журналах. В общем, любая аналогия — только аналогия, к сожалению…TimsTims
27.05.2022 11:05Вот музыканты сейчас на вас обидятся!
Почему? Я ничего обидного не написал.
Если вы послушаете одно и то же произведение в исполнении разных оркестров под управлением разных дирижеров
Мне крайне сложно будет оценить разных дирижеров адекватно. Их не послушать одновременно, а память о предыдущем концерте может помнить только отдельные отрывки. В целом, я думаю, что мне понравятся оба.
работа программиста имеет довольно странную особенность — мы работаем материальными предметами (клавиатура, экран)
Но ведь половина работ мира связана с компьютерами, это относится не только к программистам. Куча отделов продаж работают на компьютерах, продают тонны товаров даже никогда не видя их. Даже те же математики сейчас много работают на компьютерах.
Если вы разрабатываете редуктор — то вы можете его увидеть. Что касается программиста — вы никогда не сможете потрогать синглтон.
Редуктор можно подержать в руках, как программист может подержать в руках жесткий диск с кодом, или увидеть результат его работы на компьютере. Но внутрь редуктора не заглянуть, пока тот работает в реальных условиях (upd: хотя если сделать его из стекла, то в принципе можно), как и программист не может потрогать синглтон на включенном современном компьютере (если брать не современные, то можно представить себе огромную комнату из механических переключателей, реализующих в ЭВМ синглтон).
Наверное, здесь ближе аналогия не с редуктором, а например с резистором, в который тоже не заглянуть, как он создает сопротивление. Ведь технологии компьютеров дошли до такой степени, когда их уже нельзя потрогать и покрутить руками.
Вы можете взаимодействовать с ними только абстрактно, через среду разработки, отладчик, следы в журналах.
Тоже самое относится и к редуктору - ты можем посмотреть как он в теории работает в AutoCAD, через датчики в журналах посмотреть сколько он произвёл оборотов, итд.
если у человека нет природной склонности в этом направлении и ОДНОВРЕМЕННО он не чувствует тяги и потребности программировать — ему следует искать себе другую профессию.
Частично с вами согласен, потому-что сам такой, но здесь вам стоит раскрыть мысль шире. Я знаю нескольких отличных разработчиков, которые после работы не могут даже сидеть за компом.
ruomserg
27.05.2022 11:59Если разработчик уже отработал свои 10000 часов до профессионализма, возможно он может ограничиться рабочим днем, а в свободное время сажать розы. Хотя большАя часть разработчиков так или иначе за пределами рабочих часов либо что-то читают по теме, либо пишут, либо учат, и т.д.
Если же мы говорим о периоде становления и обучения разработчика, то рецепт только один — программировать столько, сколько есть желания и свободного времени. Лучшие разработчики, которых я встречал в жизни — это люди, которые пришли в профессию очень рано: через кружки, родителей, самоучкой, и т.д. Когда другим было интересно играть в карты/в компьютерные игры/whatever — этим было интересно кодить.
И сейчас — если приходит выпускник ВУЗа, который делал только строго лабораторные работы и курсовые проекты, и ничего сверх — он даже не Буратино, а полено из которого этого Буратину еще надо вытесать… А если приходит человек, который хоть что-то пилил для себя или работал с 2-3 курса — с ним уже можно разговаривать. Эта разница чувствуется просто с порога…
И это появилось не вчера и не сегодня. Отец рассказывал, что когда они учились в институте и программировали на чем-то вроде БЭСМ — тоже были те, кому было интересно составлять программу (в кодах!) на бумаге и копаться в перфокартах и распечатке с АЦПУ, и были (в основном) те, кому это было «лишь бы сдать». Просто все люди разные — у одних к тому склонность, у других — к этому…
ruomserg
27.05.2022 12:06… и все-таки есть большая разница, проектировать на компьютере объект реального мира (тот же редуктор) — который ты можешь хотя бы теоретически изготовить, покрутить в руках, разрезать, и так далее — и «изготовлением» сущностей в памяти компьютера существующих только в виде потока бит в сочетании с CPU который на этот поток битов реагирует. Их никогда нельзя будет физически достать и посмотреть.
Умение рассуждать о поведении объектов, которые не сущетсвуют нигде кроме абстрактного мира идей — кроме программистов, присуще также математикам и философам. Большинство математиков по этой причине вполне неплохо осваивают программирование. Однако есть и отличие — в математике отсутствует понятие времени.
Единый раз установленная закономерность — всегда является в математике таковой. Математика сложна именно своими концепциями (я, например, многие из них не способен толком воспринять). Программирование имеет более простые концепции, но много более сложные взаимодействия между ними (во времени). Поэтому бывают хорошие программисты, которые ни разу не математики — и обратно, отличные математики и никакие программисты. Хотя корреляция между способностями к математике и программированию — безусловно есть, и сильная.
unkmas Автор
28.05.2022 08:03Задача музыканта в оркестре - играть, то что ставит дирижёр. Если строить работу вокруг coding monkeys - этот пример будет корректным.
У меня всё же другой подход, поэтому логичнее будет привести аналогию с собеседованием композитора для фильма. Наверное, можно попросить его поиграть Баха, но как это поможет показать его навыки сочинения музыки - не до конца понятно.
В то же время, практика ревью кода на собеседовании - тоже любопытная, хороший подход.ruomserg
28.05.2022 08:11У музыкантов (даже в оркестре) все не так единообразно — есть свой табель о рангах. Если ты десятый альт в группе смычковых огромного оркестра — то самостоятельности у тебя… ну ноль примерно. А первая скрипка — она вместо дирижера репетиции проводить может, например. Также есть свои руководители у каждой группы инструментов (например, духовых — похоже на тимлидов, наверное). Какой-нибудь единичный специалист по ударным или арфе — тоже может вполне себе свою манеру исполнения иметь… И это большой оркестр, где все смотрят на дирижера!
А есть еще камерные, которые должны самосинхронизироваться. И тут тоже прямо напрашивается аналогия между гигантскими корпорациями по созданию ПО и мелкими стартапами.
panzerfaust
26.05.2022 07:43+11Вы рано или поздно нарветесь на болтунов, которые или имеют особый тип памяти или уже прошли до вас 20 собесов и нахватались всякого. Они вам за чашкой чая все расскажут: от Java Memory Model до устройства Project Reactor под капотом. А на деле окажутся последними фуфелами. У меня таких в прошлом году было аж двое подряд. Вера в такой вот "добрый" подход к собесам потом сильно пошатнулась.
Сейчас в моей компании обязательный пункт на собесе - код ревью. Бывает прямо удивительно наблюдать, как человек молча смотрит 10 минут в насквозь всратый код и вообще ничего не видит. Хотя только что вещал и про SOLID и про многопоточку.
unkmas Автор
26.05.2022 07:51+1Не верю, что можно пройти 20 собесов и научиться на них думать и рассуждать. Запомнить аббревиатуру SOLID - да, понять когда и как это стоит применять - нет. Поэтому, собственно, мы и не спрашиваем "энциклопедические вопросы", а везде выводим кандидата на обсуждение
panzerfaust
26.05.2022 08:27+2Можете эксперимент провести. Возьмите толкового джуна и дайте ему время подготовиться к вопросам про тот же SOLID. Если не дурак, то сможет за 2-3 дня проштудировать все материалы и мнения на хабре, медиуме и в оригинальных статьях. На словах не хуже вас будет рассуждать про разницу между coupling и cohesion и т.д.
sergey-gornostaev
26.05.2022 09:34+6Я 14 лет провожу эксперимент по найму и согласен с автором статьи. В свободной беседе опытного интервьювера обмануть на много сложнее, чем натреннироваться бездумно балансировать красно-чёрное дерево на маркерной доске или лайвкодить. И даже если "болтун" вдруг пролезет каким-то чудом, для фильтрации таких существует испытательный срок.
edo1h
27.05.2022 07:36натреннироваться бездумно балансировать красно-чёрное дерево на маркерной доске или лайвкодить
ну если человек натренировался кодить, то разве не это и надо было? пусть садится и кодит
sergey-gornostaev
27.05.2022 09:27Нет, не это надо было. Как и всем, нам нужны люди умеющие самостоятельно думать, разрабатывать решения, в идеале проявлять изобретательность, а не просто нажимать заученные последовательности кнопок.
edo1h
27.05.2022 09:30Эээ… проанализировать условие задачи и написать на него код — это никак не «нажимать заученные последовательности кнопок». Или вы первые задачи из leetcode даёте?
Hivemaster
27.05.2022 10:14+2Разница между реальной работой и любыми задачами литкода огромна, умение решать задачи литкода никак не коррелирует с умением разрабатывать решения для бизнеса. Может иначе у разработчиков поиска Яндекса, где сплошные алгоритмы, не знаю.
Nialpe
26.05.2022 09:42+2Мне довелось встречать на код-ревью ситуации нарушения принципов этого самого SOLID на ровном месте и полное непонимание соотнесения принципа и написанного кода. Т.е. на коммент - "смотри, тут D в явном виде нарушено - есть причины?" - человек без запинки перескажет принцип и приведет хрестоматийный пример, но не видит аналогичное в своем же коде.
kirillk0
26.05.2022 11:21+3Мне кажется, если человек может за 2-3 дня прочитать тонну текста и научиться связно разговаривать про прочитанное, то быстро научиться программировать он тем более сможет, программировать гораздо проще
DmitryKoterov
26.05.2022 07:51+10Да ну что вы. Нет, конечно, нужен кодинг. Я сам никогда не спрашиваю сложных задач, никогда. Никаких там деревьев и динамических алгоритмов. Только самое простое, пара циклов и ифы. На здравый смысл. 90% не могут и этого написать, увы - с 10+ годами опыта. Еще спрашиваю самые азы computer science (сколько бит в байте и какое количество значений там можно сохранить, например). Результаты удручающие. Это в Долине так, по крайней мере (но в Москве 7 лет назад было похоже). При этом в резюме все шекспиры (но резюме я по сути перестал читать уже давно, ориентируюсь только на самопрезентацию и практические навыки).
Просто в мире инженеров есть те, кто делают, и те, кто не делают. Достаточно бинарная шкала. Никакие даже уровни не важны, джуниор/мидл/синьер - это все не важно, если человек делает. А если не делает, да будь он хоть трижды папа римский, толку-то никакого.
nronnie
26.05.2022 08:59-6сколько бит в байте и какое количество значений там можно сохранить, например
Если меня такое спросили бы, то я бы в ответ спросил "А сколько по вашему?" И если скажут "восемь", то сразу нах :))
nronnie
26.05.2022 09:29-8И вот уже кто-то восьмибитовый поставил минус. Про восемь бит тебе на курсах "вайти", наверное, рассказали? :))
evgenyspace
26.05.2022 09:54+4И сколько по вашему бит в байте?
ooki2day
26.05.2022 10:18+8человеку на курсах «вайти» рассказывали, что в 50х годах люди экспериментировали с длиной слова, и были 6-битные байты ( эм даже ещё какие-то битные), но он забыл, что 8 бит приняли как стандарт, и в 2022 говорить о другой длине - такое себе «выпендрежничество». ну, мб ещё в секретных бункерах оборонки пытаются в другую длину - тут не знаю, оно ж секретно
nronnie
26.05.2022 10:29А ссылку на стандарт можно? Есть (не знаю писанный или неписанный) стандарт что 8 бит это "октет". А вот про стандарт на число бит в байте интернет до сих пор ничего не говорит.
Меня как-то на интервью, не знаю, с какого перепоя, спросили сколько штатов в США (возможно решили проверить эрудицию). И сами "эрудиты" ожидали стандартный ответ, что полсотни. Лучше все-таки держаться правила спрашивать на интервью только то, в чем ты сам на 100% уверен. А то можно в лужу сесть.
ooki2day
26.05.2022 10:38какую ссылку? такой же стандарт, как и октет. либо, для просвещения заблудших, дайте вы ссылку на современную железку с другой длиной слова.
nronnie
26.05.2022 10:59-6Ладно, ок. Коль уж на твоем электросамокате и айфоне байты по 8 бит, то пускай будет 8 бит :)))
Arsmerk_true
26.05.2022 11:46+8Причем тут вайти и "на твоем". Конкретно где, кроме истории создания стандартов, сейчас используется другое число бит в байте. Пока выглядит как пустое ЧСВ на пустом месте.
Tsimur_S
26.05.2022 11:27+7А ссылку на стандарт можно? Есть (не знаю писанный или неписанный) стандарт что 8 бит это «октет». А вот про стандарт на число бит в байте интернет до сих пор ничего не говорит.
IEC 80000-13:2008In English, the name byte, symbol B, is used as a
synonym for octet. Here byte means an eight-bit byte.
However, byte has been used for numbers of bits
other than eight. To avoid the risk of confusion, it is
strongly recommended that the name byte and the
symbol B be used only for eight-bit bytes.
The symbol B for byte is not international and should
not be confused with the symbol B for bel.
cdn.standards.iteh.ai/samples/14308/cd41e65dbc2f4ace9ff1a2721105ca9b/IEC-80000-13-2008.pdfnronnie
26.05.2022 11:43-5"Recommended", даже если оно "strongly", это еще не "must" и даже не "should". Есть IEC от 2015 года (более позднее ничего не ищется) где написано, что "platform dependent" и "usually 8", но "usually" это, опять-таки, совсем не "always".
Когда был переход с .NET Framework на .NET Core, то у всех куча кода не работала. Потому что его до этого писали такие "вайтиразработчики" со смузи, что даже в душе не предполагали, что FileName и filename это могут быть разные файлы, а подпапки могут разделяться не обратным слешем а прямым. Так что строить предположения типа "в моём самокате 8 бит, значит везде 8 бит" это совсем не очень.
Tsimur_S
26.05.2022 12:18+1«Recommended», даже если оно «strongly», это еще не «must» и даже не «should».
И у вас конечно же есть причина не следовать «strongly» рекомендациям стандарта во время интервью или подозревать что интервьювер им не следует?Есть IEC от 2015 года (более позднее ничего не ищется) где написано, что «platform dependent» и «usually 8», но «usually» это, опять-таки, совсем не «always».
Какой именно IEC? IEC 80000-13?nronnie
26.05.2022 12:40-3У меня есть причина заподозрить "мытожеаджайл", где все задачи описываются по принципам "это же очевидно" и "это само собой разумеется". А потом после "все готово" выясняется, например, что существуют вполне реальные люди у которых фамилия всего из одной буквы (сам когда-то с таким работал) или телефоны в которых больше 11 цифр.
bogolt
26.05.2022 15:16+2Ну да ну да, на собесе нужно написать игру на ассемблере под версию телефона интевьювера, а на работе потом джсоны перекладывать придется
Stormbringer-s
27.05.2022 06:46А сколько бит в байте это азы? Мне кажется что немного кто знает что 8 битовый байт называется октет а сам байт не состоит из 8 бит и эти единицы связаны довольно слабо.
WeezyFBaby
26.05.2022 07:53+11Для меня писать код на собеседовании это стресс. Собеседование само по себе немного волнительный процесс, но когда дело доходит до лайв кодинга сразу образовывается пустота в голове. И ведь дают не самые типовые задачи, а задачи для которых нужно время на подумать, а время на собеседованиях как правило ограничено. В этом плане мне проще взять тестовое задание и спокойно его выполнить, чем писать код когда за тобой смотрят.
andrey-kuznetsov
26.05.2022 07:53+1Успех подхода впечатляет. Возможно, секрет в активном участии 4-5 кандидатов: взгляд с разных сторон помогает лучше увидеть человека.
Я не готов уйти от проверки навыков собственно написания кода. Не раз сталкивался с таким: кандидат выглядит очень привлекательно на этапе разговора про теорию и прежний опыт, а простейший live-coding показывает, что всё грустно.
Ну и есть шанс отпугнуть некоторых кандидатов. Я, например, принципиально не устраиваюсь к работодателям, которые не дают полноценное тестовое (хотя тут надо звёздочку поставить, один раз в стрессовой ситуации нарушал это).
finalekrown
26.05.2022 07:53+10Проведение собеседований - вещь весьма субъективная и как правило малокомпетентная. Вот я, только что, закончил трёхнедельный спринт по 4 - 5 собесов каждый день 5 дней в неделю. Чего там только не было: Домашнее задание с тремя задачами, в каждом из которых были элементарные ошибки, а так же излишне заумные и многословные формулировки. Что интересно, я сделал лишь первое задание и прошёл дальше. Какие-то всем своим видом недовольные и судя по всему не вполне адекватные люди, на втором или третьем техническом собесе, которым вообще непонятно что не понравилось. До сих пор помню какую-то рыжую недовольную тётку. Были конторы, которые меня уговаривали у них работать. Были какие-то совсем стрёмные стартапы в зачаточном состоянии с деньгами на год или даже на пол года. Особенно рассмешил довод молодого основателя одного из таких стартапов: "даже если мы через год закроемся, судя по твоему CV, ты быстро найдёшь новую работу". Был стартап, пишущий софт в помощь отделов кадров компаний, соблюдающих процентный лимит негров и прочих меньшинств в политкорректных странах. Поняв, из вопросов о продукте, мою скрытую неполиткорректность они не только не перезвонили, но даже не прислали материалы о своём продукте, которые обещали прислать. Был какой-то стрёмный стартап про блокчейн, который, видимо, так же просёк мой пессимизм по поводу всех криптовалют на блокчейне. Под конец спринта, когда я, изрядно уставший, наконец получил подходящий офер, начались обиды в других конторах: "мы тебя ждали на собес, а ты не пришёл, редиска", хотя я всегда просил высылать мне приглашения на видео собеседования с указанием телефона кого угодно из компании на случай проблемы. Или обида, что тогда же в финале я отменил фронтальный собес после двух его переносов не по своей воле. Короче я прошёл через тупость, неадекватность и просто элементарную неорганизованность немалого числа собеседователей и даже целых компаний. В очередной раз убедился в правоте мнения, что основная цель собеседования - проверка психологической совместимости. Можно ответить 100% правильно на все вопросы и просто не понравиться психологически, а можно лажать по мелочи почти в каждом ответе и пройти, просто из-за какой-то симпатии.
aceofspades88
26.05.2022 12:24+1Вот я, только что, закончил трёхнедельный спринт по 4 - 5 собесов каждый день 5 дней в неделю
не знаю почему, но вспомнился анекдот:
-Ты тоже бизнесмен?
-Нет, я тоже .........
DYUMON
26.05.2022 08:26Людей после курсов по программированию не берете?
ruomserg
26.05.2022 09:25+8Сегодняшние курсы программирования напоминают мне школы летчиков в войну (СССР в первой половине, Германия — во второй). Тогда это культурно называлось "… по сокращенной программе военного времени". Фактически, выпускник этой школы гарантированно мог: войти в самолет, запустить двигатель, в простых метеоусловиях пролететь по кругу над аэродромом, сесть не разложив машину, найти переключатель для применения оружия. Остальному его надо было учить в полку…
А теперь ставим себя на место командира полка, получившего это самое «молодое пополнение». Если ты посадишь летчика в самолет, а он его разложит на взлете или посадке — можно сесть за халатное отношение к обучению и матчасти. Если ты не посадишь его в самолет — у тебя штат укомплектован, и задачи ставят как будто все облетаны. Если ты посадишь его в самолет и будешь учить — значит теперь от боевой работы отвлечен еще и опытный летчик. Короче — что бы ты не сделал, получается еще хуже чем было!
В итоге, выпускники курсов по программированию — могут рассматриваться как кандидаты либо если компания богатая и имеет свой учебный центр, либо если в компании есть избыток опытных разработчиков без проектов и планируется расширение штата (зачем ?!). Только в такой ситуации можно дообучить и добиться выхода годного от программиста после курсов. Можете сколько угодно говорить о вреде высшего образования — но по крайней мере фундаментальные математические/физические дисциплины там будут прочитаны: можно учить дальше, опираясь на эту базу. После курсов нет ничего: ни навыков, ни базы… В лучшем случае — желание и знакомство с терминологией и средой разработки. В худшем — желание получать большую зарплату и умение говорить правильные слова на типовом собеседовании. :-(
И нет, я не против курсов как таковых: технических писателей, ручных тестировщиков — учите сколько хотите. Разработчиков не трогайте. Вы же не пытаетесь на полугодовых курсах хирурга или терапевта с нуля подготовить? Вот и тут не надо…
unkmas Автор
26.05.2022 09:32+1Ну правила "не брать после курсов" у нас нет. Но и не было людей, которые пришли бы сразу после курсов и были хорошими
Nialpe
26.05.2022 09:33+4Известная холиварная тема - можно ли по навыку X судить о навыке Y?
Полагаю нанимающая сторона в идеале хотела бы проверить как будет справляться кандидат-разработчик с реальной работой. Если отталкиваться от этого допущения, то готов признаться что я - неудачник, немного старомодный и неумелый. Не знаю как у вас, но мои рабочие будни выглядят так - комфортное рабочее место, оснащённое современной техникой и доступом к Интернету, современная кухня. При решении задач из спринта есть возможность взять паузу и выпить чашечку кофе, посоветоваться с коллегами, поразмышлять над проблемными вопросами (каюсь - иногда даже во время прогулки с собакой в выходной), почитать техническую литературу или мануалы и даже (о ужас!) поискать схожие практики в Интернете. А бывает и ещё страшнее - ко мне обращаются товарищи за помощью или мнением - и получают время и внимание. Решительно не получается ежеминутно высекать идеальный код в граните или фонтанировать неоспоримыми архитектурными идеями, каждая из который достигает production. До сих пор не понимаю, почему меня держат и платят за все вышеперечисленное. А еще у меня не стоит над душой персональный "экспертный" надсмотрщик, кривящий губы и раздающий оценки каждому действию.
Резюмируя - большинство пройденных собеседований совсем не похоже на вышеизложенное. Одним словом - работаю себя кое-как за миску похлебки в компаниях, которые сжалились надо мной - сирым и убогим, далеким от проверяемого на собеседовании. Но все безусловно считают, что проверяют именно то, из чего состоит ежедневная работа разработчика. Не разработчик я, не разработчик...
P.S. Ответ на вопрос в первом предложении прост - каждый наниматель нанимает себе и делает так, как считает нужным. Практика автора - весьма любопытна.
omlin
26.05.2022 15:23+1Вы всё правильно говорите (хотя сарказма многовато). У меня даже в привычку уже вошло: как затык - так иду чай пить (и это неспроста, немного отвлечься часто помогает).
Однако вы опускаете тот факт, что всё таки в перерывах между кофе вы пишете и читаете код, и с коллегами тоже обсуждаете наверное не только погоду, но и технические моменты.
Я к тому, что в нашу работу входит множество разных вещей, и требуются знания по множеству разных тем, и плюс к тому для выполнения работы нужна куча различных навыков. На собеседовании пытаются проверить все эти вещи, но наивный подход к проверкам работает плохо, и плюс к тому, умение правильно собеседовать - это тоже навык, и он есть далеко не у каждого программиста/тимлида, в итоге имеем то, что имеем...
Практика автора - несомненно интересна. Очевидно, что она проверяет некоторое подмножество навыков кандидата которые он использует в повседневной работе, но далеко не всё.
Можно ли по подмножеству (у автора - это умение думать, наличие собственного мнения, продуктовое мышление и др.) судить о множестве? С некоторой вероятностью, вполне. Но если так, то можно предположить, что если взять другое подмножество (кодинг-скиллы, или навыки по чтению кода, абстрактное мышление, способность крутить деревья), то точно также можно с некоторой вероятностью судить о полном множестве.
Успешность найма в случае автора может быть объяснена тем, что поскольку способность крутить деревья проверяют чаще, люди которые пытаются хакнуть интервью, скорее будут учить деревья, а не продуктовое мышление. Но можно ли хакнуть точно также тест на продуктовое мышление? Я думаю, без проблем...
Nialpe
26.05.2022 16:29Согласен и позволю себе дополнить вашу мысль - "можно ли по оценке подмножества судить о множестве?". Оценка вносит дополнительный элемент субъективизма и вполне вероятно погрешность. За последний абзац - отдельный поклон, интересно... Не задумывался об этом.
sergey-gornostaev
26.05.2022 09:37Такая практика только в вашем проекте или весь VK молодцы?
unkmas Автор
26.05.2022 09:39+2За весь VK не берусь говорить, компания большая, и практики, конечно, отличаются от проекта к проекту
yaguarundi
26.05.2022 09:59Долго пытался понять картинку, так как уже жил тогда, когда под собесом понималось другое.
rjhdby
26.05.2022 10:25+9Меня как-то на интервью на синьёра срезали вопросом "Назовите принципы ООП". Удивился сильно, но на автомате выдал "инкапсуляция, наследование, полиморфизм". После чего интервьюер скривился и процедил "ещё абстракция". На этом и закончили.
iiwabor
26.05.2022 10:33+1Я за последние 3 месяца прошел почти 50 собеседований - и с лайвкодингом и с ДЗ и с задачками с литкода. Первые 10 собесов был стресс, потом отпустило. И дела сразу пошли все лучше и лучше. В итоге 7 офферов, все с релокацией
Может мне повезло, но с неадекватами я ни разу не столкнулся. И лайвкодинг кодинг реально нужен, хотя бы небольшой - в резюме можно что угодно написать и ответы на вопросы выучить наизусть. И, кстати, я кое-чему научился за время собесов - интересные вопросы и темы были, о некоторых я не задумывался в процессе работы.
Tontu
26.05.2022 10:56+5Это прям нирвана в области управления кадрами.
По моему собственному опыту за огромными сложными технически собесами маскировались негативные процессы внутри команд, где за формальностями прятались проблемы взаимодействия между разработчиками (в меньшей степени) и между исполнителями и руководством (в большей). За формальностями (а формальнее кода в принципе не придумать) пытались защитить свои личные позиции в жестокой конкурентной среде руководители. Это, по сути, последнее средство защиты у тех, кто имеет не иллюзорный риск слететь с позиции. Ведь сами подумайте, если тимлид принимает собес и очень активно гоняет по коду, то сложно сказать, что он некомпетентен как руководитель. Вон же он как активно работает, наверно что-то умеет. На моей памяти все хорошие тимлиды, у которых команда укладывалась в назначенные сроки и поддержка кодовой базы без критичных проблем шла годами при постоянном расширении функциональности, могли без проблем за десяток-другой минут составить достаточно полное представление о кандидате, а если кандидат был не из самых сильных, то эффективно помогали расти, если видели потенциал.
Есть, конечно, исключения, где, например, тестовое задание просто необходимо, потому что принимают много джунов и нужно прям реально каждому его давать, дабы не тратить время на откровенно некомпетентные кадры. Или специфика области такая, что без кода ну никак не понять квалификацию. Может быть что-то академическое-математическое, где словами сложнее описывать, чем символами.
Разумеется, субъективный взгляд на полноту не претендующий.
sukhe
26.05.2022 11:23+4Интересно — в реальной работе кому-то приходилось самостоятельно писать перебалансировку деревьев? Встречались-ли вообще такие задачи, а если встречались, то почему не использовалась библиотечная многократно оттестированная функция, а была потрачена уйма времени на разработку собственного «велосипеда»?
zloddey
26.05.2022 13:06+2Я в пет-проекте использовал когда-то
graphvizдля рисования графов (квадратики и стрелочки между ними). Генерировал файл с текстовым описанием и скармливал утилитеdot. Получал картинку, и это до поры до времени меня устраивало. Потом захотел рисовать квадратики и стрелочки сам - для большего интерактива. Сунулся в исходники "библиотечной, многократно оттестированной функции", а там такое... В итоге оказалось проще найти соответствующие paper-ы и реализовать алгоритм самому в своём коде. Да, он работает медленнее, чем библиотечный. Да, результат получается менее красивый. Но зато я могу добавлять свои собственные правила (ограничение на число элементов в 1 строке, например), и никого не сломаю.В общем, сложные алгоритмы пригождаются нечасто. Но зато когда это надо, то просто берёшь и делаешь его. Да и бииблиотечные функции нередко бывают весьма далеки от идеала.
zloddey
26.05.2022 13:42Справедливости ради, стоит добавить, что сейчас код в
graphvizстал явно лучше. Судя по графику изменений, там один из авторов весьма активно всё в порядок приводит и чистит. Но 5 лет назад ситуация могла отличаться. Да всё равно, мне мои 300 строчек алгоритма нигде не жмут.
HackerDelphi
26.05.2022 19:04Доводилось.
Причины: производительность, производительность и снова производительность.
В том проекте SOLID похоронен был и даже goto встречались. На C#. Ну а про работу с указателями в данном случае думаю можно и не упоминать.
Но это - скорее исключение из правил.
И да, знание того, как перебалансируются (и вообще устроены) деревья поиска очень помогает при работе с большими объёмами данных.
Lee_Fun
26.05.2022 13:13Хорошая практика, но стоимость для принимающей стороны выше: 4-5 человек выдергиваются из рабочего процесса на час-два, требуется больше внимания. Хотя конечно вам с этим человеком работать потом, так что всё правильно. Другое дело как на это смотрит топ-менеджмент. Хотя, если результаты найма хорошие - вопросов с их стороны быть не должно.
unkmas Автор
26.05.2022 23:32Ну в общем-то да, показываем результат и вопросов не возникает. Опять же, это не то место, где я бы старался сильно экономить время - наём слишком важная вещь
maslyaev
26.05.2022 13:54-1Если кратко резюмировать: разрабы с хорошими хард-скиллами всё равно почти все свалили, поэтому давайте набирать чисто по софт-скиллам. Даже если они совсем не способны работу работать, с ними хотя бы будет приятно общаться.
У меня был опыт принятия человека на работу так, как описано в статье. Печальная история.
event1
26.05.2022 17:30Скажите, а как вы отличаете болтунов с хорошим резюме от профессионалов?
Мы-то без программирования людей не берём. Правда на доске не мучаем, конечно. Сажаем в комнату на полтора часа и смотрим, что выйдет
unkmas Автор
26.05.2022 17:52+1Болтун на то и болтун, что знает вещи только на поверхности. Задавая более глубокие вопросы, дискутируя на какие-то темы, становится понятно, есть ли понимание, или только зубрёж
maslyaev
26.05.2022 23:21Умелый болтун знает, как подрулить дискуссией так, чтобы у вас сложилась полная уверенность в его выдающемся профессионализме.
А вот симулировать профессионализм на алгоритмическом лайвкодинге никак невозможно.
DjPhoeniX
26.05.2022 23:23+1Только если вы вообще не шарите в психологии и не способны засечь момент, когда кандидат начал «подруливать дискуссией». А психология вообще ключевой навык любой около-руководящей профессии.
sergey-gornostaev
26.05.2022 23:50+1У меня были соискатели, которые на теоретические вопросы отвечали как по книге, любые алгоритмические задачи щёлкали как орешки, на лайвкодинге выдавали образцовые абстракции и паттерны, но были просто надрессированы проходить собеседования. Я таких всегда определял безошибочно, как раз в дискуссии, но моё руководство приходило в восторг и временами продавливало найм. А потом в работе оказывалось, что они способны зазубривать, но не способны понимать, не способны развиваться, неспособны выходить за рамки синтетических задач, неспособны самостоятельно искать и анализировать информацию, не способны понимать бизнес-потребности и разрабатывать решения, раз за разом месяцами допускали очевидные инженерные и эксплуатационные ошибки, хронически изобретали велосипеды вместо использования готовых решений, писали негибкий, а зачастую и нечитаемый код и т.д. и т.п. Проще говоря, были абсолтно бесполезны.
Racheengel
27.05.2022 20:50Вот как правило, болтуны и пассажиры очень любят абстракции и паттерны. Это практически лакмусовая бумажка: если на вопрос об архитектуре приложений начинается монолог про паттерны - всё, можно тушить свет. Перед этим попросив ответить на вопрос, чем дизайн приложения отличается от архитектуры?
Racheengel
26.05.2022 17:43+6У нас принципиально нет написания кода на собеседовании. Мы ищем специалистов, а не coding monkeys. Да и термин "Собеседование" подразумевает беседу и общение. Если человек не понимает базовых принципов или пытается "загрузить базаром", то такого пассажира видно сразу, и он не проходит.
В конце концов продуктовое мышление гораздо важнее знания, как называется тот или иной паттерн. Паттерны зазубрить можно, а "думать" уметь надо.
Mike-M
26.05.2022 17:46отпугнёшь кандидата на собеседовании своей раздражительностью – твой «корабль» никуда дальше не поплывёт.
А я бы предпочел наоборот. Пусть уж лучше интервьюер проявит раздражительность на собеседовании, чем после записи в трудовой книжке кандидата о приеме на работу.
amberovsky
26.05.2022 19:59Какой у вас в итоге полный процесс вынесения вердикта по кандидату? Как выставляете оценки?
Безотносительно кода - этапы интервью в стиле "поболтать и посмотреть на адекватность" - бесконечный источник предвзятости, от которого стараются всеми силами избавиться (debiased approach) , вот тут есть немного инфы https://www.beapplied.com/post/interview-bias-explained-and-how-to-prevent-it
Это не только про то, чтобы нанять технически грамотного специалиста, а ещё и обеспечить разноплановость / разнообразие команды (diversity)
Было бы интересно узнать, как с текущим подходом ВК обеспечивает непредвзятость и разнообразие команды. Какое у вас соотношение женщин/мужчин в разработке?
unkmas Автор
26.05.2022 23:44+2Опять же не могу говорить за весь VK, говорю только за нашу команду. Девочек значительно меньше чем мальчиков, потому что их просто очень мало приходит на собеседования - слишком сильный перекос по полу на рынке. Зато конверсия по ним зашкаливает - из четырёх (если правильно помню) пришедших на собес - двоих взяли.
Теперь сугубо моё личное мнение. Diversity ради diversity - вредно и опасно, нужно работать не над unbiased процессом найма, а над unbiased головами людей. Наша команда построена вокруг культуры, результат этой культуры - наш процесс собеседований и то, как работают наши головы в этой культуре. Мы нанимаем классных людей, какого они пола, возраста или расы - неважно. К слову, у нас в команде был классный разраб возрастом в 54 года - возрастной дискриминации у нас тоже нет.
Что касается оценок - их нет. Мы просто в конце обсуждаем, кто готов человека взять себе в команду, кто нет. У нас нет "объективности" в этом смысле, и я не верю, что она вообще может быть. Как я и говорил в статье - мы ищем члена команды, это больше чем набор функций, а значит - построить "объективный скоринг" - просто невозможно при таких вводных (до тех пор, пока учёные не научатся оцифровывать и оценивать человеческий мозг и его психику). Да и не нужно.amberovsky
27.05.2022 00:06Спасибо за ответ.
У вас HR как-то устанавливает базовые процессы найма? Насколько индивидуальным может быть подход каждой команды?
Было бы интересно узнать в целом про стратегию найма, diversity и debiasing от вашего HR, если есть такая возможность.
unkmas Автор
27.05.2022 14:52Нет, у нас решает команда. На мой взгляд, именно так и должно быть - вы выступаете заказчиками для HR, так что именно вы и определяете, как должен быть устроен наём
DjPhoeniX
26.05.2022 23:18+2Я в последнее время сошёлся на трёх ключевых вопросах. Но сначала немного гоняю кандидата по основным техническим навыкам (относительно позиции, на которую хочет кандидат). Не столько ради оценки знаний, столько чтоб вогнать человека в состояние «думать про код». А дальше идёт комбо:
А почему ты вообще пошёл в айти? - тут сразу отметаются кандидаты, бегущие за деньгами, обещанными на онлайн-курсах. Высший балл получают те, кто в ответе использовал слово «интерес» - такие с наибольшей вероятностью будут добиваться результата.
А как это получилось? - тут наибольшая ставка на «флэшбеки из прошлого», как начинал кодить в школьные/студенческие времена. Опять же, смотрю на заинтересованность, а не «прочитал что за это платят».
А почему именно <название платформы>? - главный тест на критическое мышление, что с чем сравнивал, какие были критерии, как пришёл к выбору направления. Заодно узнаю, какие технологии кандидат видел по сторонам.
beDenz
27.05.2022 23:01Это конечно все здорово. Вот только все впечатление портят девочки рекрутеры. Буквально недавно, постучалась девочка из vk, красочно все описала, назначила встречу. А на встречу никто не пришёл. На мой, закономерный, вопрос, что это было - игнор.
ilynxy
Хочется расплакаться и обнять. Мой опыт подобных собеседований не настолько позитивный. Да, вращение деревьев на доске — ненужный садизм. Да проверять умение мыслить — здравый подход. Но результатом труда разработчика является код, который суть — решение поставленной задачи. Можно сколько угодно разговаривать о способах решения задач и умении обучаться, но talk is cheap, show me the code! Очень часто продемонстрированный код (решения предыдущих задач или поставленных на собеседовании) несет больше информации чем часовые собеседования с кандидатом.
Не хотелось бы чтобы мой посыл расценивался как реверсивный карго-культ (типа: пробовали как у них и оно не работает, значит и у них не работает), но я искренне удивлён такой успешности найма работников. Может быть это просто везение? Жду ещё статистики о работе такого подхода. )
unkmas Автор
Я видел очень интересную практику в других компаниях, когда вместо лайвкода и подобных вещей - людей брали на тестовый оплачиваемый день в компанию. Но такое очень сложно реализовать на мой вкус, я даже не пытался подступиться :)
DmitryKoterov
Я делал так раз 5 (но только после интервью с кодом все же), кстати. Результаты всегда отличные, причем как позитивные, так и негативные. Не все кандидаты только соглашаются.