Comments 98
Хочется расплакаться и обнять. Мой опыт подобных собеседований не настолько позитивный. Да, вращение деревьев на доске — ненужный садизм. Да проверять умение мыслить — здравый подход. Но результатом труда разработчика является код, который суть — решение поставленной задачи. Можно сколько угодно разговаривать о способах решения задач и умении обучаться, но talk is cheap, show me the code! Очень часто продемонстрированный код (решения предыдущих задач или поставленных на собеседовании) несет больше информации чем часовые собеседования с кандидатом.
Не хотелось бы чтобы мой посыл расценивался как реверсивный карго-культ (типа: пробовали как у них и оно не работает, значит и у них не работает), но я искренне удивлён такой успешности найма работников. Может быть это просто везение? Жду ещё статистики о работе такого подхода. )
Меня вполне устроило если бы шаг с кодингом был опциональным если у человека есть код на гитхабе. Понравилось резюме? Потрать 5 минут и пролистай код в репозитории, а не насилуй мозги на собеседовании. Возможно к моменту прихода человека на собеседование у тебя кроме "поговорить за жизнь" никаких вопросов к нему уже и не останется.
Вы нанимаете программиста или "человека в коллектив с разносторонним опытом и умением общаться на любые темы от принципов ООП до международной политики и способов высадки полей огурцов методом коврового бомбометания семян"?
Проще говоря - вам шашечки или ехать?
Если первое - вы садите человека писать код, следите за его размышлениями и НЕ МЕШАЕТЕ указаниями того, что бы вы считали правильным.
Если второе - не говорите, что нанимаете программиста.
Вот да.
Программист должен уметь читать и писать код (именно в таком порядке).
Читать - это не только понимать, что делает конкретное выражение, но и уметь видеть за кодом смысл, строить гипотезы, зачем это было написано, почему именно так, осознавать культурные традиции проекта.
Я не встречал не "начитанного" программиста, который бы мог писать простой код, который легко читать и поддерживать.
Читать и писать код на собеседовании можно и должно. )
Программист должен уметь читать и писать код (именно в таком порядке).
В первую очередь программист должен уметь думать и учиться
Ничто так не демонстрирует способность думать и обучаться, как наличие навыков, которые могли появиться только в результате размышлений и обучения.
Talk is cheap. Show me the code.
ТС же ясно сказал, что ему не нужен "человек-функция", у которого на входе - ТЗ, на выходе - код.
В этом смысле мне гораздо больше нравится идея — дать человеку кусок кода, и пропросить сказать свое мнение: что эта штука делает и какие к ней есть мысли по-поводу (покажите, что и как вы бы поправили). Прикол программирования заключается в том, что ~70% времени мы ЧИТАЕМ код (свой, чужой, примеры...), а не пишем. Потом уже можно поговорить про начитанность, софт-скиллы, и т.д.
Музыканты - пример внекорректный. Они ничего не строят. Их труд оценивают только те, кто сидят в зале, а не весь город или весь мир. От того, как они сыграют никто не умрёт, не заболеет, не покалечится, а об их труде максимум напишут в газетах, или покажут по телевизору, и будут просить снова и снова повторить сыграть тоже самое, изо дня в день (а программисты, как мы знаем, ек любят писать один и тот же код).
Правильней будет представлять разработчиков со строителями. Как обычно, мы можем дать тестовый день поработать на стройке, кирпичи потаскать, и оценить насколько он сильный и выносливый, и умеет ли правильно класть кирпичи.
А можем поспрашивать про архитектуру, где и как работал, какие косяки других рабочих исправлял, и как придумывал это делать. Какие здания строил и для чего, как быстро с этим справлялся. От его будущих действий зависит безопасность конструкции, и вообще качество здания.
А можем поспрашивать про архитектуру
строителя?
Почему нет? В разработке же тоже есть отдельная должность архитектор, а есть разработчик. Почему разработчиков тогда спрашивают про архитектуру, а строителя нельзя?)
Может быть потому, что типичный архитектур имеет высшее образование, а типичный каменщик не факт, что пту закончил.
И да, разработчик по мере роста решает всё больше архитектурных задач. Каменщик как клал кирпичи, так и будет класть.
Хотя разумное зерно в вашем вопросе есть, почему каменщика при приёме на работу не просят положить десяток кирпичей? Наверное, потому что в офисе этим не будешь заниматься, грязно.
архитектур имеет высшее образование
Так и сейчас много разработчиков без образования, и вообще есть тренд "у нужно ли оно".
типичный каменщик
Если берём каменщиков, то давайте брать не разработчиков, а кодеров, которым много мозга не надо - пиши вот тут, копипасти так, перекладывай джсоны.
Каменщик как клал кирпичи, так и будет класть.
У нас же здесь аналогии? Если проводить аналогии, то мы берём опытного строителя, которому дали задачу построить дом. Обычный такой домишко на 1 этаж. И вот этому вашему строителю нужно выбрать место, инструменты, технологии, продумать архитектуру, а потом начать всё это строить и закончить проект.
И вот возвращаясь к оригинальной тематике, мы можем дать тестовое задание - потаскать кирпичи, посмотреть как он кладёт кирпичи. Но правильней будет спросить сколько домов он построил, и как он это сделал, с какими трудностями боролся.
С другой стороны, справедливо — никакие две професси нельзя сравнивать по прямой аналогии. Я беру музыкантов в первую очередь по той причине, что там для успеха требуется как природный талант, так и большая работа по его развитию (невозможно стать музыкантом, занимаясь строго по расписанию в муз.школе или училище). Аналогично и у программистов — насколько я могу судить, если у человека нет природной склонности в этом направлении и ОДНОВРЕМЕННО он не чувствует тяги и потребности программировать (для себя/других/whatever) в свое свободное время — ему следует искать себе другую профессию.
Помимо этого, работа программиста имеет довольно странную особенность — мы работаем материальными предметами (клавиатура, экран — и аналогично музыкант работает с клавиатурой, смычком, барабанной палочкой) — но цель работы программиста находится далеко за пределами этих предметов. Манипулируя клавишами и трекпадом — мы оперируем совершенно абстрактными понятиями, пытаясь передать машине наши мысли и идеи по поводу тех или иных проблем окружающего мира. Аналогично, музыкант должен передать эмоции публике через посредство тех инструментов, которые ему даны. Пожалуй вот еще математики точно также работают с абстракциями при помощи записей формул и текстов на бумаге/экране.
Что касается инженерии и архитектуры — тут тоже аналогия справедлива только отчасти. Если вы разрабатываете редуктор — то вы можете его увидеть (сначала на экране CAD, потом в виде макета, потом в виде изделия). Аналогично и архитектор — как правило может увидеть то, что было задумано. Что касается программиста — вы никогда не сможете потрогать синглтон, пощупать стратегию, осмотреть command object. Вы можете взаимодействовать с ними только абстрактно, через среду разработки, отладчик, следы в журналах. В общем, любая аналогия — только аналогия, к сожалению…
Вот музыканты сейчас на вас обидятся!
Почему? Я ничего обидного не написал.
Если вы послушаете одно и то же произведение в исполнении разных оркестров под управлением разных дирижеров
Мне крайне сложно будет оценить разных дирижеров адекватно. Их не послушать одновременно, а память о предыдущем концерте может помнить только отдельные отрывки. В целом, я думаю, что мне понравятся оба.
работа программиста имеет довольно странную особенность — мы работаем материальными предметами (клавиатура, экран)
Но ведь половина работ мира связана с компьютерами, это относится не только к программистам. Куча отделов продаж работают на компьютерах, продают тонны товаров даже никогда не видя их. Даже те же математики сейчас много работают на компьютерах.
Если вы разрабатываете редуктор — то вы можете его увидеть. Что касается программиста — вы никогда не сможете потрогать синглтон.
Редуктор можно подержать в руках, как программист может подержать в руках жесткий диск с кодом, или увидеть результат его работы на компьютере. Но внутрь редуктора не заглянуть, пока тот работает в реальных условиях (upd: хотя если сделать его из стекла, то в принципе можно), как и программист не может потрогать синглтон на включенном современном компьютере (если брать не современные, то можно представить себе огромную комнату из механических переключателей, реализующих в ЭВМ синглтон).
Наверное, здесь ближе аналогия не с редуктором, а например с резистором, в который тоже не заглянуть, как он создает сопротивление. Ведь технологии компьютеров дошли до такой степени, когда их уже нельзя потрогать и покрутить руками.
Вы можете взаимодействовать с ними только абстрактно, через среду разработки, отладчик, следы в журналах.
Тоже самое относится и к редуктору - ты можем посмотреть как он в теории работает в AutoCAD, через датчики в журналах посмотреть сколько он произвёл оборотов, итд.
если у человека нет природной склонности в этом направлении и ОДНОВРЕМЕННО он не чувствует тяги и потребности программировать — ему следует искать себе другую профессию.
Частично с вами согласен, потому-что сам такой, но здесь вам стоит раскрыть мысль шире. Я знаю нескольких отличных разработчиков, которые после работы не могут даже сидеть за компом.
Если же мы говорим о периоде становления и обучения разработчика, то рецепт только один — программировать столько, сколько есть желания и свободного времени. Лучшие разработчики, которых я встречал в жизни — это люди, которые пришли в профессию очень рано: через кружки, родителей, самоучкой, и т.д. Когда другим было интересно играть в карты/в компьютерные игры/whatever — этим было интересно кодить.
И сейчас — если приходит выпускник ВУЗа, который делал только строго лабораторные работы и курсовые проекты, и ничего сверх — он даже не Буратино, а полено из которого этого Буратину еще надо вытесать… А если приходит человек, который хоть что-то пилил для себя или работал с 2-3 курса — с ним уже можно разговаривать. Эта разница чувствуется просто с порога…
И это появилось не вчера и не сегодня. Отец рассказывал, что когда они учились в институте и программировали на чем-то вроде БЭСМ — тоже были те, кому было интересно составлять программу (в кодах!) на бумаге и копаться в перфокартах и распечатке с АЦПУ, и были (в основном) те, кому это было «лишь бы сдать». Просто все люди разные — у одних к тому склонность, у других — к этому…
Умение рассуждать о поведении объектов, которые не сущетсвуют нигде кроме абстрактного мира идей — кроме программистов, присуще также математикам и философам. Большинство математиков по этой причине вполне неплохо осваивают программирование. Однако есть и отличие — в математике отсутствует понятие времени.
Единый раз установленная закономерность — всегда является в математике таковой. Математика сложна именно своими концепциями (я, например, многие из них не способен толком воспринять). Программирование имеет более простые концепции, но много более сложные взаимодействия между ними (во времени). Поэтому бывают хорошие программисты, которые ни разу не математики — и обратно, отличные математики и никакие программисты. Хотя корреляция между способностями к математике и программированию — безусловно есть, и сильная.
Задача музыканта в оркестре - играть, то что ставит дирижёр. Если строить работу вокруг coding monkeys - этот пример будет корректным.
У меня всё же другой подход, поэтому логичнее будет привести аналогию с собеседованием композитора для фильма. Наверное, можно попросить его поиграть Баха, но как это поможет показать его навыки сочинения музыки - не до конца понятно.
В то же время, практика ревью кода на собеседовании - тоже любопытная, хороший подход.
А есть еще камерные, которые должны самосинхронизироваться. И тут тоже прямо напрашивается аналогия между гигантскими корпорациями по созданию ПО и мелкими стартапами.
Вы рано или поздно нарветесь на болтунов, которые или имеют особый тип памяти или уже прошли до вас 20 собесов и нахватались всякого. Они вам за чашкой чая все расскажут: от Java Memory Model до устройства Project Reactor под капотом. А на деле окажутся последними фуфелами. У меня таких в прошлом году было аж двое подряд. Вера в такой вот "добрый" подход к собесам потом сильно пошатнулась.
Сейчас в моей компании обязательный пункт на собесе - код ревью. Бывает прямо удивительно наблюдать, как человек молча смотрит 10 минут в насквозь всратый код и вообще ничего не видит. Хотя только что вещал и про SOLID и про многопоточку.
Не верю, что можно пройти 20 собесов и научиться на них думать и рассуждать. Запомнить аббревиатуру SOLID - да, понять когда и как это стоит применять - нет. Поэтому, собственно, мы и не спрашиваем "энциклопедические вопросы", а везде выводим кандидата на обсуждение
Можете эксперимент провести. Возьмите толкового джуна и дайте ему время подготовиться к вопросам про тот же SOLID. Если не дурак, то сможет за 2-3 дня проштудировать все материалы и мнения на хабре, медиуме и в оригинальных статьях. На словах не хуже вас будет рассуждать про разницу между coupling и cohesion и т.д.
Я 14 лет провожу эксперимент по найму и согласен с автором статьи. В свободной беседе опытного интервьювера обмануть на много сложнее, чем натреннироваться бездумно балансировать красно-чёрное дерево на маркерной доске или лайвкодить. И даже если "болтун" вдруг пролезет каким-то чудом, для фильтрации таких существует испытательный срок.
натреннироваться бездумно балансировать красно-чёрное дерево на маркерной доске или лайвкодить
ну если человек натренировался кодить, то разве не это и надо было? пусть садится и кодит
Нет, не это надо было. Как и всем, нам нужны люди умеющие самостоятельно думать, разрабатывать решения, в идеале проявлять изобретательность, а не просто нажимать заученные последовательности кнопок.
Мне довелось встречать на код-ревью ситуации нарушения принципов этого самого SOLID на ровном месте и полное непонимание соотнесения принципа и написанного кода. Т.е. на коммент - "смотри, тут D в явном виде нарушено - есть причины?" - человек без запинки перескажет принцип и приведет хрестоматийный пример, но не видит аналогичное в своем же коде.
Мне кажется, если человек может за 2-3 дня прочитать тонну текста и научиться связно разговаривать про прочитанное, то быстро научиться программировать он тем более сможет, программировать гораздо проще
Да ну что вы. Нет, конечно, нужен кодинг. Я сам никогда не спрашиваю сложных задач, никогда. Никаких там деревьев и динамических алгоритмов. Только самое простое, пара циклов и ифы. На здравый смысл. 90% не могут и этого написать, увы - с 10+ годами опыта. Еще спрашиваю самые азы computer science (сколько бит в байте и какое количество значений там можно сохранить, например). Результаты удручающие. Это в Долине так, по крайней мере (но в Москве 7 лет назад было похоже). При этом в резюме все шекспиры (но резюме я по сути перестал читать уже давно, ориентируюсь только на самопрезентацию и практические навыки).
Просто в мире инженеров есть те, кто делают, и те, кто не делают. Достаточно бинарная шкала. Никакие даже уровни не важны, джуниор/мидл/синьер - это все не важно, если человек делает. А если не делает, да будь он хоть трижды папа римский, толку-то никакого.
сколько бит в байте и какое количество значений там можно сохранить, например
Если меня такое спросили бы, то я бы в ответ спросил "А сколько по вашему?" И если скажут "восемь", то сразу нах :))
И вот уже кто-то восьмибитовый поставил минус. Про восемь бит тебе на курсах "вайти", наверное, рассказали? :))
И сколько по вашему бит в байте?
А ссылку на стандарт можно? Есть (не знаю писанный или неписанный) стандарт что 8 бит это "октет". А вот про стандарт на число бит в байте интернет до сих пор ничего не говорит.
Меня как-то на интервью, не знаю, с какого перепоя, спросили сколько штатов в США (возможно решили проверить эрудицию). И сами "эрудиты" ожидали стандартный ответ, что полсотни. Лучше все-таки держаться правила спрашивать на интервью только то, в чем ты сам на 100% уверен. А то можно в лужу сесть.
А ссылку на стандарт можно? Есть (не знаю писанный или неписанный) стандарт что 8 бит это «октет». А вот про стандарт на число бит в байте интернет до сих пор ничего не говорит.
IEC 80000-13:2008
In 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.pdf
"Recommended", даже если оно "strongly", это еще не "must" и даже не "should". Есть IEC от 2015 года (более позднее ничего не ищется) где написано, что "platform dependent" и "usually 8", но "usually" это, опять-таки, совсем не "always".
Когда был переход с .NET Framework на .NET Core, то у всех куча кода не работала. Потому что его до этого писали такие "вайтиразработчики" со смузи, что даже в душе не предполагали, что FileName и filename это могут быть разные файлы, а подпапки могут разделяться не обратным слешем а прямым. Так что строить предположения типа "в моём самокате 8 бит, значит везде 8 бит" это совсем не очень.
«Recommended», даже если оно «strongly», это еще не «must» и даже не «should».
И у вас конечно же есть причина не следовать «strongly» рекомендациям стандарта во время интервью или подозревать что интервьювер им не следует?
Есть IEC от 2015 года (более позднее ничего не ищется) где написано, что «platform dependent» и «usually 8», но «usually» это, опять-таки, совсем не «always».
Какой именно IEC? IEC 80000-13?
У меня есть причина заподозрить "мытожеаджайл", где все задачи описываются по принципам "это же очевидно" и "это само собой разумеется". А потом после "все готово" выясняется, например, что существуют вполне реальные люди у которых фамилия всего из одной буквы (сам когда-то с таким работал) или телефоны в которых больше 11 цифр.
Если меня такое спросили бы, то я бы в ответ спросил "А сколько по вашему?" И если скажут "восемь", то сразу нах :))
Ну и чудненько, значит собеседование пройдет просто замечательно - нежелательный кандидат не будет принят. Судя по комментариям, Вы в коллективе будете постоянно вызывать конфликты на ровном месте.
А сколько бит в байте это азы? Мне кажется что немного кто знает что 8 битовый байт называется октет а сам байт не состоит из 8 бит и эти единицы связаны довольно слабо.
Для меня писать код на собеседовании это стресс. Собеседование само по себе немного волнительный процесс, но когда дело доходит до лайв кодинга сразу образовывается пустота в голове. И ведь дают не самые типовые задачи, а задачи для которых нужно время на подумать, а время на собеседованиях как правило ограничено. В этом плане мне проще взять тестовое задание и спокойно его выполнить, чем писать код когда за тобой смотрят.
Успех подхода впечатляет. Возможно, секрет в активном участии 4-5 кандидатов: взгляд с разных сторон помогает лучше увидеть человека.
Я не готов уйти от проверки навыков собственно написания кода. Не раз сталкивался с таким: кандидат выглядит очень привлекательно на этапе разговора про теорию и прежний опыт, а простейший live-coding показывает, что всё грустно.
Ну и есть шанс отпугнуть некоторых кандидатов. Я, например, принципиально не устраиваюсь к работодателям, которые не дают полноценное тестовое (хотя тут надо звёздочку поставить, один раз в стрессовой ситуации нарушал это).
Проведение собеседований - вещь весьма субъективная и как правило малокомпетентная. Вот я, только что, закончил трёхнедельный спринт по 4 - 5 собесов каждый день 5 дней в неделю. Чего там только не было: Домашнее задание с тремя задачами, в каждом из которых были элементарные ошибки, а так же излишне заумные и многословные формулировки. Что интересно, я сделал лишь первое задание и прошёл дальше. Какие-то всем своим видом недовольные и судя по всему не вполне адекватные люди, на втором или третьем техническом собесе, которым вообще непонятно что не понравилось. До сих пор помню какую-то рыжую недовольную тётку. Были конторы, которые меня уговаривали у них работать. Были какие-то совсем стрёмные стартапы в зачаточном состоянии с деньгами на год или даже на пол года. Особенно рассмешил довод молодого основателя одного из таких стартапов: "даже если мы через год закроемся, судя по твоему CV, ты быстро найдёшь новую работу". Был стартап, пишущий софт в помощь отделов кадров компаний, соблюдающих процентный лимит негров и прочих меньшинств в политкорректных странах. Поняв, из вопросов о продукте, мою скрытую неполиткорректность они не только не перезвонили, но даже не прислали материалы о своём продукте, которые обещали прислать. Был какой-то стрёмный стартап про блокчейн, который, видимо, так же просёк мой пессимизм по поводу всех криптовалют на блокчейне. Под конец спринта, когда я, изрядно уставший, наконец получил подходящий офер, начались обиды в других конторах: "мы тебя ждали на собес, а ты не пришёл, редиска", хотя я всегда просил высылать мне приглашения на видео собеседования с указанием телефона кого угодно из компании на случай проблемы. Или обида, что тогда же в финале я отменил фронтальный собес после двух его переносов не по своей воле. Короче я прошёл через тупость, неадекватность и просто элементарную неорганизованность немалого числа собеседователей и даже целых компаний. В очередной раз убедился в правоте мнения, что основная цель собеседования - проверка психологической совместимости. Можно ответить 100% правильно на все вопросы и просто не понравиться психологически, а можно лажать по мелочи почти в каждом ответе и пройти, просто из-за какой-то симпатии.
Людей после курсов по программированию не берете?
А теперь ставим себя на место командира полка, получившего это самое «молодое пополнение». Если ты посадишь летчика в самолет, а он его разложит на взлете или посадке — можно сесть за халатное отношение к обучению и матчасти. Если ты не посадишь его в самолет — у тебя штат укомплектован, и задачи ставят как будто все облетаны. Если ты посадишь его в самолет и будешь учить — значит теперь от боевой работы отвлечен еще и опытный летчик. Короче — что бы ты не сделал, получается еще хуже чем было!
В итоге, выпускники курсов по программированию — могут рассматриваться как кандидаты либо если компания богатая и имеет свой учебный центр, либо если в компании есть избыток опытных разработчиков без проектов и планируется расширение штата (зачем ?!). Только в такой ситуации можно дообучить и добиться выхода годного от программиста после курсов. Можете сколько угодно говорить о вреде высшего образования — но по крайней мере фундаментальные математические/физические дисциплины там будут прочитаны: можно учить дальше, опираясь на эту базу. После курсов нет ничего: ни навыков, ни базы… В лучшем случае — желание и знакомство с терминологией и средой разработки. В худшем — желание получать большую зарплату и умение говорить правильные слова на типовом собеседовании. :-(
И нет, я не против курсов как таковых: технических писателей, ручных тестировщиков — учите сколько хотите. Разработчиков не трогайте. Вы же не пытаетесь на полугодовых курсах хирурга или терапевта с нуля подготовить? Вот и тут не надо…
Ну правила "не брать после курсов" у нас нет. Но и не было людей, которые пришли бы сразу после курсов и были хорошими
Известная холиварная тема - можно ли по навыку X судить о навыке Y?
Полагаю нанимающая сторона в идеале хотела бы проверить как будет справляться кандидат-разработчик с реальной работой. Если отталкиваться от этого допущения, то готов признаться что я - неудачник, немного старомодный и неумелый. Не знаю как у вас, но мои рабочие будни выглядят так - комфортное рабочее место, оснащённое современной техникой и доступом к Интернету, современная кухня. При решении задач из спринта есть возможность взять паузу и выпить чашечку кофе, посоветоваться с коллегами, поразмышлять над проблемными вопросами (каюсь - иногда даже во время прогулки с собакой в выходной), почитать техническую литературу или мануалы и даже (о ужас!) поискать схожие практики в Интернете. А бывает и ещё страшнее - ко мне обращаются товарищи за помощью или мнением - и получают время и внимание. Решительно не получается ежеминутно высекать идеальный код в граните или фонтанировать неоспоримыми архитектурными идеями, каждая из который достигает production. До сих пор не понимаю, почему меня держат и платят за все вышеперечисленное. А еще у меня не стоит над душой персональный "экспертный" надсмотрщик, кривящий губы и раздающий оценки каждому действию.
Резюмируя - большинство пройденных собеседований совсем не похоже на вышеизложенное. Одним словом - работаю себя кое-как за миску похлебки в компаниях, которые сжалились надо мной - сирым и убогим, далеким от проверяемого на собеседовании. Но все безусловно считают, что проверяют именно то, из чего состоит ежедневная работа разработчика. Не разработчик я, не разработчик...
P.S. Ответ на вопрос в первом предложении прост - каждый наниматель нанимает себе и делает так, как считает нужным. Практика автора - весьма любопытна.
Вы всё правильно говорите (хотя сарказма многовато). У меня даже в привычку уже вошло: как затык - так иду чай пить (и это неспроста, немного отвлечься часто помогает).
Однако вы опускаете тот факт, что всё таки в перерывах между кофе вы пишете и читаете код, и с коллегами тоже обсуждаете наверное не только погоду, но и технические моменты.
Я к тому, что в нашу работу входит множество разных вещей, и требуются знания по множеству разных тем, и плюс к тому для выполнения работы нужна куча различных навыков. На собеседовании пытаются проверить все эти вещи, но наивный подход к проверкам работает плохо, и плюс к тому, умение правильно собеседовать - это тоже навык, и он есть далеко не у каждого программиста/тимлида, в итоге имеем то, что имеем...
Практика автора - несомненно интересна. Очевидно, что она проверяет некоторое подмножество навыков кандидата которые он использует в повседневной работе, но далеко не всё.
Можно ли по подмножеству (у автора - это умение думать, наличие собственного мнения, продуктовое мышление и др.) судить о множестве? С некоторой вероятностью, вполне. Но если так, то можно предположить, что если взять другое подмножество (кодинг-скиллы, или навыки по чтению кода, абстрактное мышление, способность крутить деревья), то точно также можно с некоторой вероятностью судить о полном множестве.
Успешность найма в случае автора может быть объяснена тем, что поскольку способность крутить деревья проверяют чаще, люди которые пытаются хакнуть интервью, скорее будут учить деревья, а не продуктовое мышление. Но можно ли хакнуть точно также тест на продуктовое мышление? Я думаю, без проблем...
Такая практика только в вашем проекте или весь VK молодцы?
Долго пытался понять картинку, так как уже жил тогда, когда под собесом понималось другое.
Меня как-то на интервью на синьёра срезали вопросом "Назовите принципы ООП". Удивился сильно, но на автомате выдал "инкапсуляция, наследование, полиморфизм". После чего интервьюер скривился и процедил "ещё абстракция". На этом и закончили.
Я за последние 3 месяца прошел почти 50 собеседований - и с лайвкодингом и с ДЗ и с задачками с литкода. Первые 10 собесов был стресс, потом отпустило. И дела сразу пошли все лучше и лучше. В итоге 7 офферов, все с релокацией
Может мне повезло, но с неадекватами я ни разу не столкнулся. И лайвкодинг кодинг реально нужен, хотя бы небольшой - в резюме можно что угодно написать и ответы на вопросы выучить наизусть. И, кстати, я кое-чему научился за время собесов - интересные вопросы и темы были, о некоторых я не задумывался в процессе работы.
Это прям нирвана в области управления кадрами.
По моему собственному опыту за огромными сложными технически собесами маскировались негативные процессы внутри команд, где за формальностями прятались проблемы взаимодействия между разработчиками (в меньшей степени) и между исполнителями и руководством (в большей). За формальностями (а формальнее кода в принципе не придумать) пытались защитить свои личные позиции в жестокой конкурентной среде руководители. Это, по сути, последнее средство защиты у тех, кто имеет не иллюзорный риск слететь с позиции. Ведь сами подумайте, если тимлид принимает собес и очень активно гоняет по коду, то сложно сказать, что он некомпетентен как руководитель. Вон же он как активно работает, наверно что-то умеет. На моей памяти все хорошие тимлиды, у которых команда укладывалась в назначенные сроки и поддержка кодовой базы без критичных проблем шла годами при постоянном расширении функциональности, могли без проблем за десяток-другой минут составить достаточно полное представление о кандидате, а если кандидат был не из самых сильных, то эффективно помогали расти, если видели потенциал.
Есть, конечно, исключения, где, например, тестовое задание просто необходимо, потому что принимают много джунов и нужно прям реально каждому его давать, дабы не тратить время на откровенно некомпетентные кадры. Или специфика области такая, что без кода ну никак не понять квалификацию. Может быть что-то академическое-математическое, где словами сложнее описывать, чем символами.
Разумеется, субъективный взгляд на полноту не претендующий.
Интересно — в реальной работе кому-то приходилось самостоятельно писать перебалансировку деревьев? Встречались-ли вообще такие задачи, а если встречались, то почему не использовалась библиотечная многократно оттестированная функция, а была потрачена уйма времени на разработку собственного «велосипеда»?
Я в пет-проекте использовал когда-то graphviz для рисования графов (квадратики и стрелочки между ними). Генерировал файл с текстовым описанием и скармливал утилите dot. Получал картинку, и это до поры до времени меня устраивало. Потом захотел рисовать квадратики и стрелочки сам - для большего интерактива. Сунулся в исходники "библиотечной, многократно оттестированной функции", а там такое... В итоге оказалось проще найти соответствующие paper-ы и реализовать алгоритм самому в своём коде. Да, он работает медленнее, чем библиотечный. Да, результат получается менее красивый. Но зато я могу добавлять свои собственные правила (ограничение на число элементов в 1 строке, например), и никого не сломаю.
В общем, сложные алгоритмы пригождаются нечасто. Но зато когда это надо, то просто берёшь и делаешь его. Да и бииблиотечные функции нередко бывают весьма далеки от идеала.
Справедливости ради, стоит добавить, что сейчас код в graphviz стал явно лучше. Судя по графику изменений, там один из авторов весьма активно всё в порядок приводит и чистит. Но 5 лет назад ситуация могла отличаться. Да всё равно, мне мои 300 строчек алгоритма нигде не жмут.
Доводилось.
Причины: производительность, производительность и снова производительность.
В том проекте SOLID похоронен был и даже goto встречались. На C#. Ну а про работу с указателями в данном случае думаю можно и не упоминать.
Но это - скорее исключение из правил.
И да, знание того, как перебалансируются (и вообще устроены) деревья поиска очень помогает при работе с большими объёмами данных.
Хорошая практика, но стоимость для принимающей стороны выше: 4-5 человек выдергиваются из рабочего процесса на час-два, требуется больше внимания. Хотя конечно вам с этим человеком работать потом, так что всё правильно. Другое дело как на это смотрит топ-менеджмент. Хотя, если результаты найма хорошие - вопросов с их стороны быть не должно.
Если кратко резюмировать: разрабы с хорошими хард-скиллами всё равно почти все свалили, поэтому давайте набирать чисто по софт-скиллам. Даже если они совсем не способны работу работать, с ними хотя бы будет приятно общаться.
У меня был опыт принятия человека на работу так, как описано в статье. Печальная история.
Скажите, а как вы отличаете болтунов с хорошим резюме от профессионалов?
Мы-то без программирования людей не берём. Правда на доске не мучаем, конечно. Сажаем в комнату на полтора часа и смотрим, что выйдет
Болтун на то и болтун, что знает вещи только на поверхности. Задавая более глубокие вопросы, дискутируя на какие-то темы, становится понятно, есть ли понимание, или только зубрёж
Умелый болтун знает, как подрулить дискуссией так, чтобы у вас сложилась полная уверенность в его выдающемся профессионализме.
А вот симулировать профессионализм на алгоритмическом лайвкодинге никак невозможно.
Только если вы вообще не шарите в психологии и не способны засечь момент, когда кандидат начал «подруливать дискуссией». А психология вообще ключевой навык любой около-руководящей профессии.
У меня были соискатели, которые на теоретические вопросы отвечали как по книге, любые алгоритмические задачи щёлкали как орешки, на лайвкодинге выдавали образцовые абстракции и паттерны, но были просто надрессированы проходить собеседования. Я таких всегда определял безошибочно, как раз в дискуссии, но моё руководство приходило в восторг и временами продавливало найм. А потом в работе оказывалось, что они способны зазубривать, но не способны понимать, не способны развиваться, неспособны выходить за рамки синтетических задач, неспособны самостоятельно искать и анализировать информацию, не способны понимать бизнес-потребности и разрабатывать решения, раз за разом месяцами допускали очевидные инженерные и эксплуатационные ошибки, хронически изобретали велосипеды вместо использования готовых решений, писали негибкий, а зачастую и нечитаемый код и т.д. и т.п. Проще говоря, были абсолтно бесполезны.
Вот как правило, болтуны и пассажиры очень любят абстракции и паттерны. Это практически лакмусовая бумажка: если на вопрос об архитектуре приложений начинается монолог про паттерны - всё, можно тушить свет. Перед этим попросив ответить на вопрос, чем дизайн приложения отличается от архитектуры?
И чем же отличается? Без сарказма.
Если грубо, то архитектура определяет большей мерой связь между компонентами системы, в т.ч. распределёнными (монолит или клиент-сервер, плагины, микросервисы, протоколы и т.д.), а дизайн - это уже внутренние варианты реализации этих компонент (где могут быть bridge, model-observer, MVC, event loops, да просто код лапшой как вариант, лишь бы интерфейс между модулями соблюдался).
Как то так, наверное.
У нас принципиально нет написания кода на собеседовании. Мы ищем специалистов, а не coding monkeys. Да и термин "Собеседование" подразумевает беседу и общение. Если человек не понимает базовых принципов или пытается "загрузить базаром", то такого пассажира видно сразу, и он не проходит.
В конце концов продуктовое мышление гораздо важнее знания, как называется тот или иной паттерн. Паттерны зазубрить можно, а "думать" уметь надо.
отпугнёшь кандидата на собеседовании своей раздражительностью – твой «корабль» никуда дальше не поплывёт.А я бы предпочел наоборот. Пусть уж лучше интервьюер проявит раздражительность на собеседовании, чем после записи в трудовой книжке кандидата о приеме на работу.
Какой у вас в итоге полный процесс вынесения вердикта по кандидату? Как выставляете оценки?
Безотносительно кода - этапы интервью в стиле "поболтать и посмотреть на адекватность" - бесконечный источник предвзятости, от которого стараются всеми силами избавиться (debiased approach) , вот тут есть немного инфы https://www.beapplied.com/post/interview-bias-explained-and-how-to-prevent-it
Это не только про то, чтобы нанять технически грамотного специалиста, а ещё и обеспечить разноплановость / разнообразие команды (diversity)
Было бы интересно узнать, как с текущим подходом ВК обеспечивает непредвзятость и разнообразие команды. Какое у вас соотношение женщин/мужчин в разработке?
Опять же не могу говорить за весь VK, говорю только за нашу команду. Девочек значительно меньше чем мальчиков, потому что их просто очень мало приходит на собеседования - слишком сильный перекос по полу на рынке. Зато конверсия по ним зашкаливает - из четырёх (если правильно помню) пришедших на собес - двоих взяли.
Теперь сугубо моё личное мнение. Diversity ради diversity - вредно и опасно, нужно работать не над unbiased процессом найма, а над unbiased головами людей. Наша команда построена вокруг культуры, результат этой культуры - наш процесс собеседований и то, как работают наши головы в этой культуре. Мы нанимаем классных людей, какого они пола, возраста или расы - неважно. К слову, у нас в команде был классный разраб возрастом в 54 года - возрастной дискриминации у нас тоже нет.
Что касается оценок - их нет. Мы просто в конце обсуждаем, кто готов человека взять себе в команду, кто нет. У нас нет "объективности" в этом смысле, и я не верю, что она вообще может быть. Как я и говорил в статье - мы ищем члена команды, это больше чем набор функций, а значит - построить "объективный скоринг" - просто невозможно при таких вводных (до тех пор, пока учёные не научатся оцифровывать и оценивать человеческий мозг и его психику). Да и не нужно.
Я в последнее время сошёлся на трёх ключевых вопросах. Но сначала немного гоняю кандидата по основным техническим навыкам (относительно позиции, на которую хочет кандидат). Не столько ради оценки знаний, столько чтоб вогнать человека в состояние «думать про код». А дальше идёт комбо:
А почему ты вообще пошёл в айти? - тут сразу отметаются кандидаты, бегущие за деньгами, обещанными на онлайн-курсах. Высший балл получают те, кто в ответе использовал слово «интерес» - такие с наибольшей вероятностью будут добиваться результата.
А как это получилось? - тут наибольшая ставка на «флэшбеки из прошлого», как начинал кодить в школьные/студенческие времена. Опять же, смотрю на заинтересованность, а не «прочитал что за это платят».
А почему именно <название платформы>? - главный тест на критическое мышление, что с чем сравнивал, какие были критерии, как пришёл к выбору направления. Заодно узнаю, какие технологии кандидат видел по сторонам.
Это конечно все здорово. Вот только все впечатление портят девочки рекрутеры. Буквально недавно, постучалась девочка из vk, красочно все описала, назначила встречу. А на встречу никто не пришёл. На мой, закономерный, вопрос, что это было - игнор.
Собеседования без кода: почему это сработает?