Entrevista de data engineer en OpenAI: proceso y preparación

Tienes un correo de un reclutador de OpenAI y quieres saber qué viene después antes de aceptar un calendario. Esta sección expone lo que la propia OpenAI dice sobre su proceso y luego las etapas que suele tener un ciclo de ingeniería de datos. Trata los hechos publicados como puntos fijos y todo lo demás como preparación.

OpenAI publica una guía de entrevistas general en lugar de un desglose por puesto, y no publica un ciclo aparte para data engineers. Lo que sí afirma se aplica a toda su contratación:

• Revisión del currículum. El equipo de selección suele tardar una semana en revisar un currículum y responder.
• Decisiones tras cada etapa. Los candidatos saben en la semana posterior a cada etapa si han avanzado.
• Entrevistas finales. Los candidatos suelen pasar 4-6 horas en entrevistas finales con 4-6 personas a lo largo de 1-2 días.
• Formato. Las entrevistas son virtuales por defecto, y los candidatos pueden optar por hacerlas presencialmente en la oficina de San Francisco.
• Decisión final. Los candidatos deben esperar respuesta en el plazo de una semana desde sus entrevistas finales.

OpenAI no publica cuántas entrevistas hay antes de las finales para un data engineer, cómo se llama cada una ni en qué orden se hacen. Tu reclutador es la fuente fiable: pregunta qué áreas cubre cada conversación y si alguna parte permite herramientas de IA.

Para planificar, las etapas siguientes son categorías generales de preparación para puestos de ingeniería de datos en grandes empresas tecnológicas, no los nombres de las rondas de OpenAI:

• Conversación con el reclutador. Trayectoria, motivación, el equipo y logística, como si las finales serán virtuales o presenciales.
• Prueba técnica. Normalmente SQL y algo de código, a menudo con preguntas sobre un pipeline que hayas operado en producción.
• Conversación con el responsable de contratación. Los sistemas que has construido, la escala y el desorden de los datos que manejaste, y las compensaciones que hiciste.
• Entrevistas finales. Código más profundo, modelado de datos, diseño de pipelines o de sistemas y conversaciones de comportamiento, repartidas entre las 4-6 personas que describe OpenAI.

Publicaciones en Reddit, Glassdoor y foros similares describen ciclos concretos con detalle. Cada una refleja a un candidato, en un equipo, en un momento dado; úsalas para ver el abanico de temas, no como un calendario.

En las entrevistas de ingeniería, OpenAI dice que en general busca soluciones bien diseñadas, código de alta calidad, rendimiento óptimo y buena cobertura de pruebas. Esos criterios están escritos para ingenieros en general, pero encajan muy bien con el trabajo con datos. Las preguntas de ejemplo de esta página son ejercicios de práctica, no preguntas que OpenAI haya confirmado hacer.

• Soluciones bien diseñadas: modelado y diseño de pipelines. Elegir la granularidad de una tabla, separar hechos y dimensiones, decidir entre batch y streaming, y prever recargas históricas, datos tardíos y cambios de esquema. Un diseño que resiste cambios de requisitos está bien diseñado; uno que solo encaja con el enunciado original, no.
• Código de alta calidad: Python y SQL que enviarías a producción. Nombres claros, funciones pequeñas, manejo explícito de nulos y registros mal formados, y joins que puedas justificar. A los entrevistadores suele importarles que sepas explicar por qué una consulta es correcta, no solo que se ejecute.
• Rendimiento óptimo: coste y escala. Particionado, evitar escaneos completos, reducir shuffles en trabajos distribuidos y saber cuándo una respuesta aproximada es aceptable. Indica dónde está el cuello de botella antes de proponer una solución.
• Buena cobertura de pruebas: la calidad de datos como prueba. Para un data engineer esto significa pruebas unitarias de las transformaciones y comprobaciones sobre los propios datos: recuentos de filas frente a lo esperado, claves únicas, frescura y alertas cuando una fuente cambia de forma.
• Criterio de comportamiento. La responsabilidad ante el fallo de un pipeline, los desacuerdos sobre la definición de una métrica y cómo decidiste qué no construir.

OpenAI también indica que las expectativas sobre la IA y otras herramientas varían según la entrevista. Algunos formatos las permiten a propósito, y otros están diseñados para evaluar la resolución de problemas de forma independiente, sin herramientas de IA. En un formato asistido, la habilidad que se ve es cómo diriges, verificas y corriges lo que produce la herramienta; en uno sin ayuda, escribes tú el SQL y el código. Sigue las reglas que fije cada entrevistador y pregunta cuando no estén claras. Hay más ejercicios agrupados por habilidad en los bancos de preguntas.

OpenAI no publica diferencias entre puestos, así que la comparación siguiente describe la práctica general en ingeniería de datos y no dice nada sobre los demás ciclos de OpenAI.

• Frente a ingeniería de software. Menos peso en acertijos de algoritmos y más en SQL, modelado de datos y fiabilidad de pipelines. Las preguntas de diseño tienden a girar en torno a cómo se mueven, aterrizan y se corrigen los datos, más que a servicios que atienden peticiones. Los criterios de ingeniería que cita OpenAI siguen aplicándose, así que la calidad del código y las pruebas importan tanto como en cualquier ciclo de ingeniería.
• Frente a ciencia de datos. Menos estadística y diseño de experimentos, y más construcción de las tablas de las que dependen analistas e investigadores. Aun así pueden preguntarte cómo se define una métrica, porque un data engineer suele ser dueño de la tabla que la sostiene.
• Frente a analytics engineering. La línea es difusa. Los puestos de analítica suelen inclinarse hacia el modelado y el SQL para informes, mientras que los de data engineer profundizan más en ingesta, procesamiento distribuido e infraestructura.

Comparado con otras grandes empresas, el proceso publicado por OpenAI tiene rasgos que conviene tener en cuenta. Las finales se concentran en 1-2 días, así que la resistencia importa: tu última conversación del día recibe el mismo escrutinio que la primera. La política sobre herramientas cambia según la entrevista; pregunta antes de cada sesión en lugar de suponerla. Y el compromiso de responder en la semana posterior a cada etapa te permite planificar otras entrevistas y ofertas con más confianza. Encontrarás guías sobre cómo estructuran sus ciclos otras empresas en entrevistas por empresa.

OpenAI publica algunos detalles de plazos, aunque no un calendario completo. El equipo de selección suele responder a un currículum en una semana, los candidatos reciben respuesta en la semana posterior a cada etapa y la decisión final suele llegar en una semana desde las entrevistas finales. Las finales en sí duran normalmente 4-6 horas con 4-6 personas a lo largo de 1-2 días.

Lo que OpenAI no publica es cuántas etapas atraviesa un data engineer antes de las finales, por lo que la duración total de un proceso no puede deducirse solo de la guía. Pregunta a tu reclutador cuántas conversaciones esperar y organiza tu preaviso y otras entrevistas según su respuesta.

La dificultad es más fácil de describir en términos cualitativos. Cada etapa es una puerta, ya que después de cada una sabes si has avanzado, de modo que una prueba técnica floja termina el proceso antes de que empiece cualquier conversación de diseño. Lo más difícil para la mayoría es la profundidad ante las repreguntas: esbozas un pipeline y el entrevistador añade eventos que llegan tarde, un cambio de esquema en una fuente de origen y la pregunta de cómo sabrías que la salida es incorrecta. Quienes han operado pipelines en producción suelen manejar mejor esa deriva que quienes solo los han construido.

Los candidatos senior deben esperar más peso en el criterio: qué no construir, cómo explicar un compromiso a un investigador o a un socio de producto y cómo gestionaron un error propio.

Construye tu preparación en torno a los criterios que OpenAI cita para las entrevistas de ingeniería, y después añade la cuestión de las herramientas y la parte de comportamiento.

• Soluciones bien diseñadas. Elige un dominio que conozcas, como registros de eventos o medición de uso, y esboza las tablas, su granularidad y el pipeline que las llena. Luego somete el diseño a presión: una reejecución tras un fallo parcial, una recarga histórica, datos tardíos, una columna renombrada.
• Código de alta calidad. Escribe transformaciones en Python sobre registros anidados y desordenados y mantenlas legibles. Practica funciones de ventana, deduplicación y sessionización en SQL hasta poder escribirlas sin consultar nada, y enuncia la granularidad de cada resultado antes de ejecutarlo.
• Rendimiento óptimo. Para cada diseño, nombra el paso costoso y cómo abaratarlo, por ejemplo con poda de particiones, procesamiento incremental o preagregación.
• Buena cobertura de pruebas. Añade pruebas a cada solución de práctica y describe las comprobaciones de calidad de datos que ejecutarías en producción. Añadir pruebas sin que te lo pidan muestra el hábito que describe este criterio.
• Con y sin herramientas de IA. Practica algunos problemas con un asistente y otros sin él, para que ningún formato te sorprenda. En el formato asistido, explica en voz alta cómo verificas lo que produjo la herramienta.
• Resistencia para las finales. Ensaya entrevistas simuladas seguidas en una sola sesión, ya que las finales concentran 4-6 horas de conversaciones en 1-2 días.
• Historias de comportamiento. Prepara un fallo de pipeline del que fuiste responsable, un desacuerdo sobre la definición de una métrica y una compensación que hoy harías de otra manera.

Piensa en un data engineer cuya experiencia son sobre todo trabajos batch nocturnos en una empresa de pagos. Dedica las primeras sesiones a las funciones de ventana de SQL y luego practica cómo explicar que una recarga histórica pueda reejecutarse con seguridad, porque ahí están sus historias reales. También resuelve algunos problemas con un asistente de IA y otros sin él, de modo que la política de herramientas de una entrevista concreta no cambie su forma de razonar.

El último paso es decir todo esto en voz alta, porque cada etapa es una conversación. La página de entrevista simulada de SubcueAI te permite practicar en voz alta preguntas de ingeniería de datos antes de la prueba técnica real.