¿Es “Explique el lenguaje RAII” una buena pregunta de detección de C ++? [cerrado]

Una compañía con la que trabajo me ha pedido que haga pruebas de teléfono de candidatos para asegurarme de que no se avergüencen por completo al enviar a alguien a un cliente potencial.

Resulta que un buen número de personas fueron ubicadas para un rol de desarrollador de C ++. No paso mucho tiempo en C ++, pero he realizado algunos proyectos triviales y no triviales en el lenguaje. Pensé que "Explicar el idioma de RAII" sería una buena pregunta de softball que los desarrolladores más serios de C ++ podrían responder mientras estaban medio dormidos, y me permitiría pasar a preguntas más interesantes sobre la experiencia. Pero resulta que las personas que tienen más de 10 años de experiencia en C ++ no reconocen el término, incluso si amplío el acrónimo a "Adquisición de recursos es inicialización". Un candidato llegó a decir que sentía que no siempre era práctico aplicar la técnica en el desarrollo de Windows, lo cual pensé que era un sentimiento extraño, pero pude ver un par de ejemplos que posiblemente respalden esa línea de pensamiento.)

Incluso un par de desarrolladores de C ++ que conozco lo suficientemente bien como para juzgar su competencia dijeron que no reconocían el término, pero al leer un resumen de la técnica, dijeron "Oh, sí, no sabía que tenía un nombre. Simplemente pensó en esas cosas como algo que solo tienes que hacer ". Recuerdo el término de la segunda edición del libro de Stroustrup, a pesar de que el impacto total no se absorbió en ese momento.

Entonces, es "¿Puedes explicarme el idioma de RAII?" ¿Una pregunta de evaluación justa? ¿Es razonable esperar que todos los desarrolladores competentes de C ++ lo entiendan? ¿Es el término más esotérico de lo que yo pensaría? Suponiendo que un candidato no conoce el término, ¿hay preguntas de seguimiento que podrían ayudarme a descubrir si al menos han internalizado las prácticas que hacen que funcione la RAII? ¿Existen mejores preguntas alternativas "de desvanecimiento" que le den al candidato cierta flexibilidad para responder y lo ayuden a demostrar su comprensión del desarrollo de C ++?

Edición para agregar : Para aclarar, no soy el tipo de entrevistador que descalifica a las personas porque no conocen palabras de moda y siglas. Sin embargo, creo que es razonable esperar que un programador experimentado de C ++ haya internalizado buenas prácticas para la gestión de recursos. También creo que es importante verificar que un candidato comprenda algunos "conceptos básicos" sobre la tecnología en la que afirma tener experiencia antes de pasar a preguntas más interesantes sobre diseño, resolución de problemas, etc. Creo que lo que estoy buscando es una buena manera para hacer una pregunta abierta, adecuada para su uso en una breve revisión telefónica, que puedo usar para juzgar la comprensión básica de un candidato de las buenas prácticas de gestión de recursos en C ++, antes de hacer preguntas "difíciles".

Parece que descubrió que los desarrolladores de C ++ que conoce por experiencia son competentes y no están familiarizados con ese acrónimo o incluso con la expresión completa. Eso por sí solo parece indicar que la pregunta no es adecuada como pregunta de detección durante una llamada telefónica.

Por otro lado, podría llegar al mismo punto a través de una forma más indirecta presentando un escenario. Algo así como: "Está implementando una clase Log que escribirá información de registro en un archivo. Obviamente, necesitará tener una variable miembro que sea un identificador de archivo (std :: FILE *). ¿Dónde asigna y libera este archivo? ¿encargarse de?" Si el candidato comienza a hablar de crear un método open () y close () en lugar de asignar el identificador de archivo en el constructor y desasignar el identificador en el destructor, puede continuar preguntando cosas como cómo se comportaría su clase si el el código de llamada generó excepciones, etc.

No creo que sea una pregunta práctica como se propone. Creo que encontrarás que muchos desarrolladores caerán en el campo "oh, sí, no sabía que tenía un nombre". Te sugiero que pruebes a los candidatos con el concepto y no con el nombre del concepto. Déles un ejemplo de código y pregúnteles por qué está incompleto o pídales que demuestren que conocen el concepto.

Creo que es una pregunta válida. Aunque no sé qué tan popular es el término RAII (en mi equipo, usamos el término RAII todo el tiempo), pero el concepto de manejo de recursos es importante, especialmente si también quieres seguridad de excepción y seguridad de subprocesos múltiples. .

Bueno, sé que cuando quiero saber si alguien es competente, lo primero que hago es verificar su conocimiento de las siglas. Una vez establecido, me aseguro de que sepan los nombres de otras tecnologías que creo que suenan bien. Si todavía están allí después de eso, les pido una lista de sus colores favoritos.

No puedo soportar este tipo de cosas. Quiero decir, al final de la entrevista, son sirenas y campanas de advertencia. No quiero trabajar en un lugar donde realmente importa que conozca mnemotécnicos extraños que mi jefe piensa que son "fundamentales". No puedo molestarme en aprender los nombres de personas con las que he tratado durante años, así que estoy seguro de que no malgastaré el espacio del cerebro con lindos acrónimos que describen las mejores prácticas.

Mira mi codigo. Pregúntame cómo haría las cosas. Dibujaré basura en una pizarra hasta que las vacas lleguen a casa. Te codificaré una aplicación. No me hagas preguntas triviales de mierda. La trivia siempre es impredecible, y nunca es fundamental.

Si su propósito es eliminar rápidamente a los incompetentes totales, intente algo como esto:

Prueba FizzBuzz

Luego, puede dejar los conceptos y prácticas de C ++ a quienes estén en una mejor posición para evaluar la experiencia en C ++.

Es una pregunta válida, pero no para la detección. Lo usé como una pregunta escrita, para ser discutido en la entrevista. Puede obtener mucha información sobre los patrones de pensamiento con previo aviso. Como pregunta de detección, es solo una trampa desagradable.