¿Las entrevistas técnicas tienden a ser subjetivas? [cerrado]

Según mi experiencia en entrevistas técnicas, he descubierto que la mayoría tiende a ser subjetiva porque el entrevistador ya tiene su propia respuesta. Aunque la respuesta del candidato es correcta, porque el entrevistador no estaba preparado para esa respuesta, el candidato no consigue el trabajo.

En una entrevista reciente, dije algo sobre el uso de un algoritmo de árbol AVL para resolver un problema específico que se le preguntó. El entrevistador respondió: "¿Qué es un árbol AVL?". Otro ejemplo es cualquier cosa relacionada con la sintaxis; Encontré esto principalmente en entrevistas que requieren código Ruby porque hay muchas formas de implementar una solución a un problema dado. Una muy común son los problemas relacionados con los diseños orientados a objetos.

En esta situación, no hay forma de que el entrevistado tenga éxito. ¿Alguien más se ha sentido así o solo soy yo? Si no soy solo yo, ¿cómo podemos mejorar las entrevistas técnicas?

Creo que sus propios puntos ciegos lo están llevando a una suposición que no es válida en cuanto a por qué no obtiene el trabajo.

Es posible responder todo correctamente en una entrevista de trabajo y no obtener el trabajo porque está compitiendo contra otras personas que también pueden haberlo hecho todo correctamente. Cuando solo tienes 1 trabajo y tres personas que crees que pueden hacer el trabajo, solo puedes contratar uno. Es un mercado difícil y mucha gente experimentada está buscando. Nunca se sabe qué tan bien le fue a su competencia en sus entrevistas.

Sí, las entrevistas son subjetivas, buscan personas que no solo tengan habilidades técnicas, sino que encajen en el grupo existente. Sigue intentándolo eventualmente si eres capaz, encontrarás el lugar correcto y te contratarán.

Cualquier entrevistador que despidió a un candidato simplemente porque no dio la respuesta esperada es un pobre entrevistador. Si una empresa fomenta esto y tengo esa sensación en una entrevista, es una señal de alerta seria sobre el equipo y la empresa que me entrevistan.

Si un entrevistado me proporcionó una respuesta en la que no pensé, esperaría que él pudiera explicar cuál es la solución utilizada y las ventajas / desventajas de la misma. Como dijiste, a menudo hay múltiples soluciones, que van desde elegir un algoritmo hasta las estructuras sintácticas utilizadas, y casi siempre hay compensaciones involucradas. Incluso probaría al entrevistado en busca de soluciones alternativas para ver si pueden encontrar otras, especialmente si es una solución obvia, y pediría las ventajas / desventajas de cada una.

Independientemente de cómo realice la entrevista, será subjetiva. Cada entrevistador, como persona, tendrá prejuicios. Como entrevistado, puede hacer lo mejor que pueda, ser minucioso (pero no excesivamente detallado) al responder preguntas y explicar sus respuestas y cómo llegó allí. Eso te llevará un largo camino.

Una que encontré recientemente es cuando dije algo sobre el uso de un algoritmo de árbol AVL para resolver un problema específico que se me preguntó. El entrevistador me preguntó de nuevo: "¿Qué es un árbol AVL?".

Como entrevistador, también pediría eso, incluso si supiera todo sobre los árboles AVL (no lo sé), para averiguar cuánto sabe el candidato. Fingir ignorancia puede ser un truco para ver si el candidato puede explicar bien. Pero obviamente, si se te ocurre un algoritmo / estructura de datos que resuelva el problema, que no sé, y que puedas explicar adecuadamente, te contrataría. De lo contrario, lástima de mí. No contratar personas porque son más inteligentes que tú no es una buena estrategia de contratación.

Pero en términos generales: sí, las entrevistas técnicas son siempre subjetivas. Y tienen que ser. Si vas a pasar más de 8 horas todos los días con una persona, no sería razonable elegir a alguien que logre volverte loco en una entrevista de 60 minutos.

Las preguntas de trivia son antipatrones para las entrevistas. Si se encuentra atrapado en una entrevista de este tipo, intente dirigirlos a lo que sabe. Concéntrese en su currículum. Si esto no funciona ... bueno, considere buscar en otro lado.

Los entrevistadores deben hacer preguntas abiertas relacionadas con su currículum. Si bien es posible tener una idea de las habilidades de comunicación de una persona, es difícil evaluar las habilidades de desarrollo de una persona simplemente haciendo preguntas. Esa es en parte la razón por la que tanta gente (incluido Joel en software) recomienda que los entrevistados no requieran que escriban código (y salten a través de otros aros para el caso).

El hecho es que el desarrollo de software todavía se trata principalmente de resolver un conjunto desconocido de problemas en una cantidad de tiempo desconocida. No hay un conjunto de pruebas que prueben, ok, este tipo puede construir "un puente". Estamos mejorando para convertir la creación de software en un proceso de ingeniería más definido, pero aún no hemos llegado.

Las entrevistas técnicas "reales" que tuve fueron: "Aquí está el problema, use estas tecnologías, tiene 3 horas". Después de eso, hicimos una revisión del código y hablamos sobre por qué hice lo que hice. De esta manera él vio lo que ya sé y dónde me falta conocimiento.

Luego hablamos un poco sobre las tecnologías y mis objetivos en general y eso fue todo. Las entrevistas están, en mi opinión, diseñadas para tener una idea del candidato. No puedes probar todo. Se necesita mucho tiempo para conocer a alguien bastante bien, por lo que, nuevamente en mi opinión, debe centrarse en las cosas que son importantes para su proyecto y ver cómo las personas manejan estos problemas. El resto viene con la experiencia a lo largo del tiempo.

Tengo miedo de que la parte subjetiva no se pueda eliminar, solo disminuir. Frecuentemente tengo entrevistas técnicas, donde el entrevistador "contamina" la entrevista con sus propias ideas subjetivas.

Un ejemplo simple, como usted menciona, es que el entrevistador quiere una respuesta muy cercana a su propia respuesta. Otro ejemplo es, cuando un entrevistador está más interesado en investigar, él / ella sabe más que el candidato. Y otra simple es cuando el entrevistador quiere que el candidato conozca la ubicación específica del menú para una operación de un IDE de programación (Visual Studio, Eclipse, NetBeans).

He estado en varios así, y es muy frustrante.

Y, por supuesto, también está la cuestión de la discriminación oculta, donde el entrevistador no quiere que el candidato sea pobre, género, ideas políticas, raza, escuela, lo que quiera. Y está buscando cualquier excusa para rechazar al candidato.

La parte más extraña es que, como graduado de CS, conozco algo de psicología (iba a estudiar esa profesión) y, a veces, detectaba mucha de la "interferencia" subjetiva. O, cuando el entrevistador va a la oficina de al lado y les dice explícitamente a sus compañeros de trabajo, él / ella no quiere contratar a un candidato, por una razón subjetiva.

Algo importante, a tener en cuenta, es que muchas Universidades, o Empresas, enseñan a las personas de TI / Técnicas cómo hacer entrevistas de trabajo, y esa enseñanza incluye tanto factores técnicos como humanos, no solo técnicos.

Así es como lo hago:

• Primero le pido al candidato que resuelva un problema realista. Por lo general, este es un problema que puedo resolver fácilmente; generalmente en mucho menos que el tiempo asignado.

• Una vez que el candidato haya terminado; Me convierto en el alumno . Pido al candidato que hable y señale su solución y me muestre cómo lo resolvieron. Les hago preguntas sobre sus ideas, y si saben de soluciones alternativas, y por qué eligieron esta solución en lugar de eso.

Esto es lo que estoy buscando.

• El hecho de que conozca una buena solución al problema no significa que esté buscando esa solución. Cualquier solución válida dentro de las restricciones iniciales es aceptable. Estoy interesado en cómo planearon su solución, cómo usaron las herramientas proporcionadas. Me interesan las deficiencias que pueden identificar en sus propias soluciones.

• También me interesa lo bien que escuchan y se comunican. ¿Pudieron entender e implementar todos los requisitos iniciales? ¿Qué tan bien explicaron cómo funciona su solución?

Al final de todo esto, una vez que tenga una buena idea de lo que el candidato realmente está aportando a la apertura, podría ofrecer algunos de los puntos de mi propia solución, donde creo que mis opciones serían mejores.

Si el candidato dice algo como "Esa es una buena idea, desearía haber pensado en eso" o "Oh, no sabía sobre esa técnica", o incluso "Pensé en eso, pero usé esto en su lugar" y proporciona una razón sensata como "entiendo mejor este método" o "pensé que estabas buscando este tipo de solución", todos estos cuentan fuertemente a favor del candidato.

Si resulta que el candidato eligió de manera diferente a mí, podría significar que estoy equivocado. O si estoy en lo cierto, y el candidato es lo suficientemente abierto como para discutir las diferencias en las soluciones, es una buena señal de que el candidato puede ser empujado con bastante facilidad para tomar mejores decisiones.

Así es como sé que un candidato es una mala elección:

• el candidato intenta buscar una solución esperada del entrevistador.
• la solución provista no resuelve el problema declarado, o de alguna manera viola algunas de las restricciones establecidas de una manera que el candidato no puede explicar.
• el candidato argumenta con las limitaciones para tratar de cambiar el problema que espera resolver (recuerde que este es un problema para el cual tengo una solución que se puede implementar en mucho menos tiempo que el asignado).
• el candidato se "atora" y pasa gran parte del tiempo asignado sin hacer nada. Idealmente, un candidato atacaría el problema desde otro ángulo o buscaría al entrevistador para saber qué debe hacer cuando no puede continuar.
• el candidato no sabe "por qué" utilizó una técnica, incluso si no conoce alternativas. Respuestas como "No conozco ninguna otra herramienta que haga esto" o "No sé cómo funciona esta herramienta, pero lo hace" están bien, pero "porque lo hice" son cuestionables.

¿Crees que, como entrevistado, tu aceptación de un trabajo no es subjetiva, hasta cierto punto? El reclutamiento es un proceso de dos vías.

Como entrevistador, si yo y mis colegas "hacemos clic" con un candidato, tienen una buena oportunidad de postularse para el trabajo, suponiendo que otros factores, como un ejercicio de codificación en el hogar y problemas de pizarra, funcionen bien. Hacer "clic" es estar en mi longitud de onda, tener una conversación fructífera, compartir valores comunes sobre el proceso de desarrollo. ¿Cuán objetivo puede ser esto?

Sobre la cuestión del árbol AVL, me interesaría que el candidato explique cómo funciona y proporcione información sobre las propiedades y el uso. Para hacerlo mejor que la explicación en Wikipedia. Tenga en cuenta que su audiencia puede ser alguien en un entorno empresarial corporativo donde la última referencia a O (log n) en una discusión técnica fue básicamente ... nunca.

Como entrevistador, quiero darle a un candidato todas las oportunidades para brillar. Me imagino que esto se aplicaría a cualquier organización para la que desee trabajar.

Un buen entrevistador no hará una pregunta donde espera una respuesta específica, a menos que la pregunta sea algo trivialmente simple donde solo haya una respuesta correcta. Un buen entrevistador verá cómo abordas un problema, cómo lo piensas y cómo llegas a tu respuesta: si tu respuesta es válida, no debería sostenerte en tu contra porque no hiciste las cosas como lo harían. .

Parece que acabas de ser sometido a malos entrevistadores más preocupados por mostrar su "superioridad" al candidato que por evaluar la habilidad técnica.

Una habilidad muy importante cuando trabajas en equipo es poder justificar tu propia solución y evaluar de manera justa la de otra persona. Debe poder aprender de sus colegas y enseñarles.

Si desea utilizar un árbol AVL para resolver un problema, y ​​los otros miembros de su equipo los recuerdan vagamente de la universidad y no lo han pensado desde entonces, es mejor que pueda explicarles sus ventajas. Si alguien presenta una solución que no comprende, será mejor que esté dispuesto a hacer preguntas hasta que lo haga. Si alguien presenta una solución claramente inferior, será mejor que puedas articular por qué. Si alguien presenta una solución superior, será mejor que puedas reconocer eso y dejar a un lado tu ego.

Esas son las habilidades que busco cuando hago una pregunta técnica en una entrevista. Si se les ocurrió la respuesta "correcta" en la parte superior de su cabeza es en gran medida irrelevante. Eso solo es importante en la escuela.