Есть ли какие-либо исследования так называемых интервью на доске [закрыто]

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

Если вы поищите в Интернете «интервью у доски», кажется, что это понятие воспринимается как нечто негативное. Основная причина, по-видимому, в том, что люди думают, что результат интервью у доски не похож на рабочую среду. Таким образом, невозможно показать способность кандидата выполнять работу. И это считается несправедливым обеими сторонами процесса найма: 1 2 3 .

Но все эти статьи основаны на опыте одного или нескольких человек. Итак , есть ли научные исследования эффективности интервью у доски? Я не ожидаю, что научные исследования ответят на вопрос «Являются ли интервью у доски плохими?». Но я ожидал чего-то вроде

Мы думаем, что собеседование на доске хорошо подходит для того, чтобы понять X о кандидате. Мы измеряем «хорошесть X», используя метрику Y. И мы измеряем эффективность интервью с помощью Z. Вот зависимость Y(Z) , из которой мы заключаем, предполагая, что Y является хорошей метрикой X , что интервью на доске достаточно хороши/плохи для понимания X .

Это сложная проблема выбора X и Y . Но я подозреваю, что умные ученые все же могут придумать какую-то модель.

Например. Возможно , X может быть эффективностью человека , которую действительно трудно измерить, но крупные компании все еще пытаются сделать это с помощью обзоров производительности. Допустим, Y – это среднее значение первых трех оценок по отзывам . А Z будет средним значением оценок рецензентов . Есть ли корреляция между Y и Z .

Может быть, даже что-то более простое. Давайте ответим на вопрос «Насколько хорошо наши отзывы измеряют вовлеченность человека в нашу компанию ?». Затем попробуйте измерить это с помощью Y - *количество людей, покинувших компанию в течение первых 3/6/9/12 месяцев. И построить гистограмму в зависимости от оценки Z - обзора .

Что вы планируете делать с этими данными исследования?
Ничего особенно. Просто хотелось бы посмотреть, подкреплен ли негативный опыт разработчиков научно.
Честно говоря, у меня, как у разработчика, сложилось хорошее впечатление от таких вопросов. Да, они немного неестественны и, может быть, немного более «пугающие», но они действительно могут многое рассказать ВАМ о вашем возможном работодателе.
Один момент, я сомневаюсь, что на этом (отличном) форуме у кого-нибудь будут какие-либо факты о текущих исследованиях в этой области. (Возможно, вы могли бы спросить об академических кругах или, возможно, о разработке программного обеспечения?) Этот форум действительно больше посвящен, скажем, «человеческому взаимодействию на собеседовании и в условиях рабочего места».
Я просто хочу добавить, как сильно я презираю собеседования на белой доске. Я сделал один и почувствовал себя настолько некомфортно, что мне пришлось стоять перед людьми и пытаться вытащить код из воздуха, в итоге я сделал очень глупые ошибки. Работу, конечно, не получил.
@Fattie: Возможно, «исследование» по этой теме, как правило, представляет собой статистический набор мнений. Это не может быть доказано эмпирически, не доказано, что интервью на доске было неправильным; но он просто упускает основную метрику, по которой вы измеряете способности разработчика. Запрашивать ответы здесь, возможно , означает проводить исследования, поскольку ответы в основном будут даваться либо разработчиками программного обеспечения, либо людьми, работающими в тесно связанной с ним области.
@DoctorMoisha I just would like to see whether negative experience of developers backed-up scientifically.Я изо всех сил пытаюсь понять, как это может быть научно доказано. Научное доказательство чего-либо по своей сути означает, что оно поддается объективному измерению. «отрицательный опыт разработчиков» по ​​своей сути субъективен по определению слова «опыт» в данном контексте. В лучшем случае вы можете опросить мнения. И даже если все опрошенные сходятся во мнении, вы все равно ничего не доказали .
Maybe X could be person's effectiveness, which is really hard to measure, but big companies still try to do it with performance reviews.Вы не можете сравнивать интервью на доске с обзорами производительности. Интервью на белой доске оценивают навыки вне естественной рабочей среды по шкале времени 10-20. Обзоры производительности оценивают навыки в естественной рабочей среде, обычно в годовой шкале. Разница между этими двумя понятиями является ключевой причиной, по которой собеседование на доске считается бесполезным для оценки навыков разработчика.
Let's say Y is the average of first three review grades. And Z will be average of reviewers grades. Is there any correlation between Y and Z.Разве вы только что не определили корреляцию как Z как среднее значение Y?
Maybe even something simpler. Let's answer question "How well do our reviews measure person's involvement in our company?"Как вы измеряете вовлеченность? Это, как известно, трудно объективно измерить. Если я помогаю своему коллеге что-то понять, засчитывается ли мне работа, которую он проделал на основе его улучшенного понимания? Какой коэффициент кредита я получу? Как это отслеживается? Засчитывается ли ошибка в первоначальном анализе, вызвавшая серьезную переработку, в мой вклад? Вы продолжаете пытаться использовать несовершенные и расплывчатые метрики, что сводит на нет цель получения точного результата.
Вы продолжаете перефразировать свой вопрос, повторяя одну и ту же проблему снова и снова. Вы упускаете из виду тонкости (как объективно измерить что-то, как определить успех/неудачу и т. д.), но при этом ожидаете получить ответ, которого уже ожидаете. Ваше ожидание не так четко определено, как вы думаете, что делает невозможным доказательство точных научных данных о изначально субъективном и неубедительно измеримом наборе данных.
Есть много вещей, которые трудно измерить объективно. Это не значит, что люди не должны пытаться их как-то измерить. Я спрашиваю пробовал ли кто.
Интервью на доске — это слишком плохо определенная концепция, чтобы проводить какие-либо содержательные исследования. Подходит ли любое собеседование с использованием доски? Только те, которые предполагают написание компилируемого кода или те, которые включают концептуальное описание решения проблемы? Если это концептуальное описание, то включает ли набор данных другие периферийно связанные поля? Было бы кошмаром определить эту проблему достаточно хорошо, чтобы результаты были значимыми.
@Myles Многие компании имеют стандарты проведения собеседований. Так что внутри одной компании было бы не так сложно.
@DoctorMoisha: Many companies have standards on interview processes.Наличие определенного стандарта никоим образом не делает результат значимо измеримым. Тот факт, что у компаний есть свои собственные стандарты, убедительно свидетельствует о том, что не существует объективной меры того, что является объективно лучшим. So, it wouldn't be so hard inside one company.Вы все еще упускаете из виду тот факт, что невозможно правильно приписать найм кого-то (или нет) конкретным причинам, таким как тест на доске. Интервью по своей сути являются многогранными и субъективными оценками.

Ответы (1)

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

Как вы оцениваете эффективность интервью?

  • Работодатель доволен сотрудником, который принял предложение?
  • Вероятность того, что сотрудник примет предложение после проведения собеседования на доске?
  • Процент абитуриентов, прошедших упражнение на доске?

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

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

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

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

Подумайте об этом так:

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

  • Тест пройдут два типа людей:
    • Те, кто получил степень магистра (квалифицированные)
    • Тем, кому приходилось часто переделывать курсы и в итоге удалось получить степень бакалавра, чуть ли не перебором и достаточными средствами на обучение (неквалифицированные)
  • Два типа людей не пройдут тест:
    • Те, кто бросил учебу на полпути (неквалифицированные)
    • Те, кто были настолько умны, что завершили свою учебную программу в два раза быстрее (квалифицированные).

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

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

Подводя итог цитате (которую часто ошибочно приписывают Эйнштейну):

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

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

  • Если они ожидают увидеть код с идеальным синтаксисом; это просто нереальное ожидание.
  • Если они ожидают увидеть базовое визуальное представление, например, чем связанный список отличается от массива; это то, что можно осмысленно объяснить с помощью доски.

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

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

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

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

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

Во-вторых, он оставляет дверь открытой для логической ошибки инверсии.

Допустим, интервьюер просит вас наизусть перечислить все методы Entity Framework, упорядоченные по длине имени метода (я знаю, что это глупый пример, но я хочу использовать пример, в котором мы не отвлекаемся на споры о том, что лучше всего использовать). ответ есть).

Если заявитель может это сделать, то это (косвенное) доказательство того, что он должен иметь большой опыт работы с Entity Framework. Без опыта работы с Entity Framework он бы не смог этого сделать.

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

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

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

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

Я сказал «Я согласен» в этой части. Первый пункт моего комментария заключался в том, что с помощью вопроса интервью на доске, такого как «что такое связанная цепочка», вы можете проверить в лучшем случае один навык, который вам действительно нужен от парня (или 0 в худшем случае), но не другой, такой как работа с клиентом, где менеджер по найму хочет, чтобы он делал такие вещи. Это означает, что для каждого навыка, который вы хотите проверить, вы должны подготовить адекватный вопрос, что не так просто. Я действительно чувствую, что это сказано во всем посте, конечно, но я думаю, что это может заслуживать отдельного смелого предложения или чего-то еще :)
Извините, мне не нравится ваш ответ, потому что он не отвечает на мой вопрос. Если я вас правильно понял - вы говорите, что если что-то трудно измерить - то вообще не стоит это измерять. Но я не думаю, что это правда. Да, измерение вклада сотрудников сложно и ошибочно. Тем не менее, многие компании проводят обзоры эффективности, оценивая вклад сотрудников. Это не может ответить на вопрос, хорошо это или плохо, но дает представление о влиянии интервью на доске.
@DoctorMoisha: If I understood you correctly - you say, that if something is difficult to measure - it is not worth to measure it at all.Я не об этом. Я хочу сказать, что невозможно приписать успех интервью какой-то одной причине. Вы пытаетесь использовать приблизительные метрики, которые недостаточно точны, чтобы дать вам осмысленный ответ (что похоже на недостаток интервью у доски: чрезмерно обобщенные метрики, которые не затрагивают основной фокус). Это также полностью отличается от обзоров производительности или выставления оценок.
@DoctorMoisha: обзоры производительности (и вклады) оценивают сотрудника в его естественной рабочей среде . Интервью на доске оценивают сотрудника за пределами его естественной рабочей среды . В этом ключевое отличие и основной аргумент в пользу того, почему собеседования на доске не так важны, как думают интервьюеры. Интервью на доске также проводятся в слишком короткие сроки (10-20 минут), чтобы осмысленно оценить навыки сотрудника, тогда как обзоры эффективности занимают длительный период времени (от 3 месяцев до 1 года).
@DoctorMoisha Sorry, I don't like your answer, because it doesn't answer my question.Это ответ на ваш вопрос, ответ просто не такой, как вы ожидаете. Если вы спрашиваете, существует ли что-то, а также исключаете возможность того, что этого не существует, то ваш вопрос спорен. Я не могу доказать отрицательное (отсутствие существования исследований). Если вы хотите утверждать, что исследования существуют, то на вас лежит ответственность доказать свою точку зрения.
@Flater You're trying to use approximate metrics that are not precise enough to give you, да, чтобы сделать вывод, вам нужны исследования, показатели и их точность. Это в основном то, о чем я прошу. В любом случае, я отредактировал свой ответ, что, вероятно, делает его более понятным. Спасибо за ваши комментарии.
К сожалению, этот ответ (хотя и хорошее эссе) вообще не относится к вопросу. Вопрос: «Перечислите исследовательские работы в этой области».
@Fattie Как я уже упоминал ранее: возможно, «исследование» по этой теме, как правило, представляет собой статистический набор мнений. Это не может быть доказано эмпирически, не доказано, что интервью на доске было неправильным; но он просто упускает основную метрику, по которой вы измеряете способности разработчика. Запрашивать ответы здесь, возможно, означает проводить исследования, поскольку ответы в основном будут даваться либо разработчиками программного обеспечения, либо людьми, работающими в тесно связанной с ним области. Ответ о том, что вопрос не имеет осмысленного ответа, является допустимым ответом (даже если он неверен ).
Это не имеет значения, но я не понимаю вашего комментария. Было бы совершенно тривиально измерить эффективность «интервью у доски» в крупной компании. (Бьюсь об заклад, скажем, Google действительно делает это .) Как и в случае сокращения любой статистической информации, вы бы очень просто наняли половину людей, использующих WI, и половину людей, не использующих WI. Затем через 2 года или что-то еще вы увидите, как каждая группа жил.
Любая крупная управленческая или кадровая практика обычно измеряется таким образом, просто с помощью обычного A/B-тестирования. Было бы совершенно неудивительно, если бы по этому поводу были какие-то научные статьи. В любом случае ура, хорошего дня.
@Fattie Без причинно-следственной связи данные бессмысленны. Мы могли бы провести тот же тест, основываясь на четном или нечетном количестве букв в вашем имени или цвете волос. Даже если разница измеряется производительностью труда, это не означает, что существует реальная причинно-следственная связь или даже корреляция. Существует веб-сайт под названием Spurious Correlations (iirc), который исследует именно такое поведение людей, делая выводы из кажущихся шаблонов, которые не имеют никакого значения и являются случайными. Пройдя достаточное количество тестов, в конце концов вы найдете тот, который проходит.
«Без причинно-следственной связи данные бессмысленны», вот для чего нужно A/B-тестирование, вы уменьшаете количество переменных. Весь статистический анализ «философски бессмыслен». Если в течение, скажем, 2 сд вы обнаружите , что режим X приводит к лучшим результатам, у вас есть ответ. Другой реальности нет.
@Fattie Это просто абсурд. Тот факт, что вы получаете бросок костей, не означает, что результат предопределен или каким-либо образом постоянно воспроизводим. Вы находите числа, которые соответствуют вашему заранее определенному мнению.
Есть ли какие-либо исследования так называемых интервью на доске [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v