Hablemos de entrevistas en pizarra y las posibles alternativas

No es ninguna novedad para nadie que muchos ingenieros odien las preguntas de entrevista basadas en pizarrones.

Ya sea en Twitter, Medium o LinkedIn, es fácil encontrar a alguien que se desahogue. La frase "el proceso de contratación está roto" se usa con tanta frecuencia que se ha convertido en un cliché.

Desafortunadamente, gran parte de esta frustración cae en oídos sordos.

A pesar del coro de ira que lo rodea, la "pizarra" sigue siendo un elemento básico en las entrevistas de ingeniería de software. Parte de eso se debe al hecho de que los desarrolladores expresan rápidamente su resentimiento, pero son lentos para ofrecer mejores alternativas.

¿Existen mejores alternativas?

Esta pregunta ha estado en mi mente mucho últimamente. Hace cuatro semanas, conseguí mi primer trabajo de ingeniería de software a tiempo completo. Si bien aún no estoy involucrado en el proceso de contratación, eventualmente lo estaré.

Habiendo estado del otro lado de la mesa hace apenas un mes, comprendo cuán imprecisas pueden ser las entrevistas. Cuando sea mi turno de hacer las preguntas, quiero asegurarme de evaluar a mis posibles colegas con precisión y equidad.

Esta situación me ha llevado a dos preguntas:

  1. ¿Son las entrevistas de pizarra la mejor opción?
  2. Si no es así, ¿cuáles son las mejores alternativas?

En esta publicación, intentaré responder estas preguntas. Tenga en cuenta que estas son mis opiniones personales que han sido moldeadas por mi propia experiencia en entrevistas.

Trataré de ser lo más objetivo posible al abordar esta tarea de la manera más auténtica de la ingeniería de software: examinar todas las opciones y sopesar sus compensaciones.

¿Son las entrevistas de pizarra las peores?

El primer paso en este proceso es examinar la pizarra.

Pros:

  1. Rápido y con poco esfuerzo
  2. No depende del idioma ni del dominio
  3. Sabes (generalmente) que esperar
  4. Soporte de la comunidad (Glassdoor, LeetCode, Pramp, etc.)

Contras:

  1. La suerte es un factor importante (lotería de algoritmos)
  2. No prueba necesariamente la aptitud en ingeniería
  3. Favorece a los ingenieros jóvenes y a los recién graduados

Para las empresas que requieren que los ingenieros tengan un gran conocimiento de los fundamentos de la informática, los algoritmos de bajo nivel y que no dependen de las bibliotecas, la entrevista de pizarra es perfecta.

SpaceX, MacOS / Windows y React de Facebook fueron construidos por ingenieros con ese conocimiento. Es de esperar obtener una entrevista de pizarra de una de estas empresas.

Como candidato a un puesto, me encantan las entrevistas en pizarra. Sé qué esperar. La mayoría de las preguntas sobre algoritmos se incluyen en estos temas generales:

  • Matrices / Cadenas
  • Árboles binarios
  • Listas vinculadas
  • DFS / BFS
  • Retroceso
  • Programación dinámica

Saber esto de antemano significa que puedo estudiar para ello. Y hay una gran cantidad de herramientas de estudio para elegir. La preparación de entrevistas técnicas es toda una industria en sí misma.

Es por eso que las entrevistas en pizarra no son la mejor opción para todas las empresas. Gran parte de esto se debe a la suerte, la memorización y a quien haya pasado más tiempo estudiando.

No todo el mundo puede estudiar durante mucho tiempo para dominar los algoritmos.

Tuve suerte de poder y superé a otros ingenieros que no pudieron. ¿Soy mejor ingeniero que todos ellos? Tal vez, pero no estoy seguro de que una entrevista en pizarra sea el mejor medio para revelarlo.

Entonces, si hay dudas de que la entrevista de pizarra es la mejor herramienta para el trabajo, ¿qué podría ser mejor?

Echemos un vistazo a algunas de las alternativas.

Desafíos de codificación por computadora

Pros:

  1. Empiece a utilizar una computadora y un entorno de desarrollo familiar
  2. Se puede hacer de forma remota a través de compartir pantalla
  3. Todas las demás ventajas de las entrevistas en pizarra

Contras:

  1. Más estricto sobre la sintaxis y la capacidad de ejecución.
  2. El entorno de programación y los complementos pueden jugar un papel importante
  3. Las mismas desventajas de las entrevistas de pizarra

Los desafíos de codificación en una computadora portátil son el primo menos riguroso de la entrevista de pizarra.

Los candidatos tienen la ventaja de utilizar sus propias computadoras. Se pueden hacer de forma remota o en un entorno de programación en pareja.

Una cosa buena que he notado sobre estos es que generalmente serán más fáciles que las preguntas de pizarra. La mayoría de las preguntas que me planteé estaban relacionadas con la manipulación de cadenas o algoritmos simples que ningún ingeniero experimentado no necesitaría estudiar.

El inconveniente de esto es que se pone mucho más énfasis en la funcionalidad.

Durante mi búsqueda de trabajo, me preguntaron dos veces el problema del cambio de moneda. Uno como un desafío de pizarra y el otro en un editor.

Para el desafío de la pizarra, me salí con la mía explicando principalmente mi solución. En mi computadora portátil, se esperaba que escribiera pruebas de casos extremos y garantizara que mi solución funcionaba.

Parte de la razón por la que me gusta la pizarra se debe a la indulgencia. Nadie va a ejecutar su función escrita a través de un compilador. Siempre que el entrevistador entienda lo que estás pensando y la redacción se vea lo suficientemente buena, obtienes todo el crédito.

No es así con los desafíos de código.

Algunos pueden argumentar que el énfasis en la funcionalidad es mejor, porque nos pagan por escribir código que funcione. Eso es cierto, pero no nos pagan por hacerlo en sprints de 30 a 45 minutos.

Esperemos que no se ponga nervioso durante las entrevistas. Un pequeño error que provoca que las pruebas fallen y varios minutos de depuración podría ser la diferencia entre una "contratación fuerte" o una aprobación.

Los desafíos de código todavía tienen las mismas deficiencias que la pizarra porque muchos de ellos están basados ​​en algoritmos.

Con la presión adicional de la funcionalidad, puede hacer que las preguntas sean aún más difíciles a pesar del cómodo entorno. Si ya no le gustan los problemas de algoritmos, los desafíos de código no serán mucho mejores.

Llévate las evaluaciones a casa

Pros:

  1. Puedes trabajar en tu pijama
  2. Generalmente se le da más de una semana para trabajar en una asignación
  3. Utilice su propio editor y entorno de desarrollo
  4. Puede ser una nueva incorporación a la cartera
  5. Suele ser más divertido que la pizarra

Contras:

  1. El nivel de dificultad puede variar drásticamente
  2. Mucho más esfuerzo y tiempo que los desafíos de codificación
  3. Puede depender del dominio
  4. Puede provocar que las características se pierdan debido a la competencia
  5. No representa el trabajo diario

Muchos ingenieros prefieren las tareas para llevar a casa. Los plazos para entregarlos suelen ser flexibles y los candidatos pueden codificar realmente. No es de extrañar que los programadores prefieran esto a pararse frente a una pizarra mientras son juzgados en silencio.

Sin embargo, las pruebas para llevar a casa tienen algunos inconvenientes importantes.

En primer lugar, son fáciles de manipular.

Muchas empresas alojan sus pruebas en GitHub. Escriba "Desafío" o "Prueba" en la búsqueda de GitHub y encontrará muchos. Esto le dará al candidato inteligente suficiente tiempo para investigar el desafío de manera preventiva.

Eso no es realmente una queja. Simplemente más un consejo profesional.

Lo que es un problema es que es bastante fácil de encontrar respuestas de otras personas a estos desafíos y copiarlos. Muchos ingenieros guardan las respuestas para llevarse a casa los desafíos en sus perfiles de GitHub.

Incluso puedes probarlo tú mismo. Escriba "Desafío" en la búsqueda de GitHub y vea lo que encuentra.

Vivo junto a la sede de Etsy en Brooklyn y tenía curiosidad por saber si podía encontrar las respuestas a algunas de sus pruebas. "Etsy Challenge" reveló cuatro. Había incluso más en "Prueba de Etsy".

Es cierto que las empresas pueden cambiar sus valoraciones. Sin embargo, puede ser complicado cambiar un proceso de entrevista cada dos meses debido a la filtración de detalles.

En segundo lugar, el nivel de dificultad y el tiempo que se necesita para completar estos desafíos varía ampliamente.

Durante mi última búsqueda de trabajo, me dieron cuatro tareas para llevar a casa. Tres de las empresas dijeron que solo deberían tardar entre 3 y 5 horas en finalizar.

Todos me tomaron varios días.

La razón principal de esto fue que los desafíos a menudo eran específicos de un dominio. Necesitaron varias horas de investigación de documentos API y nuevas tecnologías.

La cuarta empresa aceptó un desafío que fácilmente podría llevar una semana y me dio dos días. Tuve que crear una aplicación de chat que funcionara y que admitiera comandos de barra.

Fue un proyecto divertido e interesante, pero me obligó a dejar todo lo que estaba haciendo durante dos días para completarlo.

Si un candidato tiene la suerte de entrevistarse con varias empresas a la vez, puede convertirse en un trabajo de tiempo completo simplemente trabajando en estos desafíos.

Además, los desarrolladores profesionales tienen que trabajar en bases de código heredadas y lidiar con los plazos. Un proyecto totalmente nuevo de una semana no va a evaluar qué tan bien trabaja el entrevistado en un entorno de ritmo rápido.

En general, me gustan las tareas para llevar a casa como una pantalla inicial de la capacidad de un candidato. Dicho esto, deben estar relacionados con el trabajo que solicita el candidato y no deben tomar una cantidad de tiempo obscena para terminar.

Basado en proyecto / contrato para contratar

Pros:

  1. Tener la oportunidad de trabajar con el candidato / equipo
  2. Cobrar por trabajar
  3. Ponte manos a la obra en proyectos reales
  4. Son evaluados sobre qué tan bien trabaja con el equipo y el código de envío

Contras:

  1. Compromiso a largo plazo
  2. Trabajar sin garantía de empleo
  3. Sin beneficios para la salud como contratista
  4. Puede poner al candidato en una mala posición de negociación
  5. Depende del idioma

Las entrevistas basadas en proyectos son raras. Pero hay bastantes empresas que los apoyan, como Basecamp y Automatic. Puedo entender por qué.

Estas entrevistas son probablemente la forma más precisa de evaluar la habilidad de alguien y evaluarlo como miembro del equipo. La empresa trabaja directamente con ellos y ve cómo manejan las tareas en equipo.

El candidato también tiene la oportunidad de evaluar la empresa y determinar si es el tipo de entorno en el que le gustaría trabajar.

Ganar-ganar. O eso parece.

Dicho todo esto, como candidato a un puesto de trabajo, nunca participaría en entrevistas basadas en proyectos o roles de contrato para contratar. Los aspectos negativos superan con creces los aspectos positivos.

Los primeros meses de cualquier trabajo suelen ser los más difíciles. Te estás aclimatando a un nuevo equipo, cultura, código base. Ahora imagine trabajar en un proyecto sin saber si tendrá un trabajo al final.

Un buen amigo mío se entrevistó recientemente en Automatic y confirmó lo estresante que puede ser. Se juzga todo, desde la forma en que interactúa con los compañeros de trabajo hasta las preguntas que hace. En estos entornos, no es tal cosa como una “pregunta estúpida.”

Lo peor es que lo despidieron después del contrato de tres meses. Afortunadamente, no ha dejado que eso afecte su autoestima. Conoce su habilidad y se adelanta. No estoy seguro de si yo, o muchos otros ingenieros, podríamos hacer lo mismo tan fácilmente.

Además, los contratos ponen al solicitante de empleo en una pésima posición de negociación. La fuerza en las negociaciones proviene de la voluntad de alejarse.

Al final de un período de contrato de contratación, el candidato potencial no tendrá ninguna moneda de cambio. No tendrán otras ofertas y ya han invertido decenas o cientos de horas en sus proyectos, dependiendo de la duración del contrato.

Se sentirían incentivados para tomar el puesto incluso si no es su opción preferida. La alternativa es volver a incorporarse al mercado laboral desde el principio.

La falacia del costo hundido en su máxima expresión.

Si bien las entrevistas de pizarra pueden no ser ideales, haría un centenar de ellas antes de hacer una entrevista basada en proyectos.

Así que ¿cuál es el mejor?

Como habrás adivinado: It Depends ™.

Las compensaciones parecen estar entre velocidad y esfuerzo versus precisión. Cada método sacrifica uno por el otro. Depende de cada empresa juzgar esas compensaciones por sí mismas. Es muy probable que SpaceX tenga un proceso diferente al de una pequeña empresa emergente de Nueva York.

Lo que es cierto es que una empresa SaaS solo debería pedir a los candidatos que escriban algoritmos de programación dinámica si les ayuda a determinar la habilidad del ingeniero. No simplemente porque Google lo hace.

Si estuviera diseñando el proceso de entrevistas para mi equipo en DigitalOcean, usaría una combinación de evaluaciones para llevar a casa y desafíos de código / ejercicios de emparejamiento. También evaluaría su comprensión de la disponibilidad y los sistemas distribuidos a través de una sesión de preguntas y respuestas y un desafío de diseño de sistemas.

La buena noticia es que mi equipo ya lo hace. El duro pero justo proceso de entrevistas de DigitalOcean fue una de las razones por las que acepté su oferta. Me demostró que ya habían pasado por este proceso de autoexamen y habían descubierto cómo evaluar de manera justa a sus candidatos.

¡Hágame saber cuál es su método de entrevista preferido en los comentarios a continuación!

Finalmente, para todos los ingenieros que quieran ver un cambio en el proceso de entrevistas, comiencen a pensar en ideas. He visto a demasiados ingenieros despotricar sobre entrevistas de pizarra solo para continuar el proceso una vez que son contratados porque es demasiado trabajo cambiarlo.

No seas esa persona.

Deja de quejarte.

Encontrar soluciones.