El formato de entrevista que yo prefiero es muy conversacional; que empiece a contar un poco qué viene haciendo, qué le llamó la atención de la empresa (angulando hacia lo técnico, gradualmente). Si la entrevista es luego de un ejercicio, podés indagar preguntas abiertas que te orienten a cuál es el proceso de toma de decisión que tiene la persona. Pregunta clave que ayuda a determinar seniority ahí es: si hubieses tenido 1 día laboral completo extra para continuar el ejercicio, ¿qué hubieses priorizado? Si te dice "testing" y le falta terminar la mitad del proyecto, hay algo para pensar.
Desde mi punto de vista, preguntar cosas como la diferencia entre bind, apply y call (es decir, tecnicismos específicos de un lenguaje tan fiero como JavaScript) es hacerle pasar un mal rato a la persona y perder tiempo tanto la persona como quien entrevista. Si te toca una persona que charla mucho, podés escuchar todo lo que tenga que decir y ver cómo conecta conceptos. Ejemplo, la persona se manda a hablar sobre cómo le gusta la semántica de HTML5 y microdata... le podés preguntar y qué beneficio le ves a aplicar esos estándares?. Creo que la clave es jugar con lo que te cuenta.
Me pasó de conocer a un pibe que era ingeniero automotriz y decidió empezar frontend luego de estar 6 meses aprendiendo por su cuenta. El chabón aprendía a una velocidad importante y hacía, hacía y hacía. Muchas veces no estaba seguro de estar haciendo las cosas bien, pero la curiosidad que tenía era fantástica. Esto vale boooooooooooooocha, mucho más que cualquier expertise técnico (si las circunstancias del proyecto al que se piensa introducir lo permiten).
Si te habla mucho de frameworks... para mí es un warning eso, porque posiblemente sea un React/Ember/Angular/Vue/zaraza dev y no sepa Vanilla JS, o conozca muchos conceptos como reductores y funciones puras, y no entienda su uso fuera de React, por ej. Atenti a esas cosas.
- Un junior te va a tirar la primera/segunda solución que se le ocurra a un problema, y te va a hablar desde detalles de implementación. Probablemente te meta un montón de complejidad innecesaria para resolver un problema chico, y se ahogue en un vaso de agua con un problema más abstracto. Generalmente les cuesta pensar en reutilización y son propensos a repetir patrones. Priorizan ejecución antes que calidad. Salvo raras excepciones, necesita acompañamiento para confirmar cómo encarar las cosas. Dependiendo de cómo venga su carrera y sus intereses, puede ser más moldeable.
- Un semisenior puede moverse de forma más autónoma, y te tira una idea en mocks antes de sentarse a codear. Empieza a reflexionar un poco más sobre cómo producir código relativamente reusable, por ahí se pierde en específicos. Puede proponer, pero sigue necesitando un poco de confirmación de parte de pares o devs con más experiencia.
- Un senior te puede hacer planteos de reutilización y pensar generalizaciones. Puede ejecutar rápido y planificar con anticipación qué hace falta e iterar con facilidad.