Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

[Об авторе: Ирина Топилина — основатель Recruiting Banda, имеет 13 лет опыта работы в HR-отрасли, 10 из них — в IT-рекрутинге. Спикер и эдвайзер платформы Pro-Recruitment Сommunity. О профессии: «Я очень хочу, чтобы хороших HR-ов и рекрутеров в Украине было больше и готова тратить на это свои силы и время»]

Недавно меня пригласили в качестве спикера на встречу, которая проходила в рамках образовательной платформы для лидеров рекрутинга Pro-Recruitment Сommunity. Один из вопросов, которые при этом обсуждались, состоял в том, насколько эффективно тестирование при отборе кандидатов.

Говоря о тестировании, я подразумеваю задание для кандидата на определенную должность, которое построено по классическому формату: предлагается ряд задач/вопросов, на которые нужно выдать ряд решений/ответов за ограниченный промежуток времени.

Моя личная позиция по этому вопросу достаточно однозначна: я против использования тестирования как метода оценки кандидатов, да и просто как самостоятельного инструмента. После встречи в рамках Pro-Recruitment Сommunity меня попросили более подробно объяснить, почему я так думаю. Так появился текст, в котором собраны не только мои возражения, но и отмечены позитивные моменты тестирования.

Я, конечно же, не претендую на окончательную истину, хотя специально посвятила изучению этой темы определённое время. Мне также было бы очень интересно получить максимально широкий спектр мнений моих коллег по рекрутингу, которые также сопереживают отрасли. Конечно, я хотела бы узнать, что думают айтишники, то есть ребята, на которых это тестирование направлено (а вдруг мне скажут, что времена уже поменялись, и я абсолютно не права?) А если хотя бы одного руководителя компании этот текст заставит задуматься: «Делать нам тестирование или нет? Зачем? Какое?» и осознанно подойти к этому процессу, я пойму, что он был написан не зря.

И, конечно, мне бы очень не хотелось, чтобы эта практика, как часто у нас бывает, не превратилась в очередной инструмент, взятый на западе, который бездумно используют, где ни попадя.

Какая польза от тестирования?

Сейчас действительно есть устойчивое стремление к тому, чтобы придумать какое-то тестирование, которое заменит, например, беседу рекрутера (и не только) для оценки личностных качеств человека. Вера в то, что такое возможно реализовать, для меня непонятна. Но доводы в пользу тестирования существуют и они вполне рациональные:

  1. Сократить денежные и временные затраты на рекрутинг.
  2. Убрать субъективность.

В мире первая задача сейчас, пожалуй, считается более важной. Всё стремятся оптимизировать и ускорить. Хотя я считаю неправильным и негуманным отдавать компьютеру право принимать решение нанимать конкретного человека или нет, не используя больше никаких других методов оценки.

В этом смысле второй аспект применения тестирования мне кажется более позитивным. Например, мы недавно общались с рекрутерами из Британии. Одна из них — девушка, которая занимается проблемами инклюзии и diversity в больших корпорациях и жизни общества. Иными словами, речь идёт про обеспечение равного доступа к работе и другим составляющим жизни для людей с ограниченными возможностями, людей разных рас, нетрадиционной сексуальной идентификации и т. п. Она, кстати, сама трансгендер и понимает эти трудности очень хорошо. В качестве одного из инструментов для преодоления дискриминации она предлагает предварительный скрининг, реализованный в формате слепого анализа резюме и слепого тестирования. Это позволяет без знания пола человека, его возраста, сексуальной ориентации и т. п. оценить его компетенцию прежде всего как специалиста.

Преодоление проблемы дискриминации, причём по любому признаку, — хорошая сторона тестирования. Например, у нас очень много эйджизма в стране сейчас. И к свитчерам есть предубежденное отношение. У меня самой оно тоже было до недавнего времени, но сейчас я немного пересмотрела своё отношение. Одна из причин — очень удачный плейсмент свитчера, который мы сделали недавно. Однако мы уделили очень много внимания этому человеку, очень глубоко с ним поработали, провели более детальное интервью, чтобы быть уверенными, что предлагаем нашему заказчику качественного кандидата.

Если говорить про широкое использование тестирования в Украине, то здесь оно приносит больше негативных следствий.
Конечно, нужно разделять тестирование на техническое и психологическое, то есть, как говорят, исследование hard skills (мы оцениваем знания в первую очередь, не навыки) и soft skills (то есть личностные качества человека, его ценности, то, насколько он «душевно» подходит).

О технических тестах

Я, может быть, была бы за технические тесты, если бы не одно «но». В работе мы столкнулись с тем, что в Украине большинство технических специалистов:

  • Категорически отказываются проходить любое тестирование и выполнять какие-либо тестовые задания.
  • Согласившись, в 70% случаев не справляются с тестовым заданием, даже будучи достаточно компетентными специалистами.

Есть такой известный в Украине инструмент тестирования IT-специалистов, как Codility (сервис, который позиционирует себя как онлайн-платформа, которая «помогает техническим рекрутерам и менеджерам по найму оценивать навыки своих кандидатов путем тестирования их кода»). Очень страшная вещь. У меня есть более чем годичный опыт сотрудничества с компанией, которая его применяла, собрана обширная статистика. Так вот 70% людей не справлялось с тестами Codility не из-за недостатка своей компетенции, а именно из-за того, что это тест.

У нас на постсоветском пространстве инженеры не умеют проходить тест. Они начинают нервничать, жать не те кнопки. Они его валят, либо бросают на половине пути. Счётчик времени вводит их в катастрофический невроз. Вот такая культурная специфика. Поэтому если мы хотим отсеять хороших разработчиков или тестировщиков — неважно, — давайте всех прогоним через Codility, и таким образом мы отлично справимся с задачей никого не нанять.

В какой-то момент, во время работы с упомянутой выше компанией я даже сочла необходимым уговорить её нанимающих менеджеров продолжить общение с одним senior специалистом, не прошедшим тест. У человека был действительно, очень крутой опыт, интересные проекты за плечами, и это дало нам сильные аргументы. К нам прислушались, ему дали практическое задание, он его успешно выполнил. В итоге его взяли на работу и он прошел испытательный срок.

В Европе и США с техническими тестами справляются без проблем. Люди на постсоветском пространстве — пока что нет. Возможно, виновата наша система образования, традиции которой уходят в прошлое очень медленно.

В моей практике есть пример, когда кандидатам вместо технического задания давали технический тест. Эти тесты отлично работали для европейцев (проект был для европейской компании). Знаете, как его прошли у нас? Все seniors завалили тест. Зато juniors прошли неплохо. Возможно потому, что у более молодых уже есть опыт подготовки и сдачи тестов внешнего независимого оценивания (ВНО). По-видимому, этот опыт позволял им показывать более высокий результат. Это были средние показатели; выполнение, конечно, не было стопроцентным. Но, по крайней мере, juniors не бросали задание на полдороге. Однако мы нанимали команду seniors.

О психологических тестах

С ними есть две основные проблемы:

  1. Человек, который прочитал хотя бы пару книжек по психологии личности, на 100% понимает суть вопросов, которые в тесте задаются. И начинает выдавать либо социально желаемые ответы, либо отвечает по приколу.
  2. Так сложилось, что технари довольно часто не придают большого значения всему, что связано с психологией, и выполняют такие тесты в режиме «как придётся».

Бывают более сложные психологические тесты. Например, созданные на основе проективных методик или абстрактно-логических задач. Вопрос может выглядеть в духе: «Подумайте, какой фигуры не хватает». Они заставляют включить мозг, напрячься. Человек начинает долго думать, время заканчивается, он нервничает. И тогда см. п. 2. Возмущенный технарь скажет: «Почему я должен на это время тратить? Лучше пойду в компанию, где со мной поговорят нормально, как с человеком!». Обрывает процесс, уходит. Уровень раздражения может оказаться настолько высоким, что кандидат пренебрегает возможностью получить работу.

Так или иначе выходит, что тот, кто заинтересован в результатах тестирования, не получает ответов, соответствующих реальности. Я знаю пример, когда Senior Solution Architect, который прошёл 5 раундов интервью с менеджерами одной европейской компании, работающей в Украине, на отлично, показал низкие когнитивные навыки (внимательность, креативность, память и др.) во время тестирования, и в итоге ему отказали. У меня возникает вопрос: «Как человек с когнитивными навыками ниже среднего может 15 лет успешно работать в отрасли, прекрасно проходить интервью и быть хорошим экспертом?». Я не могу рассказать вам подробностей, как проходило его тестирование, но скажу, что через какое-то время он устроился в конкурирующую компанию и нормально там работает.

Так нужно ли тестирование?

Если говорить о тестах в целом, то любой человек, глубоко изучающий социологию или психологию, скажет вам о низкой валидности всех тестов в сравнении с личным интервью. Что это значит?

Мы можем попросить одного и того же человека раз в 2-3 месяца проходить один и тот же тест. Будем выбирать разное время: выходной/рабочий день, время суток, будет разная погода, время года и т .п. И я вам гарантирую, что результаты тестов будут достаточно сильно отличаться, при том, что навыки, знания и умения человека за эти сроки не особенно изменятся. А если это будет какой-нибудь тест на определение типа личности, то вы можете каждый раз получать результат как будто от другого человека. Например, есть такой тест 16personalities.com, укороченная версия методики определения типа личности по Майерс-Бриггс (MBTI), который, судя по отзывам в интернете, отлично зарекомендовал себя на Западе. Так вот, я проходила его ради интереса раз в два месяца в течение года и получила 6 разных результатов.

Люди, которые проводят тестирование, как правило, не знают, в каком эмоциональном состоянии находится тестируемый. Что произошло у него в жизни? В каком окружении он пребывает, когда эти тесты выполняет? Может он сел делать тест на когнитивные способности в 2 часа ночи, после тяжелого рабочего дня. И тогда, конечно, тест покажет очень низкий уровень внимательности или очень низкий уровень креативности, потому что человек устал или на нём трое детей висело в этот момент. Мы не можем этого отследить. А если посадить его делать тест в помещении компании, то у него будет повышенный уровень стресса. И тогда смотри то, о чём говорилось выше.

Всё это вместе взятое заставляет меня всё-таки придерживаться мнения, что использовать тестирование не стоит. В большинстве случаев для компании, которая нанимает людей в Украине, это навредит процессу.

У нас была пара клиентов, которые предлагали вместо тестирования техническое задание. Оно было без счётчиков и на творчество. То есть человеку нужно было решить задачу по программированию, он писал какой-то код, и потом Senior Architect или Team Lead оценивал качество работы этого человека. И то такие задания 50% кандидатов отказывались делать.

Поэтому, если тестирования всё же не избежать, то крайне желательно найти возможность для кандидатов пройти хотя бы раз пробный тест, который «не засчитывается». В моей практике был такой случай, когда мы готовили кандидатов к тестам: давали попробовать их пройти, часами разговаривали с ними о том, как это сделать. Единственный вопрос: зачем были все эти усилия, если наша цель — сократить затраты?

Полезно ли совмещать тестирование и собеседование?

Разве что для того, чтобы как-то сверить себя как профессионала во время интервью. Иметь ещё какой-то источник информации всегда хорошо. Но это такая тяжёлая и сложная работа — выбрать правильный тест. Она заставляет всё время задавать себе вопросы: «А какую проблему я решаю с помощью теста?», «Почему я выбрал именно этот тест?», «Как я пойму, что тест мне помогает, а не наоборот, мешает нанимать качественных кандидатов?» и т. д. Чтобы адекватно ответить на них, человек, который проводит и собеседование, и тестирование должен быть суперпрофессиональным. Чтобы информация, полученная во время тестов, была полезна впоследствии HR-менеджеру компании, этот человек тоже должен быть профессионалом высокого уровня.

Если у нас очень хороший интервьюер, который много лет этому учился, думающий, хорошо разбирающийся во всех методиках проведения интервью, если он умеет работать с собой, как личностью, чтобы не вовлекаться эмоционально в людей, которые приходят к нему на собеседование, если у нас есть такой профессионал, он будет способен глубоко копать. Он сможет ответить на вопрос: какое тестирование подойдет / не подойдёт, зачем оно нужно, что мы хотим проверить и почему именно эти навыки нужны для нашей компании. Вот это окей. Это нормальный приемлемый подход, который позволит работать с тестами.

Поэтому я за то, чтобы прежде всего научить наших рекрутеров и даже технических интервьюеров глубоко разбираться в людях и хорошо проводить собеседование. Некачественное интервью и тест дадут одинаково бесполезные результаты.

На каком-то этапе тестирование в Украине станет применяться чаще (мы не можем не испытать влияние Запада). Я очень надеюсь, что к этому моменту наши работодатели научатся подходить к этому инструменту более осознанно, делая всё-таки поправку на культурные особенности нашей страны.

Делегируем ИИ?

Является ли тестирование промежуточной ступенькой, после которой рекрутинг можно будет делегировать искусственному интеллекту? Думаю, что в ближайшее время — нет. Представьте, что компания хочет найти менеджера, который будет вести за собой, объединять людей на основе каких-то ценностей, то есть обладать соответствующей харизмой. Так вот, компьютерные программы не могут оценить такую совершенно нерациональную вещь, как способность влиять, способность убеждать. Это то, что мы можем увидеть только при личном контакте.

Я убеждена, что человек при общении с другим человеком воспринимает своего собеседника на телесном уровне. Мы можем не только почувствовать, но и уточнить, всё ли у него хорошо. Мы можем ввести его в хорошее, теплое расположение духа, обеспечив ему комфортную эмоциональную среду, дав понять: «Парень, ты в безопасности. Не переживай, всё нормально, расслабься...»
Компьютеры такую атмосферу пока что создать не способны. Компьютеры не умеют распознавать с высокой точностью эмоции людей. Возможно, насмотревшись сериала «Теория лжи», многие теперь убеждены, что только лишь благодаря физиогномике можно определять эмоции человека, — там высказывается такое мнение. Но это неправда. Эмоций очень много, все они очень по-разному проявляются и всего лишь по выражению лица нельзя их считывать, — очень высокая вероятность ошибки.

Добавьте сюда ещё, что лишь 80% речи может быть распознано компьютером. Но мало распознать речь. Нужно ещё распознать семантику, то есть смысловое значение. Компьютер не всегда способен корректно провести семантический анализ. И это не единственная проблема, в которую уперлась современная робототехника.

Например, на сегодняшний день всё машинное обучение построено на категоризации данных. У алгоритмов работы с категориями есть очень серьёзные ограничения. Если кому интересно, — можно почитать про парадокс Рассела хотя бы. Пройдет еще много времени, прежде чем эти и другие проблемы найдут решение. Поэтому я думаю, что мы ещё очень далеки от того момента, когда ИИ заменит рекрутера. Так что в ближайшие годы рекрутеры свою работу не потеряют.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




Найкращі коментарі пропустити

В мене є підозра, що невміння проходити класичні тести — наслідок не особливості пост-радянського навчання чи якогось особливого менталітету, а наслідок відсутності базових академічних знань в розробників. Більшість айтішників — самоучки, які починали з фрілансу чи примітивних проектів і розбиралися в сфері «на ходу». Відповідно знання до них приходять не зі стандартних підручників а з суворої реальності, в якій байти інвертуються а дерева перевертаються хіба що на співбесідах. Тож реальні бойові задачі вони вирішувати вміють, бо такий досвід в них є, чого не скажеш про досвід проходження стандартизованих тестів.

В ІТ індустрії Європи і Штатів, мабуть, більший відсоток людей з профільною та сучасною освітою, тож тести і задачки для них звична штука.

Так вот 70% людей не справлялось с тестами Codility не из-за недостатка своей компетенции, а именно из-за того, что это тест.

Вообще-то нет, они не справились в основном из-за «недостатка своей компетенции». Даже те кто бросил на полпути сделали это из-за «недостатка своей компетенции».
Тут вся хитрость в том что включено в понятие «компетенции». Кодилити проверяет знание класических задачек компутер сайнса. Человек который не может решать задания на кодилити некомпетентен в решении класических задачек.

Теперь вопрос:
Как часто эти задачки нужны в работе? В соотношении с ОО дизайном, ДДД, умением/желанием тестировать свой код, умением работать с очередями и тд.

Любой подход хорош если уметь им пользоваться, уметь извлекать из него пользу. Если контора может по задачке с кодилити понять подходит человек или нет, то пусть дают, если вы не смогли ее сделать — вы не подходите. Если могут ринять решение на основании «задачки про люки» — вперед.
По моему опыту, 30-90 минут обсуждения резюме кандидата и/или дизайн задачи вполне достаточно чтобы понять подходит человек или нет.

Я убеждена, что человек при общении с другим человеком воспринимает своего собеседника на телесном уровне.

Обнимашки вместо тестов!

Самая хорошая проверка для тестов — готов ли их пройти сам HR либо лид-разработчик. Для меня показательным был случай, когда мой же вопрос кандидат отзеркалил и попросил ответить на него. Было весело :).

То же и с тестовым. Оно не должно быть сложным в принципе, ведь как завещал Джоэль, нам важно проверить всего две вещи: что перед нами находится человек умный и что этот человек умеет решать нужные нам задачи. Одно можно проверить беседой, второе — поработав вместе над практической задачей.

Кстати для этого сугубо на выбор мы предлагаем прийти к нам в гости и сделать тестовое сев рядом, не имея практически ограничения по времени и пользуясь чем угодно в том числе задавая вопросы нам.

Есть такой известный в Украине инструмент тестирования IT-специалистов, как Codility. Очень страшная вещь. У меня есть более чем годичный опыт сотрудничества с компанией, которая его применяла, собрана обширная статистика. Так вот 70% людей не справлялось с тестами Codility не из-за недостатка своей компетенции, а именно из-за того, что это тест.

У этого есть и обратная сторона. Знаю тех, которые шутя решают задания, в том числе и тестовые, на Кодилити (а также на Хакерранке или на Кодербайте), но пасуют на реальном проекте. Как уже было сказано, задания на Кодилити — только проверка умения реализовать классические алгоритмы на том или другом языке программирования. Чистый computer science на 80% не привязанный к тем задачам, которые приходится решать ежедневно.

188 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Forbes покаже, які компанії вибрали оптимальну методику найму найкращих!
Ірина має рацію. Достатньо дослідити як наймають FAANG та TOP-100 IT компаній.

Чи може те що заважає HR-у закрити позицію — буди добрим для HR-а)))

Очень спорный вопрос. С одной стороны, видел как тесты дают стабильный результат, с другой — недавно видел тест, в котором один из четырех вопросов был задачкой, на которую написан пейпер. Предположу, что тесты, как и тестовое задание, могут быть как качественными, так и не очень. Я, например, тащусь от качественных тестовых заданий, всего припомню что встретил два таких. Касательно тестов, то было сделал программку — тест — люди пользуются и тренируют тот конкретный тест. Я так понимаю, в Штатах система экзаменации заточена на тесты — надо понимать как они пользуются этим инструментом (сам хорошо не знаю), но точно, это не просто взять тест на тему и предложить его пройти.

С удовольствием прочитал, благодарю что поделились своим опытом, пишите еще!

Так для истории:

Moishe Lettvin — What I Learned Doing 250 Interviews at Google
www.youtube.com/watch?v=r8RxkpUvxK0
www.youtube.com/watch?v=X5uKqHdFywI

Какие тесты между частным предпринимателем и юридическим лицом? Вы вообще в адеквате? Приходит ФОП к юрику, покупает товар — юрик перед отгрузкой товара и подписанием договора, говорит ФОПу ты мол давай тест пройди а то я тебе иначе товар не отгружу.
Это все крайне странно. Договор между ФОПом и юриком — там ведь мы прописываем риски, обязанности. — Нет?
Тесты? — Тогда давайте по КЗоТу общаться (это единственное оправдание тестам). Зачем ФОПы тогда? Чтобы что?
Внешний рекрутинг ничего не может кроме проедания финансов — это уже свершившися факт. Показатель здоровья, бизнес процессов компании, это способность собственного отдела рекрутинга компании, без привлечения сторонних ресурсов проводить собеседования.
И практическая ценность не в количестве закрытых позиций а LTV этой самой позиции. Этого никто из hr никогда не делает.
Тесты необходимы при релокации, когда необходимо подтвердить свой бекграунд за короткий промежуток времени — это единственное на мой взгляд, где надо и должно быть сие.
Остальное это низкая квалификация отдела рекрутинга и заинтересованных лиц в сложившейся цепочке взаимоотношений.

Из свежего — собеседовался в компанию, очень сильные работники собеседовали, гоняли и по UML и прочему. Не подошел. Спустя год, на собеседование приходит этот специалист который меня «тестировал». Происходит аказия, человек даже не смог ответить на базовые вопросы уровня джуна — хотябы назвать основные эвристики Нильсена или объяснить в чем разница между OOX и HCD. Смешно? — Не думаю.

Договор между ФОПом и юриком — там ведь мы прописываем риски, обязанности. — Нет?

У вас контракты fixed price, а не time-and-materials?

Только T&M на прямую если. По Украине никто нормальные контракты не подписывает — одна шляпа FP даже не назвать.

Трохи погоджуюсь з думкою @Bogdan Shyiak, що в «пострадянських» розробників немає компетенції вирішувати алгоритмічні завдання на Codility, але в загальному то погано. Тобто робота програміста не тільки використати вже готовий патерн з фрейморку і пиляти з дня на день монотонний код, а й вирішувати логічні задачки за певний проміжок часу.
+ можна отримати зворотній зв’язок і проаналізувати що було не так під час написання, і отримати постравматичний ріст та стійкість до задач на час, щоб наступного разу не нервувати через дрібниці.

Тут ще трохи про тестування:
www.facebook.com/...​ermalink/322992615028248

Дякую за цікаву статтю, також деякий час тому зробив для себе висновок, що тести не працюють.

Спасибо, очень интересная статья.

Но, на мой взгляд, в ней есть одна фундаментальная ошибка относительно технических тестов.

Берем факты:
— В течение одного года собиралась статистика по компании, которая использовала Codility
— 70% кандидатов не прошли тест
— Был один случай, когда настояли на игнорировании теста и кандидат выполнил тестовое, прошел собеседование и испытательный срок.

Берем вывод:
— Codility плохо работает

Вывод и факты логически не связаны. Но такой вывод, безусловно, напрашивается. Почему?

Когда вы входите во взаимоотношения с клиентом, вы начинаете работать над общей целью — нанимать подходящих (а в идеале, супер-крутых, talents, a-players, бла-бла) людей для открытых позиций клиента. Применяются разные инструменты, которые помогают достичь эту цель. Codility действительно не помогает в достижении этой цели. Потому что он, как раз наоборот, помогает не нанимать неподходящих людей vs нанимать подходящих людей

Помимо стоимости простоя (к примеру, потери компании в случае, если вакансия не закрывается слишком долго) есть стоимость найма (частично состоящая из стоимости человеко-часов сотрудников, занятых в отборе) и потери от ошибочного найма. Как правило, размер потерь от ошибочного найма значительно превышает все остальные возможные косты.

Нна вкус и цвет все фломастеры разные, поэтому решение применять или не применять Codility, Hackerrank и т.д. — исключительная прерогатива компании, в идеале основанная на понимании структуры своих расходов на хайринг. Аргументация вида «но он же отсеивает 70% кандидатов» не очень валидна, потому что это как раз то, что этот инструмент и должен делать: )

Как можно иначе истолковать приведенные факты?

— 70% кандидатов не прошли тест? Окей, есть несколько возможных причин:
1. Они уже не кодят каждый день (так часто бывает у сеньоров/лидов), поэтому не способны за ограниченное время решить задачу, в которой нужно писать код. Как с этим быть? Четко прояснять взаимные ожидания. Если позиция предполагает кодинг каждый день, и кандидат это делает (и хочет делать дальше) — он без проблем справится с codility
2. Кандидаты не способны фокусироваться на конкретной проблеме (так часто бывает у сеньоров/лидов). Они просто по колено завязли в облаках, бигдатах, архитектурах и привыкли мусолить вопросы и решения по несколько недель. Как с этим быть? Четко прояснять взаимные ожидания. Если позиция предполагает уметь фокусироваться и быстро решать конкретные проблемы, и кандидат это делает (и хочет делать дальше) — он без проблем справится с codility
3. Кандидаты просто некомпетентны. Стоит признать, большой опыт «интересных проектов», к сожалению, не всегда гарантирует компетентность кандидата.
4. У компании слишком сложный тест. На кодилити множество вариантов тестов и их кастомизации, если в тесте есть задачи на жадные алгоритмы или динамическое программирование — ну как бы, надо понимать цель, зачем проверять именно такие навыки кандидатов.
5. У компании слишком высокий проходной балл. Нужно понимать, какой реальный балл теста позволит отсеять большинство некомпетентных и «слишком компетентных архитекторов», и использовать именно его. Также можно иметь определенное окно (Например, 70 проходной, 55 — 70 — смотрим в случае наличия каких-то дополнительных положительных факторов)

— Был один случай, когда настояли на игнорировании теста и кандидат выполнил тестовое, прошел собеседование и испытательный срок?
1. Вообще ничего не говорит о том, насколько это хороший найм. Он мог быть уволен через 6 месяцев или через год.
2. В большинстве компаний испытательный срок — это формальность. «Покупают» человека именно на интервью, и, далее, держат в компании даже если он/она не совсем оправдывает ожиданий. Чтобы не пройти испытательный срок, зачастую, нужно быть злостным вредителем.

Ну и на закуску, из моего опыта работы в организациях 100+ человек, самый высокий уровень подготовки инженеров был именно в той единственной компании, которая использовала Codility как один из этапов. Существует ли корреляция? Каждый пусть решает сам для себя :)

Так что ТС всего-лишь описала свой опыт

И сделала вывод о том, что тесты не работают. Мой же поинт в том, что
1) их, скорее всего, просто неверно готовят / используют в неподходящих ситуациях.
2) вывод сделан на основании неполного разбора проблемы — проблема освещена только со стороны «тесты рубили воронку», т.е. рассмотрен только негативный сценарий. Позитивный же, «тесты экономили время наших инженеров» и «тесты помогали нам не нанимать некомпетентных» — не рассмотрен.

И он в общем совпадает с моим с этими всеми тестами. ну и по обсуждению ниже видно, что совпадает с опытом многих других отписавшихся.

ИЛИ совпадает с опытом людей, которые не любят / не умеют решать time bound алгоритмические проблемы. Мы не знаем бэкграунда этих людей поэтому это может быть истолковано как экспертная оценка, так и cognitivity bias.

Я, например, дважды не прошел behavioural intervirew в одну из FAANG компаний. Значит ли это, что behavioural interview sucks? Мой же опыт говорит именно об этом, и аргументов я могу привести массу, и даже показать, что я могу лучше справиться с теми же задачами, которые решают инженеры компании на основании опенсорса.

К чему это я все — зачастую «статистика» (70% отсев) и аналитика (большинство наших сеньоров не справлялись, а европейские справлялись, джуны не бросали, а сеньоры бросали) служат для подтверждения заранее сформированного вывода, а не для формирования вывода. Если анализировать ситуацию непредубежденно — нет оснований для вывода «это не работает». Это скорее «у меня не получилось, поэтому это не работает», что, в целом, совершенно неплохо, и тоже очень полезная информация — но статья и обсуждение настаивают именно на том, что просто «это не работает».

Ваши комментарии имеют дважды большую ценность, чем сама статтья, спасибо. Действительно, тесты никаким боком не коррелируют с задачами, которые придётся решать. У меня нет тикающего секундомера на задачах, сами задачи могут быть более комплексными, есть другие люди рядом (команда!), и если и надо решать что-то алгоритмично или математически сложное — к этому выстраивается совершенно другой подход.

В кои веки приятная статья

повністю підтримую безглуздість використання психологічних або технічних тестів на первинній співбесіді (та й далі теж). іноді навіть розмова телефоном або переписка на дає чіткого розуміння про кандидата, і при офлайн зустрічі людина показує себе ну зовсім з іншої сторони. але все ніяк не зрозумію як поводитись з кандидатами, які самі подаються на позиції, зацікавлені проектом, але відмовляються оновлювати, або взагалі складати резюме, відправляючи на свій LinkedIn, де крім ім«я/прізвище є ще максимум тайтл Senior Engineer, 10 років на поточній компанії (БЕЗ переліку проектів та технологій) і 3 ендорса. п.с. рекрутер завжди «ЗА» хоча б 1 сторінку резюме, або 2 для сіньорів :)

Якісно заповненого ЛінкедІна має бути цілком достатньо. А якщо є ще кілька референсів, то взагалі супер. «Паперові» резюме — це вже пережиток минулого.

буде достатньо «електронного» резюме (.pdf) адже сумніваюся, що хтось подавався би на роботу наприклад в Google просто лінком на лнкдн. хоча якщо такий досвід є, залюбки почитаю про нього

Вам так кажется. Background check: 1credit history + criminal records. После получения job offer вы заполняете employment application (contacts your Head of/PM/CEO + position + recommendation + reliving letter + cover letter). У меня в профиле 2 компании прекратившие свое существование — запросили форму W2 за данный период работы в компании а так же pay stub.
Долго мурыжили, потому как не на фирменном бланке был RL.

Ну я не против получить от кандидатов пару референсов, довідку про несудимість, и желательно историю кредитов, но уже спасибо если LinkedIn содержит нужные детали чтобы начать разговор.

обычный пример найма на позицию Middle UX/UI Designer в обычную «забитую» по местным меркам компанию, так что бумага торжествует.

В очередной раз убеждаюсь, что HR ничего не понимают в скилах инженеров, которых они отбирают. Причем по очень простой причине — они сами никогда не писали код. Вообще. Никакой. Никогда. Мне не нужны тесты, чтобы оценить навыки инженера — как в общении, так и технические. Но я работал с сотнями инженеров на разных проектах и точно знаю, что, когда и почему нужно. С чем можно разобраться по ходу проекту, а чему нужно посвятить пару лет вдумчивого изучения. Тесты хорошо работают на рабочих специальностях — кассир, бухгалтер, сантехник, электрик когда нужно нанимать сотни людей на стандартные задачи, но в сложных инженерных специальностях такие простые критерии не работают. Тем более минимум половина инженеров умеют правильно отвечать на любые тесты, воспринимая это как некоторое абстрактное неизбежное зло при поиске работы, которое нужно просто пройти любым способом, как очередного монстра в какой-нибудь игре )))

Ерунда. По-моему, сейчас программирование есть в каждой школе и как минимум на VB, Delphi, Pascal или С++ писала бОльшая часть учеников хотя бы год. Из IT-рекрутеров, которые реально погружаются в тему и в профессии не по случайности и не для того, чтобы найти мужа, это совершенно не редкость. %, конечно, таких все меньше и меньше из-за популярности направления и низкого порога входа в профессию. Однако категоричность про то, что HR не писали никогда никакой код — не верна. Про целесообразность тестов в том или ином случае — действительно вопрос не на одну статью, лично я за то, чтобы отсеивать поток джунов тестовыми, а уже с ребятами с опытом обсуждать конкретные задачи и примеры из того, что может реально понадобиться на проекте.

Ерунда. По-моему, сейчас программирование есть в каждой школе и как минимум на VB, Delphi, Pascal или С++ писала бОльшая часть учеников хотя бы год.

А ещё мы на химии из колбочки в колбочку переливали и смешивали всякие жидкости — теперь можем все дружно заявлять, что «проводили химические эксперименты», и оценивать таковые химиков-профессионалов, что ли?) Конечно же, не можем.

Однако категоричность про то, что HR не писали никогда никакой код — не верна.

В контексте, в котором это было озвучено, категоричность вполне оправдана.

Гораздо важнее отсеять поток сеньоров, чем поток джунов...

Где связь? Не улавливаю.

Вячеслав, а поделитесь, пожалуйста, своей воронкой:

— Кандидаты, которые пришли на собеседование (100%)
— Наймы (x%)
— из них удачные (y%)

Почему спрашиваю — мне кажется, что

Мне не нужны тесты, чтобы оценить навыки инженера — как в общении, так и технические.

ведет к тому, что у вас x == y, что невозможно на более-менее продолжительной дистанции :)

Ну так а сколько из нанятых оказалось «неудачных»?

В таком случае, чем бы вы не занимались сейчас, вы сильно недооценены.

Умение безошибочно отбирать подходящих технических специалистов — это киллер-способность, которую с руками и ногами оторвет любая крупная техническая компания. Сеньоры из долины по 200к в год будут числиться у вас секретарями. Дерзайте покорять этот мир.

Так а при чем тут начальник.

Судя по твоей статистике, ты — дартаньян идеальный специалист, который никогда не ошибается. Ну или хотя бы в вопросах оценки и найма инженеров.

Ланфрен ланфра!

Судя по твоей статистике, ты — дартаньян идеальный специалист, который никогда не ошибается.

Альтернативное мнение:
он просто понимает что ему надо. И пытается нанять людей которые будут полезны, а не «лучших из лучших, по неопределенным требованиям»

И ни разу не ошибался?

Самая хорошая проверка для тестов — готов ли их пройти сам HR либо лид-разработчик. Для меня показательным был случай, когда мой же вопрос кандидат отзеркалил и попросил ответить на него. Было весело :).

То же и с тестовым. Оно не должно быть сложным в принципе, ведь как завещал Джоэль, нам важно проверить всего две вещи: что перед нами находится человек умный и что этот человек умеет решать нужные нам задачи. Одно можно проверить беседой, второе — поработав вместе над практической задачей.

Кстати для этого сугубо на выбор мы предлагаем прийти к нам в гости и сделать тестовое сев рядом, не имея практически ограничения по времени и пользуясь чем угодно в том числе задавая вопросы нам.

Погоджуюсь з статею. Codility — платформа, яка напрягає. Ти очима більше на таймері, ніж в коді. Хоча там дозволяють писати код де хочеш, а вкінці копіювати, що непогано. Але деякі компанії йдуть далі і дають якусь платформу аля блокнот, де нормальної підсвітки нема, треба підраховувати дужки самому, дивляться в монітор на кожний клік, вже мовчу про рідненькі гарячі клавіші яких немає. Неоправданий, нікому не потрібний стрес.

Підтримую автора! Якщо б тести це — добре, тоді б не було stackoverflow. Як працює програміст: читає інструкцію до бібліотеки(і т.д.),виконує її(пише код), запускує код — випадає error. Чого? Бо по інструкції нічого не працює. Така реальність. І ще одне: вченими доведено: завжди швидше буде працювати той хто зразу правильно пише. Відповідно шукати правильний варіант — це завжди повільніше. Підсумовуючи вищесказане: правильно — брати спеціаліста на випробувальний термін і ніяких заморочок і т.д.

Если говорить про технические тесты, — то это корень всех зол при отборе.

Если хотите просто отсеять большинство кандидатов, то лучшего способа не найти.

Вопросы для этих тестов, чаще всего, придумываются тех. сотрудниками фирмы, — т.е. они будут рандомны и зависят только от фантазии придумывающего. Добавьте сюда таймер для ответа и всё, — попав в такую обстановку рандомной экзаменации, провал кандидата практически гарантирован.

Исключение, — сертификация. Суть у неё та же, но с огромными отличиями. К ней готовятся очень заранее, темы вопросов так же известны заранее (а то и в наличии сам дамп вопросов), и кандидат заинтересован в сертификате, а не в обычно абстрактной вакансии.

Решение: или оплачиваемое небольшое тестовое задание, что обяжет работодателей не разбрасывать это задание всем подряд, а кандидатам даст стимул его проходить. Или нанимать кандидата на пробный период. В любом случае его работа в первые дни/недели покажет вам, подходите или нет вы друг другу.

//
Что касается психологического отбора, а точнее в данной статье была упомянута соционика (её аналог на западе, — Майерс-Бриггс), то это имеет смысл, если нужно набрать подходящих именно по соционическому психотипу людей. Нужно так же понимать, что соционика описывает «скелет» психики, — то, что для психотипа самое важное. То, как он воспринимает и обрабатывает информацию. Но соционика абсолютно никак не учитывает приобретенные особенности характера человека или его текущее эмоциональное состояние.
Чтобы это сработало этим должен заниматься не HR, а профессиональный психолог-соционик. Соционика не учится за пару недель, — чтобы надежно типировать человека нужна практика в несколько лет.
А что касается тестов на неё то, чтобы они более или менее надежно работали (процентов на 60% я бы сказал) то выбирать надо только проверенные тесты, с кол-во вопросов не менее 70-и, и написав сверху большими крупными буквами что-то вроде: «Проходить честно, не спеша, и в обычном для себя эмоциональном состоянии»

Что касается соционики, то это, вообще говоря, псевдонаука для домохозяек.

А типология Майерс-Бриггз, которая, кстати, не то же самое, что соционика, никак не описывает отношения между типами. И тоже крайне сомнительна с научной точки зрения по части оценки личности. Как и любая другая околоюнгианская типология.

Юнг вообще очень слабо дружил с научными методами и подходами.

Если хотите просто отсеять большинство кандидатов, то лучшего способа не найти.

Отсеять тех кто никогда не сдавал экзамены. На самом деле это очень хороший способ смоделировать ситуацию: прод упал и не поднимается, товарищ который писал ту часть кода — в отпуске, надо срочно понимать, а точного знания части кода которая валится — нет. Такое деяствительно бывает, и для бизнеса важно чтобы в таких ситуациях люди не в падали в ступор а оперативно всё поднимали (и нет, это не потому что плохая архитектура/дизайн/процессы, а потому что сколько не предохраняйся shit happens). Те кто впадают в упячку при виде тестов, с большой вероятностью впадут и при описанной выше ситуации.

Тесты такие легко проходятся людьми, у которых слабая память при возможности (при прохождении ) пользоваться гуглом, доками, мануалами, хабром, оверфло — в режиме поиска и чтения. Это главное. Почему-то некоторые считают — что тесты всем надо проходить «по_памяти» не используя инструменты хранения знаний (любые сайты, где по теме чего-нибудь есть) Тесты покажут только наличие или отсутствие хорошей работы памяти. Кстати, сейчас память у всех плохой становится, так как мозг самостоятельно делегирует часть собственных функций интернету (раз в интернете есть- я не буду больше это помнить) и это происходит бессознательно. Применение знаний это НЕ запоминание-вспоминание знаний. Это другое — это уверенность в том, что что-то будет работать так, как было скопипасчено.

codeforces.com/contests. Вот тебе список тестов. Думаю что даже треть-половину задач ты с гуглом будешь мучать всё время прохождения испытания. Такие тесты не проходятся методом гугла, только знаниями. Далеко не все вещи можно сделать при помощи интернета. Кое где надо кое что поучить.

Нет. Все уже решено на уровне шаблонов. Подставляешь конкретные значения в настройки и все. Функциональная полнота достигнута уже.

Ты, видимо, к прикладным задачам и не притрагивался. Если ты считаешь что изобретение велосипедов это моветон, то почему велокомпании так успешны, и каждый год представляют новинки?

Я уже двадцать лет пишу всякую херню. Сейчас уже почти не помню ничего из того, чтобы было мной где-то когда-то написано. Оно и не было использовано — так, чьи-то хотелки...
О велосипедах — ты просто не хочешь разбираться в чужом велосипеде — потому что это значит учить его наизусть. А память бессознательно уже стараешься не переполнять.
Вместо этого ты пишешь собственный велосипед делающий тоже самое.
Есть еще вторая часть — удорожание разработки внедрением дополнительных сложностей.
Есть еще вот что про велосипеды — уже есть велосипед, но если вы не гуглите — вы ни хрена о нем не знаете — и пишете собственный.
Из-за сокрытия данных — явного или не явного — вы тоже пишете собственные велосипеды.
А я свои игрушки бесплатные написал потому что не захотел платить за чужие игрушки.
(Штук 10 более-менее работающих пет-проектиков, выполняющих для меня лично полезные мне функции.)
Наслоение это способ упорядочивания. Помнить все невозможно. Искать людей с хорошей памятью значит отбрасывать в сторону людей с хорошими аналитическими способностями (так компенсируется плохая память (и не только этим кстати)).

Я уже двадцать лет пишу всякую херню.

Вот эта фраза мне кажется ключевой.

И пришел к выводу, что любые удачные решения проще всего подбирать случайным образом.

Скоро напишут лучше. VR glasses + AR + needed software

е кто впадают в упячку при виде тестов, с большой вероятностью впадут и при описанной выше ситуации.

Фигню несете, сэр.

В случае упавшего прода есть логи сервера, доступ к исходникам, возможность дебага, доступ к интернету. Как это всё связано с тестами а-ля экзамен?

Не говоря о том что это таки процессы — прод не должен падать сам по себе без внешнего вмешательства.

В случае упавшего прода есть логи сервера, доступ к исходникам, возможность дебага, доступ к интернету

Вопрос не в том что можно поднять вообще, а за сколько ты это сделаешь.Чем быстрее тем лучше. Если ты помнишь что и где, то решение будет искаться очень быстро. Если ты помнишь откуда и почему выскакивает эта ошибка, время на локализацию тратиться не будет.

без внешнего вмешательства

 Вы сферический шар в вакууме который с внешним миром не коммуницирует?

Если ты помнишь откуда и почему выскакивает эта ошибка, время на локализацию тратиться не будет.

Угу, потому что если «ты помнишь», то должен был ее исправить, ошибка не должна была попасть на прод.

Если ты помнишь что и где, то решение будет искаться очень быстро.

А если не помнишь, то что делать?
Когда вы дорастете до синьорного уровня, то поймете, что знать код вообще не надо. Надо сформировать повторяемый сценарий проблемы (как правило с помощью логов), предложить способ прекращения таких проблем в продакшене и исправить проблему.

Когда вы дорастете до синьорного уровня, то поймете, что знать код вообще не надо. Надо сформировать повторяемый сценарий проблемы (как правило с помощью логов), предложить способ прекращения таких проблем в продакшене и исправить проблему.

Спасибо К.О. чтобы я без вас, делал.

Угу, потому что если «ты помнишь», то должен был ее исправить, ошибка не должна была попасть на прод.

Ошибки свидетельствующие о нарушении контрактов взаимодействия с внешним миром тоже ошибки, и я говорю именно о них, часть из них нельзя никак исправить, как например ошибки пользователького ввода.

Надо сформировать повторяемый сценарий проблемы (как правило с помощью логов)

Если помнишь откуда какие логи, там и формировать то нечего.

А если не помнишь, потому что код писал кто-то другой, а шарящие в этом куске в отпуске?

часть из них нельзя никак исправить, как например ошибки пользователького ввода

Валидацию ещё не изобрели?

Валидация никак не исправляет неправильное данное. Если тебе пришёл на вход аппликухи которая делит а на б а= 1 а б = 0, то ты никак это не исправишь, просто потому что а и б ввод, которым ты не управляешь. Даже если ты навесишь валидацию сюда ты свалишься с исключением валидации, но хоть тресни запрос пользователя о делении 1 на 0 ты не выполнишь, и я об этом. Зная где вылазят такие ситуации, можно понять что — где и в связи с чем поломалось.

Даже если ты навесишь валидацию сюда ты свалишься с исключением валидации

Исключение бросается в обработчике запроса, фреймворк его перехватывает и отдает клиенту ответ с кодом 400 и текстом ошибки валидации. Остальные клиенты работают с сервером как и работали, никакой прод не падает. Так работает современный веб, если писали аккуратно и проводили код-ревью.

Конечно если в команде традиция писать под таймером и лить результат на прод — то может быть все что угодно и лучше пусть они используют при отборе кодилити, хакерранк и что-нибудь ещё одновременно, чтобы точно к ним попали только ninja-hacker-samurai developer.

Конечно если в команде традиция писать под таймером и лить результат на прод

Все стартапы именно так и работают же.

Неправильное у вас представление о всех стартапах

Если ты помнишь откуда и почему выскакивает эта ошибка, время на локализацию тратиться не будет.

Тесты на сферических коней при чем?

Тут немного отошёл я в сторону, но суть теста — умение решать быстро проблемы вне зависимости от её сути. Problem solving skill, и проверять его надо именно на сферических конях, чтобы технический опыт кандидата не накладывался и не мешал его замеру. Слышал слухи что гугл его мерял его при помощи такой задачи: есть один маршмеллоу, куча лапши и скотч, нужно построить как можно более длинную конструкцию которая может стоять. К ойти и программированию она не имела совершенно никакого отношения.

Ибо у них нет привычки к поиску решения, когда его нет в памяти.

Баллшит, умение решать задачи мало связано с памятью. Знаю много живых примеров с хорошей памятью и с хреновой которые умеют решать задачи примерно на одном уровне, правда те которые с памятью делают это быстрее.

Хорошо вот тебе задачка. Есть 100 объектов в одной выборке и 200 в другой. Найти в двух выборках наиболее близкие друг к другу.

мутная постановка, решать не буду.

объектов

что за объект, какое пространство?

Пусть это будут голоса людей

это вообще что?

наиболее близкие

как отделить наиболее близкие от близких и далёких?

прод упал и не поднимается, товарищ который писал ту часть кода — в отпуске, надо срочно понимать, а точного знания части кода которая валится — нет. Такое деяствительно бывает, и для бизнеса важно чтобы в таких ситуациях люди не в падали в ступор а оперативно всё поднимали
Те кто впадают в упячку при виде тестов, с большой вероятностью впадут и при описанной выше ситуации.

Cлабая корреляция.
Описанный в цитате кейс: если упал не мой код, то откуда стресс возьмётся? Он может возникнуть разве что от чрезмерного кипиша со стороны выше по иерархии лично в сторону девелопера, но в таком случае «да, это потому что плохие процессы», и нужно увольняться из этой конторы, если нет каких-то супер условий.
Если же упал мой код, то стресс есть, но т.к. код мой, условия абсолютно разные.

Опишу кейс, который был у нас в прошлом году: важный релиз, который давно обещали в срок, и тяжёлый (прикручивается большая новая серия фич, которые пилил не я). Ближе к пятнице оказывается, что после определённого (достаточно большого) кол-ва тестовых прогонов новый код начинает падать, и в таком виде в прод его выкатывать нельзя. Мало того, всё это происходит незадолго до performance review. Девелопер пытается его фиксить, но безрезультатно. В итоге (время уже ближе к ночи) в код лезу я, и минут через 40 исправляю ошибку.
Внимание, вопрос: пофиксил бы я этот код, если бы у меня в углу цокал таймер в условных 20 минут, или если бы менеджер начал истерить? Не факт.

Поэтому, хоть от тестов лично я и не «впадаю в упячку», это не делает их осмысленным инструментом именно выбора лучшего кандидата.

у шарашмонтажа, который планирует новичка незамедлительно бросать на подъём падшего прода, имеются крупные про*бы в управлении, и долго он не протянет, так думаю.

Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

ох нихерасе, уже и пчелы против мёда

ох нихерасе, уже и пчелы против мёда

Вообще-то все логично. Рекрутеры (особенно внешние) против всего что может помешать им получить бонус за найм.
Тесты — это творчиство 23-летних лидов: человек просто не умеет проводить собеседования, не хочет учится, а хочет как амазон.

Вообще-то все логично. Рекрутеры (особенно внешние) против всего что может помешать им получить бонус за найм.

100%

Тесты — это творчиство 23-летних лидов: человек просто не умеет проводить собеседования, не хочет учится, а хочет как амазон.

Нет, это тесты курильщика. Тесты здорового человека как раз есть потому, что любой self-aware специалист исходит из того утверждения, что он может ошибаться, в том числе и при проведении собеседования и хочет снизить процент ошибок.

Ну, смотря что для компании дороже.

что любой self-aware специалист исходит из того утверждения, что он может ошибаться, в том числе и при проведении собеседования и хочет снизить процент ошибок.

А может self-aware специалист объяснить, как и каких именно тесты позволяют избежать (снизить процент) ошибок?

инженеры не умеют проходить тест. Они начинают нервничать, жать не те кнопки. Они его валят

не нужны вам такие инжинеры, они потом и в обычной работе начинают жать не те кнопки и валить задачи

За последние 2 года проходил кучу собеседований в кучу компаний. Так же проводил собеседования. Так вот, заметил следующие особенности:
1. Рынок труда стремительно меняется.
2. Компетенция и кандидатов и иниервьюверов падает. Касательно рекрутеров, стараются. Но есть и плохие процессы в компаниях, как и личная неорганизованость рекрутеров. Из всех потенциальных вакансий, приглашение на собеседования, 25-30%. А по оферам выходит, 5-7%. Это субьективная выборка.

Моё личное мнение, тестирование необходимо, так как оно позволяет всех мерять одними критериями и даёт представление о кандидате. Из минусов, те кто проводят собеседование — не учитывают стресс фактор и как он влияет на перформанс. Это проблема не Украины, это в целом общечеловеческий фактор, так устроен наш мозг. В целом если у людей уже есть опыт стрессовых интервью или работы, для них подобное не проблема. В противном случае интервьювер должен создать комфортную рабочую атмосферу и разогнать могз кандидата, в конце концов его задача — найти хорошего специалиста, а не упустить его, что бы он ушёл в другую компанию.
Советую всем кандидатам, в таких ситуациях, по хорошему разозлиться, включить профессионала и отвечать на все вопросы в соответствии со своим опытом, знаниями и пониманием. В частности если вопрос слишком абстрактен, что часто бывает. Уточнять, а ещё лучше самому задавать неопределённые вещи и выдавать все возможные варианты.

Компетенция и кандидатов и иниервьюверов падает.

нет, это ваша — незаметно для вас растёт :)

ваша — незаметно для вас растёт

 — вайтишники.

кстате :)

Цитата № 1:

доводы в пользу тестирования существуют и они вполне рациональные:
. . .
2. Убрать субъективность.

(вааще говоря, практически нереально :( )

Цитата № 2:

Я убеждена, что человек при общении с другим человеком воспринимает своего собеседника на телесном уровне.

- субЪективно, не так ли :) ?

В таком кратком изложении идея звучит :) Если автор считает, что может подбирать IT-кандидатов указанным субЪективным восприятием, то понимаемо наличие нелюбви к тестам. Я бы не против и сам обзавестись таким шестым чувством :)

Кто то явно упускает из виду психологические факторы. Порядка 90% информации при общении передаётся не вербально, если человек вам нравиться, но не самый лучший специалист, у вас все равно будет положительное впечатление. По этому стоит проводить собеседование в 2-3 человека для объективности.

Можно долго и безуспешно спорить (хотя я вопщем +1). Например, (а) 2-3 человека — это есть меньшая субЪективность, а не обЪективность (б) пси-хиатры среди рекрутеров утверджают, что среднему кандидату напряжно проводить собеседование более чем с одним интервьюером (в) соьбеседования все чаще бывают посредством коммуникатора, где 90% резко уменьшается , и пр.

Взгляд рекрутера

Вот на этом и стОит остановиться. Ибо (я в это верю) не рекрутеры берут людей на работу в компанию :). Со стороны выглядит, что Вы намекаете на сложности своей работы по успешному отбору и предлагаете сделать сито менее частым ;)

Все мы помним цитату из Бренсона (сори, по памяти): берите дескать на работу классных пацанов, нетоксичных людей, подучить их специальности — плевое дело, а вот если они начнут вас учить жить — тада всем гайки :( Кто-то так делает? из известных мне контор — нет :(( Т.е., IT-конторы предпочитают брать на работу как правило сложившихся профессионалов .. я конечно про девов и тестеров :))
2. Вааще-то практически любая вакансия содержит в себе в начале название конторы. Однако при этом па-харошему есть описание проекта и требования к позиции на этом проекте. Т.е. претендент в 95% случаев идет работать с конкретной задачей, а не в просто «в компанию». Т.е., IT-конторы берут на работу профессионалов, которые хорошо ориентируются в конкретном нужном вопросе.

Я не настаиваю на том, что сие правильно, я констатирую факт. И, насколько мне известно, в IT-ных конторах в Штатах подход аналогичный. Этот подход лет 20 как кардинально не меняется. Пришло время его изменить? вряд ли :( Я думаю, что рекрутер должен помогать заказчику вакансии в этой ситуации.

Есть такой известный в Украине инструмент тестирования IT-специалистов, как Codility

Далее, мнение автора сводится к тому, что Codility — это зло. Возможно, но из этого не следует, что любой тест — зло, не так ли? И я бы в жисть не давал всем претендентам одинаковые тесты.
Про пси-хологические тесты промолчу ... почти :) Скажем так, лична я не против их применения.

в 70% случаев не справляются с тестовым заданием, даже будучи достаточно компетентными специалистами.

Ну так настаивайте на том, чтобы взять их на работу, если считаете что они достаточно компетентны! кто мешает?! Или все-таки появляются сомнения ;) ?

Возмущенный технарь скажет: «Почему я должен на это время тратить? Лучше пойду в компанию, где со мной поговорят нормально, как с человеком!».
человеку нужно было решить задачу по программированию, он писал какой-то код, и потом Senior Architect или Team Lead оценивал качество работы этого человека. И то такие задания 50% кандидатов отказывались делать.

А Вам не кажется, что человек, который отказался от теста, потом точно так же откажется от собеседования с заказчиком, от требований заказчика по code style, по delivery, от релиза поздним вечером, когда на Калифорнийщине только-только взошло сонечко? и пр. и пр. — ?

это такая тяжёлая и сложная работа — выбрать правильный тест.

Это для рекрутера такая работа тяжелая. Для технического спеца, который проработал на проекте пару лет (см. п.1 и 2.) это несложно.

Поэтому я за то, чтобы прежде всего научить наших рекрутеров и даже технических интервьюеров глубоко разбираться в людях...

Давайте начнем с более простой задачи: обучим рекрутеров рекрутерской пси-магии, а технических спецов — умению проводить технические интервью. Про человеческие качества кандидата они посоветуются с Вами.

Но и нащот «разбираться в людях» и в их способностях. Если претендент — не Васенька с которым я-Вы отработали пару лет назад вместе на протяжении некоторого времени, то быстрым способом (т.е. за время отведенное на собеседование) узнать его тип личности, мотивацию — это Ваши пси-тесты. Узнать его профессиональную подготовку — это в т.ч. хотя бы минимальное техническое задание по интересующей интервьюера теме. Я не возражаю, что сделать это можно и в ходе собеседования, не употребляя слово «тест», но все ж умные люди :) или по крайней мере сообразительные :)

Делегируем ИИ?

Нет конечно, согласен. Причина проста: работать дальше с этим человеком, а не с ИИ, который взял его на работу.

Отож, я категорически за разговор на собеседовании, профессиональное интервьюирование, гибкий подход и пр. и пр. А дальше: у каждой вакансии есть заказчик — тот , кто ее выставил. Есть также начальник, который принимает решения о приеме людей на работу — очень надеюсь, что это не рекрутер. У начальника может быть сколько угодно соображений, в т.ч. финансовые, личные, «температура» вакансии, мнение рекрутера и пр., но определяющим должно бы быть мнение заказчика вакансии. У последнего может быть тоже куча факторов, и тест — только один из них . Если претендент завалил многозадачность, с которой ему предстояло бы работать, то тест сэкономил всем и время, и нервы, и деньги. Если не ответил на вопрос по UI, а будет писать бекенд — зачем такой тест давали :) ?

В мене є підозра, що невміння проходити класичні тести — наслідок не особливості пост-радянського навчання чи якогось особливого менталітету, а наслідок відсутності базових академічних знань в розробників. Більшість айтішників — самоучки, які починали з фрілансу чи примітивних проектів і розбиралися в сфері «на ходу». Відповідно знання до них приходять не зі стандартних підручників а з суворої реальності, в якій байти інвертуються а дерева перевертаються хіба що на співбесідах. Тож реальні бойові задачі вони вирішувати вміють, бо такий досвід в них є, чого не скажеш про досвід проходження стандартизованих тестів.

В ІТ індустрії Європи і Штатів, мабуть, більший відсоток людей з профільною та сучасною освітою, тож тести і задачки для них звична штука.

Да не обязательно — например значительную часть задачь можно легко решить после универа или он-лайн курса по алгоритмам (просто на свежую память), но если с каким-то типом задач не сталкиваться на практике регуярно — скорость решения их падает ... но ! при этом нормальный специалист прекрасно понимает в какую сторону проводить исследование (или освежить фундаментальные основы), чтобы решить бизнес проблему .... во время теста это просто могут не проверять.

Не совсем так. В Америке тоже два лагеря — один за прохождения тестов, другой — против. В основном они ломают копья на Quora. А на самом деле — все просто. Люди помоложе в основном за прохождение тестов. Люди постарше — в основном против. И те, и другие приводят ряд объективных причин. И оба лагеря по-своему правы. Проблема в том, что если Software Developer необходимо и положено знать алгоритмы, то Data Engineer — это немного другое. Для последних, программирование — не главное, это только часть их работы. Хотя, в последние пару лет эти две профессии очень сильно пресекаются.

а з суворої реальності

Что это за такая реальность где ни одной структуры данных и алгоритмической задачи нет?

Ну так это очень-очень известная и востребованная подзадача которую юзают в ML и не только. есть много подходов в зависимости от объёма данных и рода объекта. Даже для бд есть приблуды, которые делают что то подобное, но целиком и всюду там одни алгоритмы со структурами данных, и

что ты имеешь в STL

тут почти не причём. Кстати, вроде как в sklearn который можно считать stl, это уже сделано.

Вайтішна реальність

навпаки, більшість IT спеціалістів в нас — випускники технічних вузів, в яких достаньо базових академічних знань.
Здається в нідерландах 20% айтішників — випускники вишів, інші випускники аналогів шкіл\пту

От тільки ті базові знання мені в кінці 90их-початку 00их давали без привязки до індустрії. Тому важко було вчити те, що невідомо де викорстовувати.
Зараз можливо помінялось

Тому важко було вчити те, що невідомо де викорстовувати.

Это вам пригодится при написание курсовой © :)

Фишка в том что «ребалансировка дерева» или задачка на «динамическое программирование» __большинству__ пригождается только при ... написание теста на кодилити.

Большинству да, но сколько ему там платят. Я пишу языки, мне надо и алгоритмы, и просто развитым быть

Я пишу языки, мне надо и алгоритмы, и просто развитым быть

Уууу, алгоритмы, развитый. А может все-таки определять колбеки в антлре? :)

Большинству да, но сколько ему там платят.

А вам сколько платят? Только без манипуляций «100500 багзов в час, но работы было на 1 час в 10 лет»

алгоритмы, развитый. А может все-таки определять колбеки в антлре?

Нет, это только начало. Очень часто есть вещи, которые никто не подскажет.

100500 багзов в час, но работы было на 1 час в 10 лет"

Примерно так, в результате получается чуть выше рынка но я свободен

по яких критеріях Ви б вибирали собі тіммейтів? Може ребаланснути дерево, хм... та ну його, баластом буде. В нас дерев на проекті нема)

Хорошие выпускники «изучали программирование самостоятельно до поступления в университет и продолжали изучать его, несмотря на учебу в университете».

[blockquote]«Диплом для неподготовленных

Однажды я проводил собеседование с девушкой, занятой дипломной работой в области компьютерных технологий в известном университете. Она подала документы на летнюю стажировку. Я попросил ее написать для меня решение несложной задачи, а она ответила: «Вообще-то я не пишу код».

Пожалуйста, перечитайте предыдущий абзац, а потом переходите к следующему.

Я спросил, какие курсы по программированию она посещала во время обучения. Она ответила, что не посещала никаких.
Возможно, вам стоит прочитать главу с самого начала. Вы хотя бы убедитесь в том, что вы не попали в альтернативную Вселенную и вам не приснился страшный сон.

Вы спросите, как студент с учебной программой магистра в области компьютерных технологий мог обойтись без единого курса программирования? Я тогда задал себе тот же вопрос. И до сих пор не нахожу ответа.
Конечно, это самый выдающийся случай в серии разочарований, испытанных мной во время собеседований с выпускниками. Не все выпускники в области компьютерных технологий настолько плохи — вовсе нет! Однако я заметил у них нечто общее: почти все они изучали программирование самостоятельно до поступления в университет и продолжали изучать его, несмотря на учебу в университете.

Не поймите меня неправильно. Я считаю, что в университете можно получить отличное образование. Просто наряду с этим можно украдкой проскользнуть через систему и получить диплом... не получив ничего более.

Другая проблема: даже самые лучшие курсы по компьютерным технологиям обычно не готовят молодого выпускника к тому, с чем он столкнется в этой отрасли. И дело даже не столько в недостатках учебных программ, как в реалиях почти всех дисциплин. То, что вы узнаете во время учебы, часто очень сильно отличается от того, с чем вы сталкиваетесь на работе."

— Robert С. Martin
The Clean Coder: A Code of Conduct for Professional Programmers (2011) [/blockquote]

Какое тз к тестовому, такое и выполнение.

Ну, не знаю, я коли проходив скрінінг на кросовері, то тестова система мені навіть сподобалася. Там три етапи — технічний, IQ та культурний. Технічний скрінінг не дуже корелював з напрямком, що мене цікавив, більше тестувалася ширина компетенцій, аніж глибина. IQ-тест був прикольний тим, що був не тільки завідомо непрохідним за відведений час, так і таймер цокав приблизно в півтора рази швидше. Грубо кажучи, «10 хвилин» закінчилися десь за 6-7 реальних. Ну, це зрозуміло, тестування здатності працювати в запарі. А от «єнгліш» там тестувався не просто по граматиці-лексиці, а по ідіомах та різних семантичних приколах. Із вмінням читати доки на рівні «зіс із зе тейбл» його не пройдеш.

Правда, після проходження тестів до мене доколупалися, що потрібне моє офіційне фото в трійці від армані з краваткою і я їх послав лісом. Трійка від армані — то ще так-сяк, але накуку краватка ремотеру?

але накуку краватка ремотеру

Так они же фотки делают каждые 5 минут. Не в трениках же перед компом сидеть.

Я з тими, хто вимагає встановлення різних контрольних софтів, не працюю. Я продаю не жопогодини, а результат.

Ну, тому і послав лісом. Що не відміняє факту прикольності їхньої системи тестування.

Я убеждена, что человек при общении с другим человеком воспринимает своего собеседника на телесном уровне.

Обнимашки вместо тестов!

ІТ давно треба придивитись до практик з кіноіндустрії!

От ви смієтеся, а в кіноіндустрії насправді є чому повчитися

Есть такой известный в Украине инструмент тестирования IT-специалистов, как Codility. Очень страшная вещь. У меня есть более чем годичный опыт сотрудничества с компанией, которая его применяла, собрана обширная статистика. Так вот 70% людей не справлялось с тестами Codility не из-за недостатка своей компетенции, а именно из-за того, что это тест.

У этого есть и обратная сторона. Знаю тех, которые шутя решают задания, в том числе и тестовые, на Кодилити (а также на Хакерранке или на Кодербайте), но пасуют на реальном проекте. Как уже было сказано, задания на Кодилити — только проверка умения реализовать классические алгоритмы на том или другом языке программирования. Чистый computer science на 80% не привязанный к тем задачам, которые приходится решать ежедневно.

Знать и уметь это разные вещи.
Знать значит помнить.
Уметь значит понимать.
Понимать значит — быть в курсе (уже была практика, уже был некоторое количество раз пройден этот путь и сопутствующие ему пути) — быть опытным.
Опыт тем больше чем больше раз было повторено одно и то же (пусть и с некоторыми вариациями)
Знать ошибки на пути и понимать ошибки на пути это тоже разные вещи.
Без знания пределов возможностей знание имеет не четкие границы.
Часто ошибающийся исследует границы.

Знать значит помнить.

Уточню: Знать значит помнить теорию.
А уметь это получается — помнить практику.

Но не детали практики — это специально в справочниках складируют. Деталей слишком много чтобы все их помнить. Лучше (оптимальнее) помнить ключи доступа. Понимать какой запрос надо скормить препроцессору чтобы получить шаблон решения.

Существует два типа наемных работников — те, у которых хорошо работает память и те, у кого плохо работает память. Печально то, что вторые не запоминают, что память у них плохо работает. Однако радостно то, что плохо работающую память они неосознанно компенсируют сильно повышенными аналитическими способностями.

Существуют такие компании и HR которые набирают только сотрудников, у которых память работает хорошо, великолепно и отлично, ибо это делать крайне просто: тесты, вопросы по предметной области, экзамены, аттестации. Заметьте, что все это непреодолимый барьер для наших аналитиков, которые скорее будут угадывать желаемые вам ответы, чем вспоминать их из учебника.

И существует другой тип компаний — который каким-то магическим образом понимает нужду и полезность сотрудников, которым надо все повторять не один раз и не два, а десять. Еще лучше сразу засунуть их в атакующий сервис напоминания запланированных начальником свершений для них. Тут есть еще такой момент — такие сотрудники, когда пытаются соответствовать сотрудникам с нормально и очень хорошо работающей памятью — они задних пасут. Но если они будут выявлены и им будут предложены задачи подходящие для их магических скиллов (а это именно так, они по сути своей не раскрытые маги, настоящие волшебники в области перебора возможностей и вариантов и даже предсказания будущего, сильнейшие ваши интуиты, если конечно вы доверите им исполнение некоторых ваших желаний) то они эти самые ваши желания исполнят, легко разобравшись в любых головоломках — при верчении кручении которых в разные стороны память (вот уж новость) является помехой.

Я уверен, что второй тип компаний, разумно использующий скиллы брутфорсеров будет всегда на шаг впереди компаний первого типа. Поэтому вот мое «коммерческое предложение»

Элементарно просто можно запрограммировать игру — тестирующую способности человека запоминать, вспоминать и анализировать (думать)

Я уже запрограммировал модель такой игры и на мне она показывает как раз то самое — я лузер. То есть маг и волшебник. Я второго типа. Плохую память компенсирую постоянным чтением учебников и поиском по справочникам и гуглением. Для меня это элементарно просто и максимально быстро. Я так пишу на трех-пяти языках программирования и мне это не трудно (поиск подходящего по условия паттерна и потом копипаста)

P.S.

С помощью своей игры я могу проверить любого на предмет того, насколько хорошо у человека развита память.

Круто написано. Второй тип — прям про меня.
Недавно проходил 2 собеседования в 2 разные комманды. Требования одинаковые.
В первой поспрашивали немного базовых знаний и большую часть времени играли в игру типа разработчик-заказчик. Мне надо было написать функцию, по требованиям заказчика. На самом деле я ничего толком и не писал, мы много обговаривали решения неоднозначностей, логику выполнения, подводные камни, множество вариантов решения, их плюсы и минусы. Результат: всё было отлично, я им подхожу.
Во-втором собеседовании был опрос базовых знаний и знаний, хм, из справочника, что ли.. Спрашивали вещи, котрые в реальной жизни никто не использует или используют крайне редко. Очень часто у меня ответом было: не знаю, никогда не сталкивался и ни у кого в коде такого не видел. Собеседование оборвали на половине, решили, что «со мной всё ясно», посоветовали читать побольше книг. Я уже не стал говорить, что постоянно читаю и перечитываю. Но, к сожалению, запоминаю больше то, что использую на практике.

Я в_о_о_б_щ_е не могу запомнить конкретные детали вызова той или иной функции в API или фреймворке.
В общем — запоминаю, структуры помню, но что касается конкретной реализации в каждом конкретном случае — всегда гуглю или стековерфло или статьи.
Вот так устроена моя память — конкретику не хранит уже давно, словно мозг решил, что теперь конкретику будет хранить Интернет.
И ничего — любой алгоритм сначала вижу в будущем, потом ищу готовые решения в интернете (а все уже давно решено) потом просто компилирую копи-пасты (и состыковываю).
Поэтому мой код такой разношерстный.
Вчера проходил тесты на node.js и js — долго смеялся — ни хрена не помню конкретно. Специально не позволил себе пользоваться гуглом. Результат 25% правильных. Все верно — в среднем было четыре варианта ответа на каждый вопрос.

Память не_мешает в распутывании головоломок и неясных багов. Во втором случае она даже очень даже помогает. Ты помнишь детали реализации вот той штуковины которая падает, и по ошибке сразу можешь сказать приблизительно откуда и почему она вылазит. Без памяти на это нужно тратить достаточно много времени, если ты не заморочился с правильным логгингом. С головоломками тоже не всё так просто, часто под головоломками понимают разгадывание бизнес-требований. Обычно эти требования неформализованы, непонятны, а главное-их очень много. По сему, в голове нужно держать очень много факторов, и их учитывать. Если часть выпадает — можно принять ошибочные решения. Я знаю часть задач где просто необходимо помнить нефиговое количество фактов чтобы вложится во время (напр. codeforces, олимпиады по математике).

Все верно, но дело в том, что существует несколько видов памяти.
А вообще, как бы там ни было, если у тебя память хорошая ты успешен.
Плохая — ты неудачник и по жизни тебе тяжело приходится.
Потому что жизнь так устроили, чтобы выживали в ней только с хорошей памятью.
А не устроили еще, так устроят.
Механизм проверки памяти элементарен.
Того, кто не помнит просто за борт выбросят.
Если ты помнишь свои неприятности — то повторно на некие грабли не наступишь.
А вот если не помнишь... И вот тут возможность для продавцов — грабли очень четко расходятся среди беспамятных. Они наступают на них оптимистично и два и три и пять раз повторно.
Остается только один вопрос: как заставить покупателя забыть, что товар лажа?
Выпустить новую, улучшенную версию.

Память тренируется и перепрофилируется, не без усилий, конечно.

Я думаю, дело скорее не в самой памяти, а в скорости доступа к хранимым данным. Чем больше возраст человека, тем эта скорость медленнее. Потому что объем накопленных знаний больше. В IT знания очень быстро устаревают, получается в фаворе вьюноши, у которых новые знания очень близко к поверхности их выдачи. У пожилых похоже не так с памятью. Но зато у пожилых все уже достаточно структурировано и шаблонизировано (конкретики там мало, все абстрактным мне видится — самый простой способ упаковки) и переход к ассоциативной памяти и ассоциативному мышлению тоже весьма вероятен — так быстрее поиск проводить по обширной базе собственных знаний
Тренировка памяти для пожилых нереальна — даже если многократным повторением одного и того же новые знания будут воткнуты в мозг скорость доступа к ним еще больше упадет (вот что парадоксально — стека здесь и близко нет) Итог: пожилым нужны девайсы, которые будут хранить знания для них каким-нибудь искусственным электронным образом и очень быстро выдавать нагора. А пока нет этого — пожилым кранты.

Можно сделать девайс лучше — на втором мониторе выдавать подходящую по контексту справочную информацию. Причем — эту софтину сделать CRUD с возможностью добавления в нее все новых и новых успешных решений пользователя. В этом случае поиск будет куда более эффективным и предметным и быстрым, ведь софтина будет локальная и персональная, защищенная и будет постоянно накапливать проф. информацию. А вот если не найдено ничего — тогда будет включать интернет. Тут основная проблема реализация сканера окружения (контекста) — то есть содержания первого монитора.

Я говорю о динамическом поиске по локальной базе данных и немедленном отображении результата.
Уже существуют микро-реализации например список выбора:
Ты пишешь первые три буквы и поиск по сайту аджаксит тебе варианты.
Тоже самое я предлагаю провернуть в масштабе двух мониторов, где содержимое первого монитора будет немедленно определять содержимое второго монитора (монитора-подсказки)
Тут есть находка одна — определяемость результатов поиска пользователем. Не разработчиком. И не другими, и не каким-то сообществом. Если для конкретного пользователя что-то важнее, поиск ему это всегда на первое место будет ставить. Такой алгоритм предлагаю.

Когда-то давно читал. А потом сделал собственный тренажер мышления. И не один.

А ты поизобретай в MIX собственные лабиринты и их решения за ограниченное количество ходов и узнаешь.

Это значит что их нет и с вероятность 99% вы сделаете не то, что хотел заказчик.

Привычка брать и бездумно делать плохая.

Вообще-то в начале проекта с заказчиком формализуются требования так, что бы обе стороны понимали их одинаково

 А кто этим занимается? Часто те же кто и писасть будут. На самом деле разработка начинается уже отсюда, и иногда надо проводить исследование потому что у заказчика просто нет инфы о том что к чему. Этим занимаются тоже разрабы, или BA но на больших галерах и очень больших проектах, но так или иначе обдумывать что надо сделать и что из этого будет надо на всех уровнях, я именно об этом.

С помощью своей игры

есть ссылка? друг спрашивает :)

Есть финансирование?
Тогда смогу предоставить ссылку не только на прототип (без подсчета статистики удачных решений и просчетов).
giprozhorka.space/pazzl
Получится как подсчет IQ но гораздо более применимый к реальности

Коллега, а классические инструменты уже не работают? N-back, например?

я тоже против. считаю что результат такого теста говорит лишь о том, что человек хорошо проходит тесты. ни в одной компании где я проходил какие-то тесты, меня не наняли . из последнего — в 4 места куда я собеседовался , кодинг тест я прошел. но меня все равно не наняли (по другим причинам) , либо я отказался сам, потому что оффер не показался привлекательным.

1. Сократить денежные и временные затраты на рекрутинг.
2. Убрать субъективность.
В мире первая задача сейчас, пожалуй, считается более важной.

Соглашусь, что это совершенно ужасно при подборе персонала начиная с уровня младшего менеджмента и выше.
То есть на словах кадры решают все, а на практике в индустриях, отличных от ИТ, работают только нетворкинг и рандом.

нетворкинг не решает проблему подобра наиболее эффективных кандидатов. он решает проблему поиска кандидатов, не находящихся в активном поиске, а с другой стороны — проблему захвата внимания рекрутера, работающего по принципу «неудачники не нужны»

Категорически отказываются проходить любое тестирование и выполнять какие-либо тестовые задания.

Ну это лишь показывает, что ваш компания не является настолько интересной, чтобы потенциальные кандидаты готовы были выходить из зоны комфорта.

У нас на постсоветском пространстве инженеры не умеют проходить тест. Они начинают нервничать, жать не те кнопки.

С начала 2000-x везде уже были тесты — в школах, вузах. Так что достаточно широкий слой современного IT проходил тесты множество раз и понимают что к чему.
Любое собеседование в любой ее форме — это стресс. Но если ты компетентен то все сделаешь даже под стрессом.

Согласившись, в 70% случаев не справляются с тестовым заданием, даже будучи достаточно компетентными специалистами.

В большинстве случаев они некомпетентны. А вы хотите их считать компетентными, что бы закрыть свои KPI. И готовы ради этого максимально понизить планки требований.

Думаю, что Вам мы бы просто ничего не предлагали.

Согласен с Вами насчёт тестовых (в отличие от большинства здесь), но не согласен — насчёт тестов.

Любое собеседование в любой ее форме — это стресс.

Стресс стрессу рознь. Мини-задачки с коротким лимитом времени предполагают совершенно иной (неоправданно завышенный) уровень стресса, нежели всё остальное. Поэтому лично я не вижу никакого смысла в том, чтобы проводить тестирование, которое в 99% случаев не отображает реальную ситуацию и является бессмысленной нервотрёпкой кандидата. Программист решает задачи в фокусе, а какой в таких ситуациях фокус может быть?..

Ну это лишь показывает, что ваш компания не является настолько интересной, чтобы потенциальные кандидаты готовы были выходить из зоны комфорта.

Так задача — вывести кандидата из зоны комфорта а-ля «работать у нас — большая честь» ©, или всё-таки узнать, может ли он выполнять работу?

Ну это лишь показывает, что ваш компания не является настолько интересной, чтобы потенциальные кандидаты готовы были выходить из зоны комфорта.

А зачем тратить свое время на компанию, которая не готова «выходить из зоны комфорта»?

ДЗ очень часто являются косвенным признаком компаний с проблемным менеджментом: вместо постоения отношений, которые будут выгодны всем стором, менеджмент пытается прогнуть работника.

Ірино, рекрутинг для вас — це процес вибору найкомпетентнішого кандидата. А якщо подивитися на це інакше? Ми обираємо кандидата, якому в результаті відбору потрібно буде скласти тест об’ємом 6-9 місяців часу. В цьому тесті не буде варіативності — конкретна мова, конкретна логіка, структура інформації і спосіб її обробки. І він має бути мотивованим пройти цей тест до кінця. Якщо кандидат виявиться ще й достатньо компетентним для вирішення задач понад цього тесту, або творчих підходів — це необов’язковий бонус. І перехід до наступного тесту.
Дивно тільки коли тести заміняють компаніям співбесіди. Тоді керівник настільки об’єктивний (ми ж прибрали суб’єктивність) до нових працівників, що має можливість не бачити в них більше нічого крім проходжувачів тестів.

Хотя я считаю неправильным и негуманным отдавать компьютеру право принимать решение нанимать конкретного человека или нет, не используя больше никаких других методов оценки.

Это если ХР адекватный и не предвзятый. А никто гарантии не даёт

Мене у тестах бентежить те, що приблизно 30% успіху — це вміння складати саме цей тест. І півбіди, якби це було універсальною навичкою, а то ж до кожного потрібно готуватися окремо. Тобто я витрачаю значний проміжок часу не на предметну область, а на ознайомлення з форматом і практику виконання завдань за відведений час. І все це для одноразового вжитку. Якщо цього не робити, що ж, скласти його все ще можливо, але можна недорахуватися кількох залікових пунктів. І добре, якщо вони не стануть критичними.

Так вот 70% людей не справлялось с тестами Codility не из-за недостатка своей компетенции, а именно из-за того, что это тест.

Вообще-то нет, они не справились в основном из-за «недостатка своей компетенции». Даже те кто бросил на полпути сделали это из-за «недостатка своей компетенции».
Тут вся хитрость в том что включено в понятие «компетенции». Кодилити проверяет знание класических задачек компутер сайнса. Человек который не может решать задания на кодилити некомпетентен в решении класических задачек.

Теперь вопрос:
Как часто эти задачки нужны в работе? В соотношении с ОО дизайном, ДДД, умением/желанием тестировать свой код, умением работать с очередями и тд.

Любой подход хорош если уметь им пользоваться, уметь извлекать из него пользу. Если контора может по задачке с кодилити понять подходит человек или нет, то пусть дают, если вы не смогли ее сделать — вы не подходите. Если могут ринять решение на основании «задачки про люки» — вперед.
По моему опыту, 30-90 минут обсуждения резюме кандидата и/или дизайн задачи вполне достаточно чтобы понять подходит человек или нет.

А я вот не всегда могу справиться со стандартными тестами на собеседовании, хотя в свое время 10 лет проработал программистом, писал программы и фреймворки на Delphi/C++Builder/C#/Java/VB, хорошо знаю ООП. Вот буквально год назад не смог написать на Python за 45 минут перевод числа в его текстовый эквивалент. Хотя в то же время, по работе, смог написать прототип data ingestion framework на Unix Shell (с масштабированием и параметризацией), а потом переписать его на Python (AWS Lambda/Step Functions) для продакшн версии.
Самое интересное, что перед coding interview мне сказали, что им главное посмотреть мой ход мысли, как я подхожу к решению проблемы. Что кодинг сам по себе — это не главное. А в итоге я получил фидбек, что им понравился ход моих мыслей, что они считают меня strong problem solver, но не возьмут меня, потому что у меня недостаточно опыта в Python :) Вот и пойми их после этого.

что им понравился ход моих мыслей, что они считают меня strong problem solver, но не возьмут меня, потому что у меня недостаточно опыта в Python

Видимо многие считают что синьор — это как джун, только быстрее кодит

Стосовно задачок під час технічного інтерв’ю, я вважаю, що треба правильно інтерпретувати результат виконання задачки. Якщо хочемо найняти досвідченого спеціаліста. Кандидат розказав чи написав код і видно, що логіка правильна — тест пройдено. Навіть якщо кандидат помиляється у синтаксисі мови програмування чи знанні стандартного API. Бо в реальній роботі завдяки IDE, компілятору і Google ці помилки усунуться або не допустяться. Кандидат, який використовує декілька мов програмування, майже гарантовано зробить помилки в синтаксисі, якщо буде набирати код у Google Docs чи Skype. Якщо логіка у виконаному тесті в загальному правильна, але щось важливе упущено, можна про це натякнути або вказати кандидату. Якщо він сам виправить, тест пройдено, й упущення можна пояснити хвилюванням під час співбесіди.

Самое интересное, что перед coding interview мне сказали, что им главное посмотреть мой ход мысли, как я подхожу к решению проблемы. Что кодинг сам по себе — это не главное. А в итоге я получил фидбек, что им понравился ход моих мыслей, что они считают меня strong problem solver, но не возьмут меня, потому что у меня недостаточно опыта в Python :)

«Ім’я, сестра, ім’я!» :-)

«Ім’я, сестра, ім’я!» :-)

Facebook

Да точно! Длинна выложенного на стол перед интервьюером «инструмента» решает. А все, кто это не оценил и несет ересь с тестами должны вымереть!

Вообще, по-приколу, эти задания я люблю. Подковырки всякие. Даёт ли это что-то хз.

-

А что есть рекрутеры, которые действиткльно обладают навыками для оценки soft skills? Если да, то это что-то новенькое.
Обычно там не оценка, а описание каких-то ощущений рекрутера. Обратное чрезвычайно редко.
А насчёт Codility и ему подобных. Ни рекрутер, ни менеджер во многих случаях понятия не имеют что действительно надо будет делать на проекте. Могут даже лидов не спросить. Описание вакансии пишут как-нибудь . В итоге найти надо универсального единорога.
Вот и прилетают всякие тесты.
Не то, чтобы от них нет пользы. Просто они как правило не релевантны с реальной вакансией.
Бесит именно то что они не релевантны.

Именно. Это как при приеме на работу астронома тестировать его на школьных задачках про бассейн и трубы.

я не посылаю (не в том положении чтобы офферами разбрасываться), но в итоге так получается что в конторах «без тестов», оказываются более интересные предложения по деньгам либо другим критериям. я к этому отношусь так — если у тебя в данный момент нет других вариантов, нужно соглашаться на тестовое, если есть — можно лесом посылать как ты сказал

Обычное дело в кровавом энтерпрайзе — три дня исследуешь и потом правишь одну строчку

К сожалению вынужден несогласиться. Испытательный срок не только обходится дороже (ведь сотрудника надо ввести в команду, полностью дать информацию по проекту и заданию) в плане денег, но и энергетических\моральных затрат. К тому же работодатель точно так же тратит своё время и энергию как на постановку так и на проверку тестового задания.

А вот как раз со стажерами проще. Есть смысл проверить фундаментальные софт/хард скиллы, после чего посадить учиться и участвовать в проекте с нарастающими сложностями заданий.

У меня вопрос к вам как CEO. Вы нанимаете ФОП как юрлицо — у вас договор. Почему тогда и какие именно у вас растут расходы/энергетические затраты если вы прописываете в договоре все риски связанные с невыполнением/выполнением обязанностей сторон? Вы ведь договор составляете с нанимаемым персоналом?

Временные/энерг расходы на передачу информации, налаживании командной работы, ознакомление и контроль над процессами. Это всё довольно существенные затраты.

Так а договор — что в нем прописываете? Энергозатраты никого не волнуют — у нас тут у всех успешный бизнес.

Простите, но с чего я должен вам рассказывать что у нас прописано в каких-либо договорах?
Я увидел в комментарии выше что вы топите за чётко прописанные обязательства, но мы то с вами знаем, что это так не работает, только с внешними контракторами.

К нам прислушались, ему дали ему практическое задание, он его успешно выполнил.

расходимся гайс.

Можно сократить статью до твита «На собеседованиях не очень адекватно подвергать тестированию программистов»?

Дело в том, что в одной украинской компании тестировщиков ПО такому тестированию подвергают, и это адекватно и результативно, бо там 80% вопросов были нарочно сделаны открытыми. Это как будто опровергает тезисы этого текста, но мало ли, может, у меня опыт в иной плоскости, бо мне тестировать программистов или техподдержку не доводилось.

Хорошая статья. Полностью согласен с автором этой статьи.
Сам не раз проходил собеседование по тестах... Это ужасно и не приятно. После определенного количества тестов начал отказываться проходить тесты и задач на листочек. Такоеощущение, что тесты у нас в стране это инструмент для пыток, а не для отбора кандидатов. Я всегда только за живое общение был и буду.

Очень интересное мнение. Всегда считал, что собрать команду — это один из самых сложных этапов и работа настоящего HR довольно таки ценный продукт. А наличие блестящих знаний у новичка, не всегда поможет в реализации проекта, а может и развалить его вовсе. Тесты с которыми я сталкивался, часто похожи на набор балов в бенчмарке и тд. что в реальной жизни не всегда нужно и так зачастую.

Оценивать и тем более требовать полного решения задач на Codility или тому подобных сервисах или во время собеседования никто не просит, главная суть в том, как человек подходит к решению задачи, что он думает что говорит и тд. не обязательно решать задачу полностью, это лично из моего опыта. Такие сервисы и подход, как правило, скорее помогают в выборе нанять того или другого кандидата, чем принять окончательное решение

Технические тесты бывают проверяют энциклопедичесике знания, а бывают проверяют умение думать и решать задачу...

Очень классная и правильная статья!
Спасибо!

Підписатись на коментарі