El GRE sería particularmente ineficaz, ya que es principalmente una prueba de conocimiento. Así que consideremos una prueba escrita con preguntas similares a las que realmente hacen las empresas.
Incluso allí, las pruebas escritas no entregarían la información que las empresas tecnológicas necesitan. Las pruebas escritas lo evalúan sobre la exactitud del conocimiento o de la solución final.
Cuando las compañías tecnológicas le piden que resuelva un problema de codificación / algoritmos, no lo evalúan sobre la corrección o el conocimiento. Le están preguntando un problema complejo y razonablemente largo (cada uno generalmente toma de 20 a 40 minutos) y evalúan cosas como:
- ¿Cuáles son algunas preguntas que un empleador podría hacer sobre Swift durante una entrevista de trabajo para desarrolladores de iOS? ¿Qué tipo de respuestas esperaría él o ella?
- ¿Cuáles son algunas buenas preguntas para la entrevista sobre Linux IPC?
- ¿Son los mismos problemas: encontrar la subsecuencia común más larga de las cadenas originales e invertidas, y encontrar la subsecuencia palindrómica más larga? Si no, ¿cuál es un buen contraejemplo con el que entender?
- Me gusta construir cosas y prepararme para entrevistas técnicas es aburrido, ¿qué debo hacer?
- ¿Hay alguna reunión en línea para codificar la preparación de la entrevista?
- ¿Qué tan óptima es su solución?
- ¿Qué otras soluciones se te ocurrieron en el camino? ¿Cómo pasaste de uno a otro?
- ¿Cuánto tiempo te lleva obtener cada solución?
- ¿Qué tan limpio, legible y mantenible es su código?
- ¿Con qué eficacia probaste tu código?
- Cuando encontraste errores, ¿los arreglaste efectivamente o solo hiciste cambios arbitrarios hasta que lo hiciste bien?
- ¿Cómo te comunicaste durante este proceso?
Todas estas son medidas cualitativas del proceso que está tomando.
Las pruebas escritas simplemente no pueden hacer estas cosas tan bien como una humana.
- Las pruebas escritas podrían evaluar qué tan óptima es su solución al automatizar un montón de casos de prueba. Sin embargo, hacerlo de esta manera eliminaría la discreción humana. Por ejemplo, el código generalmente se diseñó muy bien y es eficiente, pero hay una función auxiliar que es muy lenta. Por lo tanto, su código se ejecuta lentamente, pero generalmente es un algoritmo óptimo.
- Las pruebas escritas realmente no pueden evaluar cuánto tiempo le lleva llegar a cada solución en el camino. Las pruebas escritas pueden medir el tiempo que le lleva presionar “enviar”, pero luego está poniendo al candidato bajo una extraña presión de tiempo. ¿Pasas 5 minutos adicionales revisando tu trabajo? ¿O se presenta ahora y parece que terminó rápidamente?
- Las pruebas escritas no pueden hacer un gran trabajo de la medida subjetiva que es la legibilidad, la limpieza y la facilidad de mantenimiento del código.
- Las pruebas escritas pueden automatizar las pruebas de su código, pero en realidad no pueden juzgar la gravedad de los errores. Supongamos, por ejemplo, que su código para un árbol intercambia las acciones de ramificación izquierda y derecha: se ramificó hacia la izquierda cuando debería haberse ramificado hacia la derecha, y viceversa. Las pruebas automatizadas revelarían una falla total y completa. Un humano vería un error menor.
- Las pruebas escritas realmente no pueden evaluar cómo corrige los errores.
- Las pruebas escritas no pueden evaluar la comunicación de su resolución de problemas.
Las computadoras simplemente no pueden hacer el trabajo que un humano puede hacer.
Y recuerde que la contratación no es el momento para una “solución del 80%”. Las malas contrataciones son increíblemente caras y pocas empresas están dispuestas a externalizar este proceso a un tercero.