Comments 75
Сейчас я предпочитаю лайв-кодинг на 10-15 минут. Самые ценные 15 минут собеседования.
Как человек, отсобеседовавший >100 инженеров, полагаю, что Вы оптимизируете не совсем ту функцию. Собеседование, - это для большинства хороших инженеров ультрастрессовая ситуация. А лайв кодинг за 15 минут это отдельная, часто соревновательная, деятельность, имеющая мало общего с коммерческим программированием. Поэтому, для меня вполне ок, что отличный спец может написать что-то невнятное и некомпилируемое в таких условиях, особенно, если его ещё и поместить вне комфорта привычной IDE.
Проводя аналогию, если бы я нанимал таксиста, то, наверное, пару кругов на автодроме давали бы некоторую корреляцию с тем, насколько хорош это водитель, как таксист, но, однозначно, это не было бы определяющим фактором.
Ок, согласен, что SQL лайв кодинг имеет смысл, и сам такое спрашиваю, ибо именно в случае SQL лайв-кодинг и реальная работа достаточно близки. Но, в случае языков вроде Java, где концентрированная бизнес-логика составляет малую часть кодовой базы, выглядит, как значительная подмена проверяемой гипотезы.
Аналогично. Я обычно просто формулирую задачу, довольно простую, вроде выдачи сдачи из вендинговой машины и пытаюсь услышать что-то про динамическое программирование. Или про систему бронирования авиабилетов для сотрудников и услышать что-то про графы. Просто за 20+ лет проведения интервью мне гораздо интереснее узнать в чем кандидат хорош, а не в чем я его могу завалить.
Я тоже не пытаюсь никого завалить, но какой-то теорминимум у кандидата должен быть. Если не освоено деление столбиком, то вряд ли он будет разбираться в производных второго порядка.
Если не освоено деление столбиком, то вряд ли он будет разбираться в производных второго порядка.
Вот тут не очень понял, можно поподробнее, по этому примеру?)
Если человек не понимает отличия джойнов (left, right, inner, outer), то вряд ли он когда-то копался в оптимизации запросов. И вряд ли он выдаст что-то приличное как дата-инженер. И не важно на SQL надо написать или на Python (Pandas например). Или сможет сделать и понять схему "звезда" или "снежинка".
Есть базовые вещи, без понимания которых нет надежды на что-то неординарное в решении задач. Никто не пишет сортировки в реальной работе, но какие они бывают надо хотя бы знать.
Я про деление столбиком и производные второго порядка. На мой взгляд, аналогия не совсем корректная и без умения делить столбиком вполне себе можно находить производные второго порядка.
В теории да конечно, но я с такими людьми ещё не сталкивался.
А если в двоичной или шестнадцатеричной системе? Готов поспорить - 90% кандидатов не справятся задачей разделить столбиком два двоичных числа..
Я как то пробовал. Реально жесть. Особенно сложно становиться при переходе через запятую. Что меня поразило, что "оказывается" те дроби, которые для нас (в десятичной системе) имеют конечное число знаков после запятой в других системах превращаются в бесконечные периодические дроби.
Я сейчас понял, что вообще не помню как делить столбиком. Помню как записать, помню как на вид выглядит решение, но как решать не помню.
Хотя могу делить в уме достаточно сложные числа.
Деление столбиком гораздо более сложная операция, чем находжение производной, пусть даже второго порядка. Например на множестве натуральных чисел - деление столбиком довольно нетривиально, а производная второго порядка находится элементарно - ноль! На множестве иррациональных или вообще трансцендентных чисел деление столбиком становится невозможно сложным, и если и возможно поделить столбиком, то только приблизительно, а производная опять таки тупо ноль.
Для полиномов производная второго порядка вычисляется уже не так тривиально, как в случае с числами, но все же полегче, чем деление столбиком полиномов.
Что касается прочих функций, там вообще с делением беда-беда, а производные иногда бывают относительно просты. Например тригонометрические функции. Вы можете столбиком синус на косинус поделить? Ну только в ряды раскладывать, а потом делить полиномы содержащие бесконечно много членов и надеяться, что удасться что то доказать по индукции. Ну а с производными все же попроще.
К сожалению, забыл фамилию, но в СССР один из высококлассных математиков проводил эксперимент по обучению некоторого кол-ва школьников математике, начиная именно с понятий высшей математики и только затем выводя из нее элементарную, как следствие. Перевернул аксиоматику другим боком, так сказать. Как базовые, выбрал какие-то интуитивно понятные образы, коррелирующие с некоторыми понятиями высшей математики. Вроде как, даже у него получилось, хотя дети были отобораны минимально способные, а не кто попало с улицы. Жаль, не помню, фамилию. Но потом проект зарубили и он никуда не пошел в развитие.
Ты можешь себе представить ситуацию, когда не нужно оптимизировать запросы? Если статистика актуальна, все индексы на месте, всё работает ок (данные вертаются за приемлемое время, апдейты апдейтят, инсерты инсертят), - зачем чинить не сломанное? В чём ценность вопросов типа "какое максимальное число строк вернёт (full/inner/left/right - nevermind) джойн таблицы из 10 строк и таблицы из 100 строк". Или зачем нужно знать, что truncate пишет в логи 1 строку, а дилит - по числу удаленных. В чём ценность верного ответа на вопрос "почему селект каунт(*) возвращает 0 и при этом долго работает"?
Согласен, что лайв-кодинг на Java имеет мало смысла, и что как раз пара SQL-запросов дают общую картину о том, может ли человек вообще в голове обработать две таблицы, сджойнить их и просчитать результат. Если кандидат не может в голове сджойнить две таблицы, то у меня большие вопросы к его уровню абстрактного мышления.
Т.е. эта пара sql-запросов как вопрос таксисту "как проехать в аэропорт". Пара кругов на автодроме - это больше похоже на вопрос про `explain query`
Тестовые задания для Java давал обычно оффлайн. Если кандидат присылал маленький проект на maven/gradle с тестами, значит у него вполне себе нормальный уровень. Если ещё и тесты покрывали большую часть случаев - вообще отлично. Здесь как раз можно увидеть как человек понимает экосистему языка, а не только синтаксис.
Я одну таблицу саму с собой не смогу "в голове" сджойнить, возможно - и при этом вполне успешно джойнил десятки таблиц в pl/sql developer. Такая невероятная история.
Ой, я как-то эпически не смог в уме посчитать последствия переноса условий соединения из where в join, который был левый, а не внутренний. Столько нулов собрал лишних...
Собеседование, - это для большинства хороших инженеров ультрастрессовая ситуация
Иногда это видно, и я пытаюсь расслабить кандидата. С другой стороны, это показатель того, как человек справляется со стрессовыми ситуациями. В обычной работе они тоже случаются. А если прод упал и начальник материться на чём свет стоит, что станет делать кандидат, который плохо справляется со стрессом на собеседовании?
А если прод упал и начальник материться на чём свет стоит, что станет делать кандидат, который плохо справляется со стрессом на собеседовании?
Давайте чуть обобщим ситуацию и посмотрим на нее с другой стороны. Посыл тут примерно такой "в работе программиста случаются пожары, которые надо тушить 15-минутным лайв-кодингом, и мне важно, чтобы члены команды делали это хорошо".
И тут я, конечно же, не буду спорить, что ситуация, когда в команде есть компетенция пожаротушения всяко лучше, чем когда ее нет. Но, вот о приоритетах я таки поспорю, ведь ситуация, когда успех (а то и выживаемость) бизнеса зависит от пожаротушения, недопустима в принципе. Да, стрессоустойчивый кандидат потушит пожар, недопустив критичных потерь, с сильно большей вероятностью, чем нестрессоустойчивый, но вероятность успеха даже у кандидатов с самым развитым скиллом пожаротушения все равно недопустимо низка для того, чтобы это было частью оперирования бизнеса.
Вообще, тут тема для большой отдельной статьи, ибо можно и про культуру героизма вспомнить, и про привести примеры реальных компаний, где искусственный перманентный кризис используется как способ мотивации инженеров, но не хотелось бы сильно уходить в антипримеры
Я тоже считаю, что упавшие проды - это плохой признак. Работать надо спокойно, размеренно, с удовольствием и минимальным уровнем стресса. Героизм - это признак плохого менеджмента.
Лайв-кодинг для питонистов, которых я собеседовал, был адовым стрессом. Никто не помнит названия и параметры методов. Циклы пишут с трудом. Объявить класс - целый подвиг. Но это питонисты, к ним отдельный разговор.
А дата-инженер вроде как пользуется SQL каждый день, синтаксис простейший, почему лайв-кодинг должен вызывать стресс? Я прошу всего два запроса: один с 1 джойном, другой - с джойном и группировкой по двум столбцам. Я брал пару кандидатов, которые туго выполнили тестовые задания. В итоге пришлось уволить через пару месяцев. Но все те, кто работают, сделали тестовые задания хорошо. Весьма очевидная корреляция на мой взгляд. Да, не 100% гарантия, но достаточно надёжный показатель.
Вместо выполнения тех.задания по left/right джоин можно было просто спросить что это такое и чем отличается.
это вы весьма лайтово, я если не джуниор позиция то оконные функции всегда спрашиваю
В том-то и прикол, что ладно оконные функции, часть дата-инженеров джойны не понимает. Поэтому практика показала, что достаточно уверенного понимания простых запросов, чтобы в работе показывать себя достаточно хорошо.
Это новинка какая-то для хипстовых субд - оконки? В мс скл они еще в версии 2005 появились, в оракеле емнип в 9-ке точно уже были.
Меня эти вопросы на собесах уже достали, какими оконными ф-ми вы пользовались. Если я назову ratio_to_report, интервьюер сможет рассказать, про что она?
Мне как-то дали SQL задачу (странную). Сказал, что это джойн трёх таблиц, но из-за странности задачи ещё и патриции нужны.
Правильно сказали они. Вот вам ручка и бумага, пишите запрос. Спасибо, но нет. Как и лив-кодинг на 15 минут.
Такая практика тушения заканчивается чем-то типа UPDATE без WHERE
В стрессовой ситуации начальник матерится и ещё больше нагоняет стресса. Лесом начальника
Стрессовая ситуация стрессовой ситуации рознь. Лично для меня ситуация "надо починить за 10 минут начальник материться" гораздо менее стрессовая чем "надо клонировать граф (ну ок, ноу проблем)", но при этом мы будем "стоять у тебя за спиной" и в риал тайме смотреть как ты пишешь (стресс +100)".
Так это легко преодолевается. Чаще коворкайте, пялясь друг другу в экран. Со временем привыкаешь и перестаешь думать о том, что кто то смотрит в монитор.
Не очень удобно, когда удаленно работаешь, это надо каждый день из другой страны коллег возить и еще что-то к чаю им покупать и стулья домой :) А если серьезно, но оно конечно можно в офисе такое устроить, но я не знаю есть ли практическая выгода в этом кроме уменьшения стресса на интервью. То есть польза есть конечно, но на сеньорском слишком дорого для работодателя получается.
Если прод упал, должны быть отлажены CI/CD процессы автоматического или полуавтоматического отката на предыдущую рабочую версию. Когда это поставлено на поток, сделать такой откат - минимально возможное время, зависимо от размера проекта. Только после этого нужно проводить postmortem, то есть по-нашему "разбор полетов" и поиск ошибок. Если в компании поиск причины падения прода проходит по коду в формате ручного code review или ищется по логам (даже если это Sentry) в то же самое время, когда прод уже упал, это признак плохой организации работы. 24/7 так не работает на нормальных энтерпрайзных проектах в нормальных компаниях, чтобы требовалось в условиях стресса срочно искать ошибку, чтобы исправить. Сначала - откат на рабочее состояние, а потом уже - поиск ошибок.
Согласен, в таких стрессовых ситуациях люди могут теряться, особенно если что-то идет не совсем по плану, словами рассказать и описать ход решения вполне, а иногда написать в условном блокноте может вызывать проблемы. В последнее интервью меня просили сделать что-то картинкой, которая приходила в виде 2д массива С стайл указателем на указатель и я просто от усталости и стресса (шел 7й час интервью) в одном месте запутался с разъименованием, но хорошо что объяснить словами подошло. В итоге когда интервью сессия закончилась, интервьювер оставил задачу открытой, я спокойно выдохнул и за 2 минуты все поправил.
Все верно. Помню как давненько тупил на собесе и не мог простейший запрос написать. Дома за 5 минут написал и саму БД с данными и запрос. Юмор в том, что потом проходил собес в материнскую компанию этой конторы и да, тесты оказались теми же (это уже другая история). Еле-еле успел записать решение пока оно не стерлось из памяти, а процесс пошёл сразу же как начал о нем думать. Стрессовая ситуация.
Вместе со мной в тот день проходили собес ещё два чела. Один оказался слишком зазнавшимся и ему отказали сразу. Другой по результатам собеса был гением. Меня взяли по остаточному принципу. По факту сам мог приходить к обеду, а вечером на живую ещё и исправлял свежие косяки тех, кто ходит вовремя. А гений сидел безвылазно с третьим китайским.
Моё мнение собеседование толком вообще не даёт никакого представления о кандидате. Сам собеседовал нескольких человек по необходимости. Обычно выяснял общую мотивацию вникать и разбираться. А конкретные знания ну такое себе. Опять же, на своём примере. В той самой упомянутый выше конторе вскользь имел дело с шарпом, ещё дотнет 3.5. Запись в резюме имелась. На недавней работе в основе была java, но когда появился проект на шарпе, то эту строчку вспомнили. Только вот шарп там уже другой, коре 5.0, т.е. весьма актуальный. Несколько дней и выкатился без проблем. А устраивайся на работу на такую вакансию, меня бы конечно не взяли.
Так что выяснение конкретных знаний совершенно ни о чем не говорит. Как и тест на IQ, который говорит лишь о том как прошёл конкретный тест. Кстати, в детстве так взяли в умную школу моего другана троечника, а меня хорошиста/отличник нет. Где то я там знатно натупил, а он проскочил по нижней границе. Только толку от этого - он все равно не тянул такую учёбу.
Человек может и запрос на собесе написать и накодить что нужно в рамках простой задачки, но в работе быть абсолютно бесполезен.
Ключевой момент для меня в том, что я не ставлю задачу в каждом кандидате найти талант. На это уйдёт много времени и душевных сил. Я пробовал, оно себя не оправдало. Сейчас я ставлю задачу найти подходящего кандидата под свои критерии.
Успехи и ошибки в найме нескольких десятков дата-инженеров говорят о том, что есть тенденция к тому, что кандидаты, успешно прошедшие такие тестовые задания, хорошо показывают себя в реальной работе. Тенденции того, что кандидаты, не справившиеся с тестовым задания, оказываются скрытыми талантами, не наблюдается. На это и опираюсь.
Я допускаю, что иногда мои собеседования дают ложноотрицательный результат (отказ достойному кандидату), но не думаю, что процент таких ошибок очень высок.
Обычно мои вопросы связаны с реальными проблемами, решение которых было достигнуто потом и кровью. Наличие готового ответа будет прекрасно...
Были у меня такие вопросы и накидывал примернон решение и ответы принимались.
А были очень странные ребята, которым накидывал гипотезы, а они их рушили потому и потому... походу пьессы детализируя.
В итоге ждали от меня точное решение их проблемы, которое они нашли всем отделом и хер знает за сколько часов... Ну не тупизм ли спрашивать такое?
Я никогда не жду точного решения проблемы в таком случае. Интересно сколько человек может выдать гипотез и будут ли среди них правильные. Или хотя бы в правильном направлении.
Например, если джавист умеет пользовать профайлером, то скорее всего он капал в сторону оптимизации производительности. Если в случае с падающим джава-приложением кандидат предложит воспользоваться профайлером, это значительно повышает шансы того, что он найдёт и исправит ошибку в реальной работе.
Вообще собеседование больше похоже на некое предсказание: будет толк от человека или не будет. На 100% никогда не скажешь. Но процентов на 80% вполне можно.
При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование…
Без указания на то, за какой срок это все происходит, данные циферки не говорят вообще ничего. 40 собеседований за четыре года, за год, и за два месяца — три большие разницы.
Может оказаться, что подбрасываение монетки имеет сравнимую эффективность.
Просто оставлю ссылку на статью по "проблеме секретаря" https://habr.com/ru/company/skillfactory/blog/522634/
Для кодеров давал задачи на "обратный говнокодинг" на полчаса с обсуждением. Это менее стрессово и отражает бОльшую часть работы - понимать и менять чужой код.
При наличии 4 открытых позиций и с результативностью 10%, получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где-то надо найти.
Тут мой ответ будет прост: если кандидат не готов сделать тестовое задание на 40 минут, тогда жди того, что он откажется делать ту работу, которая покажется ему неинтересной. Пусть этот кандидат будет прекрасным специалистом, но я-то понимаю, что -
Свое время бережем, а на время соискателей плевать? :)
Или так: "если будущий руководитель не готов потратить на собеседование час-два, тогда жди того, что он откажется детализировать ТЗ, которое покажется ему неинтересным."? :)
Или оценка собеседника по его готовности тратить свое время на собеседование работает только в сторону соискателей? :)
Даже не имея практики в тимлидсве, мне кажется даже 40 минут на собес это непозволительно много. Отсеять весь "мусор" можно путём скрининга - 5 минут телефонного звонка вполне будет достаточно чтобы оценить уровень кандидата и понять можно ли его закинуть в шорт-лист или послать. Также замечу, что скрининг - это удел эйчаров, а не тимлидов/СТО. Именно первые должны скринить, т.к. это часть их должностных обязанностей и им за это платят. Описанный выше подход - достаточно устоявшийся и распространенный.
Открыли вы нам Америку этой статьей? Нет, похожие практики уже не раз публиковались.
Умеете структурировать свой опыт и излагать доступно для широких? Да, даже два раза да. Редко встречаемый навык. Снимаю шляпу.
Является ли написанное единственно правильным? Нет, жизнь многограннее, чем может казаться.
Нужно ли спорить с вашим подходом и что-то доказывать вам? Нет, это ваш подход к поиску специалистов в вашу команду.
Стоит ли поблагодарить вас? Да, нашли время поделиться своим взглядом на проблему. Пусть не новым, но в своей статистике добавлю единичку в соответствующую графу.
Я было подумал, что вы за 30 минут успеваете принять решение о том, готовы ли вы платить человеку столько денег, сколько он просит. Но вот это:
Если мой ответ кандидату «да», тогда можно продолжить собеседование и познакомиться получше.
Вы же просто за 30 минут отвечаете себе на вопрос, хотите ли вы дальше его собеседовать или нет? Как мне казалось, у любого интервьювера этот вопрос постоянно крутится в голове фоном. Т.е. по сути человек все время в процессе собеседования раз в 30 секунд отвечает себе на вопрос "прекратить собеседования прямо сейчас, или продолжить и познакомиться получше?". Так что вам ещё есть куда ускориться - с 30 минут до 30 секунд, а то и быстрее!
Натолкнули на интересную идею. Помимо проверки адекватности в предметной области давать простую задачу с решением на каком-нибудь школьном scratch. Желательно в live-режиме. Эта задачка показывает способность человека осваивать новое и навык алгоритмизации в новых условиях.
Технически это очень простое задание.
Хочешь стать крутым HR - перестань массово нанимать джунов на потоке, а переходи на хантинг уникальных спецов.
Но видимо квалификация не позволяет сделать скачёк в развитии - поэтому вместо качественного развития выбираем количественное - чем больше сдадим - тем больше дадут
после собеседования у вас может быть только 2 ответа: «брать» или «не брать». Никаких «может быть», «если не будет других», «решим позже» и прочее.То есть Вы берете на работу первого
5 минут на вхождение в режим собеседования (чтение резюме, вход на звонок)То есть если в резюме имеются ссылки на проекты и достижения, то смотреть их Вам некогда?
Я не боюсь отказать хорошему кандидату по своим каким‑то формальным критериям.Так «по каким-то» или «по формальным»? Если последнее, интересно было бы о них узнать.
Чтобы быстро принимать решение, часто необходимо положиться на чутьё.Вы уверены, что ваше чутьё совпадает с чутьём остальных членов команды? Не получится ли так, что Ваше чутьё скажет про кандидата «хороший», а некоторые члены команды с ним не сработаются?
Также эти вопросы позволяют понять… стрессоустойчивость.Стрессоустойчивость давно исчезла из списка требований в IT-вакансияx. К руководителям пришло понимание, что опускать сотрудников до уровня стресса — себе дороже.
мне важнее увидеть то, как человек пишет код, чем то, что он себе может рассказать.Вы упускаете одну существенную деталь. Собеседование для большинства интровертов айтишников — стресс. Не каждый сможет произвести впечатление живым кодингом перед незнакомым человеком, да еще и в условиях ограниченного времени.
Хотя стоп, у Вас же выше была оценка стрессоустойчивости… Тогда OК. Но такую работу принято называть «работой на галерах».
«Быстрые» собеседования — не миф, но большой объём работы над собой и по анализу проекта и команды.Быстрые собеседования — очередной способ избежать выполнения работы, которую надо выполнять, но не хочется.
Точно так же поступают многие HR: «у нас нет времени на предоставление обратной связи».
Точно так же бывает и в тестировании: «сейчас мы все тесты автоматизируем и ручных тестировщиков можно будет уволить».
Это всё мифы.
Если новую модель самолета нужно тестировать 8 месяцев, значит её нужно тестировать 8 месяцев, и ни днем меньше.
Много вопросов, отвечаю.
То есть Вы берете на работу первого
попавшегосяподходящего, не выбирая лучшего из лучших?
Да. Первого подходящего. Может быть не лучшего, но достаточно хорошего. Главное определиться с уровнем "достаточно". Очень сокращает время поиска.
То есть если в резюме имеются ссылки на проекты и достижения, то смотреть их Вам некогда?
Смотрю всё это на этапе скрининга. Если меня всё устраивает, то я назначаю тех. собеседование. При наличии ссылок на проекты или репозитории, могу оставить себе заметку, что тестовые задания можно не давать, качество кода меня устраивает.
Так «по каким-то» или «по формальным»?
Вы можете определить для себя сами свои критерии. Бывает, что у человека на руках несколько офферов, тогда нужно понять стоит ли дальше вести диалог, что может привлечь его именно в нашу компанию. Или видно, что человек токсичный. Или чувствует себя "звездой", которой все должны.
Вы уверены, что ваше чутьё совпадает с чутьём остальных членов команды?
Уверен. Если собеседую для другой команды, назначаю дополнительный звонок с тем тимлидом. Или всей командой. Но так как я набираю людей, то обычно они все уживаются с друг другом. Беру на себя этот риск.
Стрессоустойчивость давно исчезла из списка требований в IT-вакансияx.
Для разных людей разные ситуации вызывают стресс. Я люблю выступать публично, с удовольствием сам прохожу собеседования. Для кого-то это будет стрессовыми ситуациями. Важно умение человека справляться со своим собственным ощущением стресса. Для кого-то стендап на английском языке будет стрессом. Для кого-то норм. Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.
Собеседование для большинства интровертов айтишников — стресс.
Что же может быть более спокойного для интроверта, чем вернуться к написанию кода, а не отвечать на сложные вопросы, глядя в глаза незнакомому человеку? Вот они таблицы, вот он код, вот сидим спокойно пишем. Код-ревью потом тоже будет стресс вызывать?
Быстрые собеседования — очередной способ избежать выполнения работы, которую надо выполнять, но не хочется.
Сколько по вашему мнению нужно проводить собеседование? Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?
Смотрю всё это на этапе скрининга.Прочитать резюме и оценить код в репозиториях за 5 минут? Это невозможно. Пяти минут хватит лишь для поверхностной оценки, которая вас не устроит как необъективная.
Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.То есть стрессоустойчивость Вы всё-таки оцениваете, хотя это в наше время мало кто делает. Что ж, Ваше право.
вот он код, вот сидим спокойно пишем.Пишем, только не спокойно — времени всего 15 минут.
Код-ревью потом тоже будет стресс вызывать?Нет, не будет. Потому что код-ревью будет проходить не в спешке (вы ведь не сторонник «тяп-ляп и в продакшн?) и в кругу привычной команды, а не под надзирательством человека, которого видишь в первый раз.
Сколько по вашему мнению нужно проводить собеседование?В среднем на техническое собеседование отводится около часа. И это не только мое мнение, так принято в отрасли. Собственно, вы сами упоминаете в статье один час. Разумеется, могут быть исключения в ту или иную сторону.
Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?Само слово „лучший“ подразумевает „самый хороший из имеющихся“. При вашем подходе „берем первого подходящего“ выбрать лучшего не позволит теория вероятностей )
Что касается стресса, то уж точно не стоит давать тестовое задание сеньору с горой подтвержденного опыта.
Не раз наталкивался на кандидатов, которые прекрасно отвечают на теоретические вопросы, но написать SQL‑запрос на позицию дата‑инженера могут с большим трудом.
10+ лет пишу sql-запросы, но не уверен, что с лайв-кодингом справился бы. При том, что те же джава-программисты ко мне за консультациями приходили на предыдущем месте работы.
Удивительно - самые продуктивные собеседования в моей жизни были без всякого кодинга "он-лайн". Максимум тестовое перед основным собеседованием. И удивительно - каким-то магическим образом оказывалось, что команда весьма и весьма продвинута технически.
Самые унылые и бесполезные - там где нужно было "у доски" что-то делать. Особенно этим грешат команды с количеством программеров из Индии более 1 человека.
Но вершиной треша и угара были собеседования в две компании из FAANG причем именно с буквами А и А.
Как я начал проводить технические собеседования за 30 минут