En mi trabajo, no hay absolutamente ninguna revisión de código, ninguna prueba, ningún control de versiones, ninguna organización de la arquitectura de software, ningún concepto de "servidores de prueba vs producción", ningún comentario de código. De hecho, todo esto está explícitamente prohibido y a menudo me meto en problemas por escribir comentarios o utilizar pequeñas funciones modulares: mi jefe dice que no merece la pena el espacio en disco.
Siempre que me entrevistan en otro sitio, me suelen preguntar cómo trabajo y cómo hago las pruebas o la verificación/validación. Creo que si yo fuera el entrevistador y un candidato me dijera que no se hace nada de esto, sería una señal de alarma y desecharía su solicitud. ¿Cómo debería abordar este tema en las entrevistas?
En cuanto a cómo prepararse para las entrevistas, lo mejor es investigar estos temas uno mismo y trabajar en proyectos personales que los utilicen.
Por ejemplo, en mi primer trabajo de software me pasaba algo parecido, no teníamos buenas prácticas y eran difíciles de aplicar. Así que trabajé en proyectos privados, donde podía hacer lo que quería y tenía tiempo. En esos proyectos planificaba bien las cosas, establecía el control src adecuadamente, probaba todo mi código, comentaba el código e intentaba que fuera comprensible, reutilizable y escalable, etc. Así que cuando llegó el momento de hablar de estas buenas prácticas en las entrevistas, tenía algunos conocimientos decentes y experiencia en ellas, incluso si no había estado expuesto a ellas en mi trabajo real.
Me parece que los entrevistadores no quieren ejemplos concretos de estas prácticas en tu trabajo actual, sólo quieren saber que las conoces y lo que implican. Puede que te impidan estar expuesto a ellas en tu trabajo, pero nada te impide investigarlas y utilizarlas fuera de ese horario. Sin duda merecerá la pena dedicarles tiempo, por lo que respecta a su carrera profesional. Y los proyectos personales que exhiban estas buenas prácticas son estupendos para tu cartera, aunque sean pequeños.
Si te presionan mucho para que les des ejemplos de tu trabajo actual, yo diría que tu trabajo actual no lo hace, así que te has tomado la molestia de aprenderlas o practicarlas tú mismo. Eso demuestra iniciativa y puede proporcionarles un contexto adicional sobre por qué estás buscando en otra parte.
He estado en esta situación recientemente. En mi anterior trabajo, trabajábamos con una base de código muy antigua (código compatible con java 1.2/1.3); el código estaba lleno de números mágicos y cadenas mágicas que se utilizaban para acceder a referencias Object
desde Vector
's que luego se emitían; no había pruebas unitarias, apenas pruebas de integración, ninguna de ellas automatizada; poco o ningún tiempo dedicado a refactorizar el código antiguo; ninguna revisión del código; comentarios de naturaleza esotérica...
Cuando sentí que era el momento de ir a pastos más verdes, me hicieron esta misma pregunta, me fui sobre cómo quería trabajar, y cómo esta falta de satisfacción en mi ética de trabajo personal era parte de la razón por la que estaba buscando en otra parte.
Expliqué qué características me importaban en cuanto a la calidad del código (robustez gracias a pruebas automatizadas exhaustivas, legibilidad gracias a la nomenclatura de variables y funciones, división del código en funciones lo más pequeñas posible en lugar de bloques de 1000 líneas de código repetitivo, etc.) y conseguí mi trabajo actual.
Como @Sascha señaló en su respuesta, no hay necesidad de culpar a su empleador actual / anterior. Se trata de percepciones contradictorias de las mejores prácticas que te impiden encontrar satisfacción en el trabajo que haces.
Que sea una respuesta del tipo "por qué creo que la empresa en la que estoy haciendo la entrevista es estupenda y mejor que mi lugar de trabajo actual".
Siempre que me entrevistan en otro sitio, me suelen preguntar sobre cómo trabajo y cómo hago las pruebas o la verificación/validación.
En lugar de "cómo lo hago", responda "cómo pretendo hacerlo". Diga que, obviamente, la producción de software de calidad razonable es una inversión en tiempo y formación que a veces no se considera razonable debido a los antecedentes de la empresa y los tipos de proyectos, pero que prefiere trabajar en un entorno y en proyectos en los que se ejecutan las cosas asociadas con el SW profesional. Si eso es cierto, diga que ésa es la reputación de la empresa con la que se entrevista.
Creo que si yo fuera el entrevistador y un candidato dijera que no pasa nada de esto, sería una gran señal de alarma y desecharía su solicitud. ¿Cómo debería tratar este tema en las entrevistas?