Entrevistar a candidatos para proyectos "malos"

Realmente no sé si existe tal cosa como un proyecto "malo" per se... pero claro, puedo entender dónde sería un desafío hablar con posibles nuevas contrataciones sobre un proyecto que no encuentras todo. que divertido de hacer. Tal vez hay un par de maneras en que lo abordaría:

• No "se reconcilie" ni mienta sobre cosas. Está bien ser honesto acerca de cómo empiezan los muchachos. Si se trata de una situación de "nos gusta probar a las personas en esto para asegurarnos de que estén a la altura, pero si nos gustas, te pediremos que hagas otra cosa", creo que es algo perfectamente válido para decirle a alguien. Sin embargo, si le dices a alguien cosas que no son ciertas, el mejor de los casos es que pensarán mal de ti en lugar de la empresa, y lo peor es que tienes que entrevistarte para el puesto de nuevo en un un par de semanas después de dejar de fumar.

• Por otro lado, tampoco te esfuerces por denigrarlo. Hay dos razones para esto: por un lado, el dolor en el trasero de una persona es la oportunidad de otra persona. Quién sabe, tal vez la próxima persona que contrate será la que vea algo de esa tecnología antigua, por ejemplo, y convenza a su cliente de cambiarse a algo más nuevo. O, ya sabes, tal vez no, pero no tiene sentido destrozarlo por completo. La otra razón es que cuando relacione información negativa con las personas, lo asociarán a usted (y en este caso a su empresa por poder) con la negatividad. Es solo la forma en que funciona la mente humana, y es una gran parte de por qué todos piensan mal de los chismes de la oficina.

• ¡Trabaja esas habilidades blandas! ¿Sabe cómo los agentes de bienes raíces a menudo se refieren a una casa pequeña como "acogedora" o a una casa destartalada como "una casa que necesita reparaciones"? Bueno, seguramente hay formas positivas de vender la experiencia. Bien, quizás este trabajo no sea algo que túquiere hacer, pero dependiendo de las cosas... por ejemplo, el enfoque en el mantenimiento en lugar del desarrollo podría venderse como una gran oportunidad para una persona nueva en S-Dev pero con, por ejemplo, experiencia en control de calidad o soporte técnico para perfeccionar sus habilidades mientras trabajan dentro de un marco establecido. Si está en la oficina de un cliente trabajando codo con codo con él, puede ser una situación excelente para aprender a hablar y comprender a los usuarios finales y las partes interesadas (que, por cierto, es algo muy, muy bueno para que cualquier programador aprenda ). Incluso lidiar con la burocracia es una habilidad que se puede perfeccionar y que puede ser muy, muy valiosa en algunos trabajos.

• Algunas de estas cosas van a ser motivo de ruptura, o al menos deberían serlo. Lo siento, tuve que agregar esto porque se modificó la publicación original. Trataré de mantener esto lo menos específico posible de la industria, pero tengo que decir que no haybuena excusa para la falta de control de fuente/versión, punto. Incluso una casa diminuta tiene acceso a Github. Si el cliente no lo permite, se debe educar al cliente sobre por qué es necesario. Como esto se aplica a su situación, esta es difícil. Si tuviera que aplicar a su lugar, una de las cosas que definitivamente preguntaría es su control de fuente. Si me mientes sobre eso, podría marcharme el primer día. Es casi seguro que caminaría si no encontrara un control de fuente y recibiera un rechazo cuando traté de implementar alguna forma de él. Es posible que un desarrollador más joven no "capte" la importancia de esto y, por lo tanto, no pregunte. Incluso entonces, no sé, estoy indeciso sobre si deberías o no sentirte obligado a mencionar esto por tu cuenta.

Para ser honesto, todas esas otras cosas son cuestiones viables. He tenido que lidiar con estaciones de trabajo lentas y rezagadas, burocracia, actuar como mi propio BA, descubrir qué se supone que debo hacer sobre la marcha... de hecho, creo que todas estas cosas son parte de la experiencia de desarrollo de software. Trabajar sin control de versiones no lo es, o al menos no debería serlo (y estoy seguro de que otras industrias tienen cosas similares que "no funcionan").

Respondería a esta pregunta diciendo algo como esto:

"Hay algunos grandes proyectos en los que podría trabajar eventualmente, pero tendrá que comenzar con algunos de nuestros proyectos heredados más antiguos. Son difíciles, no tanto desarrollo nuevo, pero aprenderá mucho de ellos y será una gran experiencia". No puedo decir cómo encontrarías trabajar en ellos ya que todos diferimos, personalmente no soy muy fanático de corregir errores y trabajar con el código antiguo de otras personas, pero al menos disfrutaría la oportunidad de mostrar cómo mucho podría mejorar el código. Puede que lo disfrutes y si no, tendrás la oportunidad de cambiar proyectos después de un tiempo de todos modos. En cuanto a la empresa en general, son geniales, he disfrutado mucho trabajar para ellos. ."

He tenido que decir algo muy similar a los solicitantes antes. No quiero mentirles, pero definitivamente puedes "suavizar el golpe", por así decirlo.

No creo que debas mentir abiertamente por la empresa, pero al mismo tiempo, si estás contento de trabajar allí, díselo y concéntrate menos en los proyectos en los que es probable que trabajen.

Sobre mentir por omisión

Si solo tengo opciones de empleo limitadas: me sentiré descontento y eventualmente me iré después de que su empresa haya hecho una gran inversión de tiempo y dinero en mí.

Si tengo múltiples opciones de empleo: me iré muy rápido y probablemente haré correr la voz a otras personas que lo soliciten. El representante de su empresa está destinado a caer si Recursos Humanos hace cosas sospechosas (ver: HR usually omits that)

Por falta de herramientas para hacer el trabajo (sin control de versiones, computadoras lentas)

Prácticamente lo mismo que el anterior. Ningún desarrollador que valga la pena se quedará si su lugar de trabajo no facilita su trabajo. Eso sería como pedirle a un carpintero que clavara clavos usando un plátano. La única razón para quedarse sería si no hubiera otra opción.

Sobre proyectos que tienen "equipaje"

Cuando menciona proyectos que tienen falta de documentación, clientes difíciles, tecnología antigua/obsoleta, estos son desafíos que toda gran empresa enfrentará en un momento u otro. Como entrevistado, espero que mencione estas cosas por adelantado porque, como empleado, espero que la empresa tenga una estrategia para abordar estas cosas. El problema central aquí no es que no sepa cómo informar a los entrevistados sobre estos problemas, es más que su empresa no parece tener una estrategia para eliminar esos puntos débiles simplemente porque le está dando flujo de efectivo. Eso es complacencia en el mejor de los casos.

¿Cómo comunica la realidad a los entrevistados?

Mi sugerencia sería ser honesto. Si los contratas, descubrirán la verdad más temprano que tarde. Hágales saber ahora, para que puedan tomar una decisión informada. Los que están desesperados por un trabajo todavía dirán que sí, y los que no lo están, dirán que no (que es más barato que contratarlos y luego hacer que se vayan rápidamente).

Como persona reclutada para este tipo de proyectos, así es como lo veo:

• Asegúrate de no mentir o engañar. incluso por omisión. Esto hará que la gente se vaya, rápido. Probablemente sin hacer mucho bien a la empresa antes de que se vayan.

• No responsabilice a las personas por errores que no puede probar que sean suyos y solo suyos. Y asegúrate de que lo sepan. "Algunos proyectos no utilizan ningún sistema de control de versiones porque el cliente no lo permite". - Eso es terrible. ¿Ni siquiera puedes usar GIT en tu copia local del código? Si ese es el caso, muchos desarrolladores darán la vuelta y correrán. Y esa es una reacción apropiada. Sin el control de versiones, no sabes si la culpa es realmente de ellos, por lo que si se supone que su promoción, beneficios, etc. dependen de los errores que alguien más podría introducir en el código, es simplemente injusto para ellos. Así que asegúrese de que sepan que no sucederá.

• No establezca plazos estrictos para nada relacionado con las API que no esté documentado o que pueda cambiar sin previo aviso. Nuevamente, asegúrese de que lo sepan.

• Negocia con tus clientes . El retraso en la pulsación de teclas es un factor decisivo. No puede esperar que el desarrollador se concentre en su trabajo si ni siquiera tiene los medios técnicos para escribir.

• Dígales por adelantado cuánto tiempo permanecerán en el mal proyecto. Podría aceptar pasar un mes, tal vez tres, trabajando en esas condiciones. Quizás. Si el dinero fuera lo suficientemente bueno. Pero me gustaría estar seguro de cuándo terminaría.