Analizamos miles de entrevistas de codificación. Esto es lo que aprendimos.

Nota: escribí la mayoría de las palabras en esta publicación, pero el legendario Dave Holtz hizo el trabajo pesado en el lado de los datos. Vea más de su trabajo en su blog.

Si está leyendo esta publicación, existe una buena posibilidad de que esté a punto de volver a ingresar al mundo loco y aterrador de las entrevistas técnicas.

Quizás seas un estudiante universitario o un recién graduado que está pasando por el proceso de entrevista por primera vez. Tal vez sea un ingeniero de software experimentado que ni siquiera ha pensado en entrevistas durante algunos años.

De cualquier manera, el primer paso en el proceso de entrevistas suele ser leer un montón de guías de entrevistas en línea (especialmente si están escritas por empresas que le interesan) y conversar con amigos sobre sus experiencias con el proceso de entrevistas (tanto como un entrevistador y entrevistado).

Lo más probable es que lo que lea y aprenda en esta primera fase "exploratoria" del proceso de entrevista le informará cómo elige prepararse para seguir adelante.

Hay algunos problemas con este enfoque típico para la preparación de entrevistas:

  • La mayoría de las guías de entrevistas están escritas desde la perspectiva de una empresa. Si bien la Compañía A realmente puede valorar el código eficiente, la Compañía B puede poner más énfasis en las habilidades de resolución de problemas de alto nivel. A menos que su corazón esté puesto en la Compañía A, probablemente no quiera dar demasiado peso a lo que ellos valoran.
  • La gente miente a veces, aunque no sea su intención. Por escrito, las empresas pueden decir que son independientes del idioma o que vale la pena explicar su proceso de pensamiento, incluso si la respuesta no es del todo correcta. Sin embargo, no está claro si así es como actúan. No estamos diciendo que las empresas de tecnología sean unos mentirosos nefastos que intentan engañar a su grupo de candidatos. Solo decimos que a veces los prejuicios implícitos se infiltran y la gente ni siquiera es consciente de ellos.
  • Gran parte del "conocimiento popular" que escuchas de amigos y conocidos puede no estar basado en los hechos. Mucha gente asume que las entrevistas breves significan fatalidad. Del mismo modo, todos pueden recordar una larga entrevista después de la cual pensaron: "Realmente me llevé bien con ese entrevistador, definitivamente pasaré a la siguiente etapa". En el pasado, hemos visto que la gente es realmente mala para medir cómo les fue en las entrevistas. Esta vez, queríamos mirar directamente indicadores como la duración de las entrevistas y ver si realmente importan.

En mi empresa, entrevistas.io, estamos en una posición única para abordar las entrevistas técnicas y sus resultados de una manera basada en datos. Contamos con una plataforma donde las personas pueden practicar entrevistas técnicas de forma anónima. Y si las cosas van bien, pueden desbloquear la capacidad de entrevistarse de forma anónima, cuando lo deseen, con las principales empresas como Uber, Lyft y Twitch.

Lo bueno es que tanto las entrevistas de práctica como las entrevistas reales con empresas tienen lugar dentro del ecosistema de entrevistas. Como resultado, podemos recopilar bastantes datos de entrevistas y analizarlos para comprender mejor las entrevistas técnicas, la señal que transmiten, lo que funciona y lo que no, y qué aspectos de una entrevista podrían realmente importar para el resultado. .

Cada entrevista, ya sea práctica o real, comienza con el entrevistador y el entrevistado que se reúnen en un entorno de codificación colaborativa con voz, chat de texto y una pizarra, momento en el que pasan directamente a una pregunta técnica.

Las preguntas de la entrevista tienden a caer en la categoría de lo que encontraría en la pantalla de un teléfono para un rol de ingeniería de software de back-end.

Durante estas entrevistas, recopilamos todo lo que sucede, incluidas las transcripciones de audio, datos y metadatos que describen el código que el entrevistado escribió e intentó ejecutar, y comentarios detallados tanto del entrevistador como del entrevistado sobre cómo creen que fue la entrevista y qué pensaron. El uno al otro.

Si tiene curiosidad, puede ver a continuación cómo se ven los formularios de comentarios para entrevistadores y entrevistados; además de una pregunta directa de sí / no, también preguntamos sobre algunos aspectos diferentes del desempeño de la entrevista utilizando una escala de 1 a 4.

También hacemos a los entrevistados algunas preguntas adicionales que no compartimos con sus entrevistadores, y una de las cosas que preguntamos es si un entrevistado ha visto previamente la pregunta en la que acaba de trabajar.

Los resultados

Antes de entrar en el meollo de esto, vale la pena señalar que las conclusiones a continuación se basan en datos de observación, lo que significa que no podemos hacer afirmaciones causales sólidas ... pero aún podemos compartir relaciones sorprendentes que hemos observado y explicar lo que encontramos para que usted puede sacar sus propias conclusiones.

Habiendo visto la pregunta de la entrevista antes

"¡Estamos hablando de práctica!" -Allen Iverson

Lo primero es lo primero. No hace falta ser un científico espacial para sugerir que una de las mejores formas de mejorar en las entrevistas es ... practicar la entrevista. Hay varios recursos disponibles para ayudarte a practicar, el nuestro entre ellos. Uno de los principales beneficios de trabajar con problemas de práctica es que reduce la probabilidad de que se le pida que resuelva algo que nunca antes había visto. Equilibrar ese árbol de búsqueda binaria será mucho menos intimidante si ya lo ha hecho una o dos veces.

Observamos una muestra de ~ 3000 entrevistas y comparamos el resultado con si el entrevistado había visto la pregunta de la entrevista antes. Puede ver los resultados en el gráfico a continuación.

Como era de esperar, los entrevistados que habían visto la pregunta tenían un 16,6% más de probabilidades de ser considerados deseables por su entrevistador. Esta diferencia es estadísticamente significativa: todas las barras de error en esta publicación representan un intervalo de confianza del 95%.

¿Importa en qué idioma codificas?

"El que no ama la lengua de su nacimiento es más bajo que una bestia y un pez maloliente". - José Rizal

Podrías imaginar que diferentes idiomas conducen a mejores entrevistas. Por ejemplo, tal vez la legibilidad de Python le brinde una ventaja en las entrevistas. O quizás el hecho de que ciertos lenguajes manejen las estructuras de datos de una manera particularmente limpia facilita las preguntas comunes de las entrevistas. Queríamos ver si había o no diferencias estadísticamente significativas en el desempeño de las entrevistas en los diferentes idiomas de las entrevistas.

Para investigar, agrupamos las entrevistas en nuestra plataforma por idioma de entrevista y filtramos los idiomas que se usaron en menos de 5 entrevistas (esto solo arrojó un puñado de entrevistas). Después de hacer esto, pudimos observar el resultado de la entrevista y cómo variaba en función del lenguaje de la entrevista.

Los resultados de ese análisis se encuentran en el cuadro a continuación. Cualquier intervalo de confianza que no se superponga representa una diferencia estadísticamente significativa en la probabilidad de que un entrevistado "apruebe" una entrevista, en función del lenguaje de la entrevista.

Aunque no hacemos una comparación por pares para cada posible par de idiomas, los datos a continuación sugieren que, en términos generales, no existen diferencias estadísticamente significativas entre la tasa de éxito cuando las entrevistas se realizan en diferentes idiomas. (Había más idiomas que estos en nuestra plataforma, pero cuanto más oscuro era el idioma, menos puntos de datos tenemos. Por ejemplo, todas las entrevistas en Brainf *** fueron claramente exitosas. Es broma).

Dicho esto, uno de los errores más comunes que hemos observado cualitativamente es que las personas eligen idiomas con los que no se sienten cómodos y luego estropean cosas básicas como la búsqueda de longitud de matriz, iterar sobre una matriz, instanciar una tabla hash, etc.

Esto es especialmente mortificante cuando los entrevistados eligen deliberadamente un lenguaje que suena elegante para impresionar a su entrevistador. Confíe en nosotros, usar el idioma que elija es cómodamente mejor que lucirse en un idioma que suena elegante que no conoce bien, todo el tiempo.

Incluso si el idioma no importa ... ¿es ventajoso codificar en el idioma que elija la empresa?

"Dios me ayude, me he vuelto nativo". - Margaret Blaine

Está muy bien que, en general, el lenguaje de la entrevista no parece estar particularmente correlacionado con el desempeño. Sin embargo, podría imaginarse que podría haber un efecto dependiendo del idioma que utilice una empresa determinada. Podrías imaginar una tienda Ruby diciendo "solo contratamos desarrolladores de Ruby, si haces una entrevista en Python, es menos probable que te contratemos".

Por otro lado, podría imaginarse que una empresa que escribe todo su código en Python va a ser mucho más crítica con un entrevistado en Python: conocen los entresijos del lenguaje y podrían juzgar al candidato por hacer todo tipo de cosas "no pitónicas" durante su entrevista.

El cuadro a continuación es similar al cuadro que mostró diferencias en la tasa de éxito de la entrevista (medida por los entrevistadores que están dispuestos a contratar al entrevistado) para C ++, Java y Python. Sin embargo, este gráfico también desglosa el rendimiento según si el idioma de la entrevista está o no en la pila de la empresa.

Restringimos este análisis a C ++, Java y Python porque estos son los tres lenguajes en los que tuvimos una buena mezcla de entrevistas donde la empresa usó y no usó ese lenguaje. Los resultados aquí son mixtos. Cuando el lenguaje de la entrevista es Python o C ++, no hay una diferencia estadísticamente significativa entre las tasas de éxito de las entrevistas en las que el lenguaje de la entrevista es o no un lenguaje en la pila de la empresa. Sin embargo, los entrevistadores que se entrevistaron en Java tenían más probabilidades de tener éxito al entrevistar con una tienda de Java (p = 0.037).

Entonces, ¿por qué la codificación en el lenguaje de la empresa parece ser útil cuando es Java, pero no cuando es Python o C ++? Una posible explicación es que las comunidades que existen en torno a ciertos lenguajes de programación (como Java) valoran más la experiencia previa con el lenguaje. En este sentido, también es posible que los entrevistadores de empresas que utilizan Java sean más propensos a hacer preguntas que favorezcan a aquellos con un conocimiento preexistente de las idiosincrasias de Java.

¿Qué pasa con la relación entre el idioma en el que programa y qué tan buen comunicador se percibe que es?

"Manejar un idioma con destreza es practicar una especie de hechicería evocadora". - Charles Baudelaire

Incluso si la elección del idioma no importa tanto para el rendimiento general (a pesar de las empresas que utilizan Java), teníamos curiosidad por saber si las diferentes opciones de idioma conducían a diferentes resultados en otras dimensiones de la entrevista.

Por ejemplo, un lenguaje extremadamente legible, como Python, puede llevar a entrevistar a candidatos que, según se evalúa, se han comunicado mejor. Por otro lado, un lenguaje de bajo nivel como C ++ puede generar puntuaciones más altas en capacidad técnica.

Además, los lenguajes muy legibles o de bajo nivel pueden conducir a correlaciones entre estos dos puntajes (por ejemplo, tal vez sea un candidato a una entrevista de C ++ que no puede explicar en absoluto lo que está haciendo pero que escribe un código muy eficiente). El cuadro a continuación sugiere que en realidad no hay ninguna diferencia observable entre cómo se perciben las habilidades técnicas y de comunicación de los candidatos en una variedad de lenguajes de programación.

Además, pase lo que pase, la capacidad técnica deficiente parece estar altamente correlacionada con la capacidad de comunicación deficiente; independientemente del idioma, es relativamente raro que los candidatos se desempeñen bien técnicamente pero no comuniquen de manera efectiva lo que están haciendo (o viceversa) , en gran parte (y afortunadamente) desacreditar el mito del ingeniero incoherente, torpe y de hablar rápido.

(Los mejores ingenieros que he conocido también han sido legendariamente buenos para desglosar conceptos complejos y explicárselos a los laicos. No tengo ni idea de por qué el exasperante mito del nerd tecnológico incoherente y socialmente incómodo sigue existiendo).

Duración de la entrevista

“Está bien cuando te precipitas ante desastres y críticas terriblemente malas y rechazos y todo eso cuando eres joven; tu capacidad de recuperación es simplemente fantástica ". - Harold Prince

Todos hemos tenido la experiencia de salir de una entrevista y sentir que todo salió mal. A menudo, esa sensación de cierto bajo rendimiento está motivada por reglas generales que hemos ideado nosotros mismos o que hemos escuchado repetidas una y otra vez. Es posible que se encuentre pensando, “¿la entrevista no duró mucho? Probablemente sea una mala señal… ”o“ ¡Apenas escribí nada en esa entrevista! Definitivamente no voy a aprobar ". Usando nuestros datos, queríamos ver si estas reglas generales para evaluar el desempeño de su entrevista tenían algún mérito.

Primero, analizamos la duración de la entrevista. ¿Un entrevistador más corto significa que fue un desastre tal que el entrevistador tuvo que detener la entrevista antes de tiempo? ¿O quizás fue el caso de que el entrevistador tuviera menos tiempo de lo normal, o haya visto en poco tiempo que usted era un candidato increíble? El gráfico a continuación muestra las distribuciones de la duración de la entrevista (medida en minutos) tanto para candidatos exitosos como no exitosos.

Un vistazo rápido a este gráfico sugiere que no hay diferencia en la distribución de la duración de las entrevistas entre las entrevistas que funcionan bien y las que no; la duración promedio de las entrevistas en las que el entrevistador quería contratar al candidato era de 51,00 minutos, mientras que el promedio la duración de las entrevistas donde el entrevistador no lo hizo fue de 49,95 minutos. Esta diferencia no es estadísticamente significativa .

(Para cada comparación de distribuciones en esta publicación, usamos una prueba de permutación de Fisher-Pitman para comparar la diferencia en las medias de las distribuciones).

Cantidad de código escrito

"La brevedad es el alma del ingenio." -William Shakespeare

Es posible que haya experimentado una entrevista en la que estaba totalmente perplejo. El entrevistador te hace una pregunta que apenas entiendes, tú le repites "¿qué búsqueda binaria?" Y básicamente no escribes ningún código durante la entrevista. Es posible que espere poder aprobar una entrevista como esta a través de puro ingenio, encanto y habilidades de resolución de problemas de alto nivel. Para evaluar si esto era cierto o no, analizamos la longitud final de los caracteres del código escrito por el entrevistado. La siguiente gráfica muestra las distribuciones de la longitud de los caracteres tanto para los exitosos como para los no exitosos. Un vistazo rápido a este gráfico sugiere que hay una diferencia entre los dos: las entrevistas que no salen bien tienden a tener menos código. Hay dos fenómenos que pueden contribuir a esto. Primero, los entrevistadores que no tienen éxito pueden escribir menos código para empezar. Adicionalmente,pueden ser más propensos a eliminar grandes extensiones de código que han escrito que no se ejecutan o no devuelven el resultado esperado.

En promedio, las entrevistas exitosas tenían un código de entrevista final que tenía un promedio de 2045 caracteres, mientras que las que no tenían éxito tenían, en promedio, 1760 caracteres. ¡Esa es una gran diferencia! Este hallazgo es estadísticamente significativo y probablemente no muy sorprendente.

Modularidad de código

"La marca de un programador maduro es la voluntad de descartar el código en el que dedicó tiempo cuando se da cuenta de que no tiene sentido". - Bram Cohen

Además de mirar cuántocódigo que escribe, también podemos pensar en el tipo de código que escribe. La sabiduría convencional sugiere que los buenos programadores no reciclan el código, escriben código modular que se puede reutilizar una y otra vez. Queríamos saber si ese tipo de comportamiento fue realmente recompensado durante el proceso de entrevista. Para ello, analizamos las entrevistas realizadas en Python5 y contamos cuántas definiciones de funciones aparecieron en la versión final de la entrevista. Queríamos saber si los entrevistados exitosos definieron más funciones, aunque tener más controladores de funciones no es la definición de modularidad, en nuestra experiencia, es una señal bastante fuerte de ello. Como siempre,Es imposible hacer afirmaciones causales sólidas sobre esto; podría darse el caso de que ciertos entrevistadores (que son más o menos indulgentes) hagan preguntas de entrevista que se presten a más o menos funciones. No obstante, ¡es una tendencia interesante para investigar!

El gráfico siguiente muestra la distribución de la cantidad de funciones de Python definidas tanto para los candidatos que el entrevistador dijo que contratarían como para los candidatos que el entrevistador dijo que no contratarían. Un rápido vistazo a este gráfico sugiere que hay es una diferencia en la distribución de definiciones de funciones entre las entrevistas que van bien y entrevistas que no lo hacen. Los entrevistados exitosos parecen definir más funciones.

En promedio, los candidatos exitosos que se entrevistan en Python definen 3.29 funciones, mientras que los candidatos no exitosos definen 2.71 funciones. Este hallazgo es estadísticamente significativo. El resultado aquí es que los entrevistadores realmente recompensan el tipo de código que dicen que quieren que escribas.

¿Importa si su código se ejecuta?

"Muévete rápido y rompe cosas. A menos que esté rompiendo cosas, no se está moviendo lo suficientemente rápido ". - Mark Zuckerberg "La herramienta de depuración más eficaz sigue siendo un pensamiento cuidadoso, junto con declaraciones impresas colocadas con criterio" - Brian Kernighan

Un estribillo común en las entrevistas técnicas es que a los entrevistadores en realidad no les importa si su código se ejecuta; lo que les importa es la capacidad de resolución de problemas. Dado que recopilamos datos sobre el código que ejecutan los entrevistados y si ese código se compila o no, queríamos ver si había evidencia de esto en nuestros datos. ¿Existe alguna diferencia entre el porcentaje de código que se compila sin errores en entrevistas exitosas versus entrevistas no exitosas? Además, ¿se puede seguir contratando a los entrevistados, incluso si cometen toneladas de errores de sintaxis?

Para llegar a esta pregunta, miramos los datos. Restringimos nuestro conjunto de datos a entrevistas de más de 10 minutos con más de 5 instancias únicas de código en ejecución. Esto ayudó a filtrar las entrevistas en las que los entrevistadores en realidad no querían que el entrevistado ejecutara un código, o en las que la entrevista se interrumpió por alguna razón. Luego medimos el porcentaje de ejecución de código que resultó en errores.5 Por supuesto, existen algunas limitaciones en este enfoque; por ejemplo, los candidatos podrían ejecutar código que se compila pero da una respuesta ligeramente incorrecta. ¡También podrían obtener la respuesta correcta y escribirla en stderr! No obstante, esto debería darnos una idea direccional de si existe o no una diferencia.

El cuadro a continuación ofrece un resumen de estos datos. El eje x muestra el porcentaje de ejecuciones de código sin errores en una entrevista determinada. Por lo tanto, una entrevista con 3 ejecuciones de código y 1 mensaje de error se consideraría para el grupo "30% -40%". El eje y indica el porcentaje de todas las entrevistas que caen en ese grupo, tanto para entrevistas exitosas como no exitosas. Con solo mirar el cuadro a continuación, uno tiene la sensación de que, en promedio, los candidatos exitosos ejecutan más código que se ejecuta sin errores. Pero, ¿esta diferencia es estadísticamente significativa?

En promedio, el código de los candidatos exitosos se ejecutó correctamente (no generó errores) el 64% del tiempo, mientras que los intentos de los candidatos no exitosos de compilar el código se ejecutaron exitosamente el 60% del tiempo, y esta diferencia fue realmente significativa. Una vez más, aunque no podemos hacer ninguna afirmación causal, la conclusión principal es que los candidatos seleccionados suelen escribir un código que funciona mejor, a pesar de lo que los entrevistadores puedan decirle al comienzo de la entrevista.

¿Debería esperar y ordenar sus pensamientos antes de escribir código?

"Nunca olvides el poder del silencio, esa pausa enormemente desconcertante que sigue y sigue y que por fin puede inducir a un oponente a balbucear y retroceder nerviosamente". - Lance Morrow

También teníamos curiosidad por saber si los entrevistados exitosos tendían o no a tomarse su tiempo en la entrevista. ¡Las preguntas de la entrevista son a menudo complejas! Después de que se le presente una pregunta, podría ser beneficioso dar un paso atrás y elaborar un plan, en lugar de lanzarse directamente a las cosas. Para tener una idea de si esto era cierto o no, medimos hasta qué punto los candidatos ejecutaron el código por primera vez en una entrevista determinada. A continuación se muestra un histograma que muestra hasta qué punto las entrevistas, tanto los entrevistados exitosos como los fallidos, ejecutaron el código por primera vez. Si observa rápidamente el histograma, puede ver que los candidatos seleccionados, de hecho, esperan un poco más para comenzar a ejecutar el código, aunque la magnitud del efecto no es enorme.

Más específicamente, en promedio, los candidatos con entrevistas exitosas primero ejecutan el código el 27% del camino a través de la entrevista, mientras que los candidatos con entrevistas fallidas primero ejecutan el código el 23,9% del camino a la entrevista, y esta diferencia es significativa . Por supuesto, hay explicaciones alternativas para lo que está sucediendo aquí. Por ejemplo, quizás los candidatos exitosos sean mejores en tomarse el tiempo para hablar dulcemente con su entrevistador. Además, se aplica la advertencia habitual de que no podemos hacer afirmaciones causales: si solo se sienta en una entrevista durante 5 minutos adicionales en completo silencio, no mejorará sus posibilidades. No obstante, parece haber una diferencia entre las dos cohortes.

Conclusiones

En general, esta publicación fue nuestro primer intento de comprender qué es lo que generalmente lleva a un entrevistador a decir "¿sabes qué? Me gustaría contratar a esta persona" Debido a que todos nuestros datos son de observación, es difícil hacer afirmaciones causales sobre lo que vemos.

Si bien los entrevistados exitosos pueden exhibir ciertos comportamientos, adoptar esos comportamientos no garantiza el éxito. No obstante, nos permite apoyar (o llamar a BS) muchos de los consejos que leerá en Internet sobre cómo ser un entrevistado exitoso.

Dicho esto, todavía queda mucho por hacer. Este fue un primer paso cuantitativo sobre nuestros datos (que es, en muchos sentidos, un tesoro de secretos de entrevistas), pero estamos emocionados de hacer una inmersión cualitativa más profunda y, de hecho, comenzar a categorizar diferentes preguntas para ver cuál lleva el la mayoría de las señales, además de entender realmente los comportamientos de segundo orden que no se pueden medir fácilmente ejecutando una expresión regular sobre una muestra de código o midiendo cuánto tiempo tomó una entrevista.

Si quieres ayudarnos con esto y estás emocionado de escuchar un montón de entrevistas técnicas, ¡escríbeme!

¿Quieres ser increíble en las entrevistas técnicas y conseguir tu próximo trabajo en el proceso? ¡Únete a surveying.io!