Выявление 5% лучших кандидатов с помощью формулирования технических проблем
В этом посте я поделюсь историей об ошибке, которую я совершил как неопытный менеджер по найму специалистов в области Data Science, и о том, как она изменила мой способ проведения технических собеседований. Я также рассмотрю пример приглашения на собеседование по науке о данных и покажу, как более сильные кандидаты подходят к проблеме иначе, чем более слабые кандидаты. Хотя я сосредоточил свое внимание на науке о данных, большинство моих идей и предложений актуальны для любой технической роли, включая разработку программного обеспечения, разработку данных и т. д.
Но сначала немного предыстории о себе.
Я работаю в области разработки программного обеспечения и науки о данных/машинного обучения уже около девяти лет. Я работал в компаниях всех размеров — самой крупной из них была Wayfair (13 тысяч сотрудников), а самой маленькой — мой нынешний работодатель, Fi (~ 100 сотрудников), где я являюсь вице-президентом по данным. Сейчас я приближаюсь к переломному моменту, когда половина моей карьеры прошла в качестве индивидуального участника (IC), а половина — в качестве менеджера/директора/вице-президента. Во второй половине я создал или унаследовал команды от двух до 15 человек. За это время я нанял около 20 человек, провел сотни собеседований и разработал бесчисленное количество каналов интервью.
За время работы в качестве менеджера по найму я нанял много успешных сотрудников, но также совершил немало ошибок. Например, на заре моей карьеры менеджера по найму, когда мне впервые поручили создать конвейер собеседований с нуля, я совершил одну из своих самых больших ошибок при найме. Мне потребовался еще год или два, чтобы полностью осознать ошибку, которую я совершил. Но как только я смог это сформулировать, я понял, что этого можно избежать, и смог предпринять шаги, чтобы это больше не повторилось.
Этот пост об этой ошибке и о том, что я делаю, чтобы не повторять ее снова.
Моя ошибка при найме
В 2019 году меня повысили от старшего инженера по машинному обучению до ведущего специалиста по данным, что было руководящей ролью. Моя команда стремилась создать новые приложения для моделирования, которые требовали моделей и интеграций, отличных от тех, которые я уже создал. А так как я недавно взял на себя роль менеджера, у меня не было пропускной способности, чтобы самому построить всю необходимую инфраструктуру. Поэтому я решил нанять старшего специалиста по данным, чтобы он помогал создавать и поддерживать новые модели и интеграции.
Процесс интервью
Я разработал конвейер интервью, который состоял из экрана менеджера по найму, домашнего проекта и нескольких панельных интервью. За исключением кросс-функционального интервью, все интервью носили технический характер и включали в себя ту или иную форму машинного обучения, инженерии данных или разработки программного обеспечения, а также проблемы проектирования. Через пару месяцев мы нашли нашего идеального кандидата.
Первые несколько недель новобранца прошли гладко. И как только они освоились с техническим стеком, товарищами по команде и рабочим процессом, я поручил им более крупный проект.
Появляются симптомы
Через пару недель работы над порученным им проектом я заметил, что их задачи занимают больше времени, чем предполагалось. Поэтому каждую неделю я проводил с ними дополнительное время, чтобы убедиться, что все идет по плану. Но, к сожалению, ситуация не улучшилась. Почти каждый раз, когда мы встречались для обсуждения прогресса и следующих шагов, казалось, что никакого прогресса нет. Вместо этого они выявляли недавно возникшие технические препятствия, которые, с их точки зрения, необходимо было устранить, чтобы двигаться вперед. Я помню, как чувствовал себя разочарованным, потому что мне было трудно понять, насколько важны все технические препятствия, которые они поднимали, поскольку они, казалось, возникли из ниоткуда.
Я помню, как мы два месяца работали над проектом, который, как мы планировали, займет две недели, но у нас все еще не было работающего решения. Хуже того, у нас даже не было четких сроков завершения.
Основная проблема
Теперь, когда я занимаюсь управлением и наймом в течение нескольких лет и видел свою долю как успехов, так и неудач с новыми сотрудниками, я могу точно сформулировать, в чем заключалась основная проблема и где я ошибся.
Основная проблема заключалась в том, что им не хватало набора навыков, который имел решающее значение для успеха в их роли. На первый взгляд может показаться, что им не хватало технических способностей, поскольку они часто сталкивались с техническими препятствиями, которые не могли быстро решить. Но это было не так. На самом деле, их технические возможности были исключительными.
Скорее, им не хватало способности понять связь между техническим приложением и потребностями бизнеса, из-за чего они не знали, когда и как идти на компромиссы. Это проявлялось в виде непреодолимых технических препятствий, каждого из которых можно было избежать, упростив постановку задачи.
Например, одна из проблем, с которыми они постоянно сталкивались, была связана с размером набора данных, с которым они работали. Но каждый раз, когда они ссылались на это как на проблему, я предлагал сократить набор данных только до трех или четырех наиболее важных функций, которые нас интересовали, а затем отфильтровать только те записи, которые, вероятно, будут релевантными. Это уменьшило бы общий набор данных до менее чем 0,5% от его исходного размера, что позволило бы избежать любых проблем, связанных с объемом, и дало бы нам 80% добавленной стоимости всего набора данных. Но каждый раз, когда я предлагал это, было видно, что они об этом не думали, несмотря на то, что я неоднократно упоминал об этом.
Постановка технической проблемы
Подводя итог, у новичков были проблемы с одновременным пониманием как бизнес-контекста, так и технического контекста, поэтому технические задачи, которые они намеревались решить, часто оказывались более сложными, чем им нужно было быть. Другими словами, у них были проблемы с формулированием технической проблемы, то есть с возможностью сформулировать бизнес-цель как с технической задачей и с пониманием того, как набор требований представляет базовую бизнес-цель.
Для тех, кто не знаком с формулированием технических проблем или типичным рабочим процессом группы обработки данных: обычно требования предоставляются либо менеджером по продукту (PM), либо менеджером/техническим руководителем. Но даже в тех случаях, когда требования предъявляются к ИС, они никогда не бывают полностью исчерпывающими. Поэтому важно, чтобы IC могли понять цель, которая привела к этим требованиям. Если они не могут сделать это сами, то за ними должен очень внимательно следить их менеджер или менеджер по проектам. Это ограничивает масштабируемость команды и обычно вызывает трения между IC и их менеджером/PM.
Когда я размышляю над этим сценарием, становится ясно, где я ошибся — я не построил интервью, в котором оценивалась техническая формулировка проблемы, и этот набор навыков был требованием для того, чтобы они преуспели в своей роли. Как только я понял это, я начал экспериментировать со способами внедрить это в процесс собеседования. К счастью, то, что я нашел наиболее эффективным, потребовало лишь незначительной корректировки.
Корректировка интервью
Вот что я делаю по-другому.
По крайней мере, для одного технического интервью я встраиваю техническое задание в реальный бизнес-сценарий, где требуется полное понимание добавленного контекста, чтобы адекватно решить проблему.
В дополнение к оценке технических способностей, это скорректированное собеседование также оценивает способность кандидата сделать вывод из требований, каково фактическое намерение проекта, а затем убедиться, что это намерение достигнуто при разработке технического решения.
Далее я проведу пример интервью, в котором не оценивается техническое формулирование проблемы, и обсужу, как выглядит сильное решение. Затем я покажу то же самое интервью, но с корректировкой формулировки технической проблемы и покажу, как она изменяет то, что считается сильным решением.
Вы можете найти исходный набор данных, который я использовал для этого интервью, здесь. Вы также можете найти подсказку для интервью, настроенную как блокнот Kaggle здесь.
Пример 1: интервью по моделированию Data Science БЕЗ оценки технических проблем
Вот приглашение на собеседование без какой-либо оценки технических проблем.
###############################################
# Interview WITHOUT technical problem framing #
# as part of the assessment. #
###############################################
# We have provided you with a dataset
# consisting of patient health information
# related to cardiac arrest (heart-attacks).
# Each record represents a patient that
# visited the Emergency Room (ER) because they
# were experiencing chest pains. Each column
# corresponds to a measurement that was taken
# at the time they arrived at the ER, including
# the type of chest pain they were
# experiencing. The dataset also contains a
# binary column that indicates whether or not
# the patient ended up having a heart-attack
# within 48 hours of their ER visit.
import pandas as pd
df = pd.read_csv(f"{filepath}/heart.csv")
display(df.head(5)
# Your task is to construct a model that
# predicts whether a candidate will have a
# heart-attack based on the provided inputs.
def predict_heart_attack(row):
"""
Accepts one row of heart-attack dataset.
Returns 0 or 1 as the prediction.
"""
# TODO
pass
Раньше я проводил это интервью вживую, когда удобно иметь небольшой и чистый набор данных для работы. Набор данных небольшой (303 строки и 13 входных данных) и относительно чистый, поэтому кандидаты с любым опытом машинного обучения могут без особого труда создать классификатор.
Оценка
Более слабых кандидатов легко определить, поскольку они обычно с трудом могут построить даже базовую модель за отведенное время, не говоря уже о хорошей модели. Более тонкая задача интервьюера состоит в том, чтобы отличить «хороших» кандидатов от «отличных». В дополнение к демонстрации способности построить работающий классификатор за короткий промежуток времени более сильные кандидаты обычно отличаются тем, что (1) используют итеративный подход — они быстро что-то зарабатывают, а затем улучшают это, и (2) принимают обдуманные решения. Например, когда я спрашиваю их, почему они выбрали конкретный показатель производительности для оценки производительности своей модели, у них есть конкретный ответ. Более слабые или менее опытные кандидаты будут давать ответы, но без какого-либо реального обоснования.
Пример 2. Интервью по моделированию Data Science с оценкой технических проблем
Вот тот же вопрос для собеседования, но со встроенным бизнес-сценарием, поэтому он включает техническую формулировку проблемы как часть того, что оценивается.
###############################################
# Interview WITH technical problem framing as #
# part of the assessment. #
###############################################
# An Emergency Room (ER) is receiving an
# overwhelming number of patients experiencing
# chest pains, which are a symptom of heart
# attacks. Patients who are showing other
# symptoms of heart attacks should be
# prioritized (fast-tracked) upon entering the
# ER waiting room in order to mitigate the
# effects of the heart-attack, or avoid it
# altogether.
#
# On average, the ER is equipped to fast-track
# 20% of patients who are experiencing chest
# pain, allowing them to skip the patient
# queue. Currently, the ER's policy is to
# fast-track any patients who are
# experiencing Type 2 chest pain (atypical
# angina). This corresponds to a value of
# `df['cp'] == 1` in the dataset. The ER staff
# thinks that their existing policy is
# suboptimal, and is requesting that you
# perform an analysis on this patient data in
# order to develop a policy that better
# prioritizes high-risk patients.
#
# We have provided you with a dataset
# consisting of patient health information
# related to heart-attacks. Each record
# represents a patient that visited the ER
# because they were experiencing chest pains.
# Each column corresponds to a measurement that
# was taken at the time they arrived at the ER,
# including the type of chest pain they were
# experiencing. The dataset also contains a
# binary column that indicates whether or not
# the patient ended up having a heart-attack
# within 48 hours of their ER visit.
import pandas as pd
df = pd.read_csv(f"{filepath}/heart.csv")
display(df.head(5)
# Your task is to use the dataset to construct
# a fast-track policy that is better than the
# ER's current policy.
def fast_track(row):
"""
Accepts one row of heart-attack dataset.
Returns 0 or 1 as the decision to
fast-track.
"""
# TODO
pass
Обратите внимание, что технические аспекты задачи остаются неизменными — используется точно такой же набор данных и та же сигнатура решения. Но теперь появилась дополнительная информация, меняющая профиль идеального решения.
Новая постановка задачи
Добавленный бизнес-контекст представляет две новые части информации, которые кандидат должен понять, прежде чем приступить к работе над своим решением. Во-первых, существует ограничение, согласно которому только 20% пациентов могут быть быстро отслежены. Это соответствует 60,6 пациентам или 61, если округлить:
.20 * len(df) # Outputs 60.6
Таким образом, максимальное количество пациентов, которых мы можем «спасти» с помощью ускоренного отслеживания, составляет 61, поскольку отделение неотложной помощи не может ускорить ускоренное рассмотрение большего числа пациентов.
Вторая новая часть информации, которую предоставляет контекст ER, заключается в том, что у ER есть базовая стратегия, которую необходимо превзойти, чтобы можно было рассмотреть новую политику. Эта базовая стратегия позволяет правильно предсказать 41 сердечный приступ:
# The ER baseline policiy is to fast-track # any patient with Type 2 chest pain, # which corresponds to # `df['cp'] == 1`. So the ER baseline # strategy is to return 1 when # df['cp'] == 1, and 0 otherwise. ( df.groupby(['cp'])[['had_heart_attack']] .agg(['mean', 'count']) )
.82 * 50 # outputs 41
Объединив добавленное ограничение (всего 61 ускорение) с целью превзойти базовый уровень (41 правильный прогноз), мы можем сформулировать новую задачу следующим образом: найти классификатор, у которого отзыв@k (при k=61) больше 41.
Слабые кандидаты
Кандидаты, которые слабы в формулировании технической проблемы, проигнорируют эти две части информации и сразу же перейдут к решению. Как правило, это приводит к одному из двух неоптимальных решений: одно с высокой точностью, но с полнотой, равной или ниже 41, или одно с высокой полнотой, но точность настолько плохая, что первые 61 быстро отслеженный пациент не дадут более 41 сердечного приступа. Как интервьюер, я даю подсказки, чтобы направить кандидата, если вижу, что он движется в неправильном направлении. Некоторые кандидаты поймут мои намеки и правильно скорректируют курс, в то время как другие все еще будут пытаться определить правильную проблему, которую нужно решить.
Сильные кандидаты
Кандидаты, хорошо разбирающиеся в технической формулировке проблемы, подходят к ней иначе. Вместо того, чтобы с самого начала переходить в режим решения, они тратят время на то, чтобы тщательно прочитать подсказку, часто несколько раз, чтобы убедиться, что они понимают контекст.
Затем они делают то, что тесно связано с успехом, и на что я обращаю пристальное внимание:
Лучшие кандидаты записывают свой подход, прежде чем приступить к нему, а затем спрашивают меня (интервьюера), звучит ли он разумно.
Когда я это наблюдаю, это музыка для моих ушей. Почему? Потому что это именно то, что я хочу, чтобы они сделали, если бы они присоединились к моей команде. Мне нужен кто-то, кто может заранее сформулировать свой план, прежде чем погрузиться в него, а также обладает осознанием, чтобы прогонять его вместе со мной, прежде чем он начнет его. Несмотря на то, что это занимает больше времени на начальном этапе, это избавляет от необходимости возвращаться назад и менять подходы в середине интервью, поэтому гарантирует, что оставшееся время будет потрачено с пользой.
Кандидаты, способные сформулировать правильную проблему, обычно также способны решить ее. Это не должно вызывать удивления, поскольку превзойти базовый уровень не очень сложно. Например, даже следующее простое решение на основе правил превосходит базовый уровень:
def fast_track(row):
"""
A very simple solution that still beats the
baseline.
"""
# "cp" is the column for chest pain.
if row['cp'] == 2 and row['sex'] == 0:
return 1
elif row['cp'] == 1 and row['sex'] == 0:
return 1
else:
return 0
# Check the performance
df['pred'] = df.apply(
lambda row: fast_track(row),
axis=1)
top_k_preds = df.sort_values('pred').tail(61)
recall_at_k = len(
top_k_preds
.query('had_heart_attack == 1')
.query(pred == 1))
print(f"Recall@61 = {recall_at_k}")
# Outputs Recall@61 = 50
Но бонусные баллы определенно начисляются, если кандидат может четко сформулировать проблему и решить ее в максимальной степени (отличное запоминание при k=61).
Преимущества интервью для постановки технических проблем
Основное преимущество собеседования для формулирования технических проблем заключается в том, что люди, которые проходят собеседование и, следовательно, получают работу, могут действовать более независимо. Поскольку они способны усвоить цели, которые им поручено улучшить, они могут сократить объем накладных расходов, необходимых как для их менеджеров, так и для владельцев продуктов. Это имеет решающее значение для масштабирования влияния технической команды, особенно в небольших организациях, где мало поддержки PM и где ожидается, что менеджеры будут IC, и поэтому у них ограниченная пропускная способность для наблюдения за большим количеством проектов.
Например, нам удалось сохранить команду Data в Fi очень небольшой и гибкой, и во многом это связано с тем, что мы нанимали только людей с сильными способностями к формулированию технических проблем. В настоящее время в нашей команде всего четыре человека (скоро их станет пять), но мы обслуживаем все связанные с данными потребности бизнеса из 100+ и владеем всеми процессами ETL, проектированием и обслуживанием хранилища данных, отчетами Tableau, глубоким погружением и анализом первопричин, машинным обучением и прогнозным моделированием, а в последнее время — исследованиями и разработками для разработки новых функций. Мы охватываем буквально все аспекты бизнеса: финансы, маркетинг, взаимодействие с клиентами, проектирование, аппаратное обеспечение, микропрограммы, операции и продукты. Способ, которым мы можем взять на себя такой большой объем работы и охватить так много областей, заключается в том, что каждый в команде умеет брать нечетко сформулированную проблему и сопоставлять ее с технической постановкой задачи.
Вскоре
Следите за будущим постом, в котором я расскажу о том, как улучшить вашу собственную способность формулировать технические проблемы, а также о том, как улучшить способность вашей команды делать это, если вы менеджер.
