Comments 99
Реальные бизнес-задачи практически всегда сильно связаны с контекстом бизнес-процессов компании, которые практически невозможно транслировать за ограниченное время собеседования.
А какие бизнес-задачи не связаны с контекстом бизнес-процессов?:) Нужно включить воображение и любая бизнесс задача может превратиться в легко-трансируемую и легко-вмещающуюся во временными рамки интервью.
Не уверен в том, что это легко. Возможно у нас разное понимание бизнес-задач. Было бы любопытно увидеть пример бизнес-задачи, контекст которой можно полностью сформулировать за пять минут.
Я, когда провожу собеседования (PHP), задаю обычно довольно древний вопрос о разнице между абстрактным классом и интерфейсом. С одной стороны для ответа на этот вопрос не требуется знание внутренностей PHP, с другой - это неплохая стартовая точка для начала разговора об архитектуре. Таким образом я выясняю несколько вещей сразу: насколько соискатель является действительно опытным разработчиком, насколько хорошо он может коммуницировать с другими (доносить свою точку зрения) и насколько мне будет комфортно с ним взаимодействовать.
Какое собеседование идет 5 минут?
На планированиие, где учавсует команда зачастую не могут полностью декомпозировать задачу.
Наверное вы не поняли мою мысль, не нужно полностью и правильно сформулировать\понять\разложить задачу, нужно увидеть, как мыслит кандидат, как он делает рутинную и ежедневную работу. А рутинная и ежедневная работа состоит не только из кодинга.
Контекст бизнес-процессов действительно отличается в разных компаниях и может быть весьма запутанным. Тем не менее, имея достаточно развитое абстрактное мышление, можно очистить практическую задачу от лишнего контекста и превратить в задачку для собеседования.
Пример:
В разрабатываемой системе существуют проекты (projects), к проектам прикреплены люди (people), также в проектах существуют важные даты (milestones). Система должна присылать участникам проекта напоминания о наступлении очередной важной даты за n рабочих дней до её наступления (например 10). Система не должна присылать уведомления в выходные дни (weekend). Если 10 дней до важной даты приходится на выходной - нужно уведомить заранее, т.е. в пятницу.
Как вы спроектируете подобную фичу?
Я ещё предлагаю подумать, как бы изменился язык и программы на нём, если бы одну из этих фич (интерфейсы или абстрактные классы) создатели выпилили. И что нужно добавить, чтобы не было мучительно больно: множественное наследование? делегаты? конструкцию X, которая решает такую вот типовую задачу Y?
задаю обычно довольно древний вопрос о разнице между абстрактным классом и интерфейсом
Должен константировать, что знание ответа на этот вопрос никак не добавляет плюсов знаниям и умениям разработчика, а также его способности качественно выполнять задачи в срок. Фактически, Вы тратите драгоценное время собеседования на очень незначительные вещи.
Я знаю как минимум 3-ёх программистов PHP, которые ответят вам на этот вопрос, но в в работе она окажутся полными нулями. И знаю одного, который ответит вам на этот вопрос только после «Окей, гугл», но выхлоп за троих. Это то что нужно бизнесу, быстрое корректное решение задачи. Да, он может быть не таким изящным и супер-быстро работающим, но экономить на спичках часто дороже, чем эту экономию проигнорировать.
У меня был один программист, который писал очень красивый код, прям загляденье. Знал все, что только можно было знать о языке программирования. Но с поиском решений для бизнеса было все как-то туго, работу делал очень долго, всегда оправдывая свой подход правильностью кода и до мелочей продуманными алгоритмами (на самом деле не видел дальше своего носа). А взял я его именно потому, что он так хорошо знал ответы на подобные вопросы.
Если вы не наемный интервьюер, то вы не будете страдать фигней, а посмотрите на то, что человек реально сделал до того, как прийти к вам. На то, на сколько он в теме вашего бизнеса. И его знание тонкостей языка программирования уйдет не второй план.
Да, он может быть не таким изящным и супер-быстро работающим, но экономить на спичках часто дороже, чем эту экономию проигнорировать
Видимо, зависит от бизнеса. Бывает и совсем наоборот. Когда во главу угла ставится эффективность решения.
Вот из недавнего. Приходит письмо от сопровождения:
Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться
Т.е. когда-то ответную часть сервиса на нашей стороне написали именно как
быстрое корректное решение задачи
Но прошло немного времени, нагрузка увеличилась и все начало выходить из под контроля - сервис потребляет слишком много ресурсов, работает медленно.
Когда стал смотреть - ужас ужасный. Несколько участков достаточно тяжелого оверкода, фуллскан одной таблицы... Пришлось переписывать все. Править там было бесполезно.
Ушел от оверкода, обошел фуллскан, добавил кешрование результатов предыдущих вызовов. В результат после внедрения от сопровождения получаем:
Коллеги, доброе утро!
Спасибо!
Уже утром видим очень хороший результат!!!
Доработка сокращает потребление процессорных ресурсов почти в 10 раз!
А можно было сразу сделать нормально. Если подойти вдумчиво...
И ситуация не единичная. Это не первый случай, когда приходится заниматься оптимизацией на скорую руку написанного кода, который начинает тормозить.
К сожалению красивый код не оказался чем то особенным и по скорости. Выяснялась страшная правда о том, что написание запросов MySQL и тем более их последующая оптимизация это непостижимая наука для программистов.
Я бы очень удивлен этому. Мы уперлись в то, что программисты не умеют пользоваться Гуглом для решения своих проблем. Ну и как результат, вместо ведения их за руку, мы просто передали более сложные задачи тому самому, который не умел в красивый код, но понимал принципы работы.
Выяснялась страшная правда о том, что написание запросов MySQL и тем более их последующая оптимизация это непостижимая наука для программистов
Простите, конечно, но тут явно прослеживается какой-то внутренний конфликт, который выходит за рамки обсуждаемого вопроса. Я не верю, что нельзя выцепить из рабочего времени пару раз по два часа, чтобы ваш супер-специалист передал сакральные знания оптимизации SQL.
Он работает 24/7 можно сказать, некогда ему выцеплять 2 часа, и он не хочет заниматься образованием работников. Мы не можем его заставить, это не входит в его обязанности.
> задача может превратиться в легко-трансируемую .
НЕ понял.
Предлагаю: Давайте возьмем реальную бизнес-задачу и попросим человека рассказать, как бы он работал над ней. Послушаем какие вопросы он задает, как работает его мышление.
В разных коллективах могут быть разные подходы (вплоть до совершенно кустарно-гнездовых) и опыт собеседующего тоже может быть ограничен. В итоге сложно будет отличить человека который не умеет (и не научится) работать от того кто прямо сейчас еще не умеет работать именно так как принято здесь.
Ответ с другой стороны баррикад: Эм... видите ли какое дело... Тут время от времени люди приходят на собеседование на позицию 150+К и не могут рассказать, в чём таки разница между Array и Linked. И хрен с ним с внутренним устройством. Ладно. На проекте такое же придётся зачем-то писать с нуля в исчезающе малом количестве случаев. Не ведь могут рассказать, в чём разница с точки зрения использования! Я уж не говорю про способность на пальцах прикинуть потребление памяти и процессора для разных случаев.
На просьбу рассказать о том, как организовать передачу данных между двумя потоками (производитель и потребитель) - молчат, как будто пытаешься выпытать секрет философского камня! Есть и те, которые супер отвечают... только после каждого вопроса какой-то очень подозрительный стук клавиш в фоне и задержка с ответом несколько секунд. А потом мы не можем написать блин FizzBuzz, или удалить элементы из массива! - для последнего случая задача звучит так - напишите тело функции void deleteNonSCities(List<City> allCities) {}, которая удаляет из списка все города с названием, начинающимся на букву "C". getName естественно есть... Причём написать предлагаем на стороне соискателя в его IDE, для чего пересылаем Maven проект с юнит тестами, которые собственно и проверяют выполнение задач.
Так что тут дело такое - во первых, поговорить про устройство стандартных классов из библиотеки - это поставить всех соискателей в более-менее равные условия. Во вторых - фильтр, чтобы не тратить своё и соискателя время...
Наверное стоило упомянуть в статье, что теоритические навыки можно знать горазло лучше практических. И иногда человек может быть подготовлен по теории очень хорошо, а на практике, не сможет разбить задачу и понять, что от его нужно. И я не предлагаю пропускать какую либо часть интерьвю, а начинать разговор с тех тем, которые дадут представление о реальном прошлом опыте, а не о том, что человек выучил и зазубрил.
> почему я не прав
Да я бы сказал, что по большей части вы правы — просто вы говорите о плохих собеседованиях, где все ограничивается знанием коллекций. А на самом деле это два разных подхода, которые в идеале лучше сочетать.
Ну и скажем так — вот если посмотреть со стороны кандидата, то меня множество раз спрашивали про коллекции тоже. И никогда я не вдавался в лишние подробности, а рассказывал только общие вещи, типа того, что вот эта коллекция упорядочена, а вот в этой объекты уникальны, и этого всегда хватало спрашивающим.
А разница между LinkedList и ArrayList — вот скажите, вам-то правда не очевидно, чем связанный список отличается от массива? Вы как думаете, отсутствие ответа на такой вопрос совсем ничего не говорит об уровне отвечающего?
Ох, вот в ведь правы, но отвечать на это всё по сотому разу - кошмар, даже уже воспринимается как неуважение. Я бы предложил сразу начинать с вопросов "посложнее", пытаться обсуждать интересные вещи. Если кандидат плывёт - снижать сложность, пытаться нащупать опору.
Ведь собеседование в обе стороны работает, мне как кандидату очень хочется узнать, как и о чем у вас в команде думают, как обсуждают проблемы, какие вообще вопросы считаются интересными. Очередной раз отвечать стандартную муть - не даёт новой информации, и из обратных вопросов её получить намного сложнее.
Языки, фреймворки, библиотеки, базы данных и прочее - это всего лишь инструмент для решения проблемы, и он должен быть подобран под задачу, а не наоборот.
Сюда и самих программистов стоит включить. Люди, а точнее и их знания и умения тоже сами по себе часть вводных при решении задачи.
Если есть для решения задачи больше всего подходит язык X и библиотека Y для этого языка X, а ваша команда состоит из Java программистов (где Java != X), то чаше всего быстрее переизобрести пару велосипедов и вкорячить пару костылей но при этом использовать Java. Потому что хотя решение на Java условно займет месяц, а на языке X всего неделю, но само обучение языку X и способам работы с библиотекой Y может занять два месяца.
Если бы все было так просто...
Кроме времени разработки, есть ведь еще такие факторы как эффективность, масштабируемость, устойчивость и сопровождаемость.
Наверное, есть задачи, которые можно сделать под текущие требования заказчика, сдать, получить свои деньги, а дальше трава не расти.
Но ведь бывает и так, что продукт потом нужно сопровождать. И переделывать, когда (например) клиентская база выросла в полтора раза и текущее решение на Java != X начало тормозить и перестало справляться с нагрузкой. И придется все равно переделывать ее на X потому что X нагрузку держит лучше.
Так что иногда приходится заглядывать вперед при принятии решения.
Есть еще культурная проблема: индийцы научились рассказывать про проекты замечательно, но в большинстве не могут написать fizzbuzz.
Когда начинаешь спрашивать про проекты глубже, они прикидыаются, что не поняли вопроса. А мне же нужно в отчете о собеседовании написать, почему я его не беру. Вот и приходится спрашивать по списку, чтобы честно написать: кандидат не ответил на 9 вопросов из 10.
Рассказ про Array и Linked list выравнивает не только кандидатов, но и культуры.
просто непринужденное общение на технические темы.
Человек пришёл, чтобы получать от вас бабки ежемесячно, а вы ему зубы заговариваете?
Например, рассказать о проектах, в которых принимал участие; рассказать о самом запоминающемся проекте, о самом необычном реализованном алгоритме и т.п
А если человек не участвовал в проектах?
обсудить достоинства и недостатки языков программирования, фреймворков, технологий, операционных систем;
Это собеседование на какую должность? От программиста требуется чтобы он писал код.
Мне например глубоко фиолетовы достоинства и недостатки каких-то языков.
Да они все 100% являются говном.
Мне например глубоко фиолетовы достоинства и недостатки каких-то языков.
Да они все 100% являются говном.
Если вы можете внятно и мотивированно рассказать, почему - это уже само по себе тема для разговора.
Все очень просто! берем 2 ведра - одно с медом, а другое с говном. Зачерпываем ложкой из ведра.... теперь у нас 2 ведра с говном.
В этой аналогии ложкой берут программиста без технического собеседования?)
Человек пришёл, чтобы получать от вас бабки ежемесячно, а вы ему зубы заговариваете?
Это всяко лучше, чем устраивать стресс-тест с вопросами а-ля "назовите различия между версией 1.x и 1.y такой-то технологии/языка". Собеседования, оставившие лично у меня положительные впечатления о конторе, начинались именно как беседа на сопряженные с работой темы, и заканчивались различными кейсами.
А если человек не участвовал в проектах?
Если у него нет ни рабочих, ни пет-проектов - добро пожаловать в стажёры. Часто это даже не уровень джуна, какие бы теоретические знания там ни были.
Мне например глубоко фиолетовы достоинства и недостатки каких-то языков.
Да они все 100% являются говном.
Только один где-то говнистее другого, и надо знать, что где стоит применять, чтобы проект не помер от 100 рпс на хайлоаде из-за одного условного мудака, которому фиолетово, и он решил запилить бэк на паскале.
Обычно собеседующий (технический) хочет узнать не то, что соискатель знает, а наоборот - то, что он не знает.
Если ваши собеседования превратились в скучную рутину с непонятными вопросами, возможно стоит изменить уровень компаний или должность.
Про бизнес, архитектуру и способы решения обычно говорят на system design, а не на техничке.
Обычно собеседующий (технический) хочет узнать то, что он сам хорошо знает. А так как уровень обычно невысок и знания фрагментарны - то и получается, что собеседующий занимается чем угодно, но не оценкой тех. уровня кандидата.
Для ликвидации человеческого фактора есть экзаменационные сайты. Brainbench например. Сажаете кандидата за комп и пусть сдаёт экзамен. Технический собеседующий при этом не нужен и его личные тараканы на результат никак не влияют. А собеседуемый лишён возможности заменить знание теории какой-нибудь харизмой или чем-то там ещё. По результатам экзамена берём топ N человек и приглашаем на поговорить. Срабатывает до уровня мидла, но дальше не очень хорошо срабатывает.
На мой взгляд прав, и на мой субъективный взгляд - проблема в тех же приславутых Soft Skill
По мне Soft Skill - это шапочный термин и очень не точный, из которого растут больше кол-во проблем, ведь в той же школе/институте нет таких обязательных дисциплин как: Логика, Теория аргументации, Ораторское искусства и соответственно на собесах спрашивают, то что знают - а это Hard (алгоритмы, сети, etc...)
Конечно это не отменяет того факта, что кандидаты действительно могут и не уметь в hard и как-то надо отсеивать, да и само собеседование не дешевое удовольствие по времени и силам
У нас в компании реально нет собеседований с заданиями. Мы приглашаем товарища "на разговор", где рассказываем про себя, а человек про себя. Если он в теме и согласен у нас работать - тогда ещё один раунд с генеральным, после чего выдаём оффер с испытательным сроком. По сути, человек сразу начинает работать в коллективе как полноценный сотрудник и получает уже реальные задания базового для нас уровня, а дальше - как пойдет (как справляется). Если в итоге всё всех устроило, то оффер становится бессрочным.
Как показывает практика, именно испытательный срок это и есть лучший фильтр. И, кстати, по моему, был только один случай, когда человек его не прошел и ушёл спустя неделю. В остальных случаях срабатывало.
Хороший подход. Мне он нравится. Именно так устроился на последнее место работы.
Одна проблема, легаси код ужасающий, понабрали просто кого попало.
Действительно, лучший способ проверить, как человек работает — это посадить его работать.
Но у испытательного срока есть свои проблемы — это на порядки дороже и сложнее для компании. Во многих случаех это просто физически не применимо. Если вы не прочь увеличить штат и у вас раз в полгода появляется кандидат, то это работает. Если у вас 10 желающих на одно место, а некторые еще и с релокацией из других городов или даже стран, то это не работает.
Да не, на самом деле не всё так плохо - обычно, товарищ или сам понимает, что "не туда зашёл" и больше не появляется, или сразу видно, что за пассажир - например, если особо много болтает и хвалится - то такой тип и до оффера не дойдёт.
На испытательном сроке - увольнение возможно в любое время (с предупреждением за две недели). На практике не приходилось, обычно люди сами понимали, что не тянут, и уходили тихо-мирно.
Что касается релокации - она полностью возмещается по успешному проходжению испытательного срока. Но, как бы, те, кто был релоцирован, они и испыталку прошли нормально.
обычно, товарищ или сам понимает, что "не туда зашёл" и больше не появляется, или сразу видно, что за пассажир — например, если особо много болтает и хвалится — то такой тип и до оффера не дойдёт.
Этак вы разговорчивых дейстивительно сильных специалистов отсеиваете же! Слишком субъективно к тому же. Что касается, сами понимают… вам никогда не попадались люди, с откровенно поддельными CV? Думаете, на что они надеятся? Это особенно касается больших компаний — считается, что там можно достаточно долго изображать бурную деятельность и получать 5-ти значные зарплаты, ничего не умея. Потом еще и строчкой в резюме можно повышать шансы устройства куда-то еще для просиживания штанов. Таких не много, но они есть.
Потом, а если хороших товарищей все-равно осталось 5, а место в штате одно? Нанять всех 5-рых на испытательный срок и они будут знать, что через пару месяцев 4-ех из них уволят? Как думаете они будут работать? Как хорошо это скейлиться?
И я бы на условие "возмещение релокации только после испытательного срока" ни за что не согласился. Вдруг у фирмы что-то плохо станет, первыми уволят тех, кого можно уволить без компенсации. С испытательного срока. Вдруг выяснится, что в команде менеджер — мудак, и работать там невозможно? Придется весь срок сидеть терпеть, притворятся, что все наравится.
Слишком много рисков для сотрудника. Вы так заранее отталкиваете больше людей, чем отталкивали бы"бесполезными" собеседованиями. Конечно, если нанимаете из других городов. Это, конечно, если вы нанимаете из других городов.
Перечисленные мной минусы очень сложно убрать, если они к вашей ситуации относятся. Если у вас маленький "конкурс" на место, нанимаете практически только местных, и фирма небольшая и не очень распиареная, то испытательный срок, действительно — идеальное решение для вас.
Этак вы разговорчивых дейстивительно сильных специалистов отсеиваете же! Слишком субъективно к тому же.
Ну тут важно, о чём товарищ глаголит. Если он про свой прошлый-текущий проект рассказывает, это одно, а если вещает про абстрактные паттерны в вакууме или длинную карьерную родословную - тут уже сразу понятно, что за петушок пассажир.
вам никогда не попадались люди, с откровенно поддельными CV? Думаете, на что они надеятся? Это особенно касается больших компаний — считается, что там можно достаточно долго изображать бурную деятельность и получать 5-ти значные зарплаты, ничего не умея.
Честно говоря, не попадались, да как бы в разработку такие и не пойдут, вот в маркетинг - то да... Тут ведь именно испытательный срок позволит выявить такого залётного в течении пары недель - потому что "каждый шаг на глазах коллектива".
У меня скорее обратная ситуация была на другой большой компании - люди приходили на работу, а ... работы по сути не было. Наш отдел сильно зависел от другого, который должен был нам инпут давать - ну, и сидел народ по 8 часов, кто там книжку читал, кто интернеты... а что делать...
Потом, а если хороших товарищей все-равно осталось 5, а место в штате одно? Нанять всех 5-рых на испытательный срок и они будут знать, что через пару месяцев 4-ех из них уволят?
Ну, у нас обратная проблема - место есть, а людей нужных - мало. Потому что спец.знания нужны, которые не у всех есть.
В общем, если бы пять хороших сразу пришли - наверное, всех бы и наняли :) Но беда в том, что таких мало...
Такие вопросы на собеседованиях дают представление о базовых знаниях человека
нет, такие вопросы помогают завязать разговор и понять что человек не случайно зашел. Мне рассказывали случай, пришел чувак и сказал, я ничего вообще не знаю, но вы возьмите меня, я учусь быстро и у меня двое детей с женой
Почему мы сосредотачиваемся сразу на разнице между LinkedList и ArrayList?
никто на этом не сосредотачивается, если знает ок, если нет смотрят на его рассуждения, на его поведение. Видел собес чувака, ему задавали простые вопросы, а он уставился в одну точку и какую то чушь малосвязную нес, я абсолютно не понимал его логику и рассуждения. Потом специально спросил коллег, поняли ли они о чем он говорил, и у них такое же впечатление было. Очевидно что человек не смог бы как раз в те вещи про которые вы говорите.
вопросы об ошибках и неточностях в бизнес-логике
ну какие нахрен вопросы о бизнес логике, когда человек не может вывезти простейшие рассуждения? А бизнес логику ему аналитик и прочие коллеги объяснят если он нормально умеет рассуждать
так и подмывает задать вопрос: «А вы-то сами имеете опыт работы с многопоточностью? Вы это спрашиваете, потому что на проекте приходится работать с этим?» Но ты молчишь
а я вот не молчал. Прямо так и спрашивал, иногда обсуждали формальность этого вопроса, иногда я говорил как и что в реальности используется. И это тоже вас определенно характеризует
Давайте возьмем реальную бизнес-задачу и попросим человека рассказать, как бы он работал над ней.
часто так и делают
Во всём этом ПРОЦЕССЕ знание языка и стандартной библиотеки, с которой он поставляется - далеко не на первом месте!
конечно, так и есть. У меня был собес на котором в определенный момент я поплыл, вопросы были правильные, а мои знания поверхностные и унылые, у меня даже самооценка упала. Но я не молчал, что то предлагал, мы обсуждали варианты, как лучше было бы сделать и тд. В итоге меня взяли.
ЗЫ такое ощущение что у вас маленький опыт собесов
такое ощущение что у вас маленький опыт собесов
А ведь вы правы. Действительно, откуда столько статей с хейтом в адрес собеседований? Полагаю, большинство просто их не любит, не умеет проходить и, как итог, это неприятный процесс, который бьёт по самооценке. Я собеседования прохожу в том числе и для фана, для меня это как попытаться пройти очередного босса в игре и меня уже давно не смущают дурацкие вопросы, типа "чем отличается контейнер от виртуалки?".
Такие парни действительно есть, но раз его не увольняют - то это проблема его непосредственного начальника, который не может организовать эффективную работу.
Все как порядочные сидели, работали
Может хватит уже бесплатную работу в ущерб интересам и жизни работника называть "порядочностью" и уж тем более возмущаться тем, что какие-то лодыри люди не хотят отдавать время своей жизни сверх того о чём написано в договоре?
Я понимаю негодование плохой работой данного конкретного человека, но нездоровая тенденция к переработкам, которая культивируется в том числе и нами, линейными работниками, уже поднадоела.
Автор спутал горизонтальное с вертикальным.
Посмотрите на это вот так: Вопросы про Array - это один уровень интервью. Вопросы про бизнес логику - это следующий уровень. Про бизнес логику можно спрашивать "после", но не "вместо". Потому что, если вы начнете их задавать "вместо", к вам сбежится куча народу с "общим пониманием", но без реального опыта.
И потом, где спрашивать про бизнес логику, как не на технических собесах? Есть HR собеседования, технические собеседования, собеседования на soft skills. Мне кажется, технические собеседования как раз и созданы для вопросов про бизнес логику :)
Ну что значит «без реального опыта»? У человека есть резюме, опыт работы, если по минимуму.
Я ещё пойму джуна собесить по главам справочника.
Но не мидла и выше. Здесь можно рассматривать практические комплексные кейсы. Да, их нужно будет заранее подобрать. Но, камон, если не уровень фаанг, то все эти вопросы «про Array» выглядят как неумение собеседовать.
Общение, короткое ТЗ и последующее его обсуждение дадут прекрасные результаты.
Было. Собеседовали человека на middle+ и с опытом работы. Разобрали на словах один не самый простой пример "как бы я делал систему под такие use case". Вроде всё Ок, уже собрались брать - т.е. прямо по окончании собеседования сказать "готовьте документы и приезжайте оформляться" - это ещё до ковида было. Но на всякий случай решили попросить сделать тестовое задание (тут же на ноуте, одно из стандартной пачки). Для уровня кандидата - дел на пять минут, если знает Stream API и Collectors - вообще однострочник. Чисто посмотреть, как пользуется средой разработки и вообще, какой из подходов выберет. Завалился! А глядя на то, как он мучительно выбирал методы из того, что IDEA вываливает в выпадающем списке - у нас как-то сомнения закрались, а после выхода на работу он почитает ЧТЗ и также начнёт тупить?
Ваши сомнения на самом деле не имеют должного обоснования. Человек мог в минуту подзабыть все, что знал из-за стресса или банально не помнить что-то. Если человек технически грамотный и с правильным подходом - он решит эту задачу в спокойном рабочем порядке, сделав небольшой research. Умение найти решение проблемы гораздо важнее непосредственно знаний!
Горизонтальное с вертикальным можно спутать в том случае, когда эти вещи стандартизированы во всех компаниях. А это не так, компания компании - рознь. Где-то офер дают после первого технического собеса, а просы про задачи и понимание процессов опускают, а где-то ровным счетом наоборот. Оба варианты - плохие варианты.
Умение искать пути решения задачи это не техническое интервью, а тестовое задание. Некоторые считают(я правда не в их числе), что тестовые задания - зло. Но тестовые задания на собеседовании, будь то лив кодинг или декомпозиция задачи, стопроцентное зло, потому что собеседование, в том числе и тех интервью - как первое свидание, вы приглядываетесь друг к другу, атмосфера должны быть расслабленная и доверительная. Если вы хотите заставить человека напрягать мозг в условиях ограниченного времени это не способствует сближению. Я на обдумывание задач трачу 2-3 часа в спокойной обстановке, тогда я проявляю свой уровень и потенциал. Интервью не то место, где я могу это качественно делать, так как наивно полагать, что на интервью голова работает так же, как в обычном процессе, скорее она панически выплевывает первое пришедшее в нее решение. Такие задания на интервью это всегда проаерка на стрессоустойчивость, они не дадут ясной картины как человек способен думать в реальной рабочей обстановке, где если механизмы работы выстроены верно, всегда есть достаточно времени на обдумывание.
Полностью согласен с автором. Из огромного числа собеседований, на которых я был в роли соискателя, лишь на одном задали очень простой и элегантный вопрос: как бы ты написал мп3-плеер?
А так приходится частенько задавать контрвопросы в стиле "а у вас действительно в работе эти нюансы используются, или вы просто для галочки спрашиваете?"
Такие статьи нужно начинать с представления себя. "Я, John Doe, собрал пять команд, каждая тянет проект с бюджетом ХХХ, и я хочу рассказать как делать интервью..."
Я вот тимлид, вырастил команду с 4 до 16 человек, проект высоконагруженный, 2млн запросов в час, 24/7.
Мы считаем, что базовые знания - коллекции, GC, основы мультипоточности - необходимое, но не достаточное условие, чтобы нанять хорошего инженера. На второй части - да, даём задание в контексте нашей предметной области. Можно пользоваться интернетом, IDE на свой выбор и всё такое. Некоторые теорию знают хорошо, а новый проект в своей IDE уже сделать не могут. С такими прощаемся.
Я вот тимлид, вырастил команду с 4 до 16 человек, проект высоконагруженный, 2млн запросов в час, 24/7.
Вы, конечно, извините, но это Ваше представление ровным счетом ни о чем не говорит. Нанять 12 человек - да проще простого. 2млн запросов в час - тоже не говорит ни о чем, каких запросов, куда? 24/7 - ну это вообще само собой подразумевается, в 2021-м году-то.
Надо представляться примерно так:
Собеседовал 500, нанял 100, сделали google.com и amazon.com, а в свободное время запускаем ракеты к Марсу.
Ну, я ж про это и говорю - без контекста все советы ни о чем. Там ниже ещё пример привели, что такое высоконагруженное для них - 10к в секунду. Из тех, кого мы берём, они бы наверное одного из 10 взяли. А ко мне приходили кандидаты, для которых вся нагрузка - 3 запроса... в день.
Если вы собеседовали 500 и набрали 100, вот и расскажите, спрашивали про технические знания, или только тестовое, или как вообще набирали. Я бы послушал с интересом. У меня пока около 100 собеседований, наверное, с выхлопной 1 к 4 (я ещё другим командам помагал)
Я даже специально статью написал про тестовые задания ). С уровня Middle+ тестовое задание - это просто трата времени и ничего не говорит про уровень именно разработки, а не написания кода. У сеньора время непосредственно на написание кода уходит 20-30% в среднем, остальное это - сбор требований, планирование архитектуры, взаимодействие с другими членами команды и обсуждение подходов, поиск ошибок, дебаггинг.
Зачем я буду давать тестовое на 3 часа, если человек уже делал гораздо более сложные вещи, может показать какой-то код и обсудить его плюсы-минусы?
Я Вам в качестве примера могу привести Тинькофский NPM-модуль для работы с их API. При том, что сам код написан вполне неплохо и наверняка разработчик у Тинькофф считается сеньором минимум, он имеет массу недоработок, что говорит об отсутствии опыта у разработчика. Один из основных, базовых недостатков - разработчик забыл про таймауты. Или вообще не знал. А это базовые знания для разработки сетевого ПО вобщем и API SDK в частности. Поэтому я совсем не удивлен, что вся их платформа постоянно глючит и народ воет от багов.
Два миллиона запросов в час - это, извините, 600 в секунду,
Высоконагруженая, она же хайлоад, платформа, это хотя бы 10К запросов в секунды.
Так все что меньше, делается чуть ли не с закрытыми глазами.
10К запросов - тоже ни о чем. Мы же не знаем, сколько на бэке серверов обслуживает. Если их там 1000 - то это всего 10 запросов в секунду.
Если что, у нас есть открытая позиция, и даже про релокацию можно поговорить (Польша).
Да, вы правы, у каждого своё понятие высоконагруженности, и сильно зависит от контекста. Но приходили кандидаты, которые сеньёры, но с опытом пилил-проект-три-запроса-в-день-5-лет. Теория ещё кое-как, а вот на live coding всё плохо было.
Автор, расскажите, пожалуйста, о своем опыте. Сколько лет Вы в индустрии? Сколько собеседований прошли? Сколько собеседований провели? Сколько человек наняли? Хотя бы примерный порядок.
Ремарка о 98% в начале намекает на как минимум 50 пройденных собеседований, но что-то мне подсказывает, что это далеко не так.
Я лично провел не одну сотню собесов, могу сказать, что автор прав для уровня хороший Middle+. Какой смысл спрашивать джуниорские вопросы у сеньора про классы - меня это до сих пор удивляет. На 90% сеньор виден из резюме, подтверждается это обычно первыми 5 минутами разговора. Всегда надо помнить - человек берется для решения конкретных задач, а не как советник по документации Java.
На 90% сеньор виден из резюме
Не соглашусь. Посмотрел свою статистику: из 140 последних кандидатов с опытом работы 4 года и выше (из этой цифры вычтен нерелевантный опыт и сомнительный опыт типа фриланса) мы только 31 человека оценили на уровень senior и выше. Добавлю, что все эти кандидаты успешно прошли технический скрининг (15 супер-простых технических вопросов)
Я чот даже пригорюнился.
Уровень в разработке на самом деле мало кореллирует с количеством лет, отданных IT. И смотреть в резюме надо не на количество лет.
А на что смотреть? Объясните, как по резюме понять, что перед вами сеньер а не "сеньер"?
Сам собой напрашивается вопрос: а на что надо смотреть?
Каких либо четких признаков нет, но обычно у хороших сеньоров резюме по возрастающей и должности - только технические, образование можно не смотреть совсем, хотя профильные бауманка или ЛИТМО дадут небольшой плюс, конечно же.
Например - начал с уровня техподдержки, пока учился в универе, потом - пару лет джуниором в одном месте, потом пару лет миддлом в другом, потом сеньором. В описаниях, чем занимался - тоже по возрастающей сложности. Когда сеньорские должности уже - то там "Разработал с нуля". Есть опыт тимлидства - тоже плюсик. Работал в стартапах - еще плюсик.
Вообще резюме бывают и совсем необычно оформленные, но опытный глаз способен выцепить нужное, а в разговоре уже подтвердить или опровергнуть предположения.
Языки, фреймворки, библиотеки, базы данных и прочее - это всего лишь инструмент для решения проблемы, и он должен быть подобран под задачу, а не наоборот.
Мне кажется не совсем все так просто. Задача всегда взаимосвязана с методами реализации. И обычно 99% задач среднего и низкого уровня - уже когда-то и кем-то были решены. И на их решения есть вполне неплохие best practice. Именно на уровне бизнес-логики, но часто и на уровне имплементации.
Поэтому часто просто требуется грамотно классифицировать задачу и привести ее к набору готовых типовых решений. У инженеров уже почти 100 лет есть такой принцип: "Не изобретай (новое) - комбинируй (готовое)". Часто требуется переформулировать задачу и объяснить Заказчику, что новая формулировка - и есть правильная постановка задачи.
Пример: задача учета сырья на складе. Сырье может называться по-разному (разные торговые марки), но это одно и то же химическое соединение. Причем могут быть разные партии, разные производители, разные доставщики... Задачу пытается сформулировать Директор, и тот, кто отвечает за учет на складе. Набор требований, спецификации и т. п. Решение же давно известно, все давно придумано и разработано в наборе стандартных процедур ISO/IEC 15288 и более обще - ISO 15704, в подходе ERP/MRP и даже полная имплементация в Ofbiz.
Изменяется сам подход к учету на складе, используется описанная в указанных стандартах логика. Заказчик сначала не понимает о чем речь, потом приходит в полный восторг, что "даже вот о таких мелочах подумали, все там продумано" - и соглашается, что так сделать лучше. В результате, решается совсем иная задача, но она дает именно тот результат, который хотел Директор. Причем плюс еще 100500 дополнительных "плюшек".
Правильно уточнил, что речь о постсоветском пространстве. Тут как бы всё очевидно: с обеих сторон ушлые люди. Соискатели, не обладая элементарными знаниями, хотят устроиться на позицию 150+ тыр. Представители компании валят вопросами про многопоточность, докер и кафку и прочие кубернетесы, чтобы тупо завалить соискателя и предложить наиболее низкую зарплату ("ну вы же этого не знаете"). С обеих сторон идёт битва за бабло. Всякие там знания и скиллы -- дело десятое.
Технические собесы, конечно, нужны. Хотя бы потому, что мы технари. Но их нужно уметь проводить.
Спрашивать по сотому разу разницу между реализациями листа - значит не уважать ни себя, ни кандидата, ни свое рабочее время. Это иногда напоминает протокольные разговоры о погоде в карикатурном представлении о высшем свете.
У тебя на проекте есть стек технологий и есть стек задач. И у кандидата был стек технологий и стек задач. До сих пор кажется, что не о чем поговорить, кроме линкед листа?
Допустим у тебя Kotlin + Spring + Postgres + Kafka. У кандидата Java + Camel + Oracle + ActiveMQ. Да здесь тупо по сравнительному анализу технологий и их применимости уже разговоров на час. Простой вопрос "в чем разница между kafka и activemq" может невероятно много рассказать о кандидате. Вот хотя бы читал ли он что-то о вашей кафке или надеется "приду - научат".
Но нет. Нам ведь лень читать резюме и вникать в персону кандидата. Лень придумывать вопросы, исходя из контекста. Давайте лучше на всякий случай про линкед лист уточним.
На собеседовании нужно проверять отношение человека к сути своей работы. И наоборот - отношение работодателя к сути своей. Это взаимный реверс инжиниринг уровня ценностей/мотиваций.
>> Почему технические собеседования не нужны
Давайте отбирать по актерским данным (митинговая проактивность, правильные ответы на мотивационные и поведенческие вопросы, способность продать себя заказчику), как на Западе. Ну лягут потом роутеры по всему глобусу, так он все красиво объяснит, все будут довольны.
При чем тут радиоволны и милкшейк?
Ну не набирать же людей "за выслугу лет" или "каждому по потребностям" 😀
По моим наблюдениям более менее соответствует позиции, на которую подаются, лишь каждый третий-пятый. Это не обязательно потому, что кто-то хочет обмануть или много хочет. Просто даже сам по себе диапазон уровней людей, которые именуют себя, например, мидлом, крайне широк. Аналогично ожидания разных компаний и разных проектов тоже сильно разнятся.
Соответственно, вероятность совпасть не так уж высока. Это к тому, нужно ли проверять.
Вопрос, как проверять. Обычно рассказываю о проекте, куда человек собеседуется, ключевые вещи, и прошу рассказать что у человека из опыта релевантно. По ходу рассказа могу задать пару уточняющих вопросов по технике дела. Например, если было многопоточное приложение, то спросить для чего были отдельные потоки, как они взаимодействовали, какие были проблемы. Если человек что-то разработал или хотя бы бакфиксил, это сразу видно. И даёт возможность понять что человек знает, может, насколько профессионально он подходит к работе. Это проверка именно на что человек может.
Обязательно прохожу по всем ключевым технологиям точечно, проверяя знания и понимание как использовать, как устроено. Поговорить по десятку-другому топиков нужно минут 15. Тут получаем понимание и о том, что человек не знает. Опять таки, неплохо спросить, а чем бы человек воспользовался вместо или как бы сам реализовал, если не знает, как устроено. Одно дело просто не использовал или не читал, а другое выяснить как понимает, как думает, как применяет незнакомые технологии.
Кодингом тоже не пренебрегаю. Даже минут 5-10 в условном режиме ХР тоже многое показывают.
В какой-то момент собеседование переключаю на английский
Также вразброс обычно нахожу время поговорить на отвлечённые темы, о текущей команде, процессах. Отвечаю на вопросы
В сумме около часа хватает. Это не так много по сравнению с месяцами, которые ты или твои сотрудники будут менторить, не дай Бог, без последующей отдачи.
Пусть у меня не очень большой опыт хождения по собеседованиям, могу сравнить Украину и Испанию.
Так вот, в Украине это было именно техническое собеседование, там спрашивали как инженера конкретные технические вопросы, некоторые подразумевали правильный и неправильный ответ, некоторые на показать мышление. Результат отбора - команда людей которые реально специалисты.
Испания - это разговор на отвлеченные темы, результат - просто набор случайных людей.
Я сам тут собеседовал людей, люди с 5+ годами опыта в Украине не прошли бы и на Джуна, во всяком случае те человек 7 которые через меня прошли. При чем, я спрашивал именно по тому стеку, который они заявляли, не по нашему, готовы были учить Гошечке за наш счёт.
Я не верю, что человек может эффективно решать задачи, если он не обладает знаниями инструментов с которыми работает. Не видит разных вариантов, их плюсы и минусы, на всех уровнях.
Я за годы собеседований узнал много чего. Но в широкой перспективе - все процессы найма - по сути русская рулетка: кто-то проходит все пять раундов, другой - достает свой сертифицированный кастом-шоп УЗИ и палит себе в голову.
Каждый интервьюер и каждая фирма имеют свои заморочки, равно как и кандидаты.
Собеседовали, было, барышню - СТО, куча наград, топ в каком-то списке (типа Форбс, но уже хрен вспомнишь) - красиво рассказывала про бизнес-достидения, а решить тривиальную программистическую задачу - не могла даже на словах.
Другой случай (целая каста случаев) - когда реально блин талантливых людей, решавших все задачи на отлично и суперски общавшихся резали (или опускали с мида до джуна) менеджеры, потому что человек не мог круто рассказать про бизнес-победы команды в проекте.
Некоторые фирмы (достаточно большие) предпочитают сжигать горы денег временем сотрудников (рекрутеров, менеджеров и разрабов) на интервью чтобы из 50 человек нанять ТОГО САМОГО. И это тоже с долей вероятности может оказаться провалом. Но потратить те же деньги на испытательный срок - жалко.
Золотой середины реально нету - все сводится к уровню проблем, на которых фирма и кандидат согласны балансировать аки акробаты, пока один не решит прервать этот цирк.
Что такое плохой программист? Это человек, не знающий отличия ArrayList от LinkedList. Или начинающий рассказывать, что такой простой вопрос его, великого, недостоин.
Нельзя говорить, что плохого от хорошего отличает знание в разнице между LinkedList и ArrayList. Неужели вы никогда не забывали слов на собеседовании и при этом вы, казалось бы, не сильно волновались. Я понимаю, что разработчик должен вникать в основы и погружаться в глубь языка, но хорошего от плохого отличает его образ и паттерны мыслей в его голове. Неужели нанять перпективного программиста дороже, чем того, который знает "все" и перестал развиваться, хотя может и дешевле. Да, нет тут односложного ответа к сожалению:)
Что такое плохой программист? Это человек, не знающий отличия ArrayList от LinkedList.
Смешно. А если он погуглил за минуту и уже знает отличия, он за минуту стал хорошим?
Кто желает срубить кармы на ровном месте, может перевести и выложить.
У меня не такой большой опыт собеседований, поэтому всё нижусказанное это достаточно большое ИМХО.
Да это круто пообсуждать архитектуру или способы решения задачи, что будешь искать и т.д., но вроде в крупных компаниях для такого существует архитектурная секция, которая вполне себе может варьироваться в зависимости от уровня человека. Причём по каким-то базовым и банальным вопросам станет понятно, а насколько глубоко стоит лезть в эту самую архитектуру. Да и от внутреннего устройства компании всё сильно зависит - где-то тебе могут разложить всё на косточки и тебе даже задумываться толком не придётся, а где-то нужно продумать от и до всю архитектуру и как от вводных перейти к собственно к реализации. Так что здесь всё уникально и зависит от компании.
Следующая проблема в обсжудении архитектуры, на мой взгляд, заключается в том, что это большая нагрузка собственно для интервьювера - да бывают откровенно плохие решения, но ведь их не так много, а всё остальное это балансировка и тебе самому нужно прикидывать в голове тьму этих решений. Причём это совсем не рабочая, а абстрактная задача. И это хорошо, если у тебя одно такое интервью, а если их пять в день - честно мне было бы тяжело, да и скорее всего очень быстро сам себя бы загнал в решение, которое я считаю оптимальным и было бы очень тяжело доказать обратное т.е. интервьювер был бы необъективен по отношению к кандидату.
Ну и третье для завершения так сказать - встречаются как люди с синдромом самозванца, так и наоборот завышающие свои навыки. Их всё таки неплохо как-то отсеивать. Я не могу сказать как на это реагируют по ту сторону экрана, но я когда не знаю как что-то работает в языке, то честно так и говорю - не знаю, но могу предположить, что используется вот такой механизм или вот такой. У этих механизмов есть такие-то плюсы и минусы. Надеюсь это воспрнимается адекватно, потому что ну очень редко это прямо влияет на то как ты кодишь - любой этот вопрос гуглится за пару минут при необходимости.
Итог такой - нет серебрянной пули)
На любом собеседовании человек, который с лету отвечает на все вопросы, обычно overqualified. И в "эту чудесную компанию" работать не пойдет.
Я один из тех людей, которые плохо проходят интервью, но хорошо работают (ну типа). Вот могу завалиться на каком-то джуновском вопросе, но сделать тестовое задание или ответить на более сложный вопрос или банально могу что-то забыть, но знать как это загуглить за секунд 10 и при этом интервьюверы смотрят на меня как на мошенника, который врёт что у него 7+ лет стажа) И после нескольких последних интервью аж бомбит от таких интервью и хочется чисто выучить всё эти вопросы (которые далеки от реальных задач) чтобы утереть нос этим работникам КГБ))
Вам нужно просто чаще ходить по собеседованиям. Это то же своеобразный скилл, который нужно прокачивать. И где то через 5/10/20 собеседований вы уже будете предугадывать какой вопрос сейчас зададут.
Если что и нужно, то это это научиться с первых минут определять кадров, которые строят все интервью на бестолковой банальщине. И не тратить на них свое время.
Поддерживаю. Это весьма полезно по многим причинам. Иногда попадают весьма интересные собеседующие, которые и про стэк расскажут и про инфраструктуру свою, а всегда интересно, на чем в известных компаниях пишут/строят. Ну и конечно можно вполне получить интересные предложения, а там уже и к своему руководству с офером прийти, показать, попросить надбавку.
Как раз это мне и не нужно:)
Я люблю сравнение собеседований с первым свиданием, вы показываете себя, таким, какой вы есть, что-бы девушку не ждал сюрприз в будущем. Точно так же и с компанией, не нужно никого обманывать и предугадывать, ваш работодатель должен знать, кто вы и на что способны.
Хочу заметить, что я не ничего про обман не писал. Не так давно, проработав долгое время на одном месте, я понял, что засиделся и пришло время, что то поменять. Открыл резюме, назначил собеседование. И сел в лужу: на элементарнейшие вопросы я мямлил, как школьник, не сделавший домашку. На следующих собеседования я был уже посмелее и уже через парочку сам болтал больше чем та сторона. Сейчас же меня не смутят ни сложные вопросы, ни лайв кодинг. Я, честно, не вижу здесь никакого обмана, а вы?
А вот ваша аналогия про первое свидание не корректна, так как очень субъективна: большинство парней и девушек на первом свидании притворяются, чтобы произвести впечатление.
Почему технические собеседования не нужны