Comments 13
С другой стороны, я видел людей, которые видимо генетически не способны программировать (точно также, как не у всех есть достаточный музыкальный слух чтобы играть на скрипке). Нужно любым способ убедиться, что кандидат вообще способен программировать! И тут есть два варианта:
— Либо вы спрашиваете какую-то data science хрень — типа обращения двоичного дерева, написать приоритетную очередь на основе heap, и т.д. В этом случае вы получаете кандидата который гарантированно умеет программировать, но теряете кандидатов — которые уже забыли data science хрень, а могли бы принести немало пользы в проекте.
— Либо вы придумываете какую-то задачу, которую можно в целом решить за 15-30 минут на собеседовании. Например, предлагаете вывести на однострочный экран в 20 символов сообщение длиной 50. И дальше слушаете — может ли кандидат предложить какое-то решение, и набросать его элементы на бумаге/экране.
Я пришел за годы работы ко второму варианту. Ну плюс, в зависимости от позиции кандидата — разные общие больные для всех вопросы: асимптотическая сложность, сложности и опасности при параллельных потоках, и так далее.
Только не data science, а computer science вероятно. DS это всякие нейронки, регрессии и геенетические алгоритмы.
Я обычно для отсеивания генетически неспособных использую простую задачку с обращением массива. Делается за пять минут, пока не подводила (один раз попробовал взять человека, который ее решил плохо и долго, потом пожалел).
Hidden text
Щас как обычно набегут особо умные и спросят, прокатит ли решение с использованием библиотечной функции.
Нет, перед постановкой задачи я описываю, что именно надо написать, даю ноутбук с запущенной Idea и уже заготовленным шаблоном программы (вызов пустой функции с тестовым массивом, вывод на экран) и отхожу в сторонку и прошу позвать как будет готово. Собеседуемому остается только написать саму функцию.
У меня специфика такая, что задачи инженерные. И мне важно, чтобы человек умел не только в техническое задание, а соотнести проблему с ограничениями оборудования — и как-то начать с этим работать. Я примерно на это и даю задачу.
Задача с обращением массива — тоже хороший вариант. Правда, сейчас по-слухам, курсы программистов специально натаскивают посещенцев на решение таких типовых задач. Есть шанс, что он оттарабанит готовое решение, ни бельмеса не понимая почему оно такое… Невелик пока шанс, но уже есть. :-(
Полностью согласен. В тестовые я никогда не верил — слишком далеки они от реальных задач и в лучшем случае показывают насколько программист умеет форматировать код. За десять лет я столько собеседований провёл, что разговора о задачах, с которыми человеку доводилось сталкиваться, вполне хватает для понимания его уровня и перспектив вписывания в команду. А часто всё понятно уже по резюме и на собеседовании фокусируемся на рассказе о себе и своих задачах, чтобы подходящий человек явно понимал куда попадёт.
Разве что оффер за один день не делаем. Поток у нас не большой и в момент времени вакансия только одна, поэтому важно поговорить с пачкой желающих и из них уже потом выбирать.
А вы готовы выполнять тестовое, и в каком случае?
Готов, если не слишком длинные. Конторы, не делающие тестового, лично у меня вызывают определённое недоверие. Как можно нанимать программиста не убедившись, что он умеет программировать?
Как вам офферы за один день?
Хорошо. Чем быстрее, тем лучше.
На что вы обращаете внимание при найме в свою команду?
На умение программировать, в первую очередь. Потом на релевантный опыт.
Как можно нанимать программиста не убедившись, что он умеет программировать?
Предполагается, что если человек уже где-то работал N месяцев, то объяснять ему что такое переменная и цикл не придётся. А понять, может ли он структурировать код, делать его понятным и поддерживаемым, по тестовому заданию, имхо, нельзя. Иначе оно будет "слишком длинным". Я для себя не вижу какого-то баланса здесь - сделать такое тестовое задание, чтобы его выполнение заняло пару часов, но при этом позволяющее судить о реально востребованных навыках ведения долгосрочных проектов. Но, возможно, этот баланс существует, конечно. Просто я не видал.
Предполагается, что если человек уже где-то работал N месяцев, то объяснять ему что такое переменная и цикл не придётся
У меня, к сожалению, другой опыт.
А понять, может ли он структурировать код, делать его понятным и поддерживаемым, по тестовому заданию, имхо, нельзя.
Да, согласен. Но этому, на мой взгляд можно научить или установить такие рамки чтобы коллега был вынужден делать хорошо. Компиляторы, линтеры и прочие код-ревью, в том числе, для этого и есть
Увы, хватает тех, у кого в резюме куча опыта указана, на собеседовании сыплет модными терминами и технологиями, а мое тестовое задание (про которое я писал в комментарии выше) сделать не могут.
Врать в резюме люди могут еще как. И болтать убедительно тоже.
Расскажу про тестовые задания для реверс-инженеров. Я всегда с большим нетерпением ожидаю их получение. Видел разные: были невероятно классные, решением которых я горжусь до сих пор (привет Диме Склярову и PT), а были все остальные - они же "каспер-подобные" где, как всегда, даётся очередная математическая/CTF-ная хрень, которая не юзается ни в одной малвари, и вообще ни в каких продуктах в реальности.
Знания, которые я применил при решении первого типа тестовых мне пригодились и далее в моей работе (в том числе и других компаниях), чего нельзя сказать о втором типе задач, от слова совсем.
В общем, для меня тестовое задание говорит о работодателе значительно больше, чем это может сказать то же собеседование. Но, я вполне понимаю, что это может быть исключительно специфика реверс-инжиниринга и к остальным профессиям не применимо.
Первые 3 - 4 тестовый вообще не захотелось делать. Последнее делал без какиз либо усилий. Не могу сказать на счет нужности тестового ничего. Но те которые я не сделал говорят о том, что мне не понравлось бы там точно.
Быстрый оффер - это опасная штука, если нет быстрого увольнения.
Какое тестовое задание выдать джависту? Лучше просто поговорить