Comments 30
Очередной глупый мессендж про собеседование.
Вы когда нибудь читали про собеседования - врачей - хирургов? трактористов-машинистов? сварщиков? или машинистов-поездов?
коллега, вот вам тело с одной стороны-вот с другой, вырежьте этому пациенту гланды, а другому аппендикс
неважно, что у тебя 5 разряд - вот тебе задание, как открыть бутылку отвалом - сразу возьму
.... значит , разгоняемся до 120и, и уходим в депо. Увидишь алкаша-тормози. Но учти, у нас там 6 тыс тонн.
Согласен на 100%
От себя могу добавить что бывает так, человек прошедший великолепно собеседование на практике не может/умеет и ТД работать. И наоборот, чел не прошедший собеседование но имеющий сильное желание работать ...ну и ТД.
Есть знакомый сварщик -- при найме они делают тестовое задание по сварке, а для того, чтобы приступить к работе еще и теорию сдают по каким-то нормам.
Про машинистов и хирургов не знаю, но лучше бы делали какие-то тестовые задания, чем просто наличие обучения/опыта, но все зависит от кол-ва кандидатов: когда их меньше, чем вакансий, то часто берут всех подряд.
еще со времен СССР - это называется аттестацией. Если человек работает на предприятии - то раз 3-4-5 года, собирается комиссия, в составе: глав инженер или нач предприятия, глав по специальности, мастер (уважаемый), главные по труду, пожарники, . Группа товарищей сдает охрану труда, безопасность, экз по спец, если нужно варит. И эти члены комиссии - если человек заслужил - повышают ему квалификацию (разряд). Нет, то ждать еще 3-4 года. Вне предприятия, эти функции выполняет Роспотребнадзор.
Да уж. А начиналось всё очень скромно.
Сейчас мало уметь программирование, важно иметь подвешенный язык.
Дело не в подвешанном языке) Конечная цель труда программиста — это не написанный код, а решенная проблема. Это командная работа, поэтому очень важно убедиться, что сотрудник сможет с этой командой эффективно взаимодействовать: человек должен уметь доносить свои мысли и принимать чужие. Ну и конечно, нужно понять, подходят ли соискатель и команда друг другу по духу — людям просто должно быть комфортно вместе. При этом, конечно, никто не требует от кандидата “покорить” HR своими рассказами, чаще всего на этом этапе непосредственно из общения проверяется, насколько вообще человек адекватен, и по моему опыту, большинство кандидатов с ним успешно справляется.
Конечная цель труда программиста — это не написанный код
Если программист — наемный работник, как это обычно бывает, то это утверждение неверно. Программист-наемный работник продает нанимателю свой труд, а не решение его проблем. Продуктом же труда программиста является написанный код, который от программиста отчуждается: права на код переходят к нанимателю.
А полезность этого, приобретенного нанимателем, кода — это чисто проблемы нанимателя: «бачили очі, що купували».
PS Если программист (или артель программистов) работает по подряду — то там все совсем по-другому. Но в наше время это редкость.
Из всей своей практики (не супермного, но за полсотни перевалило, за сотню пока нет) — могу только сказать, что никогда в жизни я не встречал кандидата, чьи ответы на вопросы в стиле школьного экзамена (у меня было много коллег, обожавших экзаменационные собеседования) создавали бы более полное впечатление, чем сессия лайвкодинга на 15 минут на задаче уровня FizzBuzz.
Те, кто быстро и уверенно пишут простой код — так же спокойно ответят на существенную часть экзаменационных вопросов, те, у кого возникают затруднения уровня "как же мне написать цикл?" — засыплются на вопросах.
Я никогда не видел людей, которые бы прекрасно писали простенький код, но откровенно сливались бы на теоретических вопросах, зато я видел людей, которые могли очень долго и очень правильно отвечать на вопросы, но вот очень простой код писали с огромным трудом.
Далее, я точно так же не встречал людей с существенным интересным опытом (те, кому есть что рассказать реально интересного на вопросы типа "какими проектами занимались и что в них было самым крутым?"), которые при этом не могли бы писать код. Встречал людей, которые очень любили поговорить о программировании без самого программирования, но они вычисляются крайне легко, так как в разговорах очень быстро уходят в очевиднейшую чушь.
Из этого вывел список приоритетов по убыванию:
- Мотивационно-жизненные вопросы ("секция HR"). Это без преувеличения самые важные вопросы, которые вы (не обязательно вы как технический специалист, но кто-то их должен задать обязательно) можете задать, и самые важные ответы, которые вы вообще получите от кандидата. Это практически единственная точка, на которой можно как-то отсеять тех людей, которые тем или иным способом навредят команде или компании (например тем, что возьмут и через квартал уволятся без объявления войны). Любые сомнения в мотивации и вовлеченности кандидата и в его способности работать в команде — это очень серьезно.
- Вопросы на подтверждение опыта. Это те самые "что наиболее крутое вы делали", просто разговор за плюсы и минусы технологий из опыта кандидата и по вашей вакансии (людям с опытом всегда есть что сказать на этот счет, всегда с кровавыми деталями), и тому подобное. С хорошими кандидатами эта секция практически всегда из вопросов превращается в беседу. Плохие — опять же крайне быстро выявляются по их куцым и формальным ответам. К джунами и трейни эта секция, увы, не применима, но для остальных она крайне важна.
- Лайвкодинг. Максимально быстрый способ понять, может ли кандидат писать код. Иногда это уже заведомо понятно из прошлой секции, но в случае сомнений или собеседования людей без особого опыта — это становится ключевой проверкой. Задачи лучше давать исключительно очень простые, но открытые (в которые можно продолжать добавлять новые условия вплоть до превращения очень простой задачи в очень сложную). Ни в коем случае не с заковыристым алгоритмом (чтоб не было ложноположительной офигенности, если кандидат вдруг откуда-то назубок знает этот конкретный случай), и ни в коем случае не с leetcode и подобных источников (мы проверяем, может ли человек писать код, а не практиковался ли он перед собеседованием на leetcode). Тут очень важно именно постепенное усложнение задачи — насколько далеко за отведенное время кандидат способен забраться в дебри постепенно усложняющейся задачи. Заодно это и проверяет не менее важные вещи типа понимания добавляющихся условий и их влияние на уже написанный код.
- Специализация. Это если нужен именно гуру реакта или тому подобное. Зачастую (если команда уже укомплектована специалистами) эта секция может быть вообще не нужна, т.к. отсутствие опыта энтерпрайзовой практики с конкретной либой/фреймворком — весьма незначимая деталь, и чуть более хороший "в общем" кандидат без опыта того же реакта — куда лучше чуть более плохого, но с опытом. Но если в команде специалистов нет — то это имеет большее значение, и выделять под это отдельную часть собеседования может быть весьма оправданно. И, опять же — только если после секции №2 остались какие-то сомнения.
В вопросах закрытого типа (когда кандидат должен дать некий максимально близкий к эталону ответ) я смысла не вижу, в крайнем случае только лишь в секции №4. Это долгий и трудоемкий способ собеседовать — составить хорошо сбалансированный опросник сильно тяжелее и дольше, чем придумать одну простую, но усложняемую задачу; пройти этот опросник с каждым кандидатом — аналогично, тяжелее и дольше.
Во многом согласен, только уточню пару моментов:
3. Ровно поэтому все вопросы мы формулируем в виде задач. Думаю, нет смысла спрашивать об особенностях языка или технологии, которые ни разу не приходилось использовать и которые легко гуглятся при первой же потребности. В целом, описанный вами сценарий полностью ложится на предложенный мной в статье. В частности, в моем случае каждый следующий вопрос в секции по Реакт — это расширение предыдущего задания)
4. Про конкретно мой кейс с Реактом. Возможно, здесь сработала специфика рынка, но у большинства кандидатов в резюме есть несколько лет опыта использования React. Думаю, в таком случае вполне обоснованно можно провести целую секцию, посвещенную данной технологии, потому что тут мы явно проверяем, насколько глубоко за последние несколько лет разработчик освоил свой основной инструмент. Кажется, это важный показатель не только технических навыков, но и желания разбираться в разных вещах. Конечно, если у кандидата нет опыта в конкретной технологи, то и нет смысла задавать по ней вопросы, вместо этого можно сделать упор на чем-то другом.
По поводу фиксированных формулировок дополнил в тексте статьи. Это скорее нужно для команды собеседующих: если процесс интервью распределяется на несколько человек, очень важно, чтобы все кандидаты получали одинаковые входные данные, и чтобы интервьюер не упустил никакие важные моменты в формулировке впороса и не повлиял бы этим на объективность ответа. Конечно, это только стартовая точка вопроса, от которой далее могут быть отклонения в зависимости от хода мыслей кандидата.
Что-то я не очень понимаю, как выглядят "вопросы в виде задач" — нельзя ли один (хотя бы совсем мелкий) пример?
Секцию по реакту-то можно проводить, конечно, только что она покажет? Разные люди пользуются реактом на совсем разном уровне — у одних всё готово и настроено и код обязан укладываться в пространные и подробные code style guide, другие всё сами на коленке настроили-собрали, третьи в силу каких-то соображений шпарят на голом реакте без всего остального, у четвертых реакт только рендерит, а всё остальное делают другие либы… что из этого принципиально именно для вашей вакансии, и насколько это критично?
Это скорее нужно для команды собеседующих: если процесс интервью распределяется на несколько человек, очень важно, чтобы все кандидаты получали одинаковые входные данные, и чтобы интервьюер не упустил никакие важные моменты в формулировке впороса и не повлиял бы этим на объективность ответа.
Я, если честно, совсем не понимаю, зачем это вам. Вы не ЕГЭ проводите же, зачем вам откалиброванные вопросы? В моем понимании, любая процедура технических собеседований обязана ответить на один, максимум два вопроса:
1) Берем ли мы этого кандидата? Да/нет.
2) Если на первый вопрос ответ "нет", то почему?
И второй вопрос — нужен по большей части для выдачи фидбека.
В чем смысл выставлять кандидатам какие-то оценки? Да, если в моменте у вас есть несколько подходящих кандидатов, то естественно их можно и сравить (если нет возможности и необходимости нанять всех). Но вообще-то надо вакансию закрыть пригодным для этой роли человеком, а не сидеть и ждать божественного программиста, который восхитительно ответит на вопросы.
А когда не надо ставить оценки — то калибровка вопросов не нужна. Специалист по проекту/направлению, на которое нужны люди — составляет вопросы/задачи, и конкретной вакансии сопоставляется конкретный набор этих вопросов и задач. На другие вакансии может быть легче/сложнее отбор? Ну так и пусть, что в этом плохого? Если надо будет отбор скорректировать (слишком хреновых кандидатов берем, либо наоборот никто не может пройти отбор) — то скорректируете.
К сожалению, не могу опубликовать конкретный пример с заданием. Но чаще всего это задача на live coding, покрывающая какую-то область или открытый вопрос о том, как бы человек решал определенную проблему.
По поводу React, нам удалось, на мой взгляд, разработать задание, которое раскрывает то, насколько вообще человек понимает, как устроена эта библиотека и принципы, на которых она основана. Если, например, человек указывает N лет опыта React, то как бы он его ни использовал, мы можем предположить, с чем он сталкивался и можем это проверить. Дело не в стайл-гайдах, а в понимании базовых концепций. Но опять же, это всё частности, специфичные для предметной области.
По поводу откалиброванных заданий. Здесь дело именно в том, что на одну вакансию собеседуем параллельно несколько человек и часто бывает, что есть два примерно равных кандидата, которых собеседовали разные интервьюеры, хочется достичь объективности в том, кому отдать приоритет.
Как пример: мы регулярно проводим школы, после которых выпускается несколько сильных студентов. Все хороши, но пока что у нас нет ресурса предлагать стажировку всем, поэтому нужно справедливо определять лучших)
что наиболее крутое вы делали
Вы, как и я, фронтенд разработчик. Можете привести пример, что бы вы ответили на этот вопрос? Я не работал в каких-либо крутых компаниях. В обычных средненьких компаниях над обычными проектами. За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутые, отфильтровать их по крутости и сформулировать, что и как я там делал несколько лет назад. Да и язык у меня не подвешен. Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам. А ведь потом еще надо решить простую задачу, и ответить на вопросы по теории, что опять же не сделаю без подготовки.
Я не работал в каких-либо крутых компаниях.
Я тоже. Из самого крутого — делал визуальный (и невизуальный, чисто конфигами) конструктор UI, чтоб продукт был гибко настраиваемым либо шарящим в теме (сетевое администрирование) клиентом, либо же собственными конторскими спецами предметной области, без дальнейшего привлечения программистов.
Дальше я по этой теме могу еще минут 10 минимум говорить, там есть что вспомнить, но давайте пример на этом завершим :-)
Далее по списку самого интересного можно еще остановиться на графиках с очень продвинутой автоподстройкой осей (удобные для восприятия периоды времени, правильные множители единиц, кило/мега/итд, подбор количества меток по осям, чтоб не слишком мало и не слишком много, автовыбор между логарифмической и линейной осью, вот это всё); и даже на интеграции ужей с ежами (реакта/ангуляра/вебкомпонент) — но это всё уже несколько менее интересные темы относительно топ-1. В общем, рассказом можно легко занять полсобеседования, при желании.
За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутую и сформулировать что и как я там делал несколько лет назад.
Вспомните заранее. Вопросы подобного вида сейчас, без преувеличения, задают на 8 собеседованиях из 10.
Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам.
Скорее к программистам, которые ничего более запоминающегося, чем двиганье кнопочек, не делали. Но в этой секции у меня еще вопросы по плюсам-минусам технологий, и шансов развести на разговор еще предостаточно.
А с вашей стороны(для описываемых ситуаций в статье) какой результат ждут? Прошел\Не прошел и какой-то условный грейд? Или наоборот - хотят знать ответ на вопрос кандидат к примеру хочет 200к, стоит ли он этих денег
Здесь бывает по-разному. Иногда кандидат действительно сам спрашивает, на какой грейд мы его оцениваем. В таком случае мы отвечаем на данный вопрос, опираясь на нашу матрицу компетенций.
Чаще всего в процессе общения кандидат озвучивает свои ожидания и далее по итогам собеседования мы решаем, готовы ли мы эти ожидания удовлетворить. Если ожидания кандидата расходятся с нашими итогами, то в случае отказа тоже обосновываем, почему именно отказали. А если делаем оффер, и считаем, что вилка кандидата не соответсвует его результатам, то можем предложить свой вариант также обосновывая свое решение. Кстати, оффер может отличаться как в меньшую, так и в большую сторону.
Ну и если произошел match, то тут вообще всё здорово :-)
На собеседовании очень хочется проверить насколько хорош кандидат для выполнения предполагаемой работы, состоящей из набора умений X, но проверяют умения Y, которые умеют (могут, хотят) проверить и считают коррелирующими.
По моей практике большинства собеседований предполагается такая работа разработчика:
Без IDE (только хардкор, пишем в блокноте, если умеешь водить жигуль - значит на бэхе будешь вообще красавчик)
Без Интернета и документации (ты должен помнить все, склеротикам не место у нас)
Без времени для размышлений (у нас спринты, дедлайны, планирование для галочки, мы набрали столько, что не вывозим, машем веслами)
С обязательным персональным надсмотрщиком (мы должны контролировать, что пишешь именно ты)
С написанием велосипедов (ты должен понимать основы, если надо и до квантовой физики углубимся)
Критикуешь - предлагай. Совместное код ревью, состоящее из двух частей. Первая часть кандидат показывает свой код, вторая интервьювер. И во время ревью уже можно слово за слово погружаться в дебри языковых конструкций, паттерны и прочие прелести, отталкиваясь от написанного. У меня есть свои заготовки со специально допущенными ошибками и с удовольствием посмотрю любой helloworld кандидата, пусть даже скопированный за минуту до собеседования с интернета, найду о чем спросить.
Но нет, всем проще так делать: "билет номер 4, а при нем задача".
Резюмируя. Нет правильного или неправильного собеседования. Каждый ищет под свои заморочки.
Согласен со многими мыслями. Именно поэтому думаю, что нет смысла спрашивать на собеседовании теорию, которая используется раз в жизни и легко гуглится. Не раскрывал этого в статье, но уточню: на мой взгляд, если у кандидата в резюме указан богатый и релевантный нашим потребностям опыт, то стоит проверить именно его — опыт, а не знания. Это не то, что гуглится или запоминается, это вещи, которые нужно в первую очередь понять. И то, насколько глубоко человек понял некоторые моменты (на примере конкретных кейсов), отлично демонстрирует его опыт.
Классный пример с заданиями на поиск ошибок / ревью. У нас тоже бывают такие вопросы. Еще из интересного, к чему пришел. Если кандидат прикрепил свой Гитхаб, можно заранее изучить его и найти какие-нибудь примеры кода, которые затем предложить проревьюить самому кандидату. Таким образом можно проверить профессиональный рост человека: кем он был раньше и что делал тогда, и как он изменил свои взгляды на данный момент. Но тут, конечно, нужно быть аккуратным: примеры должны быть такими, которые можно улучшить, но они должны оставаться релевантными (т.е. чтобы не было ответа: тут всё переписать с одной технологии на другую)
Таким образом, со слабым кандидатом собеседование занимает не больше часа. И наоборот — если кандидат сильный, на каждую секцию можно выделить побольше времени.
То есть у вас получается, что слабых кандидатов вы отпускаете пораньше, зато сильных мурыжите по полной программе? :) Это им в награду за то, что они сильные? :)
По-моему, должно быть наоборот. Если видно, что кандидат сильный, не парить ему мозги. А если видно, что кандидат слабый (но не безнадежный), то посидеть с ним подольше, дать больше шансов все-таки что-то нарешать и доказать, что "слабость" кажущаяся. Вроде так логичней.
Задача на собеседовании ведь определить границы познания человека, а не просто сказать «ок» или «не ок».
Поэтому, например, если кандидат плавает уже в базовых вещах, он точно не подходит и нет смысла его мучать. На практике «кажущейся» слабости не встречал. Наоборот скорее, начальные задачки кандидат может решать хорошо, а с более сложными не справляться.
Поэтому важно «прощупать» уровень человека, давая разные кейсы, разной сложности и на разные темы. Так можно более точно определить грейд и соотвественно уровень зп и тд. Мало ли, вы рассматриваете вакансию мидла, а перед вами сеньор.
Спасибо за коммментарий. Так вышло, что на многие тезисы ответил в других ветках.
Чтобы не дублировать, прикреплю ссылки:
1. О формулировках вопросов и о том, что нужно проверять не сухую теорию, а опыт ответил здесь:
https://habr.com/ru/company/kts/blog/583816/#comment_23601224
2. В этой ветке обсудили способы, которыми можно проверить опыт кандидата:
https://habr.com/ru/company/kts/blog/583816/#comment_23601070
3. Здесь ответил о секции HR
https://habr.com/ru/company/kts/blog/583816/#comment_23601248
4. О тестовом задании на несколько дней:
Здесь я всё же склоняюсь к тому, что не совсем корректно заставлять кандидата выполнять тестовое, особенно, если это задание несет коммерческую выгоду компании, в которую он собеседуется. Поэтому считаю, что нужно стремиться проверить match с кандидатом не выходя за рамки собеседования (или если нужно, нескольких собеседований).
Но чаще всего я завершаю собеседование фразой, что мы вернёмся с обратной связью в ближайшие дни.И как, возвращаетесь? Или используете эту фразу как другие, для вежливого отказа?
У автора замечательный академический стиль, чувствуется школа.
Такой подход хорош, если у вас есть куча времени, масса народа для собеседования со стороны работодателя и поток собеседуемых, которых нужно всех прогнать через процедуру и проранжировать в соответствии с их ценностью для компании, обосновав рейтинг каждого. Здесь процесс не менее важен, чем результат.
Для основной массы работодателей, представляющих из себя компании с численностью от 5 до 50 человек, такая растрата ресурсов неприемлема.
Как правильно отметили выше, существуют гораздо более экономичные способы поиска кандидатов, когда несколько правильных вопросов позволяют принять решение по кандидату
Автор, случаем, не в Газпроме работает? :)
Как проводить собеседования объективно и с пользой