¿Quién fue el peor candidato entrevistado para un puesto de desarrollador de software?

Creo que podría haber hecho 1000 entrevistas en este momento, así que creo que tengo algunas. Si pienso en dos de los peores, tengo esta respuesta:

Uno de los primeros candidatos verdaderamente malos que entrevisté fue al principio de mi carrera en Microsoft. Comencé en Microsoft cuando tenía unos 23 años. No fui a la universidad, así que a veces me intimidaba la gente que sí. En ese punto, supongo, todavía no me había dado cuenta de que no importaba.

Estaba entrevistando candidatos en nuestra oficina de la ciudad de Nueva York. Mi horario de entrevistas para el día incluía a un candidato que era doctor y trabajaba en un laboratorio nacional . Con su currículum y sus credenciales en la mano, estaba aterrorizado. Creo que podría haber sido la tercera entrevista que tuve ese día, así que probablemente hablé con él alrededor de las 10 a.m.

Cuando llegó, conversamos un poco. No era inusual contratar a un desarrollador de software que no tenía experiencia en software. Hablamos un poco sobre su trabajo en física, y eso mencionó su trabajo de programación. Comenzó a decirme que estaba aprendiendo C ++ y que había codificado un programa para ayudar a enseñar a los niños a contar el cambio. Cada tipo de moneda, me dijo, fue implementado por una clase diferente.

Esta es muy poca experiencia y un diseño terrible. Lo entretuve un poco y probé por qué podría haber un mejor diseño. En ese momento, no era un buen entrevistador, y mi falta de habilidad se vio exacerbada por mi terriblemente alta impresión de su currículum. Me disculpé, conseguí al reclutador y le pedí que le diera el gancho.

Me siento un poco mal por mi reacción; Podría haberlo manejado mucho mejor. Pero no debería haber superado cualquier examen que tuviéramos en ese momento.

Mucho más tarde en mi carrera, entrevisté a un desarrollador que tenía una gran experiencia en redes. Trabajó para una compañía en particular que vendía equipos de alta gama realmente buenos, pero ese equipo era conocido por ser muy costoso.

En ese momento, estaba interesado en hacer una pregunta de diseño del sistema. Mi pregunta era bastante específica sobre su objetivo, pero no especificaba muchos detalles sobre cuál era realmente la forma del problema. “Queremos inventar un producto. ¿Cómo lo hacemos?” era lo esencial, excepto que “el producto” tenía una descripción funcional específica y bastante simple.

Al hacer la pregunta, busco candidatos que retrocedan con más preguntas para impulsar los requisitos y el alcance.

Los buenos candidatos hacen suficientes preguntas para determinar el problema: no quiero contratar a alguien que construya la presa Grand Coulee cuando solo quiero un grifo de agua. Los grandes candidatos comienzan con esas preguntas y no avanzan más hasta que están satisfechos hasta que saben todo sobre la calidad, cantidad y presión del flujo de agua en el que estoy pensando.

Abandonando la metáfora del flujo de agua: ¿Este producto manejará a 3 usuarios o 3 mil millones de usuarios? ¿Cada usuario realizará una solicitud por año o un millón de solicitudes por segundo? Dentro de estos límites, hay un espectro gigante de diferentes soluciones posibles. ¿Se puede resolver este problema con un módem de 2400 baudios y una computadora portátil vieja? ¿O necesitamos un centro de datos con una gran infraestructura, 10000 servidores y millones de líneas de código de infraestructura antes de que podamos comenzar a resolver el problema en sí?

Desafortunadamente, este candidato intervino con una solución antes de hacer preguntas de alcance o aclaración. Dijo que pondría uno de los productos de su antigua empresa en la parte superior de la solución. “Usaremos una X-5000 aquí”, me dijo. Lo detuve: “¿Por qué necesitamos uno de esos?”

Presumió que mi pregunta era una queja sobre el gasto. En cierto modo lo era, pero se trataba de gastar el dinero sin saber si necesitábamos la capacidad de ese producto. ¿Lo necesitamos en absoluto? ¿O deberíamos obtener el modelo X-2000 más pequeño o el modelo X-7000 más grande?

Giró sobre sus talones, apartándose de la pizarra. “Simplemente piensas que todos esos productos son caros. ¿Sabes cuánto cuesta uno?

“Uh, no específicamente. Alrededor de 50 mil, creo. He usado la serie Q, pero no la serie X, y creo que …”

“¡Incorrecto! ¡Puedes conseguir uno por menos de 20 mil dólares!” Estaba elevado y discutía conmigo en su entrevista.

Difundí la situación y me senté en silencio mientras pasaba 30 minutos diseñando un sistema que manejaría muchas más solicitudes de las necesarias, a un costo de aproximadamente 2000 veces lo que era necesario. Su incapacidad para evaluar el problema antes de intentar resolverlo era reprensible. Pero junto con su actitud, le costó cualquier posibilidad de una oferta de trabajo.

Después de reflexionar un poco sobre mi respuesta, pensé en un tercero: yo mismo. Me entrevisté en una gran empresa donde todos querían trabajar.

Ya trabajaba en una gran empresa donde todos querían trabajar, pero me estaba aburriendo. No pensé que estaba progresando en mi carrera: no estaba aprendiendo cosas nuevas o mejorando mi conjunto de habilidades. Esto no quiere decir que pensé que lo sabía todo, pero en retrospectiva ciertamente fue como si estuviera actuando como si lo supiera todo.

Fui a la entrevista de la empresa candidata y quedé crema. Creo que hubo cinco sesiones de preguntas en mi bucle, y no pude responder ninguna. Con un montón de pistas, casi resolví una, pero realmente me dieron mi sombrero.

Lo bueno es que realmente me tomé esto en serio. Hay una parodia donde un comediante habla sobre las personas que conducen. Si conduce y alguien está buceando más rápido que usted, cree que es un maníaco. Si conducen más despacio que usted, son un imbécil.

En ese momento de mi carrera, pensaba que las personas que no podían hacer las cosas que sabía hacer eran idiotas. Fue fácil para mí y no soy tan bueno; ¿Por qué es difícil para ellos? Hay personas que pueden hacer cosas que yo no puedo hacer, y deben ser magos. Como, deben haberse centrado en cierta tecnología y realmente la han estudiado como locos y no puedo aprender eso.

Supongo que esto fue hace unos 12 o 15 años. Desde entonces, motivado por el resultado de la entrevista, he reestructurado la forma en que abordo las cosas de aprendizaje y mi trabajo. La próxima vez, aún podría no recibir una oferta, pero no debería ser el peor candidato que entrevistan.

Hace algunos años, una pequeña empresa emergente en la que estaba trabajando entrevistaba a candidatos para un puesto de programador web / Flash. Un día obtuvieron un candidato experimentado, que además de conocimiento de Flash afirmaba ser un experto en C / C ++ e incluso mostraba una pieza impresionante de software de escritorio para el procesamiento de sonido que afirmó que él mismo escribió en C ++. Así que la gerencia me pidió que interviniera y lo entrevistara también sobre el conocimiento de C / C ++. El chico parecía muy confiado y sabía cómo hablar. Sin embargo, cuando se trataba de preguntas de programación reales (y comencé con preguntas realmente simples), de repente perdió toda su confianza. Explicó que sería difícil para él hacer el cambio y comenzar a escribir el código en el medio de la entrevista (ya que era algo inusual), sería difícil para él codificar mientras miraba (!) Y preferiría tener un IDE y acceso a manuales. Incluso se quejó por qué le haría esas preguntas en primer lugar si venía a ser entrevistado para un papel diferente, a pesar de jactarse de su experiencia en C / C ++ al entrevistador anterior. Probablemente toda la conversación me hizo levantar las cejas más de un par de veces, pero al darle la ventaja de la duda, le permití usar una computadora portátil que generalmente no usamos. Lo que, por supuesto, no ayudó mucho: a pesar de afirmar haber escrito recientemente una gran pieza de software, ni siquiera podía decir cómo asignar memoria dinámicamente ni en C ni C ++ o escribir un bucle simple. En ese momento, estaba seguro de que estaba mintiendo sobre escribir ese software él mismo, pero por supuesto no le dije nada. Sin embargo, por alguna razón, insistió en mostrarme ese proyecto suyo, probablemente esperando compensar una entrevista bastante vergonzosa hasta ahora. Explicó una pequeña interfaz de usuario demostrada que parecía estar bien, pero luego procedió a mostrar el código que me hizo cambiar de opinión inmediatamente sobre la autoría del código. Solo alguien completamente ignorante en lenguaje C / C ++ y prácticas de programación en general, podría haber escrito eso. Fue literalmente el código más horrible que he visto en mi carrera: todo el proyecto (miles de líneas) se escribió completamente dentro de los archivos de encabezado (.h), con poca sangría, formato o nombres significativos. Fue una mezcla explosiva de estilos de C y C ++, por ejemplo, clases de C ++ con constructores asignados a través de la asignación de memoria de estilo C (malloc), y el código asociado escrito en funciones de C que no son miembros, etc. Solo el hecho de que esta monstruosidad compilada y supuestamente corrida fue un milagro en mis ojos. Y el tipo era tan ignorante de su propia incompetencia, que estaba muy orgulloso de mostrarme eso. Mostrando con orgullo el código que me puso los pelos de punta.

Ese candidato me intrigó tanto que obtuve una copia de su CV y ​​descubrí que era una lectura hilarante por sí misma. No tengo idea de por qué la gerencia decidió entrevistar a alguien con un CV tan mal escrito con tantas banderas rojas por todas partes. Por ejemplo, contenía gemas como:

“Estoy familiarizado con todas las tecnologías disponibles del lado del servidor, del lado del cliente y de la base de datos”

o

“Familiarizado con todas las principales especificaciones de codificadores / decodificadores de video / audio, formatos y logaritmo de compresión “.

PD: si hay alguien interesado, aquí está la copia del CV, con toda la información de identificación eliminada: CV: Todas las tecnologías web disponibles “Especialista”

He entrevistado a un montón de personas y han variado desde pobres hasta espectacularmente bien calificados. Sin embargo, hay un tipo que está de cabeza y hombros debajo de todos los demás.

Le di una de mis preguntas estándar de entrevista al candidato. La pregunta es interesante porque parece que hay una manera simple de calcular la respuesta. Desafortunadamente, si revisas tu trabajo, encuentras que no es correcto. Después de algunas sugerencias, el candidato generalmente ve los problemas y busca una solución correcta o casi correcta.

Entonces este tipo comienza a codificar y se le ocurre un desorden de código. Realmente no puedo seguir el código, pero parece que ha cometido el mismo error que los candidatos suelen cometer. Le pido que me guíe a través del código línea por línea para un caso muy simple para que pueda ver cuál es su enfoque y si es correcto y está mal codificado o si el enfoque es incorrecto. Tenga en cuenta que en este punto, el tipo ya tiene un golpe contra él porque el código es muy pobre. Comienza a tratar de explicar el código y en la línea 5 estoy perdido y está claramente perdido, pero está tratando de saludar y hablar rápidamente a través del código. Comienzo a sugerir que tal vez su enfoque es incorrecto y le doy algunas pistas sobre cómo abordar el problema. En cambio, el tipo se pone a la defensiva y se dobla en su charla rápida y sugiere que tal vez simplemente no entiendo su código. Golpear dos. Cuando un entrevistador comienza a dar pistas, ¡tómalas! Así que lo dejé agitarse unos minutos más. Luego lo interrumpí y le expliqué que su código puede ser correcto o no, pero es incomprensible, por lo que no importa: debería intentar un enfoque diferente e intentar codificar algo que sea más comprensible. Luego dice que su código es correcto y depende de mí mostrar que es incorrecto. Striiiiiiike Threeeeee !!! Estás fuera de aquí!