Entiendo que para medir un proyecto o código, podemos usar The Joel Test , pero ¿hay alguna prueba estándar simple (como The Joel Test) que pueda medir y filtrar qué tan bueno es un programador?
Mi plan es tener esta prueba como filtro rápido primero antes de pasar a una prueba más detallada.
Respuestas:
Existe la matriz de competencias del programador .
Al igual que con la prueba de Joel, es solo una guía vaga. La única forma de evaluar adecuadamente a un programador es preguntar a los buenos programadores que han trabajado con ellos.
fuente
Daría la vuelta a la prueba de Joel:
¿Han usado el control de fuente?
¿Saben cómo automatizar una compilación de un solo paso?
...
El único que no parece particularmente aplicable es la pregunta de tener probadores. Los otros que parecen un poco desagradables se vuelven así: cómo lo manejamos, cómo lo manejó en el pasado. (Así es como manejamos mantener nuestro horario actualizado, ¿cómo manejó la programación en el pasado?) .
editar:
Básicamente, no obtienes las cosas en la prueba de Joel de forma gratuita, tienes que contratar personas que puedan hacer que suceda. Desea establecer su capacidad para que eso suceda.
fuente
La prueba de Joel es solo una verificación informal de referencia para juzgar rápidamente si un lugar tiene buenas condiciones de trabajo para los programadores. Incluso si obtiene un puntaje perfecto de 10, aún puede ser un infierno que va a la quiebra seis meses más adelante. Un puntaje bajo es una indicación de que algo no está del todo bien y es una excelente pregunta para la entrevista ("Actualmente no está utilizando el control de fuente; ¿hay algún plan para hacerlo en el futuro?"), Y las respuestas podrían ser tales que aceptarías el trabajo a pesar de un bajo puntaje de Joel.
La prueba de Joel tampoco es una prueba 'estándar'; es solo una lista de verificación que Joel Spolsky publicó en su blog.
En cuanto a "medir" la calidad de un programador va; desafortunadamente, las habilidades y cualidades realmente importantes de un buen programador son difíciles o imposibles de cuantificar, por lo que no hay reemplazo para una evaluación humana exhaustiva. Sin embargo, puede eliminar a los candidatos completamente desorientados con bastante facilidad, utilizando una tarea de programación muy simple, idealmente, algo que implique recursividad, estructuras de árbol o punteros (es poco probable que un programador que no los 'entienda' sea de mucha utilidad). Para aquellos que pasan esta prueba, tendrá que evaluar las habilidades manualmente: leer el código que escribieron, probar las aplicaciones que escribieron, darles más tareas de programación (tanto de diseño como de implementación), verlos trabajar, hablar con ellos, ver si puede provocar una discusión profesional. Si está buscando un especialista / gurú de idiomas,
fuente
("You're not currently using source control; are there any plans to do so in the future?"), and the answers might be such that you'd accept the job despite a low Joel score.Por cierto, estaría cometiendo un error al aceptar el trabajo. Finalmente, cada desarrollador aprende que esoPlans to do so in the futurees algo que los entrevistadores dicen para engañarlo, pero que nunca actúan debido a una gestión terrible. ¿Cuántas veces hemos escuchado algo al respectoOh, we are moving towards Agile...y resulta ser otra tienda de cataratas con microgestión?Sí:
En toda mi experiencia, esta sola pregunta es más indicativa de lo bueno que es un programador. Si lo disfrutan; si les apasiona hacer la tarea, entonces serán buenos en eso.
Y, francamente, muchos trabajos de 9 a 5 no implican mucha codificación . No implican muchas iteraciones a través del ciclo de vida del diseño de nuevos programas y ver cómo funciona / falla ese diseño. Sin esa iteración, simplemente no existe la práctica necesaria para que los programadores obtengan habilidades básicas de diseño de programas.
Y no implican mucho aprendizaje. Los programadores que incluso simplemente piratean cosas en casa explorarán soluciones nuevas e interesantes sin las limitaciones de las grandes empresas.
fuente
No es tan detallado como la prueba de Joel, pero pedirles que escriban un programa fizz buzz será una buena indicación para ver si pueden codificar.
http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html y http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers- codificación who-grok /
Eso no le informará sobre la madurez de ingeniería de software de la persona, pero eliminará lo peor.
fuente
Eh, tengo reparo con la redacción al comienzo. No es "¿has usado X" o "¿Conoces Y?", Es una cuestión de usar y hacer realmente. Cualquier programador que no haya tocado o escuchado sobre los elementos de la prueba de Joel simplemente se desconecta y necesita obtener una pista. Pero tienes razón, las tiendas de códigos fallan la prueba de Joel porque las personas en las tiendas dejan que falle. La única defensa que puedo ver corre en la línea de "Lo intenté, pero no tenía la autoridad. Y ahora estoy aplicando aquí".
fuente
Sí, pero
Sí, pero no lo configuré y no lo administro, simplemente lo uso.
No, ese no es mi trabajo.
Me dan una especificación, luego la analizo y produzco documentos relevantes.
No sabes cuáles son las mejores herramientas y si crees que sí, siempre habrá alguien para discutir tu punto.
Si. En realidad, sí y no son muy buenos, pero eso no estaba en la pregunta.
Sí y fallan. Sí y pasan. ¿Qué te dice esto?
No, pero ¿y si hacemos algo mejor?
Para concluir:
Esto no es una queja, pero me interesaría saber qué tipo de desarrollador crees que estoy basado en las respuestas que he proporcionado. Con suerte, esto probará mi punto.
fuente
How do you know whether I pull changes before pushing?Bueno, no sé qué control de origen está usando, pero al menos en SVN, si intenta confirmar en una carpeta con cambios que aún no tiene, la confirmación fallará hasta que ejecute la actualización.