Комментарии 29
у вас в разделе "Алгоритмы? Алгоритмы!" написано, что новый СТО инициировал изменения в культуре компании:
/.../ По моему мнению программист это в первую очередь инженер, а не алгоритмист. Это было не соответствие видению компании, и я был вынужден измениться чтобы встроиться в новую создаваемую культуру.
В итоге мы перестали проверять навыки инженерии, и получили на входе поток программистов, которые не умели писать и поддерживать продакшен код /.../ Эффективность и результат их работы был плачевный.
не совсем понятно, как поток программистов с плачевными результатами смог привести к успеху:
Спустя время культура компании изменилась, и мы сплотились вокруг идеи, что программист должен уметь в алгоритмы. Это очень сильно повлияло на внутренние процессы и дало очень сильный толчок к развитию. Акции компании росли, конкуренты оставались в «кильватере». Причин успеха было множество, но также этому поспособствовало устранение «бардака» в найме и фокус на «правильной» культуре.
не могли бы вы пояснить?
не совсем понятно, как поток программистов с плачевными результатами смог привести к успеху
Для начало надо понять что такое успех. По моему мнению тут можно оценивать успех как рост сервисов компании, акций компании и компенсаций сотрудников. Тут все это было в течении 3 лет.
Далее я писал что причин успеха было множество. Я обратил внимание на устранение бардака и фокусировке на правильной культуре. По сути в компании оставались-нанимались люди с похожим майндсетом, что снижало затраты на коммуникацию.
При этом плачевный результат был поначалу, в дальнейшем люди научились и нашли другие способы решения проблем. Давайте я поправлю в тексте так:
В первое время эффективность и результат их работы были плачевными.
Очень неэффективный код медианы, между прочим. 10 последовательных ветвлений. Я бы постеснялся такой показывать на собеседовании.
Логика подсказывает, что медиану из трёх можно написать в 3 ветвления, а знания – что быстрее будет вообще без ветвлений, на минимаксах.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков. Иногда это совмещается с техническим интервью. Акцент в моей публикации был на оценке со стороны работодателя.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков.
Вот в процессе обсуждения "что нужно сделать" и становится понятен уровень технических навыков кандидата. Притом это улица с двухсторонним движением - кандидат тоже оценивает уровень ваших технических навыков.
Про это я писал в первом разделе - Интерлюдия. Но тут есть повышенные риски со стороны кандидата - увольнение на испытательном сроке. Не все работодатели готовы соглашаться на такой риск.
Не понял. Как раз беседа по проекту и понимание что ждёт минимизируется риск что кандидат сбежит на испытательном сроке.
Проблема не в том что сбежит, проблема в том что придется увольнять. Обычно компания не хочет иметь плохую репутацию на рынке труда из-за постоянного увольнения людей.
Увольнять скорее всего придётся успешных разворачивателей красно-белых деревьев и всяких теоретиков-зубрилкиных. Если кандидат ведёт внятную дискуссию по проблеме которую вам (ему) надо будет решать, я не очень понимаю почему он не справится с её решением. Какие-то мелкие технические пробелы в знаниях не проблема, доберёт в процессе.
Поделюсь своей историей. Тоже однажды стал активно участвовать в найме. Так как мы нанимали мидлов и сениоров, то подход несколько отличался. И так как раньше я сам проходил собеседования, то старался убрать то, что не нравилось мне и добавить то, что наоборот нравилось.
Предупреждение - все совпадения случайны ?.
В первую очередь я рассказывал про то, чем надо будет заниматься, без прикрас. Мидлам - что работа может быть скучной и однообразной, а сениорам - что придется решать саппорт тикеты. Рассказывал про процессы разработки в компании, про отсутствие людей на некоторые роли. И что программисты соответственно эти роли заполняют собой. Этим я давал шанс отказаться тем, кому что-то не понравилось бы.
Стек у нас Microsoft / .NET и собеседование поначалу состояло из двух секции.
Первая - это вопросы по программированию по различным животрепещущим темам - язык, БД, ORM, асинхронщина, тестирование и так далее. Моя цель был составить простые, но меткие вопросы. В итоге получилось что-то типа "расскажите про N что знаете" и "с какими проблемами сталкивались при использовании M". Первая секция была и для мидлов, и для сениоров.
В принципе по ответам можно было судить о глубине знаний. Более опытный человек рассказывал больше деталей. Если ответ был совсем поверхностным задавал наводящие вопросы. Например async await - что будет если обернуть в try catch - перехватит или нет. Другой пример с ORM - либо человек говорит, что не сталкивался с проблемами (что означает, что толком не использовал, или это был пет проект, или очень простой проект). Либо мы можем обсудить с человеком плюсы минусы переноса кода в хранимки.
Так же задавал "вопросы от обратного". Например меня часто на собеседованиях спрашивали про нормальные формы, но крайне редко про денормализацию. И вот вопрос "что такое денормализация и в каких случаях ее лучше использовать" выявляет людей с более широким кругозором и инженерным мышлением. Процентов 20% могли ответить на этот вопрос полностью. Примерно половина давала только определение.
В этой же секции была тема про фронт-разработку. Задавали из нее вопросы, буквально 2-3 штуки, только если собеседуемый заявлял, что работал с фронтом.
Были интересные результаты про секцию с тестированием. Первый вопрос был - что такое пирамида тестирования. Ответило буквально 5% людей, еще 5% немного порассуждали и тоже давали ответ. А с еще 5-10% можно было обсудить повторяемость интеграционных тестов, если присутствует БД.
Вторая секция была только для сениоров. Это системный дизайн. Я обратил внимание у автора в статье на "Все это прекрасно работало, но оказалось на рынке нет людей, которые могут пройти этот отбор". Подумалось, что я бы тоже не прошел. Ни разу не писал http сервера, и глубоких знаний внутренностей у меня нет. Мог бы что-то вспомнить просто из опыта. Было дело например парсил входящий поток байтов из сокета. По сути это был кастомный протокол и в тот момент я осознал (прочувствовал), почему http сначала передает хидеры и один из них - это размер запроса. Чтобы знать где остановится. И если обязательные хидеры не получены - это значит полный отказ в обработке запроса.
Так вот, в нашем случае - а у нас бизнес-ориентированные продукты - я давал задание как бы заново спроектировать один из наших продуктов. Прикол был тут в том, что собеседуемый сениор должен был взять этот продукт на себя. Поэтому мы сразу узнавали - как бы он его заговнокодил ?.
Продукт очень простой по бизнес-логике (по сути опросить внешние системы и переложить json-ы в свою БД + отчеты). Но залипательный в плане high-load-а. Я сначала давал человеку вводную, некоторые ограничения и допущения и просил спроектировать как бы первую версию. Далее мы спускались в детали каждой критической точки, где можно было поговорить о таких вещах как обработка ошибок, политики повтора, фоновые задачи и так далее. А затем набрасывал различные сценарии. Причем через часть этих сценариев мы уже прошли сами. Типа "один сервер перестал справляться, хотим добавить еще один - где у вас сломается и что будете делать". Таким образом обсуждали вещи типа подходов к (распределенным) блокировкам и заканчивали плюсами и минусами шардирования и репликацией БД.
Какие тут были интересные моменты. Как и у автора статьи - далеко не все сениоры-хочу-300-тыщ (в те времена это было более менее норм) могли пройти эту секцию. Субъективно один человек рассказал на 90% от необходимого, пара-тройка на 60-80%. Всего сениоров было человек 10-15. И да, судя по тем, кто был у нас на собеседованиях - осознанность в принятии инженерных решений начинается где-то с 10 лет опыта. Но не исключаю, что рок-звезды и 23-летние-сениоры просто не прислали нам резюме.
Факапы. Ну как же без них.
Я забыл, что проходить собеседования - это отдельный навык. И мы не проверяли как человек пишет код. По результатам, посовещавшись, мы решили не давать лайв-кодинг, а выдернули реальный код, который нас смущал, и показывали на собеседованиях с вопросом "что тут не так". К сожалению потребности в найме закончились раньше, чем мы успели обкатать эту идею массово. Но в целом, показалась полезной.
Проблема с мидлами обстояла так же остро, как и с сениорами. Более-менее нормальные мидлы просили 200-250. Или их перехватывали за эту сумму. И мне казалось, что этим людям было бы слишком скучно у нас на задачах мидлов. А вести проект самостоятельно - они бы не вытянули. Я, если я замечал потенциал, пытался некоторым дать секцию системного дизайна с их согласия. Рассказывали где-то 20-40% от необходимого.
В итоге мы немного снизили требования и перешли на джунов (от 1,5-2 года опыта). Все грустно. Не стоит брать джунов, если внутри компании нет ресурсов на менторство. И тем более, в таких случаях, не стоит брать людей, вошедших в айти через курсы, без профильного высшего образования.
И был положительный опыт - был один человек с Иннополиса, с 1,5 года опыта. Это конечно не Стенфорд (я посмотрел некоторые лекции на ютубе - там препод рассказывает о тех вещах, которые я сам узнал за 10 лет), но если бы у меня было такое высшее образование и подход к обучению - это был бы кайф. На голову выше моего. Хотя у меня не МГУ и не баумнка и люди оттуда на собеседование не приходили.
У меня все.
Спасибо что поделились опытом и цифрами. По моей памяти мы нанимали 5% от входного потока. Очень много инженеров были не способны пройти наше собеседование.
Сейчас я строю найм инженеров на новом месте и тут у нас все сильно лучше. Мы уже не пытаемся нанимать "олимпиадников". Но все равно - много людей не понимает что они делают.
Я подготовил задачи на ревью кода и оказывается в индустрии очень слабо с пониманием что такое код ревью. Что уж говорить про написание простого прохода по массиву. В общем попробую как-нибудь про это все написать с примерами задач и решений кандидатов.
У меня были такие. Как правило, когда интервьюер не знает как проводить собеседование, не готов к этой ответственности, он начинает сумбурно спрашивать из своего текущего опыта. Особенно за архитектуру. "Вот мы 2 недели решали задачку, планировали архитектуру, ее суть в том-то" и мне предлагают за 5 минут решить то, на что они потратили за 2 недели. Такой подход очень искажен. Если у интервьюера все ответы, проблематика в кеше хранятся, потому что он этим живёт и прямо сейчас занимается, то кандидат вообще не имеет к этому отношения. И от него требуют всегда быстрого ответа, на изучение чего собеседник тратил сопоставимо больше времени. В итоге интервьюер получает искаженное восприятие.
Именно поэтому надо тратить время на подготовку интервьюверов. Буквально вчера мы внутри обсуждали как и зачем проводим архитектурную секцию у себя. По сути согласовывали майндсет интервьюверов.
Лично я считаю что подготовка к архитектурному интервью это некая форма обучения интервьюверов правильным практикам разработки-проектирования, и это полезно не только для проведения собеседований.
Некоторые компании пишут даже текст для кандидата (чтобы он понимал что будет)
В целом вы правы - моя задача, такая же как и http сервер и будут кандидаты, которые ее не решат. У меня аналогичное мнение про алгоритмы. Уже писал коммент по этому поводу к статье про 600 задач с лит-кода - за 15 18 лет у меня было 2 алгоритмические задачи, и за час их было не решить.
Но у меня не было цели завалить, у меня была цель найти того, кто не завалит проект.
Опыт проводить собеседования - это тоже опыт. Специально меня этому никто не учил. И я готовился к каждому собеседованию. Изучал подробно резюме, отмечал моменты, про которые хотел уточнить, освежал в своей памяти вопросы, которые задавал сам. Да кстати, забыл - после рассказа о компании и до первой секции с вопросами был стандартный вопрос "расскажите о себе" и под шумок я задавал вопросы по резюме.
Как и у автора статьи - далеко не все сениоры-хочу-300-тыщ (в те времена это было более менее норм) могли пройти эту секцию. Субъективно один человек рассказал на 90% от необходимого, пара-тройка на 60-80%. Всего сениоров было человек 10-15. И да, судя по тем, кто был у нас на собеседованиях - осознанность в принятии инженерных решений начинается где-то с 10 лет опыта.
Видимо по нынешним временам звание "сеньор" девальвировалось, и тех сеньоров, которые умеют в инженерные решения, пора называть как-то иначе - "супер-сеньор", "мастер", либо даже просто "инженер".
Кстати в HTTP размер контента необязательное поле. При его отсутствии контентом считается всё что пришло до обрыва соединения. Не знаю насколько это соответствует стандарту. Но 20 лет назад это точно работало.
За алгоритмы грустно, конечно. Вроде бы они дали результат, судя из текста. Но, судя из того же текста, вы ненавидите алгоритмы как и все. Один из комментариев очень показательный: "я исключил полностью из собеседований то, через что проходить мне не нравилось самому". Думаю, вы этому так же подвержены. Все подвержены. В итоге мы получили новое поколение сеньоров, которые ненавидели секцию алгоритмов в бытность джуниором, и теперь секция "проверка способности мыслить" исключена. Теперь комьюнити отрицает алгоритмы и придумывает всяческие причины доказать свою правоту, вымышленные кейсы о незадачливых олимпиадниках. В то время как все мои олимпиадники (я их тренировал ещё будучи студентом) занимают позиции тимлидов и руководителей отделов разработки в своих компаниях. Самое худшее, что может случиться с олимпиадником - заскучает от вопросов архитектуры, потому что в этом нет вызова, это просто рутинная последовательность действий, описанная многими стоковыми фреймворковыми программистами. Любое знание получается со скоростью чтения, в отличие от алгоритмов - тут требуется умение мыслить творчески.
Не понимаю почему вы сделали вывод что я не люблю алгоритмы. Я отношусь к ним нейтрально и воспринимаю как рабочий инструмент. Прямо сейчас я даю алгоритмические задачи в упрощенном виде. Но я не вижу смысла давать алгоритмы на обход графа или сложный поиск в тексте.
Я согласен что есть положительная корреляция между участием в "олимпиадах" и умением писать код. Но я в свою очередь видел большой число "олипиадников", которые не умели писать продакшен код. Возможно это связано с тем, что я работал в компании куда брали любителей алгоритмических задач.
Сложных алгоритмов не надо. Но если честно, обход графа - это очень простая задача. Обход в ширину и глубину надо знать. 6-7 строк ейбоху не сложно. А в остальном хорошо бы знать хотя бы названия алгоритмов, чтобы человек понимал в какую сторону гуглить. Я в свою очередь наблюдал, как компания теряла лидов, из-за того что вовремя не распознала суть проблемы. А всего лишь нужно было знать о существовании такого класса задач как NP. Если знать хотя бы классы задач, уже можно вовремя остановиться и делегировать на алгоритмистов или на аутсорсинг отдать. Эти задачи часто появляются, просто если не знать, то и не поймёшь, что они есть и есть программы для них. Если не знать, то даже не поймёшь, что гуглить, потому что клиент не приходит с постановкой "дан связный двунаправленный граф с весами". На первый взгляд все видят всегда перекладывание джсонов.
А всего лишь нужно было знать о существовании такого класса задач как NP.
Ну то есть столько разговоров про всякие мягкие скиллы, необходимость умения работы в команде и т.д., а по факту всё равно всё сводится к тому что надо знать всё самому? Спектр-то проблем и способов их решения крайне многообразен. Тут опять получается что важнее коллектив самых разношёрстных личностей, чтобы каждый на проблему под своим углом посмотрел. Кто-то увидит NP-задачу, посоветует куда копать, или может сам возьмётся. Кто-то философски посмотрит и скажет что проблема не проблема, т.к. у неё есть более значимые выигрышные стороны если всё оставить как есть. :)
Теперь комьюнити отрицает алгоритмы и придумывает всяческие причины доказать свою правоту, вымышленные кейсы о незадачливых олимпиадниках.
Возможно алгоритмы работали лет 10-20 назад чтобы отобрать лучших из толпы апплящихся в FAANG. Но, первое, вы наверняка не FAANG, и толп талантливых инженеров в ваши Рога и Копыта не наблюдается. Зачем вы им, когда можно сразу в FAANG? Во-вторых, сегодня эта метрика уже настолько геймится и абьюзится в промышленных мастштабах, что можно вообще не уметь программировать и получать оффера от FAANG. Ну, точнее, уметь в том минимальном объёме чтобы воплощать алгоритмы - переменные, условия, циклы. На Блайнде регулярно появляются истории а-ля "взяли на инфру на С++, а я как свинья в апельсинах в этом C++, взял книжку почитать - ничего не понял, подскажите что делать".
Ну зачем же сразу фаанг? В Яндексе из 4х этапов 2 посвящены написанию алгоритмов и ещё один практически про алгоритмы - оптимизационная задачка. Вряд ли можно обвинить Яндекс в слабых программистах. Если компания не может раскрыть потенциал алгоритмистов, это отчасти проблема компании.
Я тоже читал в профильных группах ВК гневные комментарии об алгоритмах (никто не любит этот порог). Это было забавно, потому что ВК написан 2кратным чемпионом мира по программированию (Николай Дуров, не Павел).
Из-за неспособности генерировать оптимизацию и эффективные алгоритмы, эффективные архитекторы зачастую раньше времени скочат на микросервисы, усложняя преждевременно продукт, а "сопливые" связи гордо именуют "слабосвязанностью".
Считаю, что одна секция на алгоритмы хотя бы примитивные должна оставаться. Это отсекает львиную долю залетных вайтишников. Своим стажерам всегда объясняю, что владеть МРТ(читай фреймворки) это хорошо и необходимо для классного врача, но владеть скальпелем обязан каждый.
Ну зачем же сразу фаанг? В Яндексе из 4х этапов 2 посвящены написанию алгоритмов и ещё один практически про алгоритмы - оптимизационная задачка.
Яндекс это отечественный аналог FAANG, поэтому в принципе может позволить хоть алгоритмы, хоть что. Хотя лично я сторонник лотереи. Отсечь совсем уж никаких, и проводить розыгрыш на вакантную позицию. И для кандидатов реальный шанс показать себя в деле какой есть, и для компании diversity. Ибо сейчас bias в сторону алгоритмистов, со всеми из этого печально вытекающими. Хотя бы ради эксперимента какой-то небольшой % можно было бы так набирать.
Узнал Яндекс по тексту.
Какой-то диссонанс, когда человек с одной стороны топит за многоуровневый профессиональный отбор, а с другой стороны сам практически не разбирается в должности, которую замещает. Я имею в виду разного уровня лидов, которые в лучшем случае буклетик юного менеджера пролистали, а при слове педагогика начинают пошло шутить. Чел в статье какбэ толсто намекает, что он высококлассный инженер (как дед из соседнего гаража, который считает, что пока двигатель сам не переберешь пару раз - ездить не научишься), но не объясняет как это делает его хоть сколько-нибудь компетентным человеком в любой иной области человеческого знания. Жду, когда на руководящие должности у программистов будут финансово-расчетные секции и психологические задачки на мотивирование в текущем и перспективном периодах) Вот от таких управленцев от программирования я с удовольствием готов согласиться, что для перекладывания джейсончиков и перекрашивания кнопок я должен крутить разноцветные деревья все свободное время.
Эволюция оценки программиста на интервью