Por qué Leetcode está obsoleto y la programación en pareja para las entrevistas es el camino a seguir

♪♪ Hola a todos. Estoy muy emocionado de dar esta charla en Tech Lead Conf. Gracias por tomarse el tiempo para unirse a nosotros. Así que, hoy, vamos a echar un vistazo juntos a lo que está mal con las pruebas de codificación en línea, por qué leetcode está muerto, y cómo incluir una entrevista de programación en pareja puede revolucionar todo su proceso de entrevista.

Entonces, quiero comenzar dando una visión general de lo que vamos a hablar hoy. En primer lugar, muy rápidamente, ¿por qué importa el crecimiento? ¿Y por qué deberías enfocarte en las entrevistas? Dos, ¿qué estás buscando en el candidato ideal? ¿Cuáles son las características clave, rasgos, habilidades que deberías apuntar? Sabiendo eso, en tercer lugar, ¿cuáles son las habilidades que las plataformas de codificación en línea como leetcode, como HackerRank están realmente testing? ¿Coinciden bien con las habilidades que necesitas buscar en un candidato? Y por último, profundizaremos en todo el enfoque de la programación en pareja.

Entonces, un poco sobre mí y dónde trabajo. Mi nombre es Muhammad. Soy el jefe de móviles en una empresa llamada Theodo, con sede en el Reino Unido. Theodo es en realidad una consultoría global con más de 600 personas distribuidas en el Reino Unido, Francia, Estados Unidos y Marruecos. Ayudamos a los clientes a construir soluciones digitales para algunos desafíos estratégicos difíciles. Cosas como autoservicio y recorridos minoristas, plataformas de e-commerce para ropa de segunda mano, o construir bancos desafiantes desde cero. Entonces, si estás interesado en aprender un poco más sobre Theodo o simplemente quieres charlar, no dudes en enviarme un mensaje en Twitter. Siempre estoy dispuesto a tomar un café en persona o tener una charla virtual.

A nivel personal, la razón por la que realmente quería dar esta charla fue debido a mi propio viaje al unirme a Theodo. Mi decisión de unirme a la empresa fue en gran medida influenciada por mi propia entrevista de programación en pareja. Fue una experiencia realmente agradable que me empujó a decir que sí y unirme a Theodo y al equipo que tenemos. Entonces, el impacto de esto se siente mucho en mi propia career. Y ahora soy una de las personas que realiza las entrevistas de programación en pareja. Así que, hemos llegado a un punto completo. Y es algo que realmente disfruto. Así que estoy muy emocionado de compartirlo con todos ustedes hoy. Vamos a empezar.

¿Cuál es la importancia de la contratación y el crecimiento? No voy a dedicar mucho tiempo a esto, pero realmente, si lo analizas, puedes dividirlo en tres categorías. Uno es la calidad del equipo. Esto puede parecer muy, muy simple. Pero una alta calidad de contratación conducirá a equipos de mayor calidad. Entonces, sin tener un proceso de entrevista bien pensado y de buena calidad, corres el riesgo de tener falsos positivos. Así que, tal vez contratar a los candidatos equivocados, alguien que no encaja en el equipo o que no tiene las habilidades que estabas requiriendo.

O tendrás falsos negativos. Y eso no significa contratar a los candidatos adecuados. A veces, tener un sistema que no es efectivo te hará perder algunos candidatos realmente buenos que podrían haber sido un activo muy valioso para tu equipo y tu empresa.

En segundo lugar, la reputación de la empresa. Recuerdo cuando era recién graduado y buscaba trabajo, una de las cosas que se mencionaba regularmente entre mis compañeros era que ciertas empresas eran difíciles de solicitar. ¿Por qué perder el tiempo? Tenían cierta reputación de ser un poco difíciles y de no ser procesos agradables para pasar. Y por eso era conocido entre la comunidad estudiantil, probablemente no quieras perder tu tiempo solicitando en ellas o es realmente difícil. El proceso de contratación puede tener impactos realmente positivos y realmente negativos en la reputación de la empresa. Y a lo largo de todo ese proceso de entrevista y contratación, puedes aprovecharlo como una oportunidad para conocer a más ingenieros, aprender sobre las experiencias de las personas, compartir tus propias experiencias. Y es una oportunidad realmente buena para conocer a más personas en toda esa entrevista y etapa de contratación. Así que es bueno para la reputación y también una buena oportunidad para que conozcas a más personas.

Y por último, el costo. Entonces, si estás empezando a considerar ser un EM o un líder técnico, una de las cosas importantes con las que tendrás que lidiar es el costo. Eso incluye desde el costo del pago para el candidato. A corto plazo, está el costo de un equipo sordo que va a entrevistar al candidato. El costo de su tiempo que están invirtiendo para pasar por estas entrevistas con tu candidato, ver si son adecuados o no. Y luego, en el peor de los casos, si el candidato no era adecuado y necesitabas volver a contratar en algún momento, el costo de tener que volver a contratar obviamente también puede ser bastante alto. Así que con todo eso en mente, podemos tener una visión general de por qué es importante la contratación y el crecimiento y por qué debemos centrarnos en esto. ¿Qué debemos buscar en un candidato? Tengo algunos rayos de sol y la figura solitaria para darle este tipo de ambiente grandioso y sagrado. Así que este es un candidato perfecto. Estoy seguro de que en algún momento todos hemos oído hablar de este concepto del desarrollador 10X. Es el desarrollador que puede entregar a 10 veces la velocidad con una décima parte de las líneas de código. Me alegra decir que después de una extensa investigación, he llegado a la conclusión de que el desarrollador 10X es una mentira. Es una fachada total. No existe. Y a lo largo de mi investigación sobre el desarrollador 10X, en realidad encontré esta cita realmente genial que me gustó, que decía que el código se lee cuatro veces más de lo que se escribe. Entonces, si escribes código fácil de razonar, eso se paga dramáticamente en el futuro. Creo que realmente engloba algunos factores clave sobre lo que es importante cuando buscas contratar a un candidato. Quieres a alguien que pueda escribir buen código, código que será mantenible y comprensible por otros, por miembros más senior del equipo, miembros más junior del equipo, y código que en última instancia sea comprensible y razonable por otros en ese equipo. Y eso es lo que hará que esa inversión de 10X valga la pena a largo plazo, porque ese código será revisado y examinado tantas veces en el futuro y en el ciclo de vida de una base de código.

Tomando este concepto del desarrollador 10X, de manera más realista, ¿cuál es el trabajo de un desarrollador de software? Y creo que es muy multifacético. Va más allá de simplemente codificar. Entonces, un buen desarrollador de software debe ser capaz de identificar problemas y descomponer problemas a partir de requisitos y necesidades comerciales. Deben ser capaces de design una solución que resuelva el problema mientras trabajan en un equipo interfuncional y realmente escriben esa solución eficiente en un buen lapso de tiempo. También necesitan ser un poco pragmáticos con el enfoque que toman. Y si estás contratando para un nivel más alto, como un líder técnico o un EM, también hay un aspecto de coaching y gestión. ¿Qué tan bien enseña el candidato a los desarrolladores más junior en el equipo, los capacita, los entrena? ¿Puede el candidato gestionar de manera efectiva el flujo de proyectos con el PM? ¿Puede mantener la calidad del código en una multitud de proyectos? Estos son todos factores que tendrás que equilibrar. Entonces, cuando lo ves en una escala más amplia, una imagen más grande, hay una serie de conjuntos de habilidades que debes considerar cuando estás contratando a un candidato.

Entonces, pensando en eso, veamos las pruebas de codificación en línea. ¿Qué conjuntos de habilidades evalúan las pruebas de codificación en línea? Voy a ser un poco audaz aquí y decir que, principalmente, las pruebas de codificación en línea solo miden de manera efectiva el conocimiento de un candidato sobre algoritmos y estructuras de datos. Estoy seguro de que has pasado por tu parte justa de pruebas de codificación en línea. Mayormente siguen los mismos patterns. Tal vez tengas que invertir una lista enlazada, o tienes que recorrer un árbol de búsqueda binaria y encontrar un nodo específico. La mayoría de estos problemas son muy similares, de hecho, en su naturaleza. Y realmente necesitas familiarizarte con los algoritmos clásicos de COMSCI y el curso de estructuras de datos.

Es muy académico en su naturaleza, y los habrás encontrado si tienes una formación clásica en ciencias de la computación, o los verás en algún momento. Pero implica muchos de los mismos patterns que se repiten una y otra vez. Y además de eso, las pruebas de codificación en línea evalúan tu capacidad para hacerlos bajo una inmensa presión en un corto período de tiempo. Entonces, ¿qué tan rápido puedes implementar realmente esos algoritmos y estructuras de datos para resolver el problema que te dan? Así que realmente, si has estudiado, memorizado los algoritmos, las estructuras de datos, y entiendes el patrón detrás de las preguntas, comienzas a verlos, y lo harás después de un poco de práctica, los resolverás prácticamente sin problemas. Si no me crees, literalmente hay un libro para eso. Así que esto es un elemento básico en la lista de compras de cada graduado. `Cracking The Coding Interview` tiene 189 preguntas de programación y respuestas típicas en estas pruebas de codificación. Es un libro con varios cientos de páginas, y lo recorres una por una, haces los ejercicios. Se siente mucho como si estuvieras estudiando para el SAT o algún tipo de prueba estandarizada, y rápidamente comenzarás a percibir estos patterns. Muy, muy formulista, no muy efectivo para evaluar las cosas de las que hablamos cuando estábamos buscando al candidato perfecto. Y la pregunta en la que debemos pensar es, ¿cuánto de esto es realmente aplicable a un rol de desarrollo de software en el día a día? ¿Con qué frecuencia estás pensando en cómo invertir una lista enlazada? ¿O con qué frecuencia realmente te enfrentas a estos problemas en los que necesitas encontrar la solución más eficiente posible, la solución más eficiente que sea posible? No es algo común en el día a día. Ciertamente no es algo que requiera la mayoría de la atención cuando buscamos contratar a un candidato. Así que hay un desequilibrio. Es una pequeña parte del rol, pero tiene un gran peso en la decisión de qué candidatos pasan y cuáles fallan. Así que hay un desequilibrio entre la contratación y el rol real.

Pasemos a la programación en pareja. Para explicar la programación en pareja, quiero comenzar con lo que no es la programación en pareja. Y la programación en pareja no es esto. No es un candidato que se acerca a un pizarrón, comienza a garabatear algunas notas, y tú, como entrevistador, estás sentado allí mirándolo intensamente. Eso no es programación en pareja. Para un buen ejercicio de programación en pareja, necesitas un problema realista y también necesitas un entorno de codificación realista. Así que comencemos con un problema realista y luego veremos un ejemplo más adelante. No nos vamos a enfocar demasiado en esto ahora mismo, pero quieres tratar de encontrar un problema similar al del mundo real.

Y dentro de ese problema, puedes tratar de encapsular y abarcar cierta lógica, cierto conocimiento que te gustaría evaluar en el candidato. Es realmente importante que el problema sea comprensible y relacionable. Algo que realmente podrían codificar en un trabajo real de día a día. Eso incluye cierta lógica compleja también.

Ahora, cuando hablamos de un entorno de codificación realista, eso significa sin pizarras, sin papel y lápiz, utiliza un editor de código real. Hay tantos entornos de codificación reales geniales que te permitirán trabajar colaborativamente en el código al mismo tiempo. Y esto será lo más parecido al rol diario. Esto es lo que estarán utilizando todos los días cuando comiencen en el trabajo. Algunos ejemplos de esto son CodeSandbox, que es muy popular. También puedes usar la extensión LiveShare de VS Code, y trabajar colaborativamente en un solo archivo o en múltiples archivos al mismo tiempo, y tienes un entorno que compartes, es una gran herramienta para usar. Y realmente te aseguras de darle al candidato lo más parecido a un entorno de codificación real que utilizarían en su trabajo diario.

Y cuando hablamos de un entorno de codificación realista, no solo nos referimos a las herramientas, sino también al estilo de interacción que tienen. Entonces, una pregunta que debes hacer es, en el rol diario, ¿qué sucede cuando un desarrollador se encuentra con un problema difícil? Y quiero que esto se quede en tu mente por un momento. Cuando un desarrollador llega a un punto en su aplicación y está pensando en ello, razonando sobre ello, y se encuentra con un problema un poco difícil, lo que suele hacer es consultar con el equipo, dar un paso atrás, hablar con los demás, obtener su opinión y tratar de llegar a una solución óptima juntos. Ahí es donde entra en juego esa pizarra. Con eso en mente, es muy, muy importante que realmente estés trabajando juntos como parte de esta entrevista de programación en pareja. Deberías estar programando y hablando tanto como ellos. Realmente quieres que sea una sesión de programación en pareja, y esto te permitirá tener una idea de cómo es incorporarlos a tu equipo, ¿cómo es trabajar con ellos? Si se unieran a tu equipo mañana, lo cual es algo genial de saber, como entrevistador, pero también tiene el otro lado, que les da la sensación de cómo es trabajar dentro de tus equipos. Así que eso, para un candidato, es invaluable. Realmente obtienen una prueba o una demostración de cómo sería unirse a tu empresa y a tu equipo.

Así que sin más preámbulos, vamos a pasar a una demostración, y con suerte todo esto comenzará a encajar. El ejemplo que tenemos aquí es un ejemplo bastante sencillo. Es una kata de puntuación de tenis. Y puedes encontrar una recopilación de estos problemas similares al mundo real en diferentes repositorios de GitHub. Este proviene de un catálogo de katas que alguien ha pasado mucho tiempo compilando, así que felicitaciones para ellos. Y tiene varios problemas diferentes con diferentes lenguajes como plantillas para que puedas comenzar a evaluar a las personas. Vamos a repasar el contexto de este juego, y luego haremos una breve demostración en vivo. No será la extensión completa de una entrevista. Y obviamente hay diferentes problemas con diferentes longitudes, diferentes dificultades. Así que realmente puedes elegir lo que creas que es más aplicable a tu proceso de entrevista específico.

Pero en este caso, solo para esta demostración, hemos elegido algo un poco simple para poder revisarlo un poco. Y con suerte, será fácil de seguir. Así que vamos a implementar el sistema de puntuación para el tenis. En un juego de tenis, ambos jugadores comienzan con una puntuación de cero. Y en cada ronda exitosa que juegan, los puntos se suman en una secuencia de cero, 15, 30 y luego 40. Y una vez que estás en la etapa de 40, ganarás el juego si anotas nuevamente, a menos que ambos jugadores tengan una puntuación de 40, lo que se llama empate. Eso significa que estás en algún tipo de punto muerto. Y la forma de ganar cuando estás en un empate es anotar dos veces consecutivas. Entonces, si lograste romper el empate y anotar dos veces seguidas, terminarás ganando el juego. Así que reglas básicas del tenis.

Lo que estamos tratando de hacer es incorporar esto y construir la lógica en torno a esto sin centrarnos en la interfaz de usuario, sin centrarnos en la data validation, solo la lógica básica de esto. Y vamos a intentar hacerlo en un corto período de tiempo para esta demostración. Así que intentemos hacerlo. Antes de hacerlo, quiero que te enfoques en cosas como cuánto interactúo con el candidato en la entrevista. Cuando se quedan atascados, ¿me piden ayuda? Si no entienden algún tipo de sintaxis, ¿se sienten lo suficientemente cómodos como para preguntarme como entrevistador, cómo se establece una variable en este lenguaje? ¿Dan un paso atrás antes de intentar un enfoque y consideran todas las diferentes opciones, razonan al respecto, piensan en los pros y los contras? ¿O simplemente siguen el primer camino que ven? ¿Qué tan receptivos son a los comentarios, si les doy pistas? ¿Las toman y las investigan? ¿O simplemente las ignoran y continúan con lo que estaban haciendo? Y por último, ¿están creando soluciones demasiado complicadas o van por soluciones simples, tratando de ser pragmáticos? Estas son todas cosas que debes tener en cuenta. Y son cosas que te darán una buena indicación de cómo es esta persona en términos de sus habilidades de desarrollo de software y, en general, cómo es trabajar con ellos.

Así que tenemos a mi buen amigo, Sadik, aquí con nosotros, que amablemente ha aceptado hacer esta demostración. Gracias Sadik por tu tiempo con nosotros. No hay problema, un placer. Genial, tenemos un entorno de Live Share de VS Code configurado. Hay una clase de tenis, hay algunas pruebas, y vamos a seguir el estilo de programación TDD, vamos a crear más pruebas, hacer que pasen, y luego haremos una ronda de refactorización. Pasaremos por una ronda para esta demostración. Obviamente, harías una prueba completa si estuvieras entrevistando a alguien. Entonces, Sadik, ¿deberíamos pasar a la siguiente prueba? Tenemos pruebas para manejar un nuevo juego, un juego de un solo punto y un juego nivelado. ¿Qué crees que deberíamos testing a continuación? Supongo que esto maneja una puntuación bastante básica. Podríamos manejar una victoria a continuación. Genial. Hagamos un caso de prueba para eso. Genial. Adelante.

Y para ganar, anotarán cuatro veces, solo para llegar hasta el final pasando un 40. Pasado el 40. De acuerdo, genial. ¿Y qué esperamos que sean los resultados reales de la cadena de puntuación obtenida? Sí. Cambiemos eso a... Así que este es el segundo jugador al que le he dado una victoria. Así que hay dos victorias. Hagámoslo. Y supongo que sí, la forma más rápida sería devolverlo aquí de alguna manera. De acuerdo. Entonces, una victoria... Bueno, necesitamos representarla realmente en código. Así que hay un par de formas en las que podríamos hacerlo aquí. Una sería en la puntuación, como después del 40, sé que esa es la puntuación más alta que se puede obtener. Podríamos tener un valor por encima de eso solo para representar, ya que estamos recorriendo cada índice aquí, podríamos tener un último elemento que represente una victoria o podemos tener algún tipo de estado en la clase. Eso está bien.

Así que retrocediendo un poco aquí para la audiencia, es realmente bueno... Sadiq está retrocediendo, mirando las diferentes opciones que puede tomar con esto. Es una muy buena señal, está hablando en voz alta. Puedo entender completamente lo que está pensando. Así que voy a tratar de contribuir un poco a esta entrevista ahora. Entonces, sí, eso me parece bien. Supongo que pensemos en los pros y los contras de cada enfoque. Si usáramos una bandera, tendríamos que hacer comprobaciones en varios lugares dentro de la funcionalidad de puntuación. Y luego tener algunas declaraciones condicionales para no incrementar la puntuación como lo estamos haciendo ahora. Eso podría tener cierta complejidad. El otro lado es representar un valor falso en la puntuación, como dijiste. Pero entonces no te estás apegando a la lógica real. No son puntuaciones de tenis. Así que supongo que con esas compensaciones en mente, ¿qué crees que deberíamos hacer? Bueno, para obtener la solución más rápida, solo el paso más rápido para esta prueba, probablemente sea más fácil ir por un valor. Y luego, si queremos volver, obviamente podríamos refactorizarlo. Sí, podríamos volver. Así que avísame qué debo escribir, y yo usaré el teclado.

Entonces elijamos un valor, cualquier cosa por encima de 40. Hagamos 60 para... Oh, Dios. No me gusta eso. De acuerdo, genial. Tenemos un auto eficiente en tenis aquí, así que, de acuerdo. Hemos agregado un valor de 60 a esta matriz. Bien. Y luego, GetScoreString, supongo que deberíamos verificar la puntuación. De acuerdo. Si es igual a 60 para cada jugador, entonces si this dot, sí, puntuación del primer jugador, puntuación del segundo jugador. Si es 60, queremos devolver una cadena que diga algo como Player1Wins, ¿verdad?, siguiendo el patrón que has establecido allí. De lo contrario, comprobamos, veamos, de acuerdo, ¿ha ganado el segundo jugador? Y luego, en ese caso, también devolveríamos Player2Wins. Todos los errores tipográficos. De acuerdo, genial. Así que hemos tomado una nueva prueba y originalmente estaba fallando. Lo hicimos pasar. Ahora hemos llegado a la etapa de refactorización. Entonces, Sadiq, ¿hay algo en la clase de tenis o en la prueba que hayamos escrito que te gustaría refactorizar o limpiar? Sí, supongo que la primera parte del código que veo que se repite está dentro de la función de puntuación, donde estamos calculando el índice de la próxima puntuación. Estas son líneas largas. Tal vez podríamos llevarlo arriba, ponerlo en una función. Hagámoslo, inténtalo. Claro. Entonces, ¿alguna sugerencia de nombre? Bueno, si le damos un nombre semántico, está obteniendo el índice de la próxima puntuación en la línea 14 y 18. Entonces, ¿por qué no lo llamamos así? Claro, y tomaremos la puntuación. ¿Tomamos al jugador? O podemos tomar la puntuación actual, lo que sea. Claro, solo tomaremos la puntuación. Genial. Y a partir de eso, estamos poniendo esta parte aquí. Mientras Sadiq trabaja en eso, esto es bueno para los nombres, para las cosas en las que quería sugerencias, se sintió cómodo preguntándome, esa es una buena señal.

Demuestra que se siente cómodo al pedir ayuda o solicitar pistas cuando las necesita. Así que eso es una buena señal.

Genial, entonces, esa función está ahí. Probablemente deberíamos devolver, sí, y luego podemos simplemente llamar a eso en lugar de hacer esa larga búsqueda de scoring.findIndex en cada línea.

Entonces, aquí está la prueba. Genial. Y luego podemos simplemente copiar esto, hacerlo de nuevo para el segundo jugador. Suena bien. Bueno.

Entonces, hemos tomado eso. Lo hemos refactorizado, guardémoslo y veamos si la prueba sigue pasando. Increíble.

Otra cosa también, creo, en el lado de las pruebas, tenemos bastante repetición aquí, como estamos lanzando, estamos puntuando varias veces para cada uno de ellos. Podríamos ponerlo en un bucle, especialmente para este donde sucede cuatro veces. ¿Qué piensas, Sadik?

Sí, hagamos un bucle cuando sea cuatro o más. Creo que se está volviendo un poco pesado. Hagámoslo. Entonces, crearemos un bucle aquí, I es menor que cuatro, lo incrementaremos, y luego iteraremos aquí y nos desharemos de eso. Genial. Tenemos nuestras pruebas pasando. Nuevamente, hemos refactorizado ambos archivos. Estamos en un buen estado, hemos hecho un bucle del ciclo rojo-verde-refactorizar en TDD, puedes construir sobre esto en un ejercicio real. Pero nos detendremos aquí solo para mantener el ejemplo corto y simple.

Es un problema realmente interesante, te recomendaría que lo intentes, este problema del tenis, se vuelve realmente interesante una vez que tienes empates y estás tratando con las ventajas y demás.

Muchas gracias, Sadiq, por tomarte el tiempo con nosotros.

No hay problema. Gracias.

Entonces, concluyamos. Quiero dejarte con algunas reflexiones finales. Estas son cosas que suelo hacer antes y después de las entrevistas, creo que realmente dejan una buena impresión en el candidato.

En primer lugar, no te lances directamente de inmediato. No quieres tener solo una introducción simple y luego pasar al ejercicio. Recomiendo tomar un poco de tiempo, tratar de conocer al candidato. Hay mucho valor en entender su historia, sus ambiciones, cómo es conversar con ellos, y no subestimes lo bueno que puede ser para aliviar al candidato y, con suerte, brindarte un mejor ambiente para llevar a cabo la entrevista de programación.

En segundo lugar, tómate un poco de tiempo al final, revisa la solución que han creado juntos y ve si pueden encontrar mejoras y si puedes hacer que el candidato critique su propio trabajo. Es una buena señal cuando un candidato está dispuesto a criticar o señalar aspectos que faltan en su solución. Así que recomendaría tomarse un poco de tiempo al final, un par de minutos para hablar sobre ello.

Y por último, pide su feedback. Les brinda una buena oportunidad para darte puntos de mejora, pero también para hablar sobre cómo fue su experiencia. Y hablando de experiencia, quiero terminar con esta nota. Hace un tiempo tuvimos un candidato que se postuló con nosotros. Desafortunadamente, no fue seleccionado, pero recibí este correo electrónico unos días después. Y solo quiero dejarlo ahí por un segundo. Mensajes como este hacen que esta entrevista de programación en pareja sea genial a mis ojos. Es una sensación agradable cuando como entrevistador sientes que no has desperdiciado una hora del tiempo del entrevistado, y recibir su respuesta diciendo que sienten que realmente han aprendido algo o que tuvieron una experiencia agradable es algo que realmente ha valido la pena para todos nosotros. Y espero que en las entrevistas que realice en el futuro, pueda dejar una experiencia similar en los demás. Muchas gracias por escuchar.

Sí, fue como una batalla hasta hace unos minutos, hace unos segundos, verifiqué y era 46 y 46. Ahora, la opción no tiene el 56%. ¿Cómo te sientes al respecto?

Para empezar, estoy bastante contento de que la mayoría de las personas hayan abandonado las pruebas de codificación. Es genial verlo y espero que ese número aumente con el tiempo. Los `sí` todavía representan aproximadamente un tercio, alrededor del 32 o 33%. También me interesa ver para qué lo usan las personas. Entonces, las personas que aún utilizan pruebas de codificación, ¿en qué etapa de la entrevista se utilizan? ¿Es una parte fundamental o es parte de un filtro de selección? Pero sigue siendo una cantidad considerable, ¿verdad? Uno de cada tres trabajos a los que te postulas probablemente tendrá una prueba de codificación, lo que significa que se invertirá mucho tiempo en eso.

Sí, sí. Tiempo que hoy en día podría haberse invertido de manera mucho más efectiva en cosas más prácticas. Porque la energía en un proceso de contratación, y mencionaste en la charla, cuánto tiempo cuesta la entrevista para el proceso de contratación. Sí. Por cierto, el otro día fue muy popular el costo de las reuniones, ya sabes, en Google, el calendario falso y el costo de las personas. Deberíamos hacer eso después del proceso de contratación al final. ¿Cuántas personas de nuestro equipo de ingenieros hicieron la entrevista y cuánto nos costó? Sí, sí. Especialmente estando en un entorno de consultoría, sabes, es un factor clave allí. Así que definitivamente piensa en el costo del tiempo de cada persona individual también.

Comenzaré con una pregunta rápida. Alguien preguntó cómo se llamaba nuevamente el ejercicio de codificación, ¿kata de puntuación de tenis o algo así en tu charla? Sí, este tipo de problemas generalmente se llaman katas. Hay un repositorio completo en GitHub con, ya sabes, docenas de ejemplos de ellos, puedes encontrar uno que se adapte a ti y a tu estilo. Este en particular se llama kata de puntuación de tenis. Así que si lo buscas, deberías encontrar un repositorio de GitHub al respecto. Bien. De acuerdo, eso está resuelto. La segunda pregunta que recibimos fue sobre cómo encontraste que el Método de Programación en Pareja se adapta a la experiencia de los candidatos.

Sí, eso también es muy interesante. Entonces, si estás contratando, digamos, a nivel de recién graduado, lo que realmente estás buscando no es algo como experiencia con la sintaxis o muchas de las cosas que esperarías con la experiencia. Lo que estás evaluando más es la comunicación, eso es lo fundamental que deseas, y qué tan rápido pueden comprender conceptos, cuánto están dispuestos a aprender, porque ese es el career. Y eso es lo que están tratando de aprender. Si estás evaluando y haciendo una entrevista de programación con alguien que quiere ingresar a un nivel de liderazgo técnico o a un nivel de ingeniero senior, entonces tendrás que buscar otras cosas. La comunicación es importante, pero también es cómo explican estos temas. Y realmente tienes que ver si pueden encajar en ese rol de liderazgo y mentoría. Entonces, tal vez como entrevistador, te retires un poco y les des más libertad para dirigir la entrevista.

Y a partir de eso, puedes tener una idea, si fueras un desarrollador junior, trabajando con un desarrollador senior o con un líder técnico, ¿cuál sería el estilo de trabajo con ellos? Así que es muy ajustable. También puedes elegir problemas más difíciles si estás tratando de contratar a un desarrollador senior. Hay tantos de estos CADAs con diferentes requisitos y diferentes complejidades. Así que es muy adaptable, diría yo.

Sí. Y como mencionaste, la comunicación, he escuchado que al menos algunas empresas hacen esto como una prueba de una semana o incluso más o menos, la persona se integra en el equipo y literalmente tiene un trabajo porque esa es la parte de comunicación que se ve. Haciendo preguntas, depurando de alguna manera, ya sabes, incluso el proceso en la nueva empresa.

Sí. La segunda pregunta que recibimos fue sobre el candidato senior, y es como, encontré que con los candidatos más senior, la habilidad en la que estamos interesados puede ser trabajar en escalas más grandes y no siempre se presta a mirar código juntos. Los ejemplos serían architecture y organización para proyectos verdes. ¿Qué piensas, cómo se sentiría este formato con un rol de clase de personal para ti?

Claro. Así que en realidad, puedo darte una idea de cómo manejamos esto. Entonces, como parte de esto, tenemos esta entrevista de programación en pareja, creemos que sigue siendo fundamental para contratar a un líder técnico o a un gerente de ingeniería. Pero además de eso, tal vez agreguemos una entrevista de design arquitectónico también. Y la idea es, bueno, también necesitamos evaluar cómo pueden tomar decisiones arquitectónicas. Cómo crearán sistemas e integrarán diferentes partes de una aplicación. Y creo que puedes agregar eso. Pero esta entrevista de programación en pareja sigue siendo bastante importante, especialmente porque creo que hemos aprendido a lo largo del día de hoy que un líder técnico y un gerente de ingeniería tienen como tarea interactuar con las personas, comunicarse, empatizar con el equipo, enseñarles cosas. Así que creo que sigue siendo una parte fundamental. Si quieres ajustar la entrevista de programación en pareja, una sugerencia podría ser dar un paso atrás y antes de comenzar la entrevista, preguntarles en general sobre un problema más complejo. Digamos que puedes tener un problema, como cómo manejar el inicio de sesión en general, y ver cómo pueden explicar esos conceptos más fundamentales también. Así que ese es otro paso que puedes agregar antes de comenzar realmente la entrevista de programación en pareja. Sí, y puedes ajustarlo. Como mencionaste, es muy fácil ajustarlo para agregar otros niveles u otros pasos que consideres buenos para el equipo e incluso más, hacerlo específico para cada rol, cada equipo y el nivel al final. Sí. Oh, eso fue realmente esclarecedor, y aprendí mucho. Nuevamente, volveré y veré cuánto tiempo dediqué a las pruebas y la programación en pareja. Lo hacemos, cómo podemos ajustarlo más para encontrar el ajuste perfecto, especialmente hoy en día que, sí, el panorama tecnológico está cambiando mucho. Las cosas cambian tan rápido, y definitivamente queremos tener el ajuste perfecto para nuestros propios candidatos. Muchas gracias por los conocimientos hoy, Charitas. Gracias por recibirme.