Entonces, he visto ambos lados de esta pregunta y, de hecho, también he estado en ambos lados. En el mundo de la programación parece haber una línea muy fina entre las grandes entrevistas en aras de eliminar adecuadamente a los candidatos y la de mostrar cuánto saben los desarrolladores en el lado de la mesa de contratación.
Por ejemplo, tiene sentido pedirle a alguien que pseudocodifique o incluso codifique legítimamente alguna lógica aplicable al trabajo en cuestión, pero cuestiono la utilidad de que el entrevistador haga una pregunta teórica como "explicar covarianza y contravarianza" o alguna otra pregunta sobre un idioma en el que probablemente solo el equipo de creación del producto esté bien versado (es decir, el equipo de .NET Framework en Microsoft).
Sé que la reacción inicial a esta pregunta podría ser: "Claro, muestra cómo responde un candidato a una pregunta difícil que probablemente no sabrán, bla, bla, bla", o "Si es aplicable, entonces 'Sí'". ." Sin embargo, cada vez más parece que este tipo de preguntas se trata de que el equipo entrevistador le muestre al candidato cuánto sabe. (He estado en ese lado de la mesa cuando mis colegas han hecho esto, y mi pensamiento inicial fue sobre cuán irrelevante era la pregunta).
¿Cómo pueden ser útiles este tipo de preguntas tecnológicas detalladas en una situación de entrevista?
No se trata necesariamente de ego.
Tiendo a tratar de indagar y encontrar algo que la otra persona no sepa, solo para ver si intentan fanfarronear o si honestamente solo dicen "no, no me he encontrado con eso antes... ¿qué es? " (ese último bit para puntos de bonificación). Sin embargo, no me esfuerzo mucho y nunca humillo a un candidato. Ni siquiera quiero que se sientan humillados por el resto de la entrevista. Sólo quiero saber cómo reaccionan ante algo que no saben.
Sin embargo, he visto entrevistar a un par de desarrolladores que claramente solo estaban presumiendo. Esos casos eran obvios porque hacían preguntas de una lista y luego balaban la respuesta en voz alta cuando el candidato se equivocaba.
Sin embargo, algo interesante: ninguno de ellos era particularmente buenos desarrolladores. Me pregunto si estaban sobrecompensando. O tal vez prolongar las porciones de trivia, donde las respuestas estaban justo frente a ellos, para evitar quedar atrapado en una conversación técnica más fluida (que es donde me gusta hacer una entrevista).
Si bien estoy seguro de que hay desarrolladores que quieren presumir en una entrevista, en la gran mayoría de los casos en los que he visto a personas hacer preguntas "imposibles" en una entrevista, la intención no ha sido maliciosa. En cambio, el problema ha sido que las personas en general, y los desarrolladores en particular, son muy malos para saber de antemano qué tan fácil puede ser una pregunta y qué tan probable es que un desarrollador competente pueda proporcionar una respuesta creíble. En general, se necesitan bastantes candidatos que parecen competentes pero que están totalmente desconcertados por una pregunta en particular para que el entrevistador se dé cuenta de que el problema es la pregunta, no los candidatos.
Cuando los desarrolladores pasan bastante tiempo en un nicho muy particular, interactuando con otras personas que también se concentran en ese nicho en particular, se vuelve muy fácil olvidar el tipo de cosas que uno da por sentado en esas conversaciones que serían un desafío para un desarrollador competente en un nicho diferente. Cuando me entrevisté con una empresa de comunicaciones, por ejemplo, uno de los ingenieros tenía toda una serie de preguntas relacionadas con la codificación de Huffman.. Hubo un problema en una tarea en una clase en mi carrera universitaria donde la codificación Huffman surgió de pasada y no había pasado ningún tiempo contemplando el algoritmo o por qué estaba estructurado de una manera particular, así que estaba muy fuera de mi profundidad tratando para responder a esas preguntas. Sin embargo, para el entrevistador, que pasó mucho tiempo lidiando con algoritmos de compresión en general, la codificación de Huffman parecía algo tan básico que cualquier estudiante competente debería haberlo internalizado para comenzar a lidiar con el tipo de problemas que estaba tratando. Tratando con. Dudo que intencionalmente intentara parecer inteligente frente a un grupo de nuevos graduados, simplemente no se le ocurrió que los algoritmos de compresión de señales no son un nicho en el que la mayoría de los desarrolladores tienen mucha experiencia, a menos que estén trabajando para las principales empresas de comunicaciones. Apostaría a que una vez que un par de docenas de personas bombardearon por completo su parte de la entrevista mientras les iba razonablemente bien en otra parte, se dio cuenta del problema y ajustó sus preguntas.
jcmeloni