¿Debería un ingeniero o desarrollador de software tener habilidades de programación competitivas como un requisito importante?

No, la programación competitiva es extremadamente diferente de la programación “regular”. Por ejemplo, no compites con tus compañeros de trabajo para resolver los mismos problemas. Normalmente, cada uno trabaja en problemas diferentes (a veces relacionados), y debe sentirse libre de pedirse ayuda mutua.

(algunos trabajos no tan regulares tendrán varios equipos trabajando en los mismos subprogramas para que puedan ejecutarse con un algoritmo de votación, solo he oído hablar de esto cuando los programas controlan algo grande y explosivo como un cohete o un misil de fusil, pero no me sorprendería si los autos sin conductor también hicieran esto … o no)

La programación competitiva tiende a tener conjuntos de problemas mucho mejor definidos donde, como la programación “regular”, encontrar los requisitos de cambio reales es, en general, una parte importante del trabajo.

La programación competitiva produce un programa que pasa la prueba de aceptación, y luego ese programa se hace para siempre. La programación “regular” produce un programa que tiende a tener usuarios que encuentran errores que las pruebas nunca hicieron, y necesita que se solucionen esos errores. También suelen ganar suficiente dinero para que alguien descubra un conjunto de características que probablemente generarán aún más dinero, si solo alguien las escribe. Por lo tanto, los programadores “regulares” deben crear programas flexibles y fáciles de mantener.

Dadas todas esas diferencias, no creo que exigir que un ingeniero o desarrollador de software tenga habilidades de programación competitivas ( en absoluto ) tenga más sentido que exigir que todo su equipo de natación olímpica ya haya recibido un bronce o un metal mejor en el sprint de 100 m.

A menos que esté contratando a un ingeniero de software para diseñar preguntas de programación competitivas, o un entorno para hacer programación competitiva, o un lenguaje de cliente, o IDE para programación competitiva (que tiene que ser un campo extremadamente específico, no puedo ver cómo se rompería incluso …)

“ ¿Debería?”, Sí, por supuesto, ¿por qué no? Las habilidades competitivas de programación le enseñaron sobre la resolución de problemas.

Sitios como:

• Kattis, Kattis
• Entregar más rápido a través de Crowdsourcing
• codeforce
• HackerRank
• etc.

Esos sitios anteriores tienen muchos contenidos de programación competitivos que lo desafían a resolver problemas algorítmicos. Desde el nivel más fácil hasta el más difícil, te desafías a ti mismo contra las personas en el mundo. Ciertos sitios contienen ciertos criterios que debe cumplir para que sus soluciones sean aceptadas, son usos de memoria, rendimiento y ejecuciones de tiempo. Puede hablar con algunas personas sobre cómo mejorar sus soluciones. Lo importante es que la resolución de problemas es uno de los muchos requisitos que necesita el ingeniero de software, y la programación competitiva es una de las muchas formas de capacitarse.

Otra versión de esto: ¿por qué contrataría a alguien que sea muy competitivo?

Es probable que a los otros ingenieros de software pronto les desagrade la competitividad de sus compañeros de trabajo. Siempre he tratado de no contratar a alguien que creo que creará un conflicto porque esa es la mejor manera de destruir un equipo que funcione bien.

Por supuesto, si le gusta la programación competitiva pero puede mantenerla fuera del entorno de trabajo, podría ser una ventaja.

Sí, conocer su solución al problema competitivo sería fundamental, seguro que no siempre usará djikstra o programación dinámica en su trabajo, pero si su equipo está compuesto por personas sin esa capacidad, está arriesgando una característica que necesitaría revertido (porque funciona para un pequeño número de personas, pero se rompe sin ninguna solución escalable).

A menos que su trabajo solo esté haciendo una IU para CRUD para un pequeño número de personas, su equipo probablemente no estará bien sin él.

Probablemente esté bien si alguien en su equipo es confiable para manejar ese tipo de problema, pero 2 es mejor que uno.