Una forma sencilla de mejorar las entrevistas de ciencia de datos

Forma sencilla de mejorar entrevistas de ciencia de datos

Identificando el top 5% de candidatos a través de la formulación de problemas técnicos

En este artículo comparto una historia sobre un error que cometí como gerente de contratación de Ciencia de Datos sin experiencia, y cómo cambió la forma en que llevo a cabo las entrevistas técnicas. También paso por un ejemplo de una pregunta de entrevista de Ciencia de Datos y muestro cómo los candidatos más fuertes abordan el problema de manera diferente a los candidatos más débiles. Si bien me enfoco en la Ciencia de Datos, la mayoría de mis ideas y sugerencias son relevantes para cualquier rol técnico, incluyendo Ingeniería de Software, Ingeniería de Datos, etc.

Pero primero, un breve resumen sobre mí.

He estado trabajando en Ingeniería de Software y Ciencia de Datos/Aprendizaje Automático durante unos nueve años. He trabajado en empresas de todos los tamaños: la más grande es Wayfair (13k empleados), y la más pequeña es mi empleador actual, Fi (~100 empleados), donde soy el Vicepresidente de Datos. Ahora me acerco a un punto de inflexión donde la mitad de mi carrera la he pasado como Contribuyente Individual (CI), y la otra mitad como Gerente/Director/Vicepresidente. Durante la segunda mitad, he construido o heredado equipos que van desde dos hasta 15 personas. En ese tiempo, he contratado a unas 20 personas, realizado cientos de entrevistas y diseñado innumerables procesos de entrevista.

Durante mi tiempo como gerente de contratación, he hecho muchas contrataciones exitosas, pero también he cometido mis errores en el camino. Por ejemplo, al principio de mi carrera como gerente de contratación, cuando me encargaron por primera vez la responsabilidad de construir un proceso de entrevista desde cero, cometí uno de los mayores errores de contratación. Me llevó otro año o dos entender completamente el error que había cometido. Pero una vez que pude articularlo, supe que se podía evitar y tomé medidas para asegurarme de que no volviera a ocurrir.

• Este documento de IA evalúa la capacidad de los LLM para adaptarse a nuevas variantes de tareas existentes
• Optimizando el rendimiento de las máquinas virtuales de Azure mientras se reducen los costos Estrategias probadas para una eficiencia óptima
• Uplift Modeling – Una guía para científicos de datos sobre cómo optimizar una campaña de renovación de tarjetas de crédito

Este artículo trata sobre ese error y lo que hago para evitar cometerlo nuevamente.

Mi error de contratación

En 2019, fui ascendido de Ingeniero Senior de Aprendizaje Automático a Científico de Datos Principal, que era un puesto de gestión. Mi equipo estaba buscando desarrollar nuevas aplicaciones de modelado que requerían modelos e integraciones diferentes a los que ya había construido. Y como recientemente había asumido un rol de gestión, no tenía el tiempo suficiente para construir toda la infraestructura necesaria por mí mismo. Así que me propuse contratar a un Científico de Datos Senior para ayudar a construir y mantener los nuevos modelos e integraciones.

Proceso de entrevista

Diseñé un proceso de entrevista que consistía en una entrevista con el gerente de contratación, un proyecto para realizar en casa y algunas entrevistas en grupo. A excepción de la entrevista interfuncional, todas las entrevistas fueron de naturaleza técnica e involucraron algún tipo de desafío de aprendizaje automático, ingeniería de datos o ingeniería de software. En un par de meses, encontramos a nuestro candidato ideal.

Las primeras semanas del nuevo contratado fueron sin problemas. Y una vez que se familiarizó con la pila tecnológica, los compañeros de equipo y el proceso de trabajo, le asigné un proyecto más grande.

Surgimiento de síntomas

Después de un par de semanas en su proyecto asignado, noté que sus tareas estaban llevando más tiempo de lo previsto. Así que pasé tiempo extra cada semana con él para asegurarme de que las cosas se mantuvieran en el camino correcto. Pero desafortunadamente, las cosas no mejoraron. Casi cada vez que nos reuníamos para discutir el progreso y los próximos pasos, parecía que no se había logrado ningún progreso. En su lugar, surgían obstáculos técnicos que, desde su perspectiva, necesitaban resolverse para poder avanzar. Recuerdo sentirme frustrado porque tenía dificultades para entender cómo todos los obstáculos técnicos que mencionaba eran tan relevantes, ya que parecían surgir de la nada.

Recuerdo que estábamos a dos meses en el proyecto que proyectamos que tomaría dos semanas completar, pero aún no teníamos una solución funcional. Peor aún, ni siquiera teníamos un plazo claro para completarlo.

El problema subyacente

Ahora que he estado gestionando y contratando durante varios años, y he visto mi parte tanto de éxitos como de fracasos con nuevos empleados, puedo articular exactamente cuál era el problema subyacente y dónde me equivoqué.

El problema subyacente era que carecían de un conjunto de habilidades que eran críticas para el éxito en su puesto. A primera vista, podría parecer que carecían de habilidades técnicas, ya que frecuentemente surgían obstáculos técnicos que no podían resolver rápidamente. Pero ese no era el caso. De hecho, sus habilidades técnicas eran excepcionales.

Más bien, carecían de la capacidad de comprender la conexión entre la aplicación técnica y la necesidad empresarial, lo que les impedía saber cuándo y cómo hacer concesiones. Esto se manifestaba como obstáculos técnicos insuperables, cada uno de los cuales podría haberse evitado simplificando el enunciado del problema.

Por ejemplo, uno de los desafíos a los que seguían enfrentándose era debido al tamaño del conjunto de datos con el que estaban trabajando. Pero cada vez que mencionaban esto como un problema, yo sugería reducir el conjunto de datos solo a las tres o cuatro características principales en las que estábamos interesados, y luego filtrar solo los registros que probablemente fueran relevantes. Al hacerlo, se habría reducido el conjunto de datos global a menos del 0.5% de su tamaño original, lo que habría evitado cualquier problema debido al volumen y nos habría dado el 80% del valor agregado de todo el conjunto de datos. Pero cada vez que sugería esto, estaba claro que no habían pensado en ello, a pesar de que lo mencioné repetidamente.

Enmarcando el Problema Técnico

Para resumir: el nuevo empleado tuvo problemas para mantener una comprensión sólida tanto del contexto empresarial como del contexto técnico al mismo tiempo, por lo que las tareas técnicas que se propusieron resolver a menudo eran más complicadas de lo necesario. En otras palabras, tenían problemas con el enmarcado del problema técnico, que es la capacidad de enmarcar un objetivo empresarial como un objetivo técnico y la capacidad de comprender cómo un conjunto de requisitos representa un objetivo empresarial subyacente.

Para aquellos que no estén familiarizados con el enmarcado del problema técnico o el flujo de trabajo típico de un equipo de datos, por lo general, los requisitos son proporcionados por un Gerente de Producto (PM) o por el gerente/líder técnico. Pero incluso en los casos en que los requisitos se proporcionan a los miembros del equipo, los requisitos nunca son completamente exhaustivos. Por lo tanto, es esencial que los miembros del equipo puedan comprender el objetivo que condujo a esos requisitos. Si no pueden hacerlo por sí mismos, entonces deberán ser supervisados muy de cerca por su gerente o su PM. Esto limita la escalabilidad del equipo y generalmente causa fricción entre el miembro del equipo y su gerente/PM.

Cuando reflexiono sobre este escenario, está claro dónde me equivoqué: no construí una entrevista que evaluara el enmarcado del problema técnico, y esta habilidad era un requisito para que tuvieran éxito en su puesto. Una vez que me di cuenta de esto, comencé a experimentar con formas de incorporar esto en mi proceso de entrevista. Afortunadamente, lo que encontré más efectivo solo requería un pequeño ajuste.

Ajustando las entrevistas

Esto es lo que hago de manera diferente.

Para al menos una entrevista técnica, incluyo la tarea técnica en un escenario empresarial del mundo real donde es necesario comprender completamente el contexto agregado para resolver adecuadamente el problema.

Además de evaluar la capacidad técnica, esta entrevista ajustada también evalúa la capacidad del candidato para inferir de los requisitos cuál es la intención real del proyecto y luego asegurarse de que esta intención se logre al diseñar la solución técnica.

A continuación, mostraré un ejemplo de entrevista que no evalúa el enmarcado del problema técnico y discutiré cómo se ve una solución sólida. Luego mostraré esa misma entrevista pero con el ajuste del enmarcado del problema técnico y mostraré cómo modifica lo que se considera una solución sólida.

Puedes encontrar el conjunto de datos original que uso para esta entrevista aquí. También puedes encontrar la descripción de la entrevista configurada como un cuaderno de Kaggle aquí.

Ejemplo 1: Entrevista de modelado de Ciencia de Datos SIN evaluación del enmarcado del problema técnico

Aquí está la pregunta de la entrevista sin ningún problema técnico enmarcado como evaluación.

################################################ Entrevista SIN problemas técnicos enmarcados ## como parte de la evaluación.                  ################################################# Te hemos proporcionado un conjunto de datos# que consiste en información de salud de# pacientes relacionada con paro cardíaco (ataques# al corazón).# Cada registro representa a un paciente que# visitó la Sala de Emergencias (ER) porque# experimentaba dolores en el pecho. Cada columna# corresponde a una medición que se realizó# cuando llegaron a la ER, incluyendo el tipo de# dolor en el pecho que estaban experimentando.# El conjunto de datos también contiene una# columna binaria que indica si el paciente# sufrió o no un ataque al corazón dentro de las# 48 horas posteriores a su visita a la ER.import pandas as pddf = pd.read_csv(f"{filepath}/heart.csv")display(df.head(5)# Tu tarea es construir un modelo que# prediga si un candidato sufrirá un# ataque al corazón en base a los datos# proporcionados.def predecir_ataque_cardiaco(fila):  """  Acepta una fila del conjunto de datos de ataque al corazón.  Devuelve 0 o 1 como predicción.  """  # TODO  pass

Solía realizar esta entrevista en un entorno en vivo, donde es conveniente tener un conjunto de datos pequeño y limpio para trabajar. El conjunto de datos es pequeño (303 filas y 13 entradas) y relativamente limpio, por lo que los candidatos con cualquier nivel de experiencia en aprendizaje automático pueden construir un clasificador sin mucha dificultad.

Evaluación

Los candidatos más débiles son fáciles de identificar, ya que suelen tener dificultades para construir incluso un modelo básico dentro del tiempo asignado, y mucho menos uno bueno. La tarea más sutil como entrevistador es identificar a los candidatos “buenos” de los candidatos “excelentes”. Además de demostrar la capacidad de construir un clasificador funcional en un corto período de tiempo, los candidatos más fuertes suelen diferenciarse por (1) adoptar un enfoque iterativo: logran que algo funcione rápidamente y luego lo mejoran, y (2) tomar decisiones deliberadas. Por ejemplo, cuando les pregunto por qué eligieron una medida de rendimiento específica para evaluar el rendimiento de su modelo, tienen una respuesta específica. Los candidatos más débiles o menos experimentados darán respuestas, pero sin ninguna justificación real.

Ejemplo 2: Entrevista de modelado de Ciencia de Datos CON evaluación de problemas técnicos enmarcados

Aquí está la misma pregunta de la entrevista pero con un escenario empresarial incrustado, por lo que incluye problemas técnicos enmarcados como parte de lo que se evalúa.

################################################ Entrevista CON problemas técnicos enmarcados como ## parte de la evaluación.                     ################################################# Una Sala de Emergencias (ER) está recibiendo# una cantidad abrumadora de pacientes que# experimentan dolores en el pecho, que son un# síntoma de ataques al corazón. Los pacientes# que muestran otros síntomas de ataques al# corazón deben ser priorizados (acelerados)# al ingresar a la sala de espera de la ER# para mitigar los efectos del ataque al# corazón o evitarlo por completo.## En promedio, la ER puede acelerar a# un 20% de los pacientes que experimentan# dolor en el pecho, permitiéndoles saltarse# la cola de pacientes. Actualmente, la# política de la ER es acelerar a cualquier# paciente que experimente dolor en el# pecho de Tipo 2 (angina atípica). Esto# corresponde a un valor de `df['cp'] == 1` en# el conjunto de datos. El personal de la ER# cree que su política actual es subóptima# y solicita que realices un análisis de estos# datos de pacientes para desarrollar una# política que priorice mejor a los pacientes# de alto riesgo.# # Te hemos proporcionado un conjunto de datos# que consiste en información de salud de# pacientes relacionada con ataques al# corazón. Cada registro representa a un# paciente que visitó la ER porque estaba# experimentando dolores en el pecho. Cada# columna corresponde a una medición que se# realizó cuando llegaron a la ER, incluyendo# el tipo de dolor en el pecho que estaban# experimentando. El conjunto de datos también# contiene una columna binaria que indica si# el paciente sufrió o no un ataque al# corazón dentro de las 48 horas posteriores# a su visita a la ER.import pandas as pddf = pd.read_csv(f"{filepath}/heart.csv")display(df.head(5)# Tu tarea es utilizar el conjunto de datos# para construir una política de aceleración# que sea mejor que la política actual de la ER.def acelerar(fila):  """  Acepta una fila del conjunto de datos de ataque al corazón.  Devuelve 0 o 1 como decisión para acelerar.  """  # TODO  pass

Observa que los aspectos técnicos del problema permanecen sin cambios: se utiliza exactamente el mismo conjunto de datos y la firma de la solución es la misma. Pero ahora hay información adicional que cambia el perfil de una solución ideal.

Nueva declaración del problema

El contexto empresarial añadido introduce dos nuevas piezas de información que el candidato debe comprender antes de empezar con su solución. La primera es que hay una restricción que limita el número de pacientes que pueden ser acelerados en el proceso en un 20%. Esto corresponde a 60.6 pacientes, o 61 si redondeamos al alza:

.20 * len(df)  # Salida 60.6

Por lo tanto, el número máximo de pacientes que podemos “salvar” acelerando su proceso es 61, ya que el servicio de emergencias no puede acelerar más de eso.

La segunda nueva pieza de información que proporciona el contexto de la sala de emergencias es que hay una estrategia de referencia que debe superarse para que se considere la nueva política. Esta estrategia de referencia consiste en predecir correctamente 41 ataques al corazón:

# La política de referencia de la sala de emergencias es acelerar a cualquier paciente con dolor en el pecho de Tipo 2, lo cual corresponde a `df['cp'] == 1`. Por lo tanto, la estrategia de referencia de la sala de emergencias es devolver 1 cuando `df['cp'] == 1`, y 0 en caso contrario.(  df.groupby(['cp'])[['had_heart_attack']]  .agg(['mean', 'count']))

.82 * 50  # Salida 41

Combinando la restricción añadida (61 aceleraciones en total) con el objetivo de superar la estrategia de referencia (41 predicciones correctas), podemos formular el nuevo objetivo como: encontrar un clasificador que tenga un recall@k (con k=61) mayor que 41.

Candidatos débiles

Los candidatos que tienen dificultades para enmarcar el problema técnicamente pasan por alto estas dos piezas de información y saltan inmediatamente al modo de solución. Esto suele resultar en una de dos soluciones subóptimas: una con alta precisión, pero con un recall igual o inferior a 41, o una con alto recall pero una precisión tan baja que los primeros 61 pacientes acelerados no producirán más de 41 ataques al corazón. Como entrevistador, daré pistas para orientar al candidato si veo que se dirige en la dirección equivocada. Algunos candidatos captarán mis pistas y corregirán el rumbo correctamente, mientras que otros seguirán luchando por identificar el problema correcto a resolver.

Candidatos fuertes

Los candidatos que son fuertes en el enfoque técnico del problema abordarán el problema de manera diferente. En lugar de entrar directamente en el modo de solución desde el principio, se toman el tiempo necesario para leer detenidamente la consigna, a menudo varias veces, para asegurarse de entender el contexto.

A continuación, hacen algo que está fuertemente correlacionado con el éxito, y a lo que presto mucha atención:

Los mejores candidatos escriben su enfoque antes de comenzar y luego me preguntan (al entrevistador) si parece razonable.

Cuando observo esto, es música para mis oídos. ¿Por qué? Porque eso es exactamente lo que quiero que hagan si se unieran a mi equipo. Quiero a alguien que pueda articular su plan de antemano antes de sumergirse en él, y también tenga la conciencia de consultarlo conmigo antes de comenzar. Aunque esto lleva más tiempo al principio, reduce la necesidad de volver atrás y cambiar de enfoque en medio de la entrevista, asegurando así que el tiempo restante se aproveche bien.

Los candidatos que son capaces de articular el problema correcto suelen ser capaces de resolver el desafío también. Esto no debería sorprender, ya que no es muy difícil superar la estrategia de referencia. Por ejemplo, incluso la siguiente solución simple basada en reglas supera la estrategia de referencia:

def fast_track(row):  """  Una solución muy simple que aún supera la estrategia de referencia.  """  # "cp" es la columna para el dolor en el pecho.  if row['cp'] == 2 and row['sex'] == 0:    return 1  elif row['cp'] == 1 and row['sex'] == 0:    return 1  else:    return 0# Comprobar el rendimientodf['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}")# Salida Recall@61 = 50

Pero se otorgan puntos extra definitivamente si el candidato puede plantear claramente el problema y resolverlo al máximo (recuerdo perfecto en k=61).

Beneficios de entrevistar para el planteamiento de problemas técnicos

El principal beneficio de entrevistar para el planteamiento de problemas técnicos es que las personas que lo superan, y por lo tanto son contratadas, pueden operar con más independencia. Debido a que son capaces de internalizar los objetivos para mejorar con los que se les ha asignado, pueden reducir la cantidad de trabajo adicional que se necesita de su gerente, así como de los propietarios de productos. Esto es fundamental para ampliar el impacto de un equipo técnico, especialmente en organizaciones más pequeñas donde hay poco apoyo de PM y se espera que los gerentes sean IC y, por lo tanto, tienen una capacidad limitada para supervisar muchos proyectos.

Hemos logrado mantener al equipo de Datos en Fi, por ejemplo, muy pequeño y ágil, y gran parte de esto se debe a que solo hemos contratado personas con una sólida capacidad para plantear problemas técnicos. Actualmente somos un equipo de solo cuatro personas (pronto seremos cinco), sin embargo, cubrimos todas las necesidades relacionadas con los datos para un negocio de más de 100 y somos responsables de todos los procesos de ETL, diseño y mantenimiento del Data Warehouse, informes de Tableau, análisis en profundidad y de causa raíz, aprendizaje automático y modelado predictivo, y más recientemente I+D para el desarrollo de nuevas características. Y los dominios que abarcamos son literalmente todos los aspectos del negocio: Finanzas, Marketing, Experiencia del Cliente, Ingeniería, Hardware, Firmware, Operaciones y Producto. La forma en que podemos asumir tanto trabajo y cubrir tantos dominios es porque todos en el equipo tienen habilidades para tomar un problema vagamente definido y convertirlo en una declaración de problema técnico.

Próximamente

Estén atentos a una publicación futura en la que hablaré sobre cómo mejorar su propia capacidad para plantear problemas técnicos, así como cómo mejorar la capacidad de su equipo para hacerlo si es gerente.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!