En realidad conocemos planetas de un universo. El hecho de que los planetas que conocemos nosotros sean exactamente los mismos que piden en una job offer es pura casualidad.
Por eso no se puede evaluar en 1 hora de entrevista o en 2 ejercicios el conocimiento de las herramientas que se necesitan.
Por eso muchas entrevistas son una farsa. En realidad lo que conviene es tomar todas las entrevistas y por mas que te vaya mal, estudiar lo que no supiste responder, hasta que contestes todo bien, no debido a una experiencia laboral sino debido a las entrevistas previas.
Es mas, el conocimiento no es critico para el exito en el desempeño laboral. El trabajo de desarrollador no es como poner una torta al horno o cargar facturas, donde la actividad se repite. Si el trabajo se empieza a repetir, lo mas comun es que en breve el desarrollador se harte y renuncie. Asi que en un entorno donde el trabajo inherentemete no repetitivo no tiene sentido hacer entrevistas basadas en conocimiento.
En los entornos más razonables, se entiende que en vez de haber trabajado con cierta herramienta, se haya trabajado con otra, como por ejemplo : git / subversion ; hibernate / spring JPA ; React / Vue ; REST / Web Services ; Apache / nginx ; Oracle / MySql; Laravel / CodeIgniter; eclipse / IntellijIdea
Por otra parte hay ciertos standards que son más comunes en el mercado y que es más común que se utilicen juntos. En ese caso puede que sea natural que ciertas herramientas vayan juntas.
Aún las carreras informáticas no pretenden enseñar todas las herramientas. Más bien indican que aquel que haya aprobado es capaz de resolver cierta complejidad de situaciones en un dominio específico, como puede ser el desarrollo de Software, la medicina, o las leyes.
Algo que me dio resultado a la hora de hacer entrevistas que debían ser breves, es repasar el curriculum del candidato y pedir que me cuente detalles de los proyectos en los que trabajó, siendo claras evidencias de su desempeño 2 factores principales.
1.- El entusiasmo con el que habla de los proyectos, los logros que sintió y lo que hizo para mejorar, o la participación que tuvo para que no se cometa cierto error. También me interesa saber cómo reaccionó cuando algo que propuso no fue implementado de esa manera.
2.- Al mencionarme los proyectos, hago preguntas guiadoras que lleven al candidato a mencionar datos técnicos, que indiquen que realmente puso manos en la implementación. A veces pregunto…
- Y ¿qué hiciste con React js?
- Un sistema de Contabilidad
- Ah… ¿y que otras libraries usaste?
- Varias
- (Aghhhhhhh — eso no lo digo)
Entiendo que el que trabajó y está en una entrevista es un pavo real en un momento en que debería estar interesado en mostrar su plumas. Así que tampoco fuerzo la situación pero trato de encaminarlo a que mencione «palabras» o «expresiones» que el que trabajó con eso generalmente usa en lo cotidiano.
Pero volviendo al tema. Es cierto que no es razonable hacer foco en haber hecho lo mismo a alguien que tiene que efectuar un trabajo que no debe ser repetitivo.