Los entrevistas de trabajo son un problema. Aparentemente, pueden determinar si un profesional es apto o no. La realidad es que no son precisas.
En una entrevista técnica tienes a dos personas reunidas. El objetivo del solicitante es conseguir el empleo, y el del entrevistador es decidir si la persona es o no apta. Para esto se dispone de una hora de tiempo, en algunas ocasiones un poco más. Este es un escenario complicado.
¿Cómo puedes determinar las habilidades de una persona en una hora?.
En el caso de un programador se tiene la posibilidad de asignarle code challenges. Estas pruebas son ejercicios de programación con un grado de dificultad de sencillo a experto. Estos pueden a ayudar a determinar el nivel de un candidato. No son determinantes, no todas las personas son buenas bajo presión, y, el escenario de resolver un problema de la forma más eficiente con poco tiempo ni siquiera es real.
También, adicional al challenge, tenemos la entrevista de preguntas técnicas. Una serie de preguntas técnicas que buscan mapear tu nivel de habilidad. Las respuestas esperadas pueden ser abiertas o cerradas. No siempre habrá una respuesta exacta para la pregunta. El entrevistador puede determinar si la respuesta es correcta o no basado en su experiencia subjetiva. Y, aun teniendo preguntas cerradas, ¿qué preguntas podrían determinar el nivel técnico del candidato?.
La mayoría de las preguntas técnicas son estériles.
Como profesional, se espera que tengas un nivel aceptable de conocimientos. Pero, esto no implica tener que saberlo todo al dedillo. Muchas preguntas se enfocan en un aspecto técnico, especifico, muy específico, que en la práctica no aporta valor o no representa tu nivel de habilidad.
Por ejemplo. Recientemente, falle una entrevista, obvio, no conteste las preguntas de acuerdo a lo esperado. Me preguntaron la diferencia entre un INNER JOIN y un LEFT JOIN. Recordé que el INNER es la intersección, pero no estaba seguro del LEFT. No tenía claro que elementos se conservaban, si los de la izquierda o la derecha. Mejor decidí no gastar mi tiempo en una pregunta trivial.
Claro, entiendo el funcionamiento de los joins como operaciones sobre conjuntos y subconjuntos. Las diferentes variantes de joins no son más que un grupo de operaciones aplicadas a conjuntos. Cuando necesita aplicar un JOIN en específico, solo busco el diagrama y aplico el cruce de datos que necesito.
Supongo, esta pregunta influyo en que no me contrataran. Falle en una pregunta básica. Desde mi perspectiva, la pregunta no tenía peso, ni relevancia. Si me hubieran preguntado el fundamento en el cual se basan los cruces en las bases de datos relacionales, claro que hubiera podido responder. No hubo tal pregunta, nos quedamos en los joins.
Preguntas jaque mate.
Si realizas suficientes entrevistas, te vas a encontrar con preguntas de difícil solución; pensadas justo para romperte. La mayoría de estas preguntas ni siquiera son usadas a diario; como comparaciones de objetos en JavaScript, números primos, operaciones sobre estructuras de datos, optimización de árboles, hipotéticos casos de optimización, etc. Si no te sabes alguna pregunta de estas, no te sientas mal, anótala y trata de encontrar la respuesta para que no te vuelvan a sorprender.
Por ejemplo:
- Si comparo {} con [] en JavaScript, ¿obtengo true o false?.
- ¿Cómo vuelvo síncrono un método asíncrono?.
- ¿Cuándo debo emplear un ref struct en C#?
Las preguntas también evidencian tu ignorancia.
En la ya mencionada entrevista que tuve explicar que es MVC. Cosa que tenía presente, puesto que lo he utilizado antes. Bueno, no fui capaz de responder. Al tratar de formular mi respuesta solo respondí con una retalía de incoherencias.
Como humanos tenemos una condición evolutiva que nos ayuda a trabajar con información incompleta. No necesitamos conocer al cien algo para poder ocuparlo. Cuando tratas de explicar algo que mapeas, pero no dominas completamente vas a descubrir que tienes faltantes de conocimiento. Ahí es donde debes trabajar. El entrevistador técnico te puede ayudar a detectar carencias de conocimiento.
Si esto te sucede, no te lo tomes a mal y acepta tu error. Son cosas que tendrás que tener preparadas para tu siguiente entrevista.
Te irá mal en muchas entrevistas técnicas.
Las entrevistas son asunto de números, entre más hagas más posibilidades tienes que te contrate alguien, pero, también significa que tendrás muchos rechazos. Esto es normal. No tienes que sentirte bien con que te rechacen; sin embargo, debes aprender a lidiar con la frustración. Las entrevistas no reflejan tu nivel, puede que seas muy bueno y por causas externas tengas un mal desempeño.
Hace tiempo, en mi equipo, necesitábamos llenar una vacante para un desarrollador. Nos llego un Curriculum de un recomendado; no había gente disponible para entrevistar, así que decidimos entrevistarlo. Augusto es su nombre. La primera entrevista técnica que tuvimos con él fue fatal, no fue capaz de responder a la mayoría de las preguntas; estaba nervioso, se notaba. En conclusión, fue rechazado por no tener el nivel técnico.
Luego de unos días nuestro manager nos pidió darle una segunda oportunidad a Augusto, a lo cual accedimos. En la segunda entrevista volvió a hacerlo fatal. Basándonos en solo la información de las entrevistas, Augusto, de ninguna manera, estaba capacitado para el trabajo.
Después de su segundo intento, contactamos a la persona que nos lo recomendó para saber cuál era el problema. El problema se intuía, Augusto es malísimo para las entrevistas, se pone nervioso y se bloquea. Al no tener más candidatos y con la recomendación de alguien de la empresa decidimos darle una oportunidad. Fue una buena decisión. Augusto es un dev muy bueno, independiente y aprende muy rápido. El cliente lo tiene en buena estima, y su trabajo es de excelente calidad.
Él me dejo de lección esto, que las entrevistas técnicas no siempre son exactas en determinar el valor que puede aportar una persona. Desgraciadamente, el único mecanismo cien por ciento eficiente para determinar si una persona está al nivel es poner a la persona en el trabajo. No siempre esto es posible, va a haber personas que pueden aportar valor a la empresa que no sean capaces de demostrarlo y se queden en los filtros.
Conclusiones.
Fallar estrepitosamente una entrevista técnica es parte de la profesión. O ya te paso o te pasará. Te recomiendo hacer una evaluación interna, reflexiona que hiciste mal, que hiciste bien, y que parte de lo que no respondiste bien puede aportar valor. No tienes que saberlo todo al momento de ser entrevistado, habrá preguntas que te puedes dar el lujo de no saber. Si te fue mal, date un tiempo para lidiar con la frustración y vuélvelo a intentar en otro lugar.
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
