¿Cómo saber si una empresa sigue las mejores prácticas en desarrollo? [duplicar]

No es una cuestión de sacar el tema en la entrevista o pedir trabajo de prueba, es mucho antes de eso: debes hacer tu tarea antes de postularte para un determinado puesto/empresa y entender si ofrece lo que estás buscando.

Usted ha declarado que es un contratista. Es probable que lo contrataran para solucionar problemas o crear soluciones para empresas que no son de TI (empresas cuyo negocio principal no está relacionado con TI).

Para mí, está claro que si solicita, por ejemplo, una empresa minorista, encontrará un departamento de TI interno en el mejor de los casos con un conocimiento limitado sobre sus habilidades. Mantendrán personal para realizar el mantenimiento básico de los sistemas que tienen y, para proyectos más grandes, probablemente lo subcontratarán.

En su lugar, solicitaría una empresa de consultoría de TI (las empresas de consultoría le exigirán más, pero normalmente trabajará con profesionales muy capacitados y llevados al límite) o una casa de software con una presencia relativamente grande en el mercado. Sin mencionar a las grandes tecnológicas como Google o Microsoft, para las que nunca he trabajado, pero supongo que su personal debe estar cerca de los mejores disponibles.

Buena suerte

En primer lugar, buena suerte para que le den el código de producción a un candidato.

Tengo una sugerencia que te puede gustar o no. Tal vez debería intentar solicitar una puesta en marcha. Si la empresa no tiene productos existentes y usted es parte de un equipo muy pequeño, puede dar forma a las prácticas de codificación y, con suerte, crecer con la empresa, es decir, tener información sobre sus decisiones de contratación.

Como sugiere @User012876768, la alternativa es postularse para las empresas de TI de Marquee, ya que a menudo tendrán su selección de graduados. Nunca he trabajado para una empresa como esa, pero te imaginas que tienen estándares de codificación bastante estrictos.

Aquí está la cosa: las entrevistas van en ambos sentidos. Así que asegúrate de hacerles preguntas para que te convenzan de su competencia. Por ejemplo, pregúnteles qué herramientas usan, qué estándares de código tienen, cuál es su proceso, cómo aseguran la calidad del código, qué piensan sobre su base de código, incluso en qué creen que su empresa puede trabajar, qué hacen. para tratar de identificar y solucionar problemas, y en qué es buena su empresa. Cuando realice entrevistas técnicas, utilícelas como una oportunidad para iniciar un diálogo bidireccional y también piense si su entrevistador parece saber de lo que está hablando.

Utilice esta técnica y funcionará para usted, ya que lo hará parecer un buen candidato, Y también obtendrá una idea de la calidad de la empresa.

Con prácticamente todas las empresas, no podrá ver el código privado antes de ser contratado. Lo que puede intentar hacer es encontrar personas que trabajaron allí anteriormente y ver si están dispuestas a comentar sobre el estado de las cosas.

Si desea ver cantidades significativas de un código de empresas antes de ser contratado, tendrá que ser selectivo en qué tipos de empresas solicita. Para la mayoría de los campos de desarrollo de software, estará limitado a las empresas que realizan una gran cantidad de trabajo de código abierto y son las más fáciles de hacer: averigüe en qué proyectos trabajan, observe qué está comprometiendo su gente con los repositorios públicos y vea qué están abogando en listas de discusión/etc. La única excepción parcial importante son las empresas que realizan desarrollo web de cara al público; en esos casos, puede ver el aspecto del lado del cliente de la mitad de sus sitios, aunque el backend seguirá siendo en gran medida una caja negra.

¿Qué debo hacer no solo para ser entrevistado sino también para entrevistar a la posible empresa? ¿Tienes alguna experiencia con eso y podrías darme algún consejo?

La mejor manera de aprender cómo funciona realmente la empresa/departamento es hablar con alguien que realmente trabaje allí.

Si tiene a alguien en su red con conocimiento interno de la empresa y sus prácticas de desarrollo, hable con ellos.

Si no, durante sus entrevistas trate de hablar con alguien que sea uno de sus compañeros en la empresa. Cuando soy el gerente de contratación, me aseguro de incluir a un compañero como parte del proceso de entrevista. Cuando soy el candidato, pido hablar con uno de los compañeros de la posición abierta.

Durante esta discusión, puede preguntar sobre la empresa, el gerente y todos los procesos en uso.

No se limite a preguntar "¿Sigue las mejores prácticas?" porque "mejor" es muy contextual. En su lugar, pregunte sobre los detalles que le interesen.

¿Debo pedir un trabajo de prueba?

Tú podrías. Algunas empresas tienen la costumbre de contratar personas durante un período de prueba inicial y agradecerían esa oferta.

¿Debo llevar mis propias preguntas a la entrevista?

Siempre traiga sus propias preguntas.

Eso no solo garantizará que obtenga las respuestas a los elementos que necesita saber, sino que también demostrará su interés en la empresa, el trabajo y su carrera. Todas esas son buenas señales para los gerentes de contratación.

Pida opiniones de sus compañeros, profesores y mentores orientados a la tecnología sobre la reputación de cualquier empresa que esté considerando, junto con sugerencias de otros lugares que debería considerar.

Hago hincapié en "orientado a la tecnología" porque una gran cultura para los vendedores o clientes de una empresa podría no traducirse en lo mismo para sus ingenieros.

Una fuente ideal de información sería un hackathon, donde puede trabajar directamente con tecnología y otras personas dentro de la empresa.

Otra fuente de información son las valoraciones de los clientes/las quejas sobre el servicio: si los productos apestan y el servicio es terrible, es poco probable que sea un gran lugar para trabajar, especialmente si se trata de una empresa de tecnología.

En este sentido, si es posible, conviértase en usuario de los productos y servicios de la empresa. Esto proporcionará una perspectiva excelente.

Por último, sí, tenga preguntas para su(s) entrevistador(es), pero asegúrese de que no sean preguntas simples que ya hayan sido respondidas en su sitio web o en otro lugar. Preguntar "¿Cuántos empleados tiene?" lo hace parecer flojo y desprevenido. ¡Buena suerte!

Las empresas pueden ser grandes lugares. Un grupo o división puede tener prácticas completamente diferentes a las de otro.

No me preocuparía demasiado por lo que hacen otras personas en la empresa. Por lo general, cada programador trabaja en sus propias cosas. En 25 años de programación, nunca alguien se metió con mi código en un nivel significativo. Cuando las personas se apoderan del código de otras personas, encuentro que siempre lo reescriben por completo.

En cuanto a depurar el código de otras personas, eso es inevitable. Cuanto más junior y menos productivo seas, más trabajo de limpieza y chatarra obtendrás. Si es muy productivo, dedicará muy poco tiempo a la codificación de segunda mano. No hay nada más molesto que un programador junior de 3000 líneas al año quejándose del estilo del código base. Una vez, una empresa en la que estaba contrató a un contratista de habilidades débiles que fue asignado para trabajar en algunos componentes que eran una pequeña fracción de mi producción y se quejó de mi código "espagueti". Por supuesto, Mr. Beautiful Code en realidad no escribió mucho código hermoso y, en consecuencia, fue despedido después de unas pocas semanas.

Personalmente, nunca tengo problemas con el código de otras personas. No me importa lo malo que sea, o qué idioma sea, o cuál sea su estilo. Soy un maestro programador, así que puedo manejarlo y no me molesta en absoluto.

Una vez quise jugar al tenis con alguien y se negaron, diciendo: "Lo siento, no juego con malos tenistas porque eso arruina mi juego". Esa es la marca de un aficionado total. Si crees que jugar con un novato "perjudicará tu juego", tienes un largo camino por recorrer para llegar a la clase magistral.

Si desea saber cómo es un buen código, consulte Google Code Jam. Las presentaciones de los mejores chicos allí me sorprenden por completo. Soy un muy buen programador, pero ver esas cosas es como ver a un gran maestro jugar al ajedrez, simplemente increíble. Olvídense de las tonterías de OO que dicen sus profesores, no valen nada; deja que los chicos de Code Jam sean tus modelos, porque son dioses. Aprenderás MUCHO más leyendo su código que con un manual de diseño tonto.

Nadie está 100% de acuerdo con las mejores prácticas, especialmente porque las recomendaciones siguen cambiando.

Nadie implementa al 100% las mejores prácticas, por razones que van desde el historial del proyecto hasta las necesidades del negocio y el costo inicial de adoptarlas.

Y 100% no importa. Si eres bueno en tu oficio, puedes adaptarte al entorno que tienen, aprender cuáles son las limitaciones y luego trabajar con ellos para introducir mejoras donde tengan sentido.

Un buen trabajador puede hacer un buen trabajo incluso si las herramientas no son las mejores ni las más modernas. Y eso incluye herramientas cognitivas y de proceso, así como las más comúnmente reconocidas como herramientas.

Eso no pretende defender las herramientas antiguas... solo defender a sus usuarios, y sugerir que establecer este requisito en particular puede hacer que rechace algunas muy buenas oportunidades.