Transformando tus entrevistas técnicas en la era de los agentes de IA: El método McDougall en detalle

Hola a todos. Mi nombre es Anna McDougall. Estoy realmente emocionada de estar aquí hoy para hablarles sobre cómo transformar sus entrevistas técnicas en la era de los agentes de IA. Mi nombre es Anna McDougall, soy Directora de Operaciones de Ingeniería en Blinkist y soy la creadora del método McDougall que es como una nueva forma de realizar entrevistas técnicas. Personalmente, no lo veo como algo revolucionario, pero sí creo que la estructura proporciona una base realmente sólida para resolver algunos de los problemas que tenemos con las entrevistas técnicas, especialmente hoy en día.

Así que, vamos a entrar directamente. Creo que las entrevistas técnicas están rotas para los equipos de ingeniería, y una de las razones es porque, para ser honesta, la mayoría de las personas que están en mi nivel o por encima, entrevistaron para entrar en tecnología hace unos 20 años, ¿verdad? Entonces, hace 20 años, era algo muy, muy diferente. La mayoría de las personas trabajaban en la oficina y entrar en una ronda técnica significaba ir a la oficina, pararse frente a una pizarra como nuestro lindo personaje de dibujos animados y realmente resolver un problema allí en la pizarra, ideando soluciones de una manera muy práctica.

Esta forma de entrevistar, quiero decir, en primer lugar, ya pienso que es defectuosa, pero supongamos que es una buena manera de entrevistar a las personas. Involucra mucho control sobre el entorno, ¿verdad? La oficina es un entorno controlado, la sala es un entorno controlado, la pizarra es una herramienta controlada para el entrevistador, entrevistado, lo que sea, para completar su entrevista aquí. Así que, hoy en día, ese control se ha ido. El 99.99% de las entrevistas técnicas se están realizando de forma remota. En las propias computadoras de las personas, a menudo en sus propios hogares, y los entrevistadores, como yo, no tienen control sobre el entorno en el que están sus candidatos, ¿verdad? Y esto no es realmente algo súper nuevo. Creo que tan pronto como comenzamos a hacer entrevistas técnicas de forma remota, esto fue un punto.

Entonces, ¿qué hicimos? Intentamos imitar lo que teníamos originalmente. Creamos plataformas de leet code donde podemos controlar la herramienta que usan y mira, hay todas estas preguntas de DSA, pero ahora, ya sabes, incluso eso, supongamos de nuevo que esto realmente funciona, incluso eso ahora está tan extendido en términos de canales de YouTube, libros, etcétera sobre cómo resolver estos problemas, que incluso ellos no son un buen indicador. Entonces, pensamos, está bien, démosles una tarea para llevar a casa. Porque entonces podemos darles este código, vemos cómo lo resuelven, lo hacen en su propio tiempo, está probando la implementación, no se trata solo de memorización, etcétera, etcétera, y luego podemos revisarlo con ellos. Pero de nuevo, ahora que las herramientas de IA están aquí, hemos perdido el control de ese medio también.

Así que ahora, cualquiera puede tomar cualquier tarea para llevar a casa, y por ejemplo, no sé Ruby, podrías darme una tarea técnica en Ruby, y podría ir y con IA, podría hacer algo que funcione en Ruby. Puede que no sea genial, pero podría hacer algo que funcione como un proyecto Greenfield, y probablemente podría explicar más o menos lo que estaba sucediendo. ¿Es eso una buena prueba de que soy un ingeniero de Ruby? Mi argumento sería que no, ¿verdad? Y ahora también tenemos agentes de IA. Entonces, entramos en esta área de programación en pareja, que es más en lo que se basa mi método. Pero luego la gente dice, bueno, los agentes de IA también pueden simplemente resolver esto sobre la marcha. La gente puede tener una segunda pantalla, podrían tener su móvil afuera, lo que sea, un iPad, cualquier cosa, y podrían tener IA resolviendo el problema por ellos, y solo lo están leyendo o copiando. Así que esto crea un problema también, porque entonces de nuevo, podrías estar en vivo con alguien, y no puedes confiar en lo que están escribiendo y que realmente proviene de su cabeza.

Y luego el cuarto problema que tenemos, como si eso no fuera suficiente, son los deep fakes y las herramientas de trampa. Si aún no lo has visto, hay un video de alguien que realmente ha superpuesto otra cara en su cara y está tratando de pasar entrevistas para obtener acceso a los sistemas de una empresa. Y esto se puede usar para propósitos de hacking muy nefastos, tanto a nivel individual como también a nivel de estado nación. Así que hay muchos problemas con eso. Yo argumentaría que el método McDougall aborda tres de estos cuatro problemas. Desafortunadamente, aún no he encontrado una manera de tener en cuenta a las personas que falsifican su rostro, pero eso no es parte de lo que estoy hablando hoy. Hoy lo que estoy tratando de hacer es idear una manera de crear una estructura para un proceso de entrevista técnica que realmente pruebe si las personas pueden implementar código mientras también permite la existencia de IA y no lucha contra ella, ¿verdad?

Oh, y por supuesto, olvidé, esta es la otra cosa que necesitamos evitar, ¿verdad? No hacer la entrevista técnica tan ridículamente difícil que ya no imite el trabajo real que la gente está haciendo. Sabes, creo que este meme realmente dice todo lo que necesito decir. Pero el objetivo aquí del método McDougall es imitar el trabajo real. Entonces, ¿qué harán realmente las personas en este trabajo? Sí, un ingeniero backend de nivel medio que principalmente escribe CRUD APIs no debería tener un proceso de entrevista donde tengan que diseñar algún tipo de sistema de mensajería complejo, ¿verdad? Eso no es necesariamente lo que necesitan para completar el trabajo. Entonces, el objetivo aquí debería ser imitar esa sensación del primer día en el trabajo en la entrevista técnica.

La segunda cosa es la seguridad psicológica. No hay mucho enfoque de los líderes de ingeniería en cómo realmente hacer que los candidatos se sientan más bienvenidos y realmente darles una buena experiencia. Hay mucho más enfoque en cómo encontramos a la persona con las habilidades adecuadas, y entiendo eso porque es en lo que están pensando, ese es el problema que tienen, pero mi objetivo con esto también es equilibrar cómo podemos hacer de esto una experiencia agradable para las personas para que no se sientan nerviosas o sientan que están siendo irrespetadas o utilizadas de alguna manera. Y también evaluar el pensamiento y no solo la memorización. No solo dejar que las personas memoricen, ya sabes, cómo invertir un binario, cómo invertir un árbol binario, sino realmente, como, ¿pueden resolver un problema del día a día que existe?

Entonces, en el método McDougall. Moderno, realista, indicativo. Moderno en el sentido de que no trato de controlar demasiado el entorno y las herramientas que un candidato está usando. Realista en el sentido de que tengo en cuenta la existencia de IA, e indicativo en el sentido de que realmente me mostrará las habilidades de la persona que estoy entrevistando. Entonces, lo primero que hay que decir es que en el método McDougall, hay dos ingenieros dirigiendo la entrevista. No tres, no cuatro, no uno. Dos. La razón de esto es que cuantas más personas agregues, más estrés es para un candidato, pero si solo tienes una persona, tiendes a caer en patrones de sesgo personal. No sabes realmente si esa persona tendría el mismo enfoque que otras personas, o la misma opinión que otras personas, y es más agradable tener esa idea de, como, está bien, tenemos dos puntos de datos aquí sobre las habilidades de esta persona, no solo uno.

pero si solo tienes una persona, tiendes a caer en patrones de sesgo personal.

No sabes realmente si esa persona tendría el mismo enfoque que otras personas, o la misma opinión que otras personas, y es más agradable tener esa idea de, como, está bien, tenemos dos puntos de datos aquí sobre las habilidades de esta persona, no solo uno. Entonces, mi consejo es siempre tener dos, y están divididos de esta manera. El primero es lo que llamo el ingeniero organizador. Esta es la persona que dirige las bienvenidas, que se ocupa del tiempo, que dice, está bien, necesitamos llegar al final de esta sección ahora. Pasemos a esta parte aquí. Dicen, oh, tal y tal, ¿te gustaría presentarte? Son esta persona que dirige la reunión, por así decirlo.

Y el otro es el ingeniero de emparejamiento. Cuando llegamos a la parte de programación en pareja del método McDougall que describiré en breve, deberían ser quienes realmente actúen como el socio, no ambos ingenieros. El ingeniero organizador debería estar sentado atrás y solo observando siempre que sea posible. El ingeniero de emparejamiento es quien realmente está trabajando con esa persona. Y, nuevamente, esto es para imitar esa sensación del primer día en el trabajo.

¿Cómo estaría realmente trabajando esta persona si estuviera tratando de resolver un problema con uno de nuestros ingenieros existentes? Lo principal a notar aquí en esta diapositiva es que todas las herramientas están permitidas. Esta es la otra gran parte del método McDougall. Puedes usar Google. Puedes usar ChatGPT. Puedes usar cualquier herramienta que desees para resolver los problemas que te presentamos. La razón es porque estas son ahora herramientas del oficio. No permitir que las personas usen estas herramientas es no obtener una visión real de lo que harían en el trabajo, ¿verdad? Y eso es lo que realmente queremos. Como líderes de ingeniería, realmente queremos saber, ¿puede esta persona hacer el trabajo?

Así que eso, para mí, es sentido común, pero creo que es realmente importante decir que las herramientas de IA no son hacer trampa. Son parte del desarrollo ahora. Así que abracemos eso y veamos realmente lo que la gente puede hacer con ellas.

Así que aquí está la estructura básica del método McDougall. La mayor parte, como dije, no es algo revolucionario. Realmente, es el cómo dentro de esto lo que es más interesante, creo. Introducción, calentamiento, sesión de programación en pareja, reflexión, y luego un cierre y los siguientes pasos.

Sin embargo, es importante destacar que esto es más corto que muchas entrevistas técnicas que ves por ahí. Esto es de 75 a 90 minutos en total. Así que esto realmente impulsa esta idea de no ocupar demasiado tiempo del candidato. Y entenderás por qué en breve.

Lo primero es el calentamiento de introducción. Bastante directo al grano. No voy a pasar mucho tiempo aquí. Preséntate, sonríe, haz que se sientan relajados. Solo debería durar de 10 a 15 minutos. Hazles algunas preguntas sobre su experiencia. Lánzales algunas preguntas fáciles para que se relajen un poco y creen esa sensación de comodidad con los dos entrevistadores.

Los dos entrevistadores también deben presentarse, no solo en un sentido empresarial y no de manera súper seria. Realmente muestra un poco de personalidad. Déjalos relajarse un poco. Haz que se sientan lo más relajados posible en un proceso de entrevista. Dales esa oportunidad. ¿Verdad? Entonces pasamos al núcleo, que es la programación en pareja, y voy a entrar en mucho más detalle aquí. El objetivo de toda esta sección es que estamos verificando la implementación.

En otras palabras, ¿pueden hacer el trabajo? Si les doy un ticket, ¿se completará ese ticket a mi satisfacción? Eso es lo que estoy verificando aquí. Son de 35 a 45 minutos. ¿Por qué se limita a 45 minutos? Porque en mi opinión, no van a aprender mucho más allá de los 45 minutos que no hayas visto ya. No va a haber una revelación masiva en términos de sus habilidades técnicas en términos de implementación que vayas a obtener después de 45 minutos. Realmente no necesitas más tiempo que eso.

Creación de repositorio. Así que he mencionado que esto involucra programación en pareja. La pregunta natural siguiente es ¿qué? ¿Qué van a programar en pareja? Para esto, necesitas hacer un poco de trabajo, y el trabajo implica que uno de tus ingenieros o varios creen un nuevo repositorio. Este repositorio debe basarse en una base de código real. No una base de código real. No deberías obtener trabajo gratis de tus candidatos, pero deberías basarlo en cómo estructuras las cosas.

Entonces, por ejemplo, ¿cómo es tu convención de nombres, cómo están estructuradas estas cosas, dónde se encuentran ciertos componentes, qué paquetes estás usando? Todo esto debería ser muy similar en esta base de código Mimic, excepto obviamente mucho más pequeña y mucho más simple. Además, porque las bases de código reales son complejas, y no puedes esperar que alguien realmente las entienda en 45 minutos, y mucho menos crear razonablemente una nueva característica, por ejemplo.

Entonces, creas este repositorio y se lo envías una hora antes, y dentro de este repositorio, habrá pruebas. Podrían ser solo pruebas unitarias o lo que sea, o como quieras hacerlo, pero estas pruebas, debería haber algunas que fallen. Y mi recomendación aquí es tener de cinco a diez pruebas fallidas, cada una representando una tarea para ese ingeniero.

Entonces, el ingeniero entra, instala todo, tiene esta hora para poner todo en funcionamiento en su máquina, y luego puede ejecutar la suite de pruebas, y la suite de pruebas debería tener algunas fallas. Cada una de estas fallas debería representar un nivel diferente. Entonces, aquí es donde entra en juego la parte indicativa del método McDougal que deberían estar niveladas por estas tareas. Entonces, el nivel uno es un junior interno fresco, el nivel dos junior a medio bajo, el nivel tres es un nivel medio, medio sólido, el nivel cuatro es un medio alto a bajo senior, y el nivel cinco es un senior plus. Estos son, nuevamente, tareas reales.

He dado algunos ejemplos para cada una aquí. No voy a leerlas, pero puedes revisarlas en tu propio tiempo. Recomendaría mantenerlas más o menos a ese tipo de nivel. ¿Qué esperarías realmente que alguien recién salido de la universidad o recién salido de un boot camp pudiera hacer en el trabajo en el código? Y eso debería ser el nivel uno. Manténlo realmente pequeño, realmente realista. La otra cosa es que siempre deberías comenzar a tus candidatos un nivel por debajo. Entonces, si estás contratando para un senior, deberías comenzar en el nivel cuatro, tal vez incluso en el nivel tres. No en el nivel cinco. ¿De acuerdo? Y definitivamente no en el nivel uno, porque obviamente, incluso los pequeños cambios toman tiempo, así que no quieres perder tiempo en cosas que sabes que pueden hacer. Pero quieres comenzarles un nivel por debajo. ¿Por qué? Porque muchas personas se sobrevaloran o se subvaloran. Un senior en una empresa no es lo mismo que un senior en otra empresa. No puedes confiar en los títulos de trabajo anteriores para representar con precisión dónde estaría nivelada esa persona en tu empresa. Así que necesitas comenzarles un nivel por debajo para darles la oportunidad de mostrar, está bien, ellos pueden hacer eso o no pueden.

Entonces es muy claro, está bien, esto no es un senior, esto es realmente un ingeniero de nivel medio. Además, volvemos a este tema de la seguridad psicológica. Si soy un ingeniero de nivel medio real, por ejemplo, y me dan una tarea de nivel dos, entonces debería encontrar eso fácil y eso debería darme una sensación de pequeña victoria, y luego tengo ese pequeño golpe de dopamina donde pienso, genial, puedo hacer esto. Te da un poco de confianza, lo que con suerte significa que ves su comportamiento real, porque, te guste o no, cada entrevista lleva al estrés, el estrés lleva al bajo rendimiento. Cada entrevista técnica, cada persona en una entrevista técnica probablemente esté rindiendo por debajo de su capacidad, así que dales la oportunidad de tener esa pequeña victoria y con suerte eso ayuda a aliviar algo de ese estrés. Y esto hace que la nivelación sea fácil.

Lo contrario también es cierto, debo decir. Si alguien es un junior y entra y llega al nivel cuatro, bueno, entonces de repente estás pensando, oh, esta persona no es realmente un junior, deberíamos tal vez pensar en dónde más podríamos ponerles, o, hmm, ¿eso siquiera va a funcionar, es eso lo que estamos buscando? Ayuda con la nivelación, básicamente. Entonces, después de que han hecho esta tarea, tienen estos 45 minutos, han hecho programación en pareja con su ingeniero dedicado de programación en pareja, han hecho una o dos, si tienen suerte, tres de estas tareas, pero probablemente no en 45 minutos, entonces obtienes una buena idea de lo que pueden implementar. Ahora, hay una posibilidad de que hayan usado AI y Google y Stack Overflow y un montón de diferentes herramientas para completar esa tarea, y aquí es donde la etapa de reflexión se vuelve útil. Porque incluso si alguien está usando un agente AI, no todos aceptarán cada sugerencia que el agente AI haga, y ahí es donde sucede lo interesante.

Entonces, esta etapa de reflexión se trata de que tú digas, oye, ¿realmente entienden lo que acaban de hacer? Tal vez simplemente aceptaron cada sugerencia que hizo la AI. ¿Por qué hicieron eso? ¿Es así como normalmente trabajan? Entonces también podrías darles retroalimentación. Bueno, vi que aceptaste esta cosa, y eso en realidad no es lo que yo habría hecho. ¿Por qué elegiste hacerlo de esa manera? Ve si realmente pueden reflexionar sobre lo que hicieron y por qué lo hicieron. Y también, sobre cómo recibieron la retroalimentación, ¿cómo la tomaron, se pusieron a la defensiva? ¿Sí? Cuando les ofreciste una retroalimentación, ¿se pusieron a la defensiva o realmente la abordaron y dijeron, oh, sí, tienes razón, podría haberlo hecho de manera diferente. Eso habría sido mejor, etcétera.

Bien. Luego, el último paso es la conclusión y la sección de próximos pasos. Nuevamente, nada revolucionario, pero aquí quiero realmente enfatizar el elemento del cronograma. Esta es la parte que muchas personas hacen mal, o simplemente la pasan por alto por completo. Tomas algunas preguntas. Les haces algunas preguntas finales. Luego deberías decirles, está bien, en los próximos X días o en la próxima semana, serás contactado por esta persona para informarte si pasarás a la siguiente etapa o si necesitamos más tiempo. No tienes que darles una respuesta definitiva. Solo puedes decir, este es el marco de tiempo en el que puedes esperar escuchar de nosotros. Y luego el último paso es, por supuesto, decir adiós. Y nuevamente, manténlo amigable y optimista, incluso si no fue una buena entrevista, sigue siendo agradable hacer que alguien se sienta bienvenido.

Así que ese es el Método McDougall. Moderno, realista, indicativo. Espero que te dé un buen punto de partida. Mi llamado a la acción para ti. Discútelo con tu equipo, con tu gerente, con tu CTO. Pruébalo. Dale una oportunidad. No tienes que probarlo todo de una vez. Tal vez solo pruebes un elemento de él. Y luego adáptalo. Úsalo como mejor te parezca. Cada organización es diferente, pero te animaría a experimentar con él. Así que eso es todo de mi parte. Espero que eso te haya dado una visión muy rápida, rápida y sucia del Método McDougall y lo que contiene. Si vas a mi sitio web, annamcdougall.com, puedes desplazarte hacia abajo hasta donde menciono el Método McDougall, y hay un enlace a la página de Medium. Y también, como agradecimiento de mi parte para ti, puedes obtener un año gratis con Blinkist usando este código especial que he creado para ti. Así que por favor visita el enlace, obtén tu año gratis con Blinkist, y disfruta de la app de mi parte. ¿De acuerdo? Gracias a todos, y que tengan una maravillosa conferencia. ¡Adiós!