Si estás leyendo esta publicación, hay una buena posibilidad de que estés a punto de volver a entrar en el loco y aterrador mundo de las entrevistas técnicas.
Quizás eres un estudiante universitario o un recién graduado que está pasando por el proceso de entrevista por primera vez. Tal vez eres 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 entrevista generalmente es leer un montón de guías de entrevista en línea (especialmente si están escritas por compañías que le interesan) y conversar con amigos sobre sus experiencias con el proceso de entrevista (tanto como un entrevistador y entrevistado).
Lo más probable es que lo que leas y aprendas en esta primera fase “exploratoria” del proceso de entrevista informará cómo eliges prepararte 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 compañía. Mientras que la Compañía A puede realmente 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é centrado en la Compañía A, probablemente no quiera dar demasiado peso a lo que valoran.
- Las personas mienten a veces, incluso si no quieren hacerlo. Al escribir, las compañías pueden decir que son independientes del lenguaje o que vale la pena explicar su proceso de pensamiento, incluso si la respuesta no es correcta. Sin embargo, no está claro si así es como actúan. No estamos diciendo que las empresas tecnológicas sean mentirosos nefastos que intentan engañar a su grupo de solicitantes. Solo estamos diciendo que a veces se introducen sesgos implícitos y las personas ni siquiera son conscientes de ellos.
- Gran parte del “conocimiento popular” que escuchas de amigos y conocidos puede no estar basado en realidad. Mucha gente supone que las entrevistas cortas 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 las personas son realmente malo para medir cómo les fue en las entrevistas. Esta vez, queríamos mirar directamente a indicadores como la duración de la entrevista 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. Tenemos una plataforma donde las personas pueden practicar entrevistas técnicas de forma anónima. Y si las cosas van bien, pueden desbloquear la posibilidad de entrevistar anónimamente, cuando lo deseen, con las principales compañías como Uber, Lyft y Twitch.
Lo bueno es que tanto las entrevistas de práctica como las entrevistas reales con empresas se llevan a cabo dentro de la práctica de entrevistas con ingenieros de las principales empresas, de forma anónima. ecosistema. 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 funciona, y qué aspectos de una entrevista podrían importar realmente para el resultado .
Cada entrevista, ya sea práctica o real, comienza con el entrevistador y la reunión del entrevistado en un entorno de codificación colaborativo con voz, chat de texto y una pizarra, en cuyo punto se dirigen 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 una función de ingeniería de software de back-end.
Durante estas entrevistas, recopilamos todo lo que sucede, incluidas 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 cómo se ven los formularios de comentarios para entrevistadores y entrevistados a continuación: además de una pregunta directa de sí / no, también preguntamos sobre algunos aspectos diferentes del desempeño de la entrevista usando una escala de 1 a 4.
También les hacemos algunas preguntas adicionales a los entrevistados 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.
Formulario de comentarios para entrevistadores
Formulario de comentarios para entrevistados
Los resultados
Antes de entrar en el meollo, 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 fuertes … pero aún podemos compartir relaciones sorprendentes que hemos observado y explicar lo que encontramos para que usted Puedes sacar tus 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 un científico espacial para sugerir que una de las mejores maneras de mejorar en las entrevistas es … practicar entrevistas. Existen varios recursos disponibles para ayudarlo a practicar, el nuestro entre ellos. Uno de los principales beneficios de resolver los 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 binario será mucho menos intimidante si ya lo has 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?
“Quien no ama el idioma de su nacimiento es más bajo que una bestia y un pez maloliente”. – José Rizal
Puede imaginar que diferentes idiomas conducen a mejores entrevistas. Por ejemplo, tal vez la legibilidad de Python te da una ventaja en las entrevistas. O quizás el hecho de que ciertos idiomas manejan 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 rendimiento de la entrevista en los diferentes idiomas de la entrevista.
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 ver el resultado de la entrevista y cómo variaba en función del lenguaje de la entrevista.
Los resultados de ese análisis están en el cuadro a continuación. Cualquier intervalo de confianza no superpuesto 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 es el idioma, menos puntos de datos tenemos. Por ejemplo, todas las entrevistas en Brainf *** fueron claramente exitosas. Broma).
Dicho esto, uno de los errores más comunes que hemos observado cualitativamente es que las personas eligen idiomas en los que no se sienten cómodos y luego desordenan cosas básicas como la búsqueda de longitud de la matriz, iterar sobre una matriz, crear instancias de una tabla hash, etc.
Esto es especialmente mortificante cuando los entrevistados eligen deliberadamente un lenguaje elegante para impresionar a su entrevistador. Confía en nosotros, manejando tu idioma de elección cómodamente, presume de lucir en un lenguaje elegante que no conoces bien, todo el tiempo.
Incluso si el idioma no importa … ¿es ventajoso codificar en el idioma de elección de la empresa?
“Dios me ayude, me he vuelto nativo”. – Margaret Blaine
Está muy bien que, en general, el lenguaje de la entrevista no parezca particularmente correlacionado con el rendimiento. Sin embargo, puede imaginar que podría haber un efecto dependiendo del idioma que use una compañía determinada. Podrías imaginar una tienda de Ruby que diga “solo contratamos desarrolladores de Ruby, si entrevistas en Python es menos probable que te contratemos”.
Por otro lado, podrías imaginar que una empresa que escribe todo su código en Python va a ser mucho más crítico con un entrevistado en Python: conoce los entresijos del lenguaje y puede juzgar al candidato por hacer todo tipos de cosas “no pitónicas” durante su entrevista.
La tabla a continuación es similar a la tabla que mostró diferencias en la tasa de éxito de la entrevista (medida por los entrevistadores 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 compañía.
Restringimos este análisis a C ++, Java y Python porque estos son los tres lenguajes en los que tuvimos una buena mezcla de entrevistas en las que la empresa utilizó y no utilizó ese lenguaje. Los resultados aquí son mixtos. Cuando el lenguaje de la entrevista es Python o C ++, no existe una diferencia estadísticamente significativa entre las tasas de éxito de las entrevistas donde el idioma de la entrevista es o no un idioma en la pila de la compañía. Sin embargo, los entrevistadores que entrevistaron en Java tenían más probabilidades de tener éxito al entrevistar en una tienda de Java (p = 0.037).
Entonces, ¿por qué la codificación en el lenguaje de la compañía 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) otorgan una mayor importancia a la experiencia previa con el lenguaje. En este sentido, también es posible que los entrevistadores de compañías que usan Java tengan más probabilidades de 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 le percibe?
“Manejar un idioma con habilidad es practicar una especie de hechicería evocativa”. – Charles Baudelaire
Incluso si la elección del idioma no es tan importante para el rendimiento general (a pesar de las empresas que manejan Java), teníamos curiosidad sobre si las diferentes opciones de idioma conducían a resultados diferentes en otras dimensiones de la entrevista.
Por ejemplo, un lenguaje extremadamente legible, como Python, puede conducir a entrevistar a candidatos que se evalúan para comunicarse mejor. Por otro lado, un lenguaje de bajo nivel como C ++ podría conducir a puntajes más altos para la 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 sean candidatos a una entrevista en C ++ que no pueden explicar lo que está haciendo, pero que escriben códigos muy eficientes). El cuadro a continuación sugiere que no hay realmente 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 efectivamente lo que están haciendo (o viceversa) , en gran medida (y afortunadamente) desacreditando el mito del ingeniero incoherente, que habla rápido y torpe.
(Los mejores ingenieros que he conocido también han sido legendariamente buenos para descomponer conceptos complejos y explicarlos a los laicos. Por qué el exasperante mito del nerd tecnológico socialmente incómodo e incoherente sigue existiendo, no tengo absolutamente ninguna idea).
Duración de la entrevista
“Está bien cuando caes en desastres y críticas y rechazos terriblemente malos y todo eso cuando eres joven; su resistencia es simplemente excelente “. – Harold Prince
Todos hemos tenido la experiencia de dejar una entrevista y sentimos que todo salió mal. A menudo, esa sensación de cierto bajo rendimiento está motivada por las reglas generales que hemos inventado o escuchamos repetidas una y otra vez. Puede que te encuentres pensando: “¿la entrevista no duró mucho? Esa es probablemente una mala señal … “o” ¡Apenas escribí algo en esa entrevista! Definitivamente no voy a aprobar ”. Utilizando nuestros datos, queríamos ver si estas reglas generales para evaluar el desempeño de su entrevista tenían algún mérito.
Primero, miramos la duración de la entrevista. ¿Un entrevistador más corto significa que usted fue un desastre de tren que el entrevistador solo tuvo que detener la entrevista antes? ¿O tal vez fue el caso de que el entrevistador tuvo menos tiempo de lo normal o había visto en poco tiempo que eras un candidato increíble? La siguiente gráfica muestra las distribuciones de la duración de la entrevista (medida en minutos) para los candidatos exitosos y 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 van bien y las entrevistas que no: la duración promedio de las entrevistas donde el entrevistador quería contratar al candidato fue de 51.00 minutos, mientras que el promedio La duración de las entrevistas en las que el entrevistador no fue fue de 49.95 minutos. Esta diferencia no es estadísticamente significativa .
(Para cada comparación de distribuciones en esta publicación, utilizamos 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 quedó totalmente perplejo. El entrevistador le hace una pregunta que apenas comprende, le repite “búsqueda binaria ¿qué?” Y básicamente no escribe ningún código durante la entrevista. Es posible que aún pueda pasar una entrevista como esta por puro ingenio, encanto y habilidades de resolución de problemas de alto nivel. Para evaluar si esto era cierto o no, observamos la longitud final del código del personaje escrito por el entrevistado. El gráfico a continuación muestra las distribuciones de longitud de caracteres para ambos exitosos y no exitosos. Un vistazo rápido a este gráfico sugiere que hay una diferencia entre los dos: las entrevistas que no van bien tienden a tener menos código. Hay dos fenómenos que pueden contribuir a esto. Primero, los entrevistadores fracasados pueden escribir menos código para empezar. Además, 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 una longitud promedio de 2045 caracteres, mientras que las que no tuvieron éxito tenían, en promedio, 1760 caracteres. Esa es una gran diferencia! Este hallazgo es estadísticamente significativo y probablemente no sea muy sorprendente.
Modularidad de código
“La marca de un programador maduro es la disposición a tirar el código en el que pasaste tiempo cuando te das cuenta de que no tiene sentido”. – Bram Cohen
Además de ver cuánto código escribes, también podemos pensar en el tipo de código que escribes. 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 la entrevista. Para hacerlo, 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 manejadores 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 fuertes afirmaciones causales sobre esto: podría ser el caso de que ciertos entrevistadores (que son más o menos indulgentes) hacen preguntas de entrevista que se prestan a más o menos funciones. ¡Sin embargo, es una tendencia interesante investigar!
El siguiente diagrama muestra la distribución del número 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 vistazo rápido a este gráfico sugiere que existe una diferencia en la distribución de definiciones de funciones entre las entrevistas que salen bien y las entrevistas que no. 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 se ejecuta tu código?
“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 juiciosas”. – Brian Kernighan
Un estribillo común en las entrevistas técnicas es que a los entrevistadores en realidad no les importa si se ejecuta su código; lo que les importa son las habilidades para resolver problemas. Como 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. ¿Hay alguna diferencia entre el porcentaje de código que compila libre de errores en entrevistas exitosas versus entrevistas no exitosas? Además, ¿pueden los entrevistados aún ser contratados, 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 donde los entrevistadores en realidad no querían que el entrevistado ejecutara el código, o donde la entrevista se interrumpió por alguna razón. Luego medimos el porcentaje de ejecuciones de código que dieron como resultado errores.5 Por supuesto, hay algunas limitaciones para este enfoque; por ejemplo, los candidatos podrían ejecutar código que 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 un sentido direccional de si hay 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 dada. Por lo tanto, una entrevista con 3 ejecuciones de código y 1 mensaje de error contaría para el segmento “30% -40%”. El eje y indica el porcentaje de todas las entrevistas que caen en ese segmento, tanto para entrevistas exitosas como no exitosas. Simplemente mirando el cuadro a continuación, uno tiene la sensación de que, en promedio, los candidatos exitosos ejecutan más código que se activa sin un error. ¿Pero es esta diferencia estadísticamente significativa?
En promedio, el código de los candidatos exitosos se ejecutó con éxito (no resultó en errores) el 64% del tiempo, mientras que los intentos de los candidatos no exitosos de compilar el código se ejecutaron con éxito el 60% del tiempo, y esta diferencia fue realmente significativa. Una vez más, aunque no podemos hacer ningún reclamo causal, la conclusión principal es que los candidatos exitosos generalmente escriben un código que funciona mejor, a pesar de lo que los entrevistadores pueden decirle al comienzo de una entrevista.
¿Deberías esperar y ordenar tus pensamientos antes de escribir el código?
“Nunca olvides el poder del silencio, esa pausa enormemente desconcertante que sigue y sigue y puede al fin inducir a un oponente a balbucear y retroceder nerviosamente”. – Lance Morrow
También teníamos curiosidad sobre 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, puede ser beneficioso dar un paso atrás y elaborar un plan, en lugar de saltar directamente a las cosas. Con el fin de tener una idea de si esto era cierto o no, medimos hasta qué punto en una entrevista dada los primeros códigos ejecutados. A continuación se muestra un histograma que muestra hasta qué punto en las entrevistas, los entrevistados exitosos y no exitosos ejecutaron el código por primera vez. Si observa rápidamente el histograma, puede ver que los candidatos exitosos, 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 no exitosas primero ejecutan el código el 23.9% del camino hacia la entrevista, y esta diferencia es significativa . Por supuesto, hay explicaciones alternativas de lo que está sucediendo aquí. Por ejemplo, quizás los candidatos exitosos son mejores para tomarse el tiempo de 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 ayudará a 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é, realmente 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. Sin embargo, nos permite apoyar (o llamar a BS) muchos de los consejos que leerá en Internet sobre cómo ser un entrevistado exitoso.
Dicho esto, aún 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 entusiasmados de hacer una inmersión más profunda y cualitativa y, de hecho, comenzar a clasificar diferentes preguntas para ver cuáles llevan la mayoría de las señales, además de entender realmente, 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 llevó una entrevista.