He entrevistado a más de varios cientos de candidatos en Zynga. Durante un par de años estuve promediando 3-4 por semana. Cuando Zynga todavía estaba en su fase de inicio, solíamos tener un escenario de entrevista conocido como “El problema del póker”
Hasta el día de hoy, esta es mi forma favorita de examinar a un candidato, aunque desde que Zynga ha crecido hemos tenido que eliminar este método. Es un desafío divertido, y me gusta trabajar con personas que disfrutan de un buen desafío técnico.
Escribí un artículo completo sobre él y lo publiqué en mi blog hace aproximadamente un año. El enlace es el siguiente: la pregunta de la entrevista de póker
El contenido de la publicación también está debajo para que pueda leerlo. Es realmente una forma agradable de realizar una entrevista y realmente entrar en las habilidades básicas de los candidatos.
Configuración básica
Le proporcionaríamos al candidato una computadora portátil que realmente no tiene nada instalado. Es importante asegurarse de que el candidato no tenga acceso a Internet. Proporcione al usuario un bloc de notas y luego una interfaz de línea de comandos junto con un mensaje para ejecutar su código. Asegúrese de antemano que PHP o cualquier idioma en el que esté probando esté configurado para ejecutarse.
Sienta al candidato con la computadora portátil y repasa el problema con ellos en una pizarra. También proporcionamos una versión de texto del problema para que pudieran volver a leerlo para comprender claramente el objetivo.
Reglas de póker
Es importante tener en cuenta que si el candidato no tiene experiencia con el póker, entonces esta probablemente no sea una prueba justa para ellos. Si proporcionas suficiente instrucción, deberían (como ingenieros competentes) programar cualquier juego que les des, pero durante una entrevista siempre querrás eliminar tantos bloqueadores como sea posible. O tal vez no … depende de usted y su empresa.
Explique al candidato que está trabajando en un equipo que controla un juego de póker. El juego es el típico póker de 5 cartas, sin variaciones especiales. Proporcione un conjunto básico de reglas al candidato. Esto incluye una regla de rango de manos. En esencia, las manos se clasifican de las más altas a las más bajas como: Escalera real, Escalera de color, 4 de un tipo, Full House, Flush, Recta, 3 de un tipo, 2 pares, 1 par y luego carta alta. También explique que el póker también se clasifica por palo en caso de empate: picas, corazones, clubes y luego diamantes.
El “problema del póker”
Explique al candidato que su objetivo es programar un algoritmo que simule el final de un partido de póker y determine un ganador. En concreto, deben tomar N número de manos, averiguar cuáles son las manos (color, escalera, nada, etc.), clasificarlas todas y determinar qué jugador ha ganado.
El candidato puede configurar esto de la forma que desee, solo asegúrese de que al final del algoritmo se proporcione un ganador (y es el ganador correcto).
Supuestos
Puede explicarle al candidato que existen ciertas suposiciones bajo las cuales puede trabajar.
- El candidato puede dictar cómo se verá la entrada en el algoritmo. Algunos candidatos decidirán utilizar un enfoque OOP y pasar objetos del tipo “Mano” que contienen 5 objetos del tipo “Tarjeta”. Otros candidatos simplemente pueden pasar arreglos, listas, etc. La parte crítica es permitirles elegir (no darles pistas) y asegurarse de que puedan explicar racionalmente por qué eligen ese formato.
- El candidato también puede dictar cómo debe verse la salida del algoritmo. Algunos candidatos querrán devolver una lista completa de quienes obtuvieron el segundo lugar, el tercer lugar, etc. Otros simplemente devolverán un índice de la mano ganadora, etc. Una vez más, la parte crítica es permitir que el candidato elija y luego asegurarse de que explicar racionalmente por qué hicieron su elección.
- Estás jugando póker estándar de 5 cartas. No hay comodines, las 5 cartas que se envían son estáticas. Solo se usa 1 mazo de cartas, etc.
Crédito adicional
Puede explicarle al candidato que existen varias oportunidades de “crédito adicional” con este problema. Cada uno de estos debe controlarse dentro de un archivo de configuración para que puedan encenderse y apagarse fácilmente. Algunos de estos incluyen:
- Asegurarse de que el código esté escrito de manera que pueda manejar 1 tarjeta WILD. ¿Cómo manejarían las pruebas de posibles manos con un comodín?
- Asegurarse de que el código sea compatible con el póker Texas Holdem, que acepta 7 cartas y devuelve la mejor mano de 5 cartas.
- Asegurarse de que el código sea compatible con varias barajas de cartas, como si fuera en Las Vegas y se estuvieran usando 5 barajas de cartas a la vez.
Periodo de tiempo
Les damos a los ingenieros 2 horas para realizar este problema. La clave es que los dejamos solos durante las 2 horas. Explique al candidato que cuando hayan transcurrido las dos horas se les pedirá que muestren su código y expliquen cómo funciona.
Se ofrecen 2 puntos de control a lo largo de la ventana de tiempo. Los puntos de control están diseñados para ser interacciones rápidas de 1-2 minutos para garantizar que el candidato no esté bloqueado o tenga alguna pregunta. El primer punto de control se realiza aproximadamente 30 minutos después de que comienza el ingeniero. Algunos candidatos querrán tomar notas o planificar cómo programar el problema. En general, durante la primera revisión, simplemente les hace saber que han transcurrido 30 minutos y, si aún no han comenzado a programar, deberían comenzar. El segundo punto de control es aproximadamente una hora más tarde cuando solo quedan 30 minutos. Este es más un recordatorio de un punto de control para informarles que solo les quedan unos 30 minutos.
Análisis
Cuando hayan transcurrido las 2 horas, ahora es el momento de hacer el análisis del código escrito. Cuando entro a hacer el análisis, generalmente le doy al candidato unos 30 segundos para que termine lo que sea que esté trabajando, pero trato de no darle más que eso.
Primero les pregunto cómo les fue. ¿Qué fue fácil? ¿Qué fue desafiante? Les pregunto cómo fue programar en este entorno y bajo este tipo de “estrés”. Esto es clave ya que la mayoría de los entornos de programación operan bajo algún tipo de estrés. ¿Cómo les fue?
Luego les pido que expliquen un alto nivel de la solución que decidieron tomar. Si hay una pizarra disponible, les pediré que mapeen el flujo de datos a medida que pasan a través de su algoritmo. Intento hacer tantas preguntas sobre por qué eligieron ciertas direcciones. También trato de pedirles que expliquen qué sucederá con su código o algoritmo una vez que se ponga a escala.
A continuación, les pediré que me guíen por su código. Esto es más una inspección visual de sus habilidades de escritura de código. ¿Usaron comentarios? ¿Usan código abreviado? ¿Está bien organizado con un flujo lógico?
Tenga en cuenta que las preguntas que haga durante la fase de análisis le darán más información sobre cómo se desempeñará ese candidato en su empresa que cualquier otra pregunta de la entrevista, simplemente porque realmente está evaluando su propio código original. Use su tiempo sabiamente y evalúe su trabajo como si ya fuera un miembro de su equipo y estuviera realizando una revisión de código.
Gotchas
Una cosa que me encanta de este proceso de entrevista es que ofrece varias oportunidades para que los candidatos brillen o fracasen.
Un problema clásico es si el candidato pasa por alto o no. Muchas veces, un candidato se criticará creando una estructura de datos muy elaborada o un marco de código. Este candidato perdió de vista el objetivo general (para decirme quién ganó) porque el candidato estaba tratando de impresionarme con su amplio conocimiento de código. Esto le dará a usted como entrevistador una muy buena idea de cuánta dirección y supervisión necesitará el candidato regularmente con sus tareas de programación.
Otro problema común es si el código tendrá un rendimiento a escala o no. Esto a menudo se relaciona directamente con las experiencias a las que el candidato ha estado expuesto. Los candidatos con menos experiencia tienden a hacer soluciones que han anidado profundamente las declaraciones if o bucles. Los candidatos que han escrito código de escala de producción a menudo proporcionan soluciones que están modularizadas con funciones limpias o pasos que separan las diversas tareas de programación.
El crédito extra proporciona otra trampa. Algunos ingenieros buscarán el crédito adicional antes de terminar la tarea asignada real. En algunos casos, terminan fallando en entregar el resultado como un todo. Siempre soy un fanático de darles a los ingenieros tanto objetivos explícitos como objetivos extensos que perseguir, pero no ser capaz de concentrarse en la tarea principal puede decirle que el ingeniero puede tener problemas para concentrarse y puede necesitar chequeos constantes en sus resultados asignados .
Mi gotcha favorita es durante la fase de explicación. Un ingeniero con el que no puede comunicarse no es un ingeniero con el que desea trabajar regularmente. Si el candidato no puede explicar qué escribió exactamente (si es una buena solución o no), generalmente es una buena indicación de si esa persona debe ser contratada o no.
Conclusiones
Puedo decir honestamente que usar esto como el proceso de entrevista SOLE para un candidato ha dado algunos de los mejores ingenieros con los que he trabajado. Tuvimos aproximadamente una tasa de abandono del 20% con este proceso de entrevista. Tuvimos varias personas que simplemente salieron del edificio después de darse una hora o más para resolver el problema. Para ser honesto, me alegré, ya que claramente no eran los ingenieros con los que me gustaría trabajar. También tuvimos otros ingenieros que pudieron proporcionar una solución ingeniosa a la que le dimos la vuelta y ofrecieron ofertas de trabajo en el acto. Hasta el día de hoy, son algunos de los mejores ingenieros que he reclutado.