¿Cómo podemos calificar las preguntas objetivas de la prueba escrita C Embedded?

La respuesta a esto probablemente dependa del tipo de rol que tenga en mente, el conjunto de habilidades que está buscando y la cantidad de solicitantes que espera ver.

La mayoría de las “pruebas de competencia” escritas que he visto fueron peores que inútiles. Lo que ocurre comúnmente es que un gerente de contratación le pide a su mejor desarrollador que escriba una prueba y proporcione ejemplos de respuestas. El desarrollador visita algunos sitios “C ofuscados” y Stack Overflow para encontrar algunos “problemas” y los pone a prueba. Tales pruebas son inútiles como herramientas de detección, y en realidad son solo una guía para la presunción y la actitud de superioridad del autor de la prueba.

Si logra evitar esta trampa, el siguiente problema es que generalmente hay muchas formas de responder la mayoría de las preguntas, lo que significa que la única forma justa de calificar las respuestas es hacer que un programador competente las revise. Para un gran número de solicitantes, esto realmente no escala.

El tercer problema se relaciona con la discriminación. Muchas “pruebas de programación” están sesgadas hacia graduados recientes que generalmente son buenos para memorizar y reproducir respuestas de “estilo de examen” donde los programadores más experimentados adquieren el hábito (correcto) de buscar las cosas estándar cuando lo necesitan. No tengo ni idea de cómo codificar un árbol rojo-negro, pero sé dónde buscar esta información y también sé que en realidad estaré mejor el 99% del tiempo usando un contenedor estándar biblioteca o similar.

Aquí está mi sugerencia.

Tenga algunas preguntas de “conceptos” que requieren un párrafo o dos de respuesta. Pídale a un programador que proporcione una lista de “puntos clave” que se esperaría en una buena respuesta.

Tenga algunas preguntas de “diseño” que requieran que el candidato demuestre conocimiento de cuestiones clave de diseño, como el manejo de interrupciones, el enhebrado y la sincronización. Nuevamente, está buscando “puntos clave” en la respuesta.

Solicite una solución a un solo problema en forma de código fuente + makefile. Sea muy específico con las instrucciones sobre cómo desea construir, p. Ej.

  • Todo el código debe estar en un único directorio llamado “muestra”
  • La aplicación de muestra completa debe construirse llamando a “make”, y debe generar un archivo ejecutable llamado “sample”.
  • La aplicación de muestra debe aceptar la línea de comando “sample —input —output
  • Describa el formato de los archivos de entrada y salida. En particular, describa datos de entrada válidos y el comportamiento cuando los datos no son válidos. Del mismo modo con la salida.

Luego puede escribir scripts que compilarán y ejecutarán las aplicaciones enviadas y verificarán la salida de diferentes conjuntos de entrada.

Si lo anterior parece demasiado trabajo, sitios como Topcoder ofrecen una buena alternativa.