No soy un reclutador para grandes empresas, pero tengo mucha experiencia con pequeñas empresas y un poco de sentido común.
En 2013, realicé una campaña de contratación muy exitosa en AboutEcho.com que resultó en la contratación de nueve ingenieros superiores. Mis lectores de habla rusa pueden leerlo aquí .
Todo esto me da la confianza para criticar los métodos que utilizan los gigantes de Internet para contratar ingenieros hasta el día de hoy.
No apuntes a la mejor solución
Cuando llega a una entrevista, el entrevistador le plantea un problema y espera una solución en 0 a 2 minutos. Si te tomas más tiempo, realmente se emocionarán y les pedirán que digan algo.
Esto es comprensible: después de todo, solo tienen 45 minutos y quieren discutir muchas cosas contigo.
No puedo entender cómo se le juzga por la calidad de la solución que se le ocurrió en dos minutos. Porque no es así como funciona la creatividad humana. Es fácil tener muchas ideas, pero es extraño esperar que lo mejor siempre sea lo primero. Incluso los genios no pueden generar de manera predecible las mejores ideas del mundo en un corto período de tiempo.
La creatividad es la capacidad de evaluar y filtrar el flujo de ideas que se te ocurren. Si está realmente interesado en esto, ¿por qué no pedirle a la otra persona que compare y evalúe varias ideas? Compruebe si una persona puede evaluar las propiedades de la solución propuesta. ¿Si ve claramente los pros y los contras?
Y si pides encontrar la mejor solución en dos minutos, entonces estás probando tu suerte, nada más. ¿Está en el negocio de contratar empleados exitosos? ¿O capaz?
No preguntes rompecabezas
¿Cómo puedo comprobar si una lista vinculada tiene un bucle? ¿Cabe una caja de N dimensiones en otra caja de N dimensiones? ¿Puedes intercambiar dos variables sin la tercera? ¿Cómo encontrar la distancia más corta entre dos barcos en movimiento? ¿Encuentra todas las permutaciones de N elementos realizando solo N-1 permutaciones?
Es divertido hablar de estos acertijos y sus soluciones pueden ser muy útiles. Cuando era niño, me encantaba que muchos de ellos leyeran Math Fun and Essays . No me malinterpretes, son divertidísimos.
Sin embargo, por muy divertidas que sean, son solo anécdotas. La propiedad de un acertijo es que o sabes la respuesta o no. Esto no te dice nada más. No tiene nada que ver con el desempeño futuro, la habilidad, la habilidad o cualquier otra cosa. Conocer una respuesta concreta no significa que tengas un aparato para resolver problemas reales de forma general y predecible. Lo único que te dice es que la persona estaba en esta situación y alguien compartió una solución con él. Ni mas ni menos. Detente ya.
¿Cómo salvarse antes de que la vela queme la cuerda?
Estar abierto a alternativas
Esto es algo de esperar, pero las grandes empresas todavía parecen caer en la trampa. Si el entrevistado ofrece una solución alternativa, usted, como entrevistador, tiene la oportunidad de aprender algo. Esta también es una buena oportunidad para una discusión más profunda si la solución propuesta resulta ser imposible o mala.
Sin embargo, me despidieron por proponer una solución alternativa de la misma complejidad (y me agobiaron con una conferencia sobre "el único enfoque verdadero para este problema"), y en otra ocasión llevé estrictamente a una solución específica. En el último caso, el entrevistador realmente quería ignorar todas mis preocupaciones y quería discutir solo lo que él veía como una solución al problema, y luego dejó una reseña "no impresionante" sobre mí.
Nadie lo sabe todo. Estar abierto. Escuchar. Meditar. Sí, incluso si está entrevistando a alguien.
Sea tolerante con los defectos
Los errores individuales son ampliamente reconocidos como uno de los problemas más difíciles en CS por una razón: todos los cometen. Los errores son parte de la vida de un programador, no algo de lo que deba deshacerse. Un buen programador simplemente sabe qué hacer al respecto. La calidad de un programador NO está determinada por los pocos errores que cometa.
Ahora, si solo selecciona personas que no cometieron errores durante la entrevista, mágicamente no obtendrá un equipo de programadores que siempre escriban un código impecable. Simplemente no sabes cómo se comportarán cuando inevitablemente cometan errores.
Entonces, los errores son realmente buenos, porque aprenderá cómo esta persona los corrige. No juzgues los errores, evalúa cómo los maneja el interlocutor:
- código simple,
- divide y vencerás,
- autoevaluaciones,
- invariantes,
- declaración,
- compilando y ejecutando,
- pruebas.
Oh, perdón por los dos últimos. Olvidé que no les dejas ejecutar sus programas. Bueno, ¿qué esperabas entonces?
¡Dejame revisar!
En serio, ¿qué es escribir un programa en una pizarra?
Quiero decir, estoy feliz de discutir algoritmos, ya que discutir cosas abstractas es más eficiente.
¿Pero escribir programas para programadores reales en un cuaderno? ¿Sin siquiera ejecutarlos? ¿Cuál es el punto de? Obtener el primer borrador del código es solo una décima parte de todo el proceso, seguido de la compilación, la validación, el ajuste, las pruebas, la validación, etc. Estas son partes esenciales del flujo de trabajo de cualquier programador. Es útil mirar el código solo cuando ya ha pasado por todo esto, y no antes.
Es como pedirle al artista que dibuje un caballo y luego detenerlo a la mitad del primer boceto, cuando ves las cuatro líneas verticales de las patas y lo juzgas. ¿Cuánto aprendes sobre ella?
Explora más profundo
¿Cinco entrevistas breves? ¿O dos largos?
Con cinco, obtienes cinco opiniones independientes, que es mejor que dos. Pero, ¿a qué profundidad puedes bucear en 45 minutos? La práctica demuestra que es suficiente escribir de 20 a 30 líneas de código y hacer un par de preguntas realmente simples (¿cuál es la dificultad? ¿Cómo probar?).
El siguiente entrevistador simplemente repite el mismo proceso hasta el anterior. Eso no durará mucho. No por mucho tiempo.
¿Por qué no hacerlos dos y hacerlos realmente sólidos? Por ejemplo, ¿uno antes del almuerzo y otro después? Tres horas tampoco es mucho, pero al menos tienes la oportunidad de ver cómo una persona prueba el código, cómo lo cambia, cómo trabaja con los requisitos, todo dentro del contexto ya establecido, sin reiniciar y comenzando desde cero cada 45 minutos. ...
Con tanto tiempo, incluso puede pedirle que escriba el código como si fuera parte de un sistema, no solo un problema algorítmico abstracto en el vacío, y aprender un par de cosas más sobre sus características reales.
¿Y si quieres más opiniones? Tenga algunos entrevistadores en la sala para que discutan más tarde.
Explore el fondo
Tengo catorce años de experiencia (al momento de escribir este artículo, 2019). Me encantaría hablar sobre programación funcional, sistemas distribuidos, consenso, replicación, coautoría, CRDT, arquitecturas paralelas, marcos de interfaz de usuario, procesos de equipo, diseño de productos, experiencia de usuario. Tengo experiencia práctica y de investigación en todas estas áreas. Todos ellos son de interés directo para más o menos los gigantes de Internet que he entrevistado.
¿Alguna vez me han preguntado sobre esto? No.
Me sale "Imagina que tienes una función que toma una lista ..." cinco veces seguidas. ¿Las cinco tareas a nivel escolar deberían darte una idea adecuada de qué? ¿Qué tan cerca he leído a Cormen et al.? Para ser honesto, rara vez se les pregunta sobre ellos.
En su lugar, personalice su entrevista en función de la experiencia del candidato. Habla sobre lo que hace bien. Tendrá la oportunidad de hacer preguntas profundas y aprender más sobre el nivel de experiencia y los beneficios que traerá a su empresa.
Haz que el proceso sea suave
¿Dirección incorrecta? ¿Entradas retrasadas? ¿Formulario de solicitud que requiere la instalación específica de Adobe Reader original? ¿Un ultrabook barato con una distribución de teclado desconocida y un mal editor web sin atajos que se ralentiza incluso en una máquina local? Lo siento, estoy en la oficina de la empresa de TI más capaz del mundo, ¿verdad?
En mi caso, un reclutador estaba haciendo cinco entrevistas al día. Cinco personas todos los días. Multiplicado por el número de reclutadores de esta empresa. Imagínese que todos estos candidatos están un poco frustrados con el proceso. Cotidiano. Año tras año.
Podrías pensar que no importa. Depende. Hubo un episodio del programa de televisión "Louis" donde el nombre del cómic estaba escrito en su puerta. Por lo tanto, argumentó: sí, este error es fácil de cometer, pero también es fácil de corregir. No importa, es solo por un día, si estás un poco preocupado, hazlo bien.
Sí, creo que cualquiera puede hacerlo mejor.
Por fin
Si contrata ingenieros de software, los profesionales de las grandes empresas no son sus amigos. El sentido común, la justicia, la tolerancia, el interés real y la mentalidad abierta son amigos.
¡Buena contratación!