En mi experiencia, antes de comenzar a trabajar para una empresa, no tiene la oportunidad de mirar el código base (he preguntado y por razones de confidencialidad todos siempre han dicho que no, creo que es justo), así que durante el proceso de la entrevista, qué ¿crees que son las preguntas más importantes para averiguar en qué tipo de estado se encuentra el código (después de todo, si es un perro, entonces estarás entre los desafortunados pobres que tienen que caminarlo todos los días)?
ACTUALIZAR:
Una lista de verificación: preguntar;
- Lo que piensan de la base de código. Y cuando lo haga, preste mucha atención a las expresiones faciales y al tiempo que les toma responder. [Luego]
- ¿Cuál es el nivel CMM de la empresa [DPD] (y si escucha que el Nivel 5 se ejecuta en sentido contrario [Doug T])
- Qué ciclo de vida usan [DPD] (Y si escuchas "Agile", es cuando comienzas a hacer algunas preguntas penetrantes para tratar de descubrir si por "Agile" se refieren a "Agile o" codificación de vaquero "[Carson63000])
- ¿Qué herramientas usan para evaluar la calidad del código? [DPD]
- ¿Qué herramientas usan para el desarrollo? [DPD] (Busque herramientas de refactorización y servidores de compilación continua)
- Qué sistema de código fuente (control de versiones) usan, y un buen seguimiento es preguntar por qué lo usan. [Zachary K].
- ¿Cómo son sus procedimientos de prueba? [Karl Bielefeldt] (Busque especialmente los equipos que usan marcos de trabajo burlones y ponga énfasis en pruebas de unidades automatizadas exhaustivas a través de marcos establecidos como NUnit / JUnit; no se desanime por los equipos que no usan TDD de desarrollo basado en pruebas, pero sea Tenga cuidado si no consideran que las pruebas son parte integral y la piedra angular del desarrollo de software sólido. Busque equipos con evaluadores dedicados).
- ¿Qué tipo de tareas se asignan a los nuevos desarrolladores? ¿Para desarrolladores experimentados? [Karl Bielefeldt]
- ¿Cuántas personas trabajan en un proyecto? [Karl Bielefeldt]
- ¿Se permite la refactorización? ¿Alentado? [Karl Bielefeldt]
- ¿Qué procesos relacionados con la calidad o cambios de arquitectura se están considerando o se han realizado recientemente? [Karl Bielefeldt]
- ¿Cuánta autonomía tienen los individuos sobre sus módulos? [Karl Bielefeldt]
- ¿Desarrollará proyectos más nuevos (desarrollo greenfield) o proyectos heredados (desarrollo brownfield)? (El desarrollo de Greenfield es generalmente más divertido y tiene menos problemas ya que no está limpiando los errores de otra persona).
- ¿La tasa de rotación de empleados es alta en la organización o en el equipo? (Esto a menudo indica una calidad de código inferior) [M.Sameer]
- Algunos problemas de programación propios; pero evita parecer un imbécil. [Sparky]
- ¿Cómo colaboran los desarrolladores y cómo se comparte el conocimiento entre el equipo? (Esto debería coincidir con su personalidad; diría que una combinación de trabajo en solitario y en pareja es probablemente la mejor, con la proporción que coincida con sus necesidades sociales)
- ¿Qué tan cerca está su base de datos de la 3ra forma normal (3NF) y si se desvía de dónde y por qué? (Si dicen "3NF ???", váyase. Si no, y puede haber buenas razones para no hacerlo, descubra cuáles son).
NOTA: He aceptado la respuesta de Anon porque después de aproximadamente una semana, la comunidad cree que es la mejor, creo que esto sugiere que es algo para lo que de alguna manera necesitas desarrollar un sexto sentido. Pero, creo que todos han tenido algo valioso que decir.
Respuestas:
En lugar de pedir ver su código, pregunte qué piensan de la base de código. Y cuando lo haga, preste mucha atención a las expresiones faciales y al tiempo que les toma responder.
Luego aplique su conocimiento de los gestos no verbales de su cultura para interpretar lo que realmente están diciendo. Para una empresa norteamericana, lo siguiente debe ser exacto:
Por supuesto, si tiene problemas con la comunicación interpersonal, esto podría no funcionar para usted.
fuente
Me sorprende que incluso hayas preguntado. Ninguna compañía le mostrará el código antes de unirse. Ni siquiera a los consultores llamados para el proceso, a menos que hayan firmado un acuerdo de confidencialidad.
Esto es lo que puede pedir para averiguar.
fuente
Eso sería desde lo alto de mi cabeza. Notarás que algunas de mis preguntas se refieren al proceso de desarrollo de software, y no solo estrictamente a la codificación. La calidad del último es una función directa de la calidad del primero.
Dicho esto, cuando haga estas preguntas, proceda con precaución. Estúdialos y selecciona algunos al momento de una entrevista.
Un par de cosas que debes tener en cuenta. Un buen equipo de desarrollo se alegrará de escuchar a una persona entrevistada hacer estas preguntas ... siempre que se las haga con tacto. Hazlo mal y le darás al entrevistador una impresión de arrogancia y perfeccionismo. No importa cuán bueno sea un equipo de desarrollo, ningún grupo es perfecto y todos tienen problemas que resolver, compromisos de calidad y demás. Quieren un jugador de equipo con una inclinación por la calidad, no un perfeccionista disruptivo. Así que ten cuidado.
Además, podría haber casos en los que tenga un equipo de personas buenas que, por circunstancias externas, deben trabajar en un código de calidad inferior (podrían ser desarrolladores junior o simplemente heredaron un montón de basura en la que ahora deben trabajar con recursos dedicados a mejorar la calidad.) Puede trabajar con código de mierda y aún así tener una buena experiencia laboral si las personas que lo rodean también son buenas personas (tanto personal como profesionalmente). Déles una impresión equivocada cuando haga las preguntas, y tal vez eviten contratarlo por completo (robándole la oportunidad de trabajar con buenas personas en una situación muy difícil y desafiante).
También puede encontrar un grupo de desarrollo de mierda con gente de mierda. Obviamente, entonces, su código será una mierda, y rechazarán cualquiera de estas preguntas. Podrían despreciarlo por hacerle preguntas difíciles (y por lo tanto podrían hacerle un favor), o lo contratarán porque lo necesitan (incluso si son / serán incapaces de trabajar con usted).
Cuando eso sucede, debe preguntarse si necesita este trabajo tan mal. A veces lo haces, y tienes que zambullirte en un montón de mierda de espagueti. A veces no lo hace (es decir, puede darse el lujo de no hacerlo).
Esas son las cosas que debe tener en cuenta cuando / si elige preguntarle a un entrevistador sobre la calidad de sus procesos de código y software.
fuente
En lugar de la calidad del código real, preferiría buscar una compañía donde se entienda bien la importancia de la calidad del código.
Por ejemplo, digamos que la compañía A tiene gerentes que creen que "la planificación es tiempo perdido" y "podemos solucionar los problemas de diseño más adelante (por ejemplo, cuando el infierno se congele. Tendremos tiempo entonces)". Incluso si esa compañía tuviera una buena base de código ahora, no la tendrán por mucho tiempo. Y usted será el que (se verá obligado) a empeorar las cosas.
Por otro lado, digamos que la compañía B tiene una base de código incorrecta, pero la gerencia entiende que la calidad del código está causando todos esos errores y retrasos, ven la necesidad de un cambio y están dispuestos a hacer algo al respecto (por ejemplo, a gran escala refactorización o incluso reescritura). Esa compañía mejorará su base de código, y usted puede ayudarlos a lograrlo.
Sé dónde me gustaría trabajar.
fuente
Hay un 99.9% de posibilidades de que no pueda ver el código antes de comenzar. (A menos que publiquen un producto de software libre, por supuesto)
Entonces, ¿qué puede hacer? Preguntaría sobre el proceso, en general, un buen proceso producirá un buen código. Comenzaría con la prueba de Joel y preguntaría sobre el método de desarrollo. También ve más allá de lo básico. Por ejemplo, siempre pregunto qué sistema de código fuente usan, por lo que un buen seguimiento es preguntar por qué lo usan.
fuente
El lugar donde trabajé con código de muy alta calidad básicamente no permitió que dos tercios de los desarrolladores tocasen el código. Los otros escribieron scripts de prueba de caja negra automatizados. Si demostró ser digno de cambiar el código real, los requisitos estaban tan extremadamente especificados que básicamente no era más que una transcripción al código fuente. Los guiones de prueba fueron realmente más divertidos de escribir.
Los lugares en los que he visto el código de menor calidad fueron exactamente al revés: solo los programadores relativamente sin entrenamiento o sin adornos tocaron el código, generalmente porque era una herramienta que no estaba directamente relacionada con el producto de la compañía o que se consideraba experimental.
Los lugares más agradables para trabajar tienen un equilibrio. A los nuevos desarrolladores se les asignan tareas reales, pero son asesorados. Hay un buen departamento de control de calidad y un proceso de revisión por pares para detectar sus errores. No se lo castiga por cometer errores, pero se espera que los corrija y aprenda de ellos. Ocasionalmente, un módulo mal escrito cae en el olvido, pero no se le critica por pasar tiempo mejorando la calidad del código cuando se los encuentra. La compañía en su conjunto se esfuerza continuamente por encontrar nuevas formas de mejorar el código.
Por lo tanto, las preguntas que haría para evaluar la calidad del código son:
fuente
Como dijeron @DPD y @Zachary, el proceso y el SDLC son factores muy importantes, pero quiero agregar algunos otros factores que, según mi experiencia, tienen un impacto significativo en la calidad del código:
Tenga en cuenta que un proceso ayuda mucho, pero no dará inmunidad total contra los factores anteriores. Cuando muchos desarrolladores pasan un proyecto, cada uno tiene una mentalidad diferente. El arquitecto y el desarrollador no seguirán exactamente la forma en que lo hicieron sus predecesores, lo que generará algunas inconsistencias.
fuente
Mi actitud es esta, el código es código, si es malo, bueno, es un desafío mejorarlo. Si es bueno, ¡es un desafío aún más difícil mejorarlo!
Lo más importante para mí es si quiero trabajar para la empresa y las personas con las que tengo la oportunidad de interactuar. El código se puede cambiar, la gente no puede ...
fuente
Le digo en broma un poco, entrevista conmigo .
Normalmente uso un error real (ya corregido) en nuestra base de código como prueba de entrevista, por lo que ve un código real. Generalmente es un código un poco complicado y tiene un error.
Animo a todos a usar esta técnica, ya que ya saben que el error es real, el problema es real y saben cuánto tiempo llevó encontrarlo y solucionarlo.
Lo bueno es que puedes tener un problema difícil de medir.
He utilizado un problema muy difícil como última pregunta de la entrevista para separar a los expertos de los bastante buenos.
La relevancia para la pregunta del OP es que todos los que llegan a una entrevista física pueden ver algún código. (No hay nada con contenido confidencial de la compañía)
Si no pudiste usar esta técnica, por decir blasfemias en la base del código, entonces la prueba funciona, ya que los posibles empleados preguntarán "¿puedo ver el código" y la respuesta sería "oh, no puedes, es lleno de blasfemias ".
Por supuesto, la respuesta estándar de "todo es un secreto de la compañía" es el juego completo.
Mi prueba: en mi anterior empleador, una parte no confidencial de un producto militar era el ejemplo de código para la pregunta de la entrevista. [Afortunadamente sin clasificar]
Dejo el problema de determinar la calidad de los diseños clasificados antes de trabajar allí a alguien más inteligente que yo. Sugiero que puede ser común que clasificado sea sinónimo de libre de supervisión.
fuente
Es dudoso que te permitan ver su código, pero es posible que puedas hacerte una idea de cómo sería si les asignas una tarea de programación. Muchos lugares dan a los entrevistados una tarea de programación para llevar a casa que pueden usar para evaluarlo. Devuelva el favor: espere uno de ellos para que pueda evaluar mejor en qué podría estar metiéndose.
fuente
Pregunte qué se requiere para que el código llegue a la compilación de producción. Si obtienes 'uhh ... el desarrollador lo comete ...' entonces es casi seguro que es basura.
Hay varias cosas que tienden a aumentar la calidad del código (obviamente, no hay garantías).
Estos pueden ayudar a mejorar, no solo la fuerza del código, sino también la calidad del código.
fuente
Pregúnteles sobre las pruebas unitarias. Si se lo toman en serio, entonces el entrevistador probablemente tendrá algunas opiniones definitivas sobre el tema y estará encantado de compartirlas. Si las respuestas son vagas, es una gran señal de advertencia.
Si se trata de una tienda Java, pregúnteles qué biblioteca ORM están utilizando. Si han rodado los suyos, entonces podría ir de cualquier manera, podría ser una mierda, o podría estar bien. Si no están usando ninguno, corre hacia la puerta de inmediato.
Esta es una tarea difícil porque hay tantas prácticas diferentes de codificación incorrecta que nunca podrás predecirlas todas.
fuente
No puedes, desafortunadamente. Ninguna compañía le permitirá ver su código (pero le pedirán ver SU código ...), y lo más probable es que si les hace preguntas sobre el entorno, le mentirán directamente ("¿Control de versiones? Seguro ... usamos ... uhh ... pensando en Sub ... Sub-algo ") o nos equivocamos acerca de la calidad (" Estamos usando el último y mejor .NET 4 "solo para descubrir que mientras usan .NET 4 ellos ' reescribiéndolo como .NET 1.1).
Me he quemado muchas veces en el pasado y todavía no he encontrado una buena manera de medir la calidad. Por lo general, la mejor manera es usar su propio criterio y, si todo se reduce a eso, irse inmediatamente si es peor de lo que pensaba; podrías terminar en una bolsa de trabajo pero mantendrás la cordura.
fuente