¿Cómo evitar ser empleado por compañías que son candidatas a las historias de DailyWTF? [cerrado]

Estoy leyendo los archivos de The Daily WTF y especialmente aquellas historias sobre compañías relacionadas con TI que tienen un enfoque completamente erróneo del desarrollo de software, el trabajo de un desarrollador, etc.

Algunas historias son totalmente horribles: una empresa no tiene una red local por razones de seguridad, otra tiene un servidor de control de fuente al que solo puede acceder el gerente , etc. Agregue todas esas historias sobre gerentes que no conocen nada sobre su trabajo y tomar decisiones estúpidas sin escuchar a nadie.

El caso es que no veo cómo saber si usted será empleado de dicha empresa durante una entrevista. Por supuesto, a veces, un entrevistador dice cosas extrañas que le dan la idea de que algo va muy mal con la empresa (en mi caso, el último gerente dijo que debería trabajar el 100% de mi tiempo a través de Escritorio remoto, conectado a un equipo antiguo y máquina lenta, porque "evita que varias personas modifiquen el mismo código fuente" ; tal vez debería explicarle qué es SVN).

Pero en la mayoría de los casos, no podrá obtener suficiente información durante la entrevista para obtener la imagen exacta de una empresa.

Entonces, ¿cómo evitar ser empleado por este tipo de empresas?

• Pensé en pedir ver algunos documentos como guía de documentación o pautas de estilo de código . El problema es que vivo en Francia, y aquí, la mayoría de las compañías no tienen esos documentos en absoluto, y en los raros casos en que esos documentos existen, están desactualizados, mal escritos, nunca se usan o te obligan a hacer cosas que no tengan sentido .

• También pensé en pedir ver cómo funcionan realmente los programadores . Pero ver que tienen pantallas dobles o "mobiliario de fartsy artístico moderno-tardío" no significa que no tengan personas que tomen decisiones extrañas, lo que hace imposible trabajar allí.

¿Has estado en tales situaciones? Que has intentado ¿Ha funcionado?

Recuerde que las entrevistas son una calle de doble sentido. Hágales preguntas abiertas que le permitan saber que saben lo que están haciendo. Y aprenda a "leer entre líneas" al evaluar sus respuestas. Por ejemplo:

¿Cómo se aseguran de que el software que están escribiendo no es malo? (reformulado a algo más "apropiado" si eres aburrido)

Buena respuesta: "Utilizamos pruebas unitarias, tenemos un departamento de control de calidad y revisiones de código".

No tiene que ser esto. Tampoco la persona que está entrevistando necesita tener la misma respuesta que le di. En su mayoría, solo está buscando asegurarse de que la compañía valore el código que escribe hasta cierto punto y no solo lo empujará hacia la puerta con un abandono imprudente.

Mala respuesta: "Bueno, hemos tenido la intención de hacer más de esas cosas de 'prueba unitaria'. Simplemente no lo hemos logrado"

Una vez más, la atención se centra menos en las pruebas unitarias y más en la actitud que el entrevistador toma con respecto al tema. En general, "Sabemos que lo necesitamos, simplemente no lo hemos hecho" es una bandera roja. Eso significa una de varias posibilidades:

1. Tus compañeros de trabajo serán vagos.
2. La gerencia no da tiempo para usar el proceso adecuado.
3. Sus compañeros de trabajo no son lo suficientemente inteligentes como para comprender las pruebas unitarias.

Ninguno de estos es bueno (pero algunos son peores que otros).

Describa el proceso que utiliza su empresa para agregar una función (desde decidir que la función es necesaria para enviarla al cliente).

Buena respuesta: "La gente de negocios decide que una característica es una buena idea y consulta a los programadores para ver qué tan fácil de implementar es. Los programadores y el personal técnico deciden sobre una arquitectura y la implementan. Luego, un equipo de lanzamiento la lleva a la naturaleza ".

Mala respuesta: "La gente de negocios le dice a los programadores qué hacer y ellos lo hacen".

Al igual que con lo anterior, la respuesta en sí no es tan importante como la actitud. La buena respuesta indica que la parte comercial y la técnica trabajan juntas para generar un producto. La mala respuesta indica que la gerencia ve a los programadores como mecanógrafos pagados en exceso.

En resumen , recuerde hacer las preguntas correctas durante la entrevista. Y recuerde que las respuestas particulares no son tan importantes como la actitud detrás de esas respuestas. Por último, no te detengas . Hacer preguntas difíciles indica que estás realmente interesado en el trabajo y que crees que eres lo suficientemente bueno como para ser un poco exigente con respecto a quién te empleará.

Podrías darles la prueba de Joel:

1. ¿Usas control de fuente?
2. ¿Se puede hacer una acumulación en un solo paso?
3. Haces contrucciones todos los dias.
4. ¿Tienes una base de datos de errores?
5. ¿Tú arreglas los errores antes de escribir un nuevo código?
6. ¿Tiene un horario actualizado?
7. ¿Tienes una especificación?
8. ¿Los programadores tienen condiciones de trabajo tranquilas?
9. Utilizas las mejores herramientas que el dinero puede comprar?
10. ¿Tienes probadores?
11. ¿Los nuevos candidatos escriben código durante su entrevista?
12. ¿Haces pruebas de usabilidad en el pasillo?

Mantenga su currículum circulando durante aproximadamente un mes después de ser contratado, y si las cosas no están a la altura, no tenga miedo de aprovechar otra oportunidad. Las empresas a menudo verán su empleo como prueba durante un período de tiempo porque quieren asegurarse de que trabaje tan bien como lo entrevistó. Es justo que hagas lo mismo si las cosas realmente están en un nivel Daily WTF.

Voy a tomar la posición pesimista y no tradicionalmente ingeniera sobre esto.

No puedes

Todas las compañías, sin excepción, son candidatas para las historias diarias de WTF. Esto se debe a que cada persona, sin excepción, sin importar su profesión y su experiencia, puede ser un imbécil en algún aspecto de su vida profesional elegida.

Sí. Esto te incluye a ti, la persona que lee esto. (Si no cree que esto se aplica a usted, creo que acabamos de encontrar una de sus áreas de incompetencia ...)

Tal vez podrías tratar de ver las cosas de manera diferente.

Ser contratado por una empresa que está en el centro de atención de The Daily WTF es una oportunidad para que le muestre cómo puede resolver los problemas. Enormes problemas.

Puede ver esas dificultades como oportunidades .

En lugar de usar la prueba de Joel para las avoidempresas, úsela para improveellas.

Que podria ser mas emocionante que eso?

Si vienes en compañía con tu caballo blanco como Napoleón diciéndoles que todos están equivocados, serás expulsado muy rápidamente.

La oportunidad es que podrá hacer propuestas constructivas , respaldadas con hechos y referencias . Si se hace como se describe en la oración anterior, se le propondrá cuidarla la mayor parte del tiempo (esa es la oportunidad). En muy pocos casos, serás ignorado.

Recuerde que cualquier entrevista es una calle de doble sentido. El empleador está tratando de determinar si usted es un buen candidato. Del mismo modo, debe intentar determinar si vale la pena trabajar para la empresa. Haz un montón de preguntas. Averigua qué es importante para ti y pregunta al respecto. Pregunte a sus entrevistadores qué les gusta y qué no les gusta de la compañía.

Además, secundo la recomendación del otro póster para darles la prueba de Joel .

Incluso un gerente megalómano psicótico puede dirigir un equipo que pase la prueba de Joel. ¿Cómo reaccionan cuando no se cumplen los plazos? ¿El CIO informa al CEO o CFO? Esto puede darle una idea de la importancia de TI en una empresa que no es de software.

¿Por qué está disponible el puesto? ¿Tienen mucha rotación?

Busque maneras de ver si los programadores están sobrecargados de trabajo. ¿Nadie ha tenido vacaciones en varios meses a un año? No se puede vencer a una empresa que da tiempo de vacaciones, pero nadie siente que pueda tomarlo.

Puede modificar las malas prácticas de prueba y los sistemas de control de código. No se puede curar loco.

Esto es lo que haría si fuera usted:

• trate de obtener la posibilidad de entrevistar a uno o más programadores en la empresa y pregúnteles cuál es un día típico en su trabajo. Puede ser difícil preguntar si no lo proporcionan, pero una empresa que lo proporciona es una gran ventaja en mi libro
• pregúnteles cómo se desarrolla una nueva característica, por lo general, y cómo se comparte el trabajo entre los programadores.

Ambas preguntas terminan siendo lo mismo, hechas de manera diferente a diferentes personas. Puntos importantes:

• ¿Cómo se resuelven los desacuerdos sobre problemas técnicos en el equipo?
• ¿Cómo se comparte el trabajo entre los desarrolladores?
• ¿Cómo se asignan los errores a las personas?
• ¿Cómo toma la decisión de diseñar dentro de la empresa, externalizar, fuera de la estantería?
• ¿Cómo juzga el fracaso / éxito del proyecto?

Esto en complemento a la prueba de Joel. Tenga en cuenta que no hay una respuesta "correcta": depende de lo que esté buscando por sí mismo, qué tipo de empresa está buscando, qué tipo de empresa es (por ejemplo, una startup será menos probable que pueda pagar mejores herramientas en comparación con una fortuna 500). Si la persona no puede responder esta pregunta, es casi definitivamente una mala señal: lo más probable es que ni siquiera hayan pensado en esos problemas.

Hay una serie de cosas obvias y de diligencia debida que puede hacer, como hacerles algunas preguntas sobre su proceso, o tratar de hablar o incluso trabajar brevemente con otro desarrollador allí. Por bueno que sea, también es fácilmente engañoso: incluso los peores gerentes a menudo saben lo que deben decir sobre su metodología (saber qué decir sin entender el "por qué" es lo que los convierte en malos gerentes en primer lugar, correcto). ?) y la mayoría de los programadores no van a querer maldecir a la empresa a una posible contratación: ¿por qué arriesgarse a volver a alguien por uno de un millón de entrevistados que pasa por el sistema? (en una compañía poco saludable donde las críticas son ... mal vistas ... eso puede ser un riesgo real)

Sin embargo, puede ver cosas más subjetivas: ¿los gerentes parecen estar llenos de palabras de moda o honestos? ¿Parece un ambiente saludable?

¿Cuál es la calidad de las preguntas y la capacidad de conocimiento de sus entrevistadores? Este es el proceso por el que todos los que trabajan han pasado, recuerden. ¿Te están haciendo preguntas estúpidas? Pregunta tipo HR ¿Las preguntas de codificación son demasiado fáciles?

Como otros ya han dicho, las entrevistas son una calle de doble sentido ...

Pero hay un sutil factor psicológico aquí que creo que a mucha gente no le va bien: sentirse intimidada para tomar un trabajo horrible. Esto es más un problema para las personas jóvenes, pero todos somos vulnerables a él.

Creo que mucha gente tiene la mentalidad de que realmente no se puede cambiar el comportamiento corporativo horrible, por lo que tomamos demasiados sentimientos negativos cuando decidimos aceptar una oferta de trabajo. Parte de la psicología aquí también es la relación de poder entre el empleador y el empleado, especialmente en una economía mala o competitiva, uno siente que tiene que dar mucho margen de maniobra, incluso ante algunos olores de trabajo bastante malos, como Joel, un fracaso total. Pruebas, etc.

Así que efectivamente, lo que estoy diciendo es que muchos de nosotros aceptamos trabajos SABIENDO que serán trabajos de DailyWTF. El truco es ser más exigente, perforar a los entrevistadores con fuerza, y simplemente no aceptar trabajos malos a menos que estés absolutamente desesperado. Existe un equilibrio, por supuesto, pero realmente vale la pena examinar sus sentimientos al decidir si una oferta de trabajo en la mesa es un WTF o no. Es fácil convencerse de que simplemente está siendo "demasiado exigente e inflexible", cuando en realidad está ignorando un olor genuino a mal trabajo.