Всем привет!

Предыдущие серии: серия-1

Автор: sanchez911
Дата: 17.09.15

, серия-2

Автор: sanchez911
Дата: 15.10.15

.

Продолжая писать о скромном IT-бизнесе, хочу коснуться интересной и холиварной темы — подбор людей в компанию. Многие руководители недооценивают важность процесса, а ведь реально, от набранных людей зависит 90% бизнеса. Например, если у фирмы низкая эффективность из-за плохого оборудования, то виновато не оборудование, а люди, которые его закупили, и начальники, которые наняли этих людей себе в подчинение.

Итак. Сначала — о поиске разработчиков.

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

Критики данной позиции делятся на 2 части:
— те, кто против выполнения каких-либо тестовых заданий вообще;
— те, кто против выполнения ТЗ на дому (а на собеседовании — ок).

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

Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!

У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации. На них можно отсеить 80-90% человек. И если кто-то из них начнет доказывать, что это я сам осел, что не оценил такую хорошую программу, то на это можно смело забить: у тебя есть 10%, которые выполнили задание хорошо, а значит задание адекватно, и твои тесты — тоже.

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

Еще один пример удобства сравнения людей по ТЗ. Когда я разработчику говорю в отказе, потому что в таком-то случае программа повела себя неправильно, мне порой отвечают — да, но это же тестовое задание. Но у меня есть люди, которые и в тестовом задании эту ситуацию обрабатывают правильно. Если один поленился, а другой нет, разве это не помогает сделать выбор? Да и откуда мне знать, человек действительно знал, но не сделал из-за объема, или не догадался протестировать одну из возможных ситуаций? А это ведь важно в работе.

Другими словами: 100 человек получили задание, 99 сделало плохо и обосрало тебя и твой подход, а 1 просто взял и молча сделал хорошо. Да и плевать тогда на мнение этих 99 — оставшийся 1 получает работу, делает ее хорошо, я и он получаем деньги от заказчика и положительный отзыв. У нас в стране так часто: один работает, остальные трендят. Меня в общем-то несильно волнует мнение остальных 99, которые не умеют работать хорошо.

Предвижу, что мне скажут: "да ты просто плохой программист, что не умеешь видеть человека по коду". Возможно и так, и я искренне завидую тем, кто умеет действительно интуитивно по коду понять, чего стоит человек. Но, сдается мне, что таких людей — процентов 10 от силы, а остальные только разглагольствовать громко умеют

Но все же мне очень интересно обсудить — а на что вы бы смотрели в коде?

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

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

Кроме того, при очном собеседовании часто можно попасть в ловушку "мне кажется, что человек умный, потому что он согласен со мной". Может получиться, что вам комфортно с человеком, но для работы в общем-то это не самое важное... Скажем, между угрюмым толковым разработчиком и общительным среднячком я выберу первого.

Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?

С разработчиками разобрались, идем дальше. Ранее я рассказывал, что ввязался в один совместный проект по разработке и продаже ПО для медицинской сферы (организовали с заказчиком ранее разработанной программы совместное предприятие).

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

В общем, разместили вакансии на хедхантере. На IT-директора пришло 300 откликов, на остальные должности — около 50. Я решил для начала дать людям тоже простенькую "домашку".

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

Руководитель обучения получил 1 вопрос — просьбу объяснить врачу "что такое компилятор". Опять же, доступную аналогию проводили немногие, на четверку считался ответ "это переводчик с языка человека на язык компьютера". На четверку, потому что в общем-то суть правильна, но ответ похож на отмазку. Что значит "язык компьютера"? Мне больше нравится, когда человек проводит понятную для слушателя аналогию. Например, кто-то объяснял на примере расшифровки медицинского рецепта пациенту.

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

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

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

Ну, про катастрофы вообще никто правильно не ответил. Некоторые вообще отвечали что-то в духе "безопасность надо мерить количеством происшествий, где меньше там и лучше". Впрочем, заставлял задуматься мой вопрос "за месяц 100 самолетов перевезло 10000 человек, 2 разбилось; за тот же месяц 2 автомобиля перевезло 4 человека, 1 разбился — значит автомобиль безопасней?". Ну и все в таком духе. Кстати, была у меня в кандидатах на обучателя одна девушка, которая пишет диссертацию с активным использованием аппарата матстатистики, и она тоже бредово ответила.

А вот с яндекс-картами интересней. Технари отвечали хуже, чем гуманитарии — те чаще догадывались до правильного ответа.

Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality У меня была еще задачка из недавней реальной практики. У нас толстый клиент, который коннектится к WCF. Несколько клиник в Москве. Сервер в Москве. Клиники коннектятся к серверу через инет. В одной из клиник жалуются на медленную работу программы, в остальных все нормально. Все условия идентичны: одно железо, одни компы, один набор прикладного софта. Скорость инета в "медленной" клинике — даже больше, чем в других — скачивали большой файл с сервера и замеряли время. В чем может быть причина? Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги (а скорость уже установленного соединения — нормальная). Там какой-то странный провайдер, у которого линк идет через Канаду. Отсюда и все проблемы. На этот вопрос большинство кандидатов тоже не смогло ответить. И ведь это люди из шорт-листа, на приличную зарплату!

Когда я осмелился дать им обратную связь — мол, господа, ну нельзя же так, — стал получать ответы "а я же руководитель, я буду руководить, а разбираться в этом должны мои сисадмины!". На что я сразу задавал следующий тестовый вопрос: вам нужно набрать себе в штат 2 сисадмина. Разместили вакансию, пришло 500 откликов. Как вы будете выбирать? Первое, что отвечали — по резюме. Ну ок, говорю я, выбрали 100, с идеальными резюме. Дальше? Дальше ответы варьировались (но мало какие мне понравились). Наконец, дошли до истины: как вы будете собеседовать людей себе в подчинение, если сами не разбираетесь ни в чем? Все это я спрашивал со свойственной мне прямотой и заработал некоторые обиды на себя)))) В общем, печально.

В итоге из 25 прособеседованных человек мне понравился один IT-директор, 3 руководителя обучения и 2 менеджера. Пригласил их на еще одно собеседование — со вторым учредителем (он более бизнесовый, чем технарский, поэтому взгляд со стороны очень полезен). И в общем-то по результатам я мысленно похвалил себя за правильный выбор: IT-директор понравился, руководители обучения понравились все (пришлось выбирать), и только менеджеры оба не понравились — их не взяли. А так моя методика оказалась пока что успешной Посмотрим, как эти люди будут вести себя в работе, но пока мне их деятельность нравится.

Ну все, пора заканчивать, а то целую поэму уже накатал. Как всегда, на правах рекламы — если вас не отпугивает мой подход, то приглашаю к себе разработчиков dotNet. Нам нужны и фултайм в офис (м. 1905 года), так и на удаленку. Проекты — разные, в основном интересные Пишите мне на mailbox at nevlabs dot ru с темой письма "Разработчик на удаленку (код rsdn-dev)". В письме расскажите о себе: из какого вы города, сколько вам лет, кратко-кратко о своем опыте, сколько есть свободного времени на мои проекты. Как я писал выше, я оцениваю кандидатов в первую очередь с позиции тестового задания — поэтому оно обязательно. Жду вас!

See you!

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

Здравствуйте, sanchez911, Вы писали:


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

"хоть ссы в глаза, всё божья роса"

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

Здравствуйте, sanchez911, Вы писали:

S>Ну все, пора заканчивать, а то целую поэму уже накатал. Как всегда, на правах рекламы — если вас не отпугивает мой подход, то приглашаю к себе разработчиков dotNet. Нам нужны и фултайм в офис (м. 1905 года), так и на удаленку. Проекты — разные, в основном интересные Пишите мне на mailbox at nevlabs dot ru с темой письма "Разработчик на удаленку (код rsdn-dev)". В письме расскажите о себе: из какого вы города, сколько вам лет, кратко-кратко о своем опыте, сколько есть свободного времени на мои проекты. Как я писал выше, я оцениваю кандидатов в первую очередь с позиции тестового задания — поэтому оно обязательно. Жду вас!

где-то на половине прочтённого, мне показалось что автор занимается самоудовлетворением
мне показалось неприличным, но я всё же дочитал до конца
со свойственной мне прямотой, конечно отпугивает

S>See you!

Удачи!

Здравствуйте, tofox2, Вы писали:

T>где-то на половине прочтённого, мне показалось что автор занимается самоудовлетворением
так и есть, ну и ещё в каждом абзаце — вы все дураки, а я дартаньян, и мне покласть с прибором на чужое мнение))


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

Здравствуйте, antropolog, Вы писали:

A>Здравствуйте, tofox2, Вы писали:

T>>где-то на половине прочтённого, мне показалось что автор занимается самоудовлетворением
A>так и есть, ну и ещё в каждом абзаце — вы все дураки, а я дартаньян, и мне покласть с прибором на чужое мнение))

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

Здравствуйте, Kerk, Вы писали:

K>Автор всего-лишь говорит, что его задача — найти работников, а не получить одобрение от неудачливых кандидатов. Вполне адекватная точка зрения. Пока ему удается находить подходящих людей.

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

Здравствуйте, antropolog, Вы писали:

A>Здравствуйте, Kerk, Вы писали:

K>>Автор всего-лишь говорит, что его задача — найти работников, а не получить одобрение от неудачливых кандидатов. Вполне адекватная точка зрения. Пока ему удается находить подходящих людей.

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

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

В общем, лучше отсеять двух хороших, чем нанять одного плохого.

Причем в результате в выигрыше обе стороны. И "на порядок лучшие работники" найдут себе более подходящую им вакансию и автор нашел тех, кто ему подошел. А квалификация должна быть достаточной. Истории с наймом overqualified-специалиста часто заканчиваются грустно.

A>В общем там сплошной фейспалм

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

Практика — критерий истины.

Здравствуйте, sanchez911, Вы писали:

Да миллион раз уже обсуждали.

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

Такой подход к собеседованию может быть оправдан в трёх случаях:
1. Вы работодатель с мировым именем, и к вам выстроилась очередь желающих работать именно у вас.
2. На рынке острый дефицит рабочих мест.
3. Для выполнения вашей работы нет нужды в программистах хорошего уровня, достаточно средних джуниоров.

Здравствуйте, sanchez911, Вы писали:

S>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой.

Говорят, из заведомо ложного предположения вытекает все, что угодно.
Тут именно такой случай.

Здравствуйте, Kerk, Вы писали:

K>В этой сфере правильно все то, что работает
вот это логика. браво! т.е. когда бизнес крякнет, или перестанет развиваться — тогда и думать, да? А до тех пор чтобы не делал — всё правильно.

Разумеется. Но я о задании и объеме предупреждаю честно заранее. Кто не хочет — просто не откликается.

A>они не прошли его тесты, простая мысль что это не люди отстой, а его тесты
Вы немного путаете, "мне наплевать на мнение человека Х по вопросу Y" и "человек Х — отстой" — немного разные вещи, не находите? Покажите мне, где я назвал этих людей дураками и отстоем.

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

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

A> а-ля "код нихрена не показывает" и то что автор в коде видит только его "аккуратность", это вообще пять, похоже автор дальше джуна в разработке не продвинулся
Ну, а все же, расскажите, как бы вы смотрели код? На что смотрели бы? Как оценивали бы?

K>Распространенное ошибочное мнение — это то, что кому-то якобы нужны "на порядок лучшие работники". Автор подбирает сотрудников согласно собственным субъективным фильтрам и это нормально.
Ну, фильтр конечно действительно субъективный, но 100% людей, которые со мной работают, являются разработчиками более высокого уровня, чем я. У меня нет комплексов по этому поводу, так и должно быть.

K>Практика — критерий истины.
Именно! Спасибо В каком-то бандитском фильме был хороший диалог между двумя ментами:
— Ну Петр Петрович, операция была спланирована тщательно, все продумали...
— А он ушел. Качество операции, Иван Иваныч, определяется ее результатом. Упустили! И это все значит.

S>Поэтому наличие домашнего тестового задания на дом сразу отсеивает по-настоящему хороших спецов — они найдут работу ещё до того, как за это задание сядут.
Да, я понимаю. Но до сих пор удавалось найти хороших людей таким способом.

S>>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой.
L>Говорят, из заведомо ложного предположения вытекает все, что угодно.
L>Тут именно такой случай.

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

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


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

Быстро найти можно кучу посредственных предложений с посредственными зарплатами и задачами.

S>Итак. Сначала — о поиске разработчиков.
S>Я практикую тестовое задание на дом.
S>Критики данной позиции делятся на 2 части:
S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Есть 3-я — это я...
Вот если б я к вам надумал идти, и получил ТЗ для разработки, то ПЕРВОЕ, что я сделал бы — раздербанил бы ваше ТЗ на предмет неточных и неполных данных.
Явно уточнений там потребовалось бы +100500 штук.
Второе — непременно попросил бы уточнить цель написания — какую прогу надо писать:
— самую короткую?
— самую быструю?
— самую простую и понятную?
— самую экономную по памяти?
— самую сопровождаемую (рефакторинг легко делать) ?
— самую...

И еще в копилку наблюдений при общении с программистами.
Претенденты, у которых плохо "подвешен язык" — интроверты.
Как правило, это — хорошие программисты.

LVV>И еще в копилку наблюдений при общении с программистами.
LVV>Претенденты, у которых плохо "подвешен язык" — интроверты.
Не нужно так обощать, Эллочка-людоедка ни разу не интроверт
И обратное тоже неверно: умение красиво и уверенно говорить — всего лишь навык.

LVV>>И еще в копилку наблюдений при общении с программистами.
LVV>>Претенденты, у которых плохо "подвешен язык" — интроверты.
N>Не нужно так обощать, Эллочка-людоедка ни разу не интроверт
N>И обратное тоже неверно: умение красиво и уверенно говорить — всего лишь навык.
Ну, на собеседование к топикстартеру попадают не Эллочки-людоедочки, а вполне себе конкретные ребята, справившиеся с тестовым заданием.
Речь именно о них.

И собственный овер20летний опыт — на студентах.