Задача
За последние несколько лет я значительно изменил свой подход к проведению технических собеседований. Если когда‑то (лет 7 назад) я мог весело и задорно интервьюировать джавистов два часа, то на текущей позиции у меня нет столько времени на каждого кандидата. При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где‑то надо найти. Плюс накинуть 10 минут на переключение между задачами, получается ещё 400 минут (~6.5 часов).
Поэтому я задумался над вопросом повышения эффективности собеседований.
Для себя я сформулировал это следующим образом: как организовать собеседования, чтобы принимать решение о найме в течение 30 минут.
Ограничение по времени достаточно сильное, но тем интереснее анализировать свой опыт и искать способы сократить время, необходимое для принятия решения о найме. Ещё раз подчеркну ключевую мысль: чтобы проводить техническое собеседование за 30 минут, мне нужно научиться принимать решение о найме за эти 30 минут. Тогда при умеренной рабочей загрузке, я смогу увеличить длительность собеседования до 50 или 60 минут, чтобы лучше узнать кандидата. А при значительной рабочей загрузке, я смогу тратить 40 минут на собеседование. Да, нужно быть честным: 5 минут на вхождение в режим собеседования (чтение резюме, вход на звонок), 30 минут само собеседование, 5 минут на написание отзыва для HR и выход из режима собеседования. Как вы понимаете, это идеальный тайминг.
Проанализировав свои предыдущие собеседования, я сформулировал для себя несколько требований и использовал несколько предпосылок к тому, чтобы сократить время одного собеседования, не слишком потеряв в результативности.
Ограничения и предварительные требования
Чтобы понять как решать какую-то задачу, нужно понять или сформулировать ограничения:
Я не могу эффективно проводить больше 2 собеседований в день или всего 7 в неделю. Лучше 1 собеседование в день. Иначе я теряю способность понять и почувствовать кандидата.
Длительность собеседования не должна превышать 1 часа в самом экстремальном случае. Это искусственное ограничение. Смысл его прост: если я за час не понял, хочу ли я работать с этим человеком, значит я не хочу с ним работать.
Чтобы что-то оптимизировать, нужно обладать достаточным эмпирическим и теоретическим опытом. Т.е. ставить себе задачу "быстрых" собеседований в начале проекта не слишком разумно. Ставить себе такую задачу через год и после 20-30 собеседований - вполне реально.
Самое важное - после собеседования у вас может быть только 2 ответа: "брать" или "не брать". Никаких "может быть", "если не будет других", "решим позже" и прочее. Провели собеседование - приняли решение.
Предварительные требования к назначенному техническому собеседованию:
Первичный скрининг проводит HR-специалист. На техсобеседование должен попасть только заинтересованный кандидат, которого устроят наши условия работы. С этим прекрасно справится кто-то из HR-отдела.
Кандидат должен быть одобрен мной. После первичного скрининга, я смотрю резюме и даю добро на проведение собеседования.
Предпосылки для оптимизации собеседований
Что же может позволить сократить время на принятие решения? На какие вопросы нужно ответить самому себе, чтобы понять: как принять решение о найме в течение 30 минут?
Понимание требований к кандидату
Первый вопрос, на который нужно ответить, следующий: насколько хорошо я понимаю требования к кандидату?
Я разделяю требования к кандидату на два разных вопроса:
Что минимально должен уже уметь кандидат?
Чему ему нужно будет научиться?
В начале проекта, особенно если для вас произошла смена технологического стека, ответить на первый вопрос непросто. Значит к нему нужно возвращаться регулярно, смотреть на тех, кто хорошо работает, и особенно на тех, кто работает не очень. Смотреть на свои заметки про их ответы на собеседованиях и как это коррелирует с их текущими успехами на работе.
В своей карьере я смог чётко сформулировать эти требования к бэкенд‑джавистам (8 лет руководства разработкой веб‑приложений) и дата‑инженерам (2 года разработки платформы обработки данных).
Понимание требований к кандидату подводит к следующему важному вопросу —
Возможность сформулировать тестовое задание
Хорошее тестовое задание позволяет ответить как минимум на 4 вопроса:
как кандидат понимает задание, что коррелирует с тем как он будет понимать требования в дальнейшем
как кандидат пишет код, что позволяет понять как он думает и что потом окажется в системе контроля версий.
может ли кандидат выполнять задание до конца
как кандидат относится к требованиям, пытается ли их осмыслить, задаёт ли уточняющие вопросы
Сейчас я предпочитаю лайв‑кодинг на 10–15 минут. Самые ценные 15 минут собеседования. Не раз наталкивался на кандидатов, которые прекрасно отвечают на теоретические вопросы, но написать SQL‑запрос на позицию дата‑инженера могут с большим трудом. Нормальный специалист напишет мои тестовые два запроса минут за 5–7 без ошибок и промахов. И это тестовое задание великолепно коррелирует с тем, как люди потом работают. Просто магическим образом по всем 4 пунктам выше.
Раньше я давал джавистам оффлайн‑задание на 30–40 минут, чтобы было что потом обсудить на собеседовании. Опыт и подход был сразу виден. А если кандидат присылал код, который не работал, то как я мог положиться на такого кандидата в работе? Постоянно контролировать наличие ошибок? Нет, спасибо.
Уважаемый читатель может сказать, что у кандидата не хватит времени делать все тестовые задания от всех компаний. Тут мой ответ будет прост: если кандидат не готов сделать тестовое задание на 40 минут, тогда жди того, что он откажется делать ту работу, которая покажется ему неинтересной. Пусть этот кандидат будет прекрасным специалистом, но я‑то понимаю, что —
Ошибки в найме - это норма
Если кто‑то не ошибался в найме, то пусть первым откажет мне на собеседовании.
Допустить мысль о возможности ошибки жизненно важно. При найме можно допустить две ошибки:
нанять неподходящего
отказать подходящему
Очевидно, что при наличии потока кандидатов пропустить хорошее не так страшно как нанять неподходящего. Даже при отсутствии потока кандидатов лучше не брать неподходящего.
Я не боюсь отказать хорошему кандидату по своим каким‑то формальным критериям. Или в силу личной антипатии, потому что мне с ним ещё работать и работать. Поэтому приходим к тому, что —
Эмпатия и эмоциональный интеллект решают
Чтобы быстро принимать решение, часто необходимо положиться на чутьё. В случае с собеседованиями чутью помогает эмоциональный интеллект. Или ощущение от того, насколько вы сработаетесь с человеком. Иногда с каким‑то очень крутым специалистом невозможно работать в силу его характера. Так зачем оно вам надо? Кандидат должен вписываться в коллектив и команду. А раз уж вы принимаете решение, тогда на ваших плечах, с одной стороны, возможность отказать неприятным кандидатам, а с другой стороны — груз ответственности найти того, кто впишется.
Получается, что вы можете использовать симпатию и антипатию совершенно законно, особенно с учётом того, что ошибка типа «отказ хорошему кандидату» допустима.
Хорошо, разрешили себе полагаться на эмоции («эмоции как данные»), что ещё может помочь быстрее принимать решение?
Вопросы двойного назначения
Помимо тестового задания, я задаю несколько вопросов кандидатам касательно того, как они решали бы некоторые проблемы. Важно, чтобы список вопросов был постоянным. Это позволяет минимально сравнивать кандидатов между собой. И не только кандидатов, но и текущих хороших разработчиков с кандидатами.
Также эти вопросы позволяют понять подход к решению проблем, предыдущий опыт, и стрессоустойчивость. Обычно мои вопросы связаны с реальными проблемами, решение которых было достигнуто потом и кровью. Наличие готового ответа будет прекрасно описывать богатый опыт кандидата, но умение быстро накидать 5–7 гипотез о том, как решить незнакомую проблему, будет даже более ценно.
Попробуйте сформулировать для себя 2 вопроса, которые позволят вам понять, «выживет» ли кандидат на данной позиции или будет постоянно «тормозить».
Всё вместе и сразу
В своей практике я стараюсь объединить все пункты выше и оценивать кандидата одновременно и как технического специалиста и как живого человека. Я понимаю, кто мне нужен как технарь, я чувствую, с кем мне будет приятно работать, и я не боюсь ошибиться.
Я думаю, что каждый может дописать ещё несколько предпосылок, но перечисленное выше стало для меня достаточно формальным обоснованием того, что могу принять решение о найме за 30 минут. Если брать прямо точный тайминг, то он будет следующим:
5 минут я рассказываю о проекте и почему мне важно дать тестовые задания
-
12 минут — тестовые задания
Если тестовые задания сделаны плохо, тогда можно сказать «нет» и пойти делать дела дальше. Итого — 17 минут
5 минут кандидат рассказывает о себе
-
8 минут — теоретические вопросы
После 30 минут я точно должен определить для себя «да» или «нет».
Если мой ответ кандидату «да», тогда можно продолжить собеседование и познакомиться получше.
Можно поменять местами рассказ кандидата о себе и тестовые задания, но мне важнее увидеть то, как человек пишет код, чем то, что он себе может рассказать. Опыт покажет себя даже в самом простом запросе, а вменяемый кандидат не обидится, что я не выслушал его красивый рассказ о себе.
«Быстрые» собеседования — не миф, но большой объём работы над собой и по анализу проекта и команды.
Хороших вам кандидатов и интересных собеседований!
Хочу порекомендовать вам бесплатный вебинар от OTUS, где мы поговорим о важности презентации своих достижений и формирования персонального бренда в рабочей среде. Если вы специалист который считает, что для успешной карьеры достаточно хорошо работать и все про это узнают сами, то наш открытый урок для вас. Изучим, как правильно говорить о своих достижениях с коллегами, руководством и в каком формате, чтобы получить максимальную пользу. Поговорим о том, как помочь своим подчиненным научиться говорить о своих достижениях. Научимся выделять свои достижения и поговорим почему важно это делать регулярно. Научимся планировать достижения и достигать своих профессиональных целей.
Комментарии (71)
stackjava
00.00.0000 00:00+4Обычно мои вопросы связаны с реальными проблемами, решение которых было достигнуто потом и кровью. Наличие готового ответа будет прекрасно...
Были у меня такие вопросы и накидывал примернон решение и ответы принимались.
А были очень странные ребята, которым накидывал гипотезы, а они их рушили потому и потому... походу пьессы детализируя.
В итоге ждали от меня точное решение их проблемы, которое они нашли всем отделом и хер знает за сколько часов... Ну не тупизм ли спрашивать такое?
Kipriz Автор
00.00.0000 00:00+2Я никогда не жду точного решения проблемы в таком случае. Интересно сколько человек может выдать гипотез и будут ли среди них правильные. Или хотя бы в правильном направлении.
Например, если джавист умеет пользовать профайлером, то скорее всего он капал в сторону оптимизации производительности. Если в случае с падающим джава-приложением кандидат предложит воспользоваться профайлером, это значительно повышает шансы того, что он найдёт и исправит ошибку в реальной работе.
Вообще собеседование больше похоже на некое предсказание: будет толк от человека или не будет. На 100% никогда не скажешь. Но процентов на 80% вполне можно.
Mr_Bruce_Wayne
00.00.0000 00:00А нельзя сразу смотреть как у кандидата с оптимизацией производительности?
Kipriz Автор
00.00.0000 00:00Слишком долго. К тому же надо как-то отсечь "профессиональных болтунов", которые рассуждают прекрасно, а вот с конкретными делами у них сложно. Были на моей практике такие уникумы.
anonymous
00.00.0000 00:00НЛО прилетело и опубликовало эту надпись здесь
Kipriz Автор
00.00.0000 00:00Где-то 15% техсобеседований сейчас заканчиваются оффером.
В транскрипте не вижу смысла, потому что никто не будет его перечитывать. Я принимаю решение, я принимаю его сразу после собеседования. Код тестовых заданий и оценки ответов на вопросы сохраняю.
sshikov
00.00.0000 00:00+1При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование…
Без указания на то, за какой срок это все происходит, данные циферки не говорят вообще ничего. 40 собеседований за четыре года, за год, и за два месяца — три большие разницы.Kipriz Автор
00.00.0000 00:004 открытых позиции есть прямо сейчас. Закрыть надо как можно быстрее. А за два года порядка 30 нанятых дата-инженеров.
kemsky
00.00.0000 00:00+5Может оказаться, что подбрасываение монетки имеет сравнимую эффективность.
Kipriz Автор
00.00.0000 00:00Подбрасывание монетки точно даст намного больший процент найма неподходящих людей, так что точно нет =)
AnthonyMikh
00.00.0000 00:00+4То есть вы даже не проверяли нулевую гипотезу и при этом заявляете что-то об эффективности своей методики?
sshmakov
00.00.0000 00:00+2Просто оставлю ссылку на статью по "проблеме секретаря" https://habr.com/ru/company/skillfactory/blog/522634/
olku
00.00.0000 00:00+5Для кодеров давал задачи на "обратный говнокодинг" на полчаса с обсуждением. Это менее стрессово и отражает бОльшую часть работы - понимать и менять чужой код.
denis-isaev
00.00.0000 00:00+6При наличии 4 открытых позиций и с результативностью 10%, получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где-то надо найти.
Тут мой ответ будет прост: если кандидат не готов сделать тестовое задание на 40 минут, тогда жди того, что он откажется делать ту работу, которая покажется ему неинтересной. Пусть этот кандидат будет прекрасным специалистом, но я-то понимаю, что -
Свое время бережем, а на время соискателей плевать? :)
Или так: "если будущий руководитель не готов потратить на собеседование час-два, тогда жди того, что он откажется детализировать ТЗ, которое покажется ему неинтересным."? :)
Или оценка собеседника по его готовности тратить свое время на собеседование работает только в сторону соискателей? :)
scruff
00.00.0000 00:00-1Даже не имея практики в тимлидсве, мне кажется даже 40 минут на собес это непозволительно много. Отсеять весь "мусор" можно путём скрининга - 5 минут телефонного звонка вполне будет достаточно чтобы оценить уровень кандидата и понять можно ли его закинуть в шорт-лист или послать. Также замечу, что скрининг - это удел эйчаров, а не тимлидов/СТО. Именно первые должны скринить, т.к. это часть их должностных обязанностей и им за это платят. Описанный выше подход - достаточно устоявшийся и распространенный.
Kipriz Автор
00.00.0000 00:00Скрининг делается HR-отделом. Ко мне на собеседования попадают только адекватные кандидаты.
Nialpe
00.00.0000 00:00+4Открыли вы нам Америку этой статьей? Нет, похожие практики уже не раз публиковались.
Умеете структурировать свой опыт и излагать доступно для широких? Да, даже два раза да. Редко встречаемый навык. Снимаю шляпу.
Является ли написанное единственно правильным? Нет, жизнь многограннее, чем может казаться.
Нужно ли спорить с вашим подходом и что-то доказывать вам? Нет, это ваш подход к поиску специалистов в вашу команду.
Стоит ли поблагодарить вас? Да, нашли время поделиться своим взглядом на проблему. Пусть не новым, но в своей статистике добавлю единичку в соответствующую графу.
GospodinKolhoznik
00.00.0000 00:00Я было подумал, что вы за 30 минут успеваете принять решение о том, готовы ли вы платить человеку столько денег, сколько он просит. Но вот это:
Если мой ответ кандидату «да», тогда можно продолжить собеседование и познакомиться получше.
Вы же просто за 30 минут отвечаете себе на вопрос, хотите ли вы дальше его собеседовать или нет? Как мне казалось, у любого интервьювера этот вопрос постоянно крутится в голове фоном. Т.е. по сути человек все время в процессе собеседования раз в 30 секунд отвечает себе на вопрос "прекратить собеседования прямо сейчас, или продолжить и познакомиться получше?". Так что вам ещё есть куда ускориться - с 30 минут до 30 секунд, а то и быстрее!
Mishootk
00.00.0000 00:00Натолкнули на интересную идею. Помимо проверки адекватности в предметной области давать простую задачу с решением на каком-нибудь школьном scratch. Желательно в live-режиме. Эта задачка показывает способность человека осваивать новое и навык алгоритмизации в новых условиях.
Технически это очень простое задание.
Ndochp
00.00.0000 00:00Эта задачка будет только показывать, учил ли кандидат стратчу свою дочь/племянника/сам в детстве баловался.
dprotopopov
00.00.0000 00:00-1Хочешь стать крутым HR - перестань массово нанимать джунов на потоке, а переходи на хантинг уникальных спецов.
Но видимо квалификация не позволяет сделать скачёк в развитии - поэтому вместо качественного развития выбираем количественное - чем больше сдадим - тем больше дадут
Mike-M
00.00.0000 00:00+3после собеседования у вас может быть только 2 ответа: «брать» или «не брать». Никаких «может быть», «если не будет других», «решим позже» и прочее.
То есть Вы берете на работу первогопопавшегосяподходящего, не выбирая лучшего из лучших?5 минут на вхождение в режим собеседования (чтение резюме, вход на звонок)
То есть если в резюме имеются ссылки на проекты и достижения, то смотреть их Вам некогда?Я не боюсь отказать хорошему кандидату по своим каким‑то формальным критериям.
Так «по каким-то» или «по формальным»? Если последнее, интересно было бы о них узнать.Чтобы быстро принимать решение, часто необходимо положиться на чутьё.
Вы уверены, что ваше чутьё совпадает с чутьём остальных членов команды? Не получится ли так, что Ваше чутьё скажет про кандидата «хороший», а некоторые члены команды с ним не сработаются?Также эти вопросы позволяют понять… стрессоустойчивость.
Стрессоустойчивость давно исчезла из списка требований в IT-вакансияx. К руководителям пришло понимание, что опускать сотрудников до уровня стресса — себе дороже.мне важнее увидеть то, как человек пишет код, чем то, что он себе может рассказать.
Вы упускаете одну существенную деталь. Собеседование для большинства интровертов айтишников — стресс. Не каждый сможет произвести впечатление живым кодингом перед незнакомым человеком, да еще и в условиях ограниченного времени.
Хотя стоп, у Вас же выше была оценка стрессоустойчивости… Тогда OК. Но такую работу принято называть «работой на галерах».«Быстрые» собеседования — не миф, но большой объём работы над собой и по анализу проекта и команды.
Быстрые собеседования — очередной способ избежать выполнения работы, которую надо выполнять, но не хочется.
Точно так же поступают многие HR: «у нас нет времени на предоставление обратной связи».
Точно так же бывает и в тестировании: «сейчас мы все тесты автоматизируем и ручных тестировщиков можно будет уволить».
Это всё мифы.
Если новую модель самолета нужно тестировать 8 месяцев, значит её нужно тестировать 8 месяцев, и ни днем меньше.Kipriz Автор
00.00.0000 00:00Много вопросов, отвечаю.
То есть Вы берете на работу первого
попавшегосяподходящего, не выбирая лучшего из лучших?Да. Первого подходящего. Может быть не лучшего, но достаточно хорошего. Главное определиться с уровнем "достаточно". Очень сокращает время поиска.
То есть если в резюме имеются ссылки на проекты и достижения, то смотреть их Вам некогда?
Смотрю всё это на этапе скрининга. Если меня всё устраивает, то я назначаю тех. собеседование. При наличии ссылок на проекты или репозитории, могу оставить себе заметку, что тестовые задания можно не давать, качество кода меня устраивает.
Так «по каким-то» или «по формальным»?
Вы можете определить для себя сами свои критерии. Бывает, что у человека на руках несколько офферов, тогда нужно понять стоит ли дальше вести диалог, что может привлечь его именно в нашу компанию. Или видно, что человек токсичный. Или чувствует себя "звездой", которой все должны.
Вы уверены, что ваше чутьё совпадает с чутьём остальных членов команды?
Уверен. Если собеседую для другой команды, назначаю дополнительный звонок с тем тимлидом. Или всей командой. Но так как я набираю людей, то обычно они все уживаются с друг другом. Беру на себя этот риск.
Стрессоустойчивость давно исчезла из списка требований в IT-вакансияx.
Для разных людей разные ситуации вызывают стресс. Я люблю выступать публично, с удовольствием сам прохожу собеседования. Для кого-то это будет стрессовыми ситуациями. Важно умение человека справляться со своим собственным ощущением стресса. Для кого-то стендап на английском языке будет стрессом. Для кого-то норм. Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.
Собеседование для большинства интровертов айтишников — стресс.
Что же может быть более спокойного для интроверта, чем вернуться к написанию кода, а не отвечать на сложные вопросы, глядя в глаза незнакомому человеку? Вот они таблицы, вот он код, вот сидим спокойно пишем. Код-ревью потом тоже будет стресс вызывать?
Быстрые собеседования — очередной способ избежать выполнения работы, которую надо выполнять, но не хочется.
Сколько по вашему мнению нужно проводить собеседование? Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?
Mike-M
00.00.0000 00:00Спасибо за ответы. Прокомментирую со своей стороны.
Смотрю всё это на этапе скрининга.
Прочитать резюме и оценить код в репозиториях за 5 минут? Это невозможно. Пяти минут хватит лишь для поверхностной оценки, которая вас не устроит как необъективная.Я не требую какой-то абстрактной стрессоустойчивости, но умение с ней справляться приветствуется.
То есть стрессоустойчивость Вы всё-таки оцениваете, хотя это в наше время мало кто делает. Что ж, Ваше право.вот он код, вот сидим спокойно пишем.
Пишем, только не спокойно — времени всего 15 минут.Код-ревью потом тоже будет стресс вызывать?
Нет, не будет. Потому что код-ревью будет проходить не в спешке (вы ведь не сторонник «тяп-ляп и в продакшн?) и в кругу привычной команды, а не под надзирательством человека, которого видишь в первый раз.Сколько по вашему мнению нужно проводить собеседование?
В среднем на техническое собеседование отводится около часа. И это не только мое мнение, так принято в отрасли. Собственно, вы сами упоминаете в статье один час. Разумеется, могут быть исключения в ту или иную сторону.Как его спланировать, чтобы избежать стресса с обеих сторон и найти лучших специалистов?
Само слово „лучший“ подразумевает „самый хороший из имеющихся“. При вашем подходе „берем первого подходящего“ выбрать лучшего не позволит теория вероятностей )
Что касается стресса, то уж точно не стоит давать тестовое задание сеньору с горой подтвержденного опыта.
velipre_xella
00.00.0000 00:00Не раз наталкивался на кандидатов, которые прекрасно отвечают на теоретические вопросы, но написать SQL‑запрос на позицию дата‑инженера могут с большим трудом.
10+ лет пишу sql-запросы, но не уверен, что с лайв-кодингом справился бы. При том, что те же джава-программисты ко мне за консультациями приходили на предыдущем месте работы.
Ivan22
00.00.0000 00:00+1но без лайф кодинга ну совсем никак. Я таких индусов собеседовал, соловьем заливаются на теории, как чатGPT прямо, а первый простейший же лайф код показывает такое дно...
megamrmax
00.00.0000 00:00+1Удивительно - самые продуктивные собеседования в моей жизни были без всякого кодинга "он-лайн". Максимум тестовое перед основным собеседованием. И удивительно - каким-то магическим образом оказывалось, что команда весьма и весьма продвинута технически.
Самые унылые и бесполезные - там где нужно было "у доски" что-то делать. Особенно этим грешат команды с количеством программеров из Индии более 1 человека.
Но вершиной треша и угара были собеседования в две компании из FAANG причем именно с буквами А и А.
akakoychenko
Как человек, отсобеседовавший >100 инженеров, полагаю, что Вы оптимизируете не совсем ту функцию. Собеседование, - это для большинства хороших инженеров ультрастрессовая ситуация. А лайв кодинг за 15 минут это отдельная, часто соревновательная, деятельность, имеющая мало общего с коммерческим программированием. Поэтому, для меня вполне ок, что отличный спец может написать что-то невнятное и некомпилируемое в таких условиях, особенно, если его ещё и поместить вне комфорта привычной IDE.
Проводя аналогию, если бы я нанимал таксиста, то, наверное, пару кругов на автодроме давали бы некоторую корреляцию с тем, насколько хорош это водитель, как таксист, но, однозначно, это не было бы определяющим фактором.
Ок, согласен, что SQL лайв кодинг имеет смысл, и сам такое спрашиваю, ибо именно в случае SQL лайв-кодинг и реальная работа достаточно близки. Но, в случае языков вроде Java, где концентрированная бизнес-логика составляет малую часть кодовой базы, выглядит, как значительная подмена проверяемой гипотезы.
tessob
Аналогично. Я обычно просто формулирую задачу, довольно простую, вроде выдачи сдачи из вендинговой машины и пытаюсь услышать что-то про динамическое программирование. Или про систему бронирования авиабилетов для сотрудников и услышать что-то про графы. Просто за 20+ лет проведения интервью мне гораздо интереснее узнать в чем кандидат хорош, а не в чем я его могу завалить.
Kipriz Автор
Я тоже не пытаюсь никого завалить, но какой-то теорминимум у кандидата должен быть. Если не освоено деление столбиком, то вряд ли он будет разбираться в производных второго порядка.
whoisking
Вот тут не очень понял, можно поподробнее, по этому примеру?)
Kipriz Автор
Если человек не понимает отличия джойнов (left, right, inner, outer), то вряд ли он когда-то копался в оптимизации запросов. И вряд ли он выдаст что-то приличное как дата-инженер. И не важно на SQL надо написать или на Python (Pandas например). Или сможет сделать и понять схему "звезда" или "снежинка".
Есть базовые вещи, без понимания которых нет надежды на что-то неординарное в решении задач. Никто не пишет сортировки в реальной работе, но какие они бывают надо хотя бы знать.
whoisking
Я про деление столбиком и производные второго порядка. На мой взгляд, аналогия не совсем корректная и без умения делить столбиком вполне себе можно находить производные второго порядка.
Lizdroz
В теории да конечно, но я с такими людьми ещё не сталкивался.
DmitryZlobec
А если в двоичной или шестнадцатеричной системе? Готов поспорить - 90% кандидатов не справятся задачей разделить столбиком два двоичных числа..
GospodinKolhoznik
Я как то пробовал. Реально жесть. Особенно сложно становиться при переходе через запятую. Что меня поразило, что "оказывается" те дроби, которые для нас (в десятичной системе) имеют конечное число знаков после запятой в других системах превращаются в бесконечные периодические дроби.
BTRchik
Я сейчас понял, что вообще не помню как делить столбиком. Помню как записать, помню как на вид выглядит решение, но как решать не помню.
Хотя могу делить в уме достаточно сложные числа.
GospodinKolhoznik
Деление столбиком гораздо более сложная операция, чем находжение производной, пусть даже второго порядка. Например на множестве натуральных чисел - деление столбиком довольно нетривиально, а производная второго порядка находится элементарно - ноль! На множестве иррациональных или вообще трансцендентных чисел деление столбиком становится невозможно сложным, и если и возможно поделить столбиком, то только приблизительно, а производная опять таки тупо ноль.
Для полиномов производная второго порядка вычисляется уже не так тривиально, как в случае с числами, но все же полегче, чем деление столбиком полиномов.
Что касается прочих функций, там вообще с делением беда-беда, а производные иногда бывают относительно просты. Например тригонометрические функции. Вы можете столбиком синус на косинус поделить? Ну только в ряды раскладывать, а потом делить полиномы содержащие бесконечно много членов и надеяться, что удасться что то доказать по индукции. Ну а с производными все же попроще.
AYamangulov
К сожалению, забыл фамилию, но в СССР один из высококлассных математиков проводил эксперимент по обучению некоторого кол-ва школьников математике, начиная именно с понятий высшей математики и только затем выводя из нее элементарную, как следствие. Перевернул аксиоматику другим боком, так сказать. Как базовые, выбрал какие-то интуитивно понятные образы, коррелирующие с некоторыми понятиями высшей математики. Вроде как, даже у него получилось, хотя дети были отобораны минимально способные, а не кто попало с улицы. Жаль, не помню, фамилию. Но потом проект зарубили и он никуда не пошел в развитие.
velipre_xella
Ты можешь себе представить ситуацию, когда не нужно оптимизировать запросы? Если статистика актуальна, все индексы на месте, всё работает ок (данные вертаются за приемлемое время, апдейты апдейтят, инсерты инсертят), - зачем чинить не сломанное? В чём ценность вопросов типа "какое максимальное число строк вернёт (full/inner/left/right - nevermind) джойн таблицы из 10 строк и таблицы из 100 строк". Или зачем нужно знать, что truncate пишет в логи 1 строку, а дилит - по числу удаленных. В чём ценность верного ответа на вопрос "почему селект каунт(*) возвращает 0 и при этом долго работает"?
Kipriz Автор
Согласен, что лайв-кодинг на Java имеет мало смысла, и что как раз пара SQL-запросов дают общую картину о том, может ли человек вообще в голове обработать две таблицы, сджойнить их и просчитать результат. Если кандидат не может в голове сджойнить две таблицы, то у меня большие вопросы к его уровню абстрактного мышления.
Т.е. эта пара sql-запросов как вопрос таксисту "как проехать в аэропорт". Пара кругов на автодроме - это больше похоже на вопрос про `explain query`
Тестовые задания для Java давал обычно оффлайн. Если кандидат присылал маленький проект на maven/gradle с тестами, значит у него вполне себе нормальный уровень. Если ещё и тесты покрывали большую часть случаев - вообще отлично. Здесь как раз можно увидеть как человек понимает экосистему языка, а не только синтаксис.
velipre_xella
Я одну таблицу саму с собой не смогу "в голове" сджойнить, возможно - и при этом вполне успешно джойнил десятки таблиц в pl/sql developer. Такая невероятная история.
Ndochp
Ой, я как-то эпически не смог в уме посчитать последствия переноса условий соединения из where в join, который был левый, а не внутренний. Столько нулов собрал лишних...
Kipriz Автор
Иногда это видно, и я пытаюсь расслабить кандидата. С другой стороны, это показатель того, как человек справляется со стрессовыми ситуациями. В обычной работе они тоже случаются. А если прод упал и начальник материться на чём свет стоит, что станет делать кандидат, который плохо справляется со стрессом на собеседовании?
akakoychenko
Давайте чуть обобщим ситуацию и посмотрим на нее с другой стороны. Посыл тут примерно такой "в работе программиста случаются пожары, которые надо тушить 15-минутным лайв-кодингом, и мне важно, чтобы члены команды делали это хорошо".
И тут я, конечно же, не буду спорить, что ситуация, когда в команде есть компетенция пожаротушения всяко лучше, чем когда ее нет. Но, вот о приоритетах я таки поспорю, ведь ситуация, когда успех (а то и выживаемость) бизнеса зависит от пожаротушения, недопустима в принципе. Да, стрессоустойчивый кандидат потушит пожар, недопустив критичных потерь, с сильно большей вероятностью, чем нестрессоустойчивый, но вероятность успеха даже у кандидатов с самым развитым скиллом пожаротушения все равно недопустимо низка для того, чтобы это было частью оперирования бизнеса.
Вообще, тут тема для большой отдельной статьи, ибо можно и про культуру героизма вспомнить, и про привести примеры реальных компаний, где искусственный перманентный кризис используется как способ мотивации инженеров, но не хотелось бы сильно уходить в антипримеры
Kipriz Автор
Я тоже считаю, что упавшие проды - это плохой признак. Работать надо спокойно, размеренно, с удовольствием и минимальным уровнем стресса. Героизм - это признак плохого менеджмента.
Лайв-кодинг для питонистов, которых я собеседовал, был адовым стрессом. Никто не помнит названия и параметры методов. Циклы пишут с трудом. Объявить класс - целый подвиг. Но это питонисты, к ним отдельный разговор.
А дата-инженер вроде как пользуется SQL каждый день, синтаксис простейший, почему лайв-кодинг должен вызывать стресс? Я прошу всего два запроса: один с 1 джойном, другой - с джойном и группировкой по двум столбцам. Я брал пару кандидатов, которые туго выполнили тестовые задания. В итоге пришлось уволить через пару месяцев. Но все те, кто работают, сделали тестовые задания хорошо. Весьма очевидная корреляция на мой взгляд. Да, не 100% гарантия, но достаточно надёжный показатель.
saboteur_kiev
Вместо выполнения тех.задания по left/right джоин можно было просто спросить что это такое и чем отличается.
Kipriz Автор
Практика показывает, что между описанием типов джойнов и умением их применять лежит просто пропасть.
Ivan22
это вы весьма лайтово, я если не джуниор позиция то оконные функции всегда спрашиваю
Kipriz Автор
В том-то и прикол, что ладно оконные функции, часть дата-инженеров джойны не понимает. Поэтому практика показала, что достаточно уверенного понимания простых запросов, чтобы в работе показывать себя достаточно хорошо.
velipre_xella
Это новинка какая-то для хипстовых субд - оконки? В мс скл они еще в версии 2005 появились, в оракеле емнип в 9-ке точно уже были.
Меня эти вопросы на собесах уже достали, какими оконными ф-ми вы пользовались. Если я назову ratio_to_report, интервьюер сможет рассказать, про что она?
ioncorpse
Мне как-то дали SQL задачу (странную). Сказал, что это джойн трёх таблиц, но из-за странности задачи ещё и патриции нужны.
Правильно сказали они. Вот вам ручка и бумага, пишите запрос. Спасибо, но нет. Как и лив-кодинг на 15 минут.
GospodinKolhoznik
Это опечатка, или это сленг такой, когда разбиение таблиц называют величественным Древне Римским словом?
John_Nash
Такая практика тушения заканчивается чем-то типа UPDATE без WHERE
tba
Вот! Если кандидат пишет update начиная с where (условие), а потом уже set - это огромный плюс.
Ivan22
я видел умудренного админа начинающего писать Update с "begin tran" !! Сразу чуствуется богатый жизненный опыт
anonymous
НЛО прилетело и опубликовало эту надпись здесь
reishi
В стрессовой ситуации начальник матерится и ещё больше нагоняет стресса. Лесом начальника
AYamangulov
Согласен. Это вариант токсичного начальника. Правильный начальник помогает людям решить проблему, а не ухудшает и без того авральную ситуацию.
nameless323
Стрессовая ситуация стрессовой ситуации рознь. Лично для меня ситуация "надо починить за 10 минут начальник материться" гораздо менее стрессовая чем "надо клонировать граф (ну ок, ноу проблем)", но при этом мы будем "стоять у тебя за спиной" и в риал тайме смотреть как ты пишешь (стресс +100)".
GospodinKolhoznik
Так это легко преодолевается. Чаще коворкайте, пялясь друг другу в экран. Со временем привыкаешь и перестаешь думать о том, что кто то смотрит в монитор.
nameless323
Не очень удобно, когда удаленно работаешь, это надо каждый день из другой страны коллег возить и еще что-то к чаю им покупать и стулья домой :) А если серьезно, но оно конечно можно в офисе такое устроить, но я не знаю есть ли практическая выгода в этом кроме уменьшения стресса на интервью. То есть польза есть конечно, но на сеньорском слишком дорого для работодателя получается.
AYamangulov
Если прод упал, должны быть отлажены CI/CD процессы автоматического или полуавтоматического отката на предыдущую рабочую версию. Когда это поставлено на поток, сделать такой откат - минимально возможное время, зависимо от размера проекта. Только после этого нужно проводить postmortem, то есть по-нашему "разбор полетов" и поиск ошибок. Если в компании поиск причины падения прода проходит по коду в формате ручного code review или ищется по логам (даже если это Sentry) в то же самое время, когда прод уже упал, это признак плохой организации работы. 24/7 так не работает на нормальных энтерпрайзных проектах в нормальных компаниях, чтобы требовалось в условиях стресса срочно искать ошибку, чтобы исправить. Сначала - откат на рабочее состояние, а потом уже - поиск ошибок.
Ivan22
в стране розовых пони оно-то так. В нашем реальном мире полно проектов где продакшен запускается еще ДО всякого CICD. А оно "как-нить потом" прикрутится. Да еще и часто без полного покрытия логами, да и много без чего
nameless323
Согласен, в таких стрессовых ситуациях люди могут теряться, особенно если что-то идет не совсем по плану, словами рассказать и описать ход решения вполне, а иногда написать в условном блокноте может вызывать проблемы. В последнее интервью меня просили сделать что-то картинкой, которая приходила в виде 2д массива С стайл указателем на указатель и я просто от усталости и стресса (шел 7й час интервью) в одном месте запутался с разъименованием, но хорошо что объяснить словами подошло. В итоге когда интервью сессия закончилась, интервьювер оставил задачу открытой, я спокойно выдохнул и за 2 минуты все поправил.
MrNutz
Все верно. Помню как давненько тупил на собесе и не мог простейший запрос написать. Дома за 5 минут написал и саму БД с данными и запрос. Юмор в том, что потом проходил собес в материнскую компанию этой конторы и да, тесты оказались теми же (это уже другая история). Еле-еле успел записать решение пока оно не стерлось из памяти, а процесс пошёл сразу же как начал о нем думать. Стрессовая ситуация.
Вместе со мной в тот день проходили собес ещё два чела. Один оказался слишком зазнавшимся и ему отказали сразу. Другой по результатам собеса был гением. Меня взяли по остаточному принципу. По факту сам мог приходить к обеду, а вечером на живую ещё и исправлял свежие косяки тех, кто ходит вовремя. А гений сидел безвылазно с третьим китайским.
Моё мнение собеседование толком вообще не даёт никакого представления о кандидате. Сам собеседовал нескольких человек по необходимости. Обычно выяснял общую мотивацию вникать и разбираться. А конкретные знания ну такое себе. Опять же, на своём примере. В той самой упомянутый выше конторе вскользь имел дело с шарпом, ещё дотнет 3.5. Запись в резюме имелась. На недавней работе в основе была java, но когда появился проект на шарпе, то эту строчку вспомнили. Только вот шарп там уже другой, коре 5.0, т.е. весьма актуальный. Несколько дней и выкатился без проблем. А устраивайся на работу на такую вакансию, меня бы конечно не взяли.
Так что выяснение конкретных знаний совершенно ни о чем не говорит. Как и тест на IQ, который говорит лишь о том как прошёл конкретный тест. Кстати, в детстве так взяли в умную школу моего другана троечника, а меня хорошиста/отличник нет. Где то я там знатно натупил, а он проскочил по нижней границе. Только толку от этого - он все равно не тянул такую учёбу.
Человек может и запрос на собесе написать и накодить что нужно в рамках простой задачки, но в работе быть абсолютно бесполезен.
Kipriz Автор
Ключевой момент для меня в том, что я не ставлю задачу в каждом кандидате найти талант. На это уйдёт много времени и душевных сил. Я пробовал, оно себя не оправдало. Сейчас я ставлю задачу найти подходящего кандидата под свои критерии.
Успехи и ошибки в найме нескольких десятков дата-инженеров говорят о том, что есть тенденция к тому, что кандидаты, успешно прошедшие такие тестовые задания, хорошо показывают себя в реальной работе. Тенденции того, что кандидаты, не справившиеся с тестовым задания, оказываются скрытыми талантами, не наблюдается. На это и опираюсь.
Я допускаю, что иногда мои собеседования дают ложноотрицательный результат (отказ достойному кандидату), но не думаю, что процент таких ошибок очень высок.