¿Están sobrevalorados los algoritmos, en comparación con la escritura de software limpio, escalable y de fácil mantenimiento? Sé mi parte de algoritmos y acerté mis entrevistas. Pero en la industria, se trata de cumplir con los requisitos de software y administrar la base del código.

Si el desarrollador conoce las tecnologías que usamos, nunca pido algoritmos. Me concentro en las tecnologías y la experiencia de los desarrolladores con esas tecnologías. Además, incluyo preguntas sobre multihilos y administración de memoria. Según cómo se explica el desarrollador y escribe un código para responder a mi pregunta, tengo una buena idea de sus capacidades

Puedo solicitar el algoritmo solo cuando el desarrollador acaba de salir de la universidad y no conoce ninguna tecnología. Les doy algo de tiempo para hablar sobre lo que saben y sus materias favoritas en la universidad. luego, según lo que les resulte más cómodo, comenzaré a presentar problemas difíciles. Aquí, no estoy probando el conocimiento del desarrollador. En cambio, estoy viendo cómo maneja él / ella resuelve los problemas y cómo maneja la presión.

Tienes que traer algo a la mesa. Si vienes a mí diciendo que conoces J2EE, te probaré en J2EE. Vienes a mí diciendo que tu mejor materia en la escuela son los algoritmos, voy a probarte con algoritmos.

“Mientras que en la industria, se trata de asegurarse de cumplir con los requisitos de software, administrar su base de código para permitir el mantenimiento futuro”. Esta es una generalización general y es una suposición completamente incorrecta. Creo que las prioridades y decisiones de programación se basan en el tipo de trabajo que realiza la empresa.

Si una empresa está cobrando a los clientes por un servicio a largo plazo con requisitos cambiantes, su código se centrará más en la supervivencia y la facilidad de cambio. Es posible que no preste mucha atención a los algoritmos y la facilidad de lectura del código y la adherencia a los patrones de diseño podrían ser más importantes. Lo único que importa es que el SLA se cumpla y cualquier equipo arbitrario puede cumplir con los requisitos de código. Me atrevería a decir que la empresa en la que está trabajando en este momento podría tener prioridades similares. Es cierto que cuando tales empresas se centran en algoritmos en sus entrevistas, es realmente divertido. Contratan personas en base a algo que rara vez les obligan a hacer.

Entonces, ¿qué tipo de empresas se centran más en algoritmos y menos en gestión de código? Estas son compañías en las que simplemente no tiene que hacer que aparezca una lógica comercial ante el usuario en el tiempo especificado en el SLA. Estas son cosas en tiempo real como enrutadores, motores de juegos, motores de bolsa, sistemas operativos. El código se implementa con requisitos muy precisos y los sistemas se optimizan tanto como sea posible para hacer estas cosas en el menor tiempo posible. Los algoritmos son de suma importancia aquí. Las técnicas de gestión de código como los patrones de diseño no son realmente necesarias.

Dicho esto, el código limpio es importante en cualquiera de las empresas. Si el código no está limpio, la depuración sería extremadamente difícil.

Se llama efecto de farola.

Los algoritmos como criterio de contratación no están tan sobrevalorados como sobrevalorados. Probar el conocimiento algorítmico no es tan fácil como parece pensar mucha gente, pero sigue siendo más fácil que probar la capacidad de alguien para escribir código mantenible o colaborar con otros. Los desarrolladores perezosos, o los desarrolladores que odian las entrevistas, prueban lo que es más fácil, incluso si no es lo más importante. Otros usan la entrevista para evaluar atributos que son visibles en un período tan corto, y se basan en el historial de trabajo o referencias para evaluar otros atributos que solo se desarrollan a largo plazo. Saben que los algoritmos no son lo único a tener en cuenta, pero son lo único que se prueba cara a cara.

Tendría que decir que sí, pero dado que estas preguntas se hacen en entrevistas, tiene sentido prestarles atención. Por lo general, evito hacer este tipo de preguntas y me concentro en la corrección, la asignación de nombres razonables, las pruebas, etc.

He visto algunas preguntas de entrevista que fueron realmente preguntas de rompecabezas diseñadas como preguntas de código, como “Dada una lista que tiene N + 1 elementos de 1 a N, escriba una función que devuelva un duplicado”. Mi primer pensamiento es que esa función parece estar demasiado especificada. Si tuviera que escribir una función como esa, digamos FindDuplicateValue, me sorprendería que nadie la llamara con una entrada que no coincidiera con las especificaciones de esta función. FindDuplicateValueOfNPlus1NumbersFrom1ToN no parece tan útil. Reconozco que podría haber un caso extraño en el que es crítico y usted necesita esto específicamente, pero tendría problemas para no presentar una solución más general primero si me lo preguntaran.

Nadie quiere contratar a un ingeniero de software, cuyo objetivo es escribir un software “simplemente” limpio, escalable y de fácil mantenimiento y no preocuparse por el diseño. Puede escribir scripts que generen código automáticamente si ese fuera todo el conjunto de requisitos. Como ingeniero, su tarea principal es diseñar un buen software y analizar la complejidad y los cuellos de botella. Sin una comprensión justa de las estructuras de datos y algoritmos, es difícil lograr un buen diseño.

Es realmente difícil verificar si un candidato puede escribir código limpio, eficiente, escalable y sostenible. Tampoco se acuerda universalmente cómo se vería dicho código. Puede ser muy diferente según el empleado. También es bastante fácil (podría tomar un poco de preguntar y explicar, incluso así) que alguien escriba código siguiendo las reglas de calidad locales.

Por otro lado, es bastante fácil verificar la comprensión de los algoritmos por parte de un candidato determinado.

Dicho esto, si digamos que el candidato contribuyó a algún proyecto de código abierto, puedo verlo en github o tal. La forma en que escribe el código probablemente tendrá un efecto aún mayor en mí que la forma en que responde a mis preguntas algorítmicas. La enseñanza principal que obtendré de su código publicado probablemente será si puede codificar o no, y si tiene éxito o no maneja las complejidades de un proyecto real (tal vez grande). Eso también me dará pistas sobre la forma en que puede encajar en mi equipo actual.

Si no tengo acceso a esa base de código, hago lo que está disponible: las respuestas a las preguntas sobre el funcionamiento interno de la computadora, la explicación de los algoritmos, puede ser un código real si logro tener el candidato para escribirlo.

El código mantenible no es más que disciplina. Si no lo haces ahora, el equipo puede golpearte más tarde.

Sin embargo, si no comprende los algoritmos, no va a mejorar mágicamente cuando lo necesite.

En cuanto a tu experiencia específica, eres el chico nuevo sin mucha experiencia. Si hay algo complejo que hacer, no te lo van a entregar. Hay personas que tienen la capacidad y el sentido de lo que necesita el negocio que se liberan al contratarlo. Existen trabajos de nivel de entrada para permitir que el resto del equipo se concentre en sus especialidades, y es algo con lo que necesita vivir, al menos por un tiempo.

Es cierto que la mayoría de la programación equivale a organizar la salida en informes, pero no descarte la capacidad de comprender más que eso.

Depende de qué tipo de trabajo sea. Por ejemplo, si está desarrollando un motor de juego u otros programas que se compilan directamente desde el nivel del sistema operativo, entonces el material del algoritmo es imprescindible. Por otro lado, si el trabajo es construir programas en algunos marcos fáciles de usar, los algoritmos no son tan importantes.

Debe poder hacer toda la planificación necesaria para escribir algoritmos para poder escribir cualquier código que no sea repetitivo. ¡Simple como eso!