¿Qué sentido tiene examinar ingenieros de software sobre estructuras de datos y algoritmos durante las entrevistas de trabajo cuando todo el mundo sabe que en la vida real apenas nos preocupamos por todas estas cosas?

¿Por qué crees que apenas usamos estas cosas en la “vida real”? Si estaba hablando de algo como cómo implementar un árbol rojo negro o algo así, podría admitir que es poco probable que lo implemente, pero la clasificación es increíblemente común y útil.

La razón por la que necesita saber cómo funcionan es porque probablemente necesitará usar estructuras de datos cuando haga algo, y comprender cómo funcionan le permite sopesar los pros y los contras de uno sobre el otro. La complejidad del tiempo es la misma; no se espera que los memorice, se espera que pueda deducirlos de su comprensión de posibles implementaciones.

Si ni siquiera puede probar la complejidad temporal de algo que está bien estudiado y que debería haber aprendido en su clase de algoritmos, ¿cómo puede esperar poder demostrar la complejidad temporal de un sistema complejo que ha construido? Claro, uno podría argumentar que los cpus modernos son tan rápidos que muchos programas no necesitan preocuparse por el rendimiento. Pero, ¿qué sucede cuando obtienes muchos usuarios o datos y las cosas se ralentizan? ¿Cómo puede alguien esperar que pueda mejorar el rendimiento cuando ni siquiera lo comprende adecuadamente?

Además, la forma en que explica este tipo de cosas muestra lo apasionado que es por la informática. Y si eres apasionado, es probable que conozcas muchas otras cosas, y quién sabe cuándo ese conocimiento podría ser útil.

wow, cada uno de ustedes parece juzgar a un programador solo por su conocimiento en estructuras de datos / algoritmos. Estoy tentado a decir que todos ustedes están equivocados / de mente estrecha y estoy en lo cierto, pero eso no suena bien / lógico … así que, déjenme explicar mi razonamiento y dejen que ustedes decidan.

No soy un desarrollador rockstar / ninja, pero podría encajar en la categoría de ‘programador decente’ a pesar de mi falta de conocimiento en algoritmos / estructuras de datos. Estoy publicando esto anónimo porque todos (mis colegas actuales / anteriores, amigos, esposa) piensan que soy uno de los mejores programadores (puede ser porque vivo en el área de Washington DC y no en Silicon Valley), pero estos Quora Las respuestas me hacen pensar que tal vez no merezco tanta admiración. Puedo ser un programador útil pero no un programador ‘real’ basado en todas sus respuestas. Bueno, aquí está mi historia.

He estado desarrollando aplicaciones (principalmente aplicaciones web basadas en Java y recientemente servicios API REST) ​​durante los últimos 15 años. Con los años, he adquirido un amplio conjunto de conocimientos en front-end, dispositivos móviles, backend, bases de datos, redes, seguridad, solución de problemas, etc. Domino algunas herramientas específicas que uso todos los días, como Eclipse, Firebug, SubLime, etc. Yo altamente productivo. En estos días, desarrollo aplicaciones para la nube con más frecuencia (AWS). Trabajo a menudo en el gobierno. industria, así que tuve que aprender algunos requisitos específicos del gobierno (508, requisitos de certificación, proceso de contrato, artefactos específicos del gobierno, etc.). Del mismo modo, aprendí contabilidad, banca cuando trabajaba para clientes financieros. Si bien estas habilidades comerciales pueden no contar realmente para el programador ‘perfecto’, sí son importantes para el cliente e incluso para la finalización exitosa del proyecto.

Como puede ver, es un amplio conjunto de tecnologías / herramientas. Cuando utilicé las tecnologías / herramientas anteriores en los últimos 15 años, nunca tuve que usar algoritmos. Puede sonar extraño, pero ese es realmente el caso. Puede ser que simplemente trabaje en aplicaciones que nunca tuve la necesidad de trabajar en los algoritmos. Tampoco tuve que lidiar con estructuras de datos, aunque uso las colecciones Java apropiadas como mapas, listas, listas vinculadas, matrices, etc., según sea necesario. No recuerdo haber escrito una clasificación compleja ni más de 50 objetos en colecciones. La mayor parte de la clasificación se realizó en el lado de la base de datos. Sin embargo, tuve que escribir una clasificación personalizada para los objetos. Espero que haya programadores por ahí que tengan esta extraña situación. Si surge una necesidad, definitivamente aprenderé más sobre algoritmos / estructuras de datos, pero hasta ahora, no estoy obligado a aprenderlos. Y tampoco soy una montaña rusa. Nunca trabajo para el mismo cliente por más de 2 años. Entonces, he trabajado en más de 10 aplicaciones diferentes en mi carrera. Y en la mayoría de los proyectos recientes, casi todos acuden a mí para resolver algún problema, solucionar un problema de producción o simplemente cualquier cosa. Y tampoco parece afectar el pago. He podido cobrar alrededor de $ 90-100 / hora. Y a menudo digo que no a las ofertas de tiempo completo que pagan en el rango de $ 150-160k. No es una buena paga, pero es decente para un tipo que no conoce la ciencia de la ciencia lo suficientemente profunda. Estudié ingeniería mecánica en una universidad promedio en India … después de la universidad, enseñé Java y desde entonces, he estado aprendiendo conscientemente … pero me concentro en aprender cosas que solo puedo usar en el trabajo o en mis proyectos personales. Entonces, mientras aprendí móvil / nube, no aprendí nada sobre big data, análisis, algoritmos, aprendizaje automático, etc.

Supongo que la ingeniería de software se ha convertido en un vasto campo con varias especialidades. Realmente no se puede definir un buen programador con solo un criterio. Si bien estoy de acuerdo en que una base sólida en ciencias de la computación es un gran activo, especialmente para una compañía basada en productos de software o una compañía a escala de Internet como Google / FB / etc., puede que no sea la habilidad más importante en muchos otros lugares. Todo depende de qué valor aportes al cliente. Mientras que mi amigo realmente inteligente (que sabe lo que respetas: estructuras de datos, algoritmos, programación funcional con scala, etc.) gana menos ($ 130- $ 150k) en comparación con un desarrollador de informes ($ 110 + por hora) que no es realmente un programador , no realizan ninguna programación, principalmente arrastran y sueltan los controles de la interfaz de usuario y los vinculan con algunas consultas SQL.

También recluté a algunos programadores sobre eLance para crear prototipos de mis ideas de ‘inicio’ y nunca hice ninguna pregunta sobre la estructura de datos o los algoritmos. Solo me aseguré de que puedan desarrollar lo que espero. En este momento, desarrollar características / funcionalidades es más importante para mí que los algoritmos eficientes, y siempre puedo escalar aplicaciones web sin estado con más instancias de Beanstalk y servicio RDS. Sí, entiendo que habría pocos lugares donde un algoritmo eficiente o una estructura de datos pueden mejorar mi aplicación y los grandes programadores pueden mejorarla … pero bueno, no estoy construyendo un google. Cuando se convierta en google, vendré a ustedes, los caballeros brillantes con espadas de algoritmo.

Tienes razón y estás equivocado. Yo diría que, en su mayoría, es correcto, y la distinción es la que veo entre Ingeniería de Software y Ciencias de la Computación.

La programación no es ciencia. Es ingeniería. Los científicos juegan con problemas de juguetes frágiles, buscando la perfección teórica. Los ingenieros hacen cosas resistentes que son utilizadas por personas normales, equilibrando las compensaciones necesarias.

Ningún programador debería necesitar o esperar saber de memoria el modelo de siete capas o los diez algoritmos de clasificación más comúnmente discutidos o lo que sea. Eso es solo CompSci, es alimento para estudiantes, es lo que la gente se alimenta en la escuela para olvidar rápidamente.

Lo que un programador DEBE saber es, dada una lista del modelo de siete capas (como podrían encontrar en Google), en qué capa tiene más sentido implementar una característica determinada.

Lo que un programador DEBE saber es, dada una lista de nombres y propiedades de algoritmos (como puede encontrar en Google), cómo saber cuál sería el apropiado. Casi nunca es un problema con problemas resueltos como sort (), pero es importante para otros algoritmos que aún no se resuelven universalmente, como el embalaje de contenedores, la generación de laberintos, la barajadura, la búsqueda, etc.

Es decir, un programador no necesita conocer la ciencia de memoria, pero debe estar equipado para tomar decisiones de ingeniería. No necesitan conocer todos los patrones de diseño, antipatrones y algoritmos, pero deben saber cuáles son esas cosas, cómo encontrarlas y cómo seleccionarlas.

Conocer algoritmos específicos es solo más flechas en su carcaj. Más flechas significan menos soluciones “si todo lo que tienes es un martillo”, menos “solo ve con lo que sabes” y más seleccionando la opción con la mejor compensación. Si todo lo que sabes son hashes, entonces tendrás problemas cuando un árbol sería mejor.

Si alguien, al pedirle que cargue gráficos web más rápido, puede sugerir la optimización / reducción de imágenes, otros formatos de imágenes, gráficos vectoriales, hojas de sprites, balanceo de carga, almacenamiento en caché de clientes y servidores, y una variedad de otros métodos, entonces tienen un buen carcaj. Si solo pueden sugerir uno o dos, entonces no lo hacen, y es probable que se golpeen la cabeza durante demasiado tiempo tratando de obtener un kilometraje irrazonable de una sola idea.

El mismo trato con cualquier otro conjunto de problemas. Cuanto más grande sea su carcaj, menos tiempo pasará buscando soluciones y mejor será su selección de soluciones.

Amigo, si realmente nunca has tenido que ordenar más de 50 elementos en el código que has escrito profesionalmente, entonces creo que es justo asumir que estás cometiendo un error común en tu generación: estás confundiendo (probablemente del lado del cliente) la programación web con toda la ingeniería de software.

Mucha gente usa muchos algoritmos todo el tiempo. Algoritmos complicados, algoritmos simples, todo tipo de algoritmos.

Usted menciona la clasificación. Los algoritmos de clasificación son parte de una base sobre la cual se construyen muchos otros algoritmos entre dominios: en geometría computacional, en teoría de grafos, en computacional esto, en computacional eso, etc. Por ejemplo, el algoritmo de Kruskal para encontrar un árbol de expansión mínimo se basa en una clasificación y es el tiempo de ejecución de la ordenación el que controla más o menos el tiempo de ejecución de todo el algoritmo si usa la implementación de compresión de ruta de la estructura de datos del conjunto disjunto. Si realiza la ordenación en tiempo lineal al no utilizar una ordenación de comparación, Kruskal puede ejecutarse en tiempo esencialmente lineal, pero debe saber que es posible ordenar en tiempo lineal utilizando una ordenación de conteo o lo que sea. Kruskal se usa para muchas cosas; por ejemplo, segmentación de imagen, que espero no tenga que describir la utilidad de. Así que acabo de esbozar desde la parte superior de mi cabeza cómo el conocimiento de los algoritmos de clasificación se aplica directamente al procesamiento de imágenes a través de algoritmos gráficos, y eso estaba fuera de mi cabeza .

No sé cómo es tu trabajo. Mi trabajo es saber estas cosas. Es perjudicial para la profesión pretender que tal conocimiento es innecesario.

En estos días, sí, hay muchas herramientas, bibliotecas y marcos. Tenga en cuenta que todas esas herramientas, bibliotecas y marcos fueron escritos por personas, escritos por personas que generosamente le han donado su trabajo, para que su trabajo pueda sentarse sobre el suyo y pueda expresar una incredulidad que cualquiera realmente tiene que entender. cómo funciona quicksort

Los algoritmos (p. ej., clasificación, búsqueda de rutas, recorrido de gráficos) y las estructuras de datos (p. ej., árboles, listas vinculadas, montones) son la materia atómica a partir de la cual nosotros (programadores) hacemos cosas.

lo que es más, estos dos están estrechamente conectados; de hecho, una estructura de datos es a menudo el quid de un algoritmo, por ejemplo, BFS y DFS , tal vez las dos técnicas principales en el recorrido de gráficos, y en algunos sentidos opuestos, se implementan comúnmente con el mismo código, excepto por la estructura de datos se usa para almacenar los nodos visitados ( stack vs. deque ); Del mismo modo, el refinamiento crucial de la estrella A (A *) sobre los algoritmos de búsqueda de ruta de última generación existentes es el uso del montón mínimo para implementar una cola prioritaria.

bien y que? ¿Por qué molestarse en aprenderlos cuando solo puedes googlear el término una vez que el líder de tu proyecto te asigna la tarea, especialmente cuando puedes dedicar tu tiempo a aprender complementos de jquery más geniales?

Aquí está el trato: los proyectos rara vez declaran por sí mismos sus soluciones en estos términos atómicos, por ejemplo, ¡ soy un problema de cruce de gráficos!

en su lugar, se le proporciona un proyecto con una descripción que puede estar a kilómetros de distancia, por ejemplo, cree un módulo para clasificar a estos usuarios según su similitud. Una forma de hacer esto, y si esta es la mejor manera es específica de los hechos, es construir un gráfico explícito sobre los usuarios y calcular qué tan lejos está uno del otro en función de la longitud de la ruta, y usar eso como la métrica de similitud.

así que tomemos el ejemplo en el OP: ordenar. Por lo general, es trivial reconocer cuándo necesita ordenar algunos datos, pero no espere que la especificación, ya sea formal o no, le diga la mejor manera de hacerlo. De hecho, tal vez hay varias formas mejores, pero es probable que también haya varias formas malas. En cambio, la especificación podría indicar que es una secuencia masiva de enteros que necesita clasificar, y bajo un umbral de latencia muy estricto. Esos detalles particulares sugieren la clasificación de radix; Para un buen desarrollador, en mi opinión, este tipo de solución de problemas debería ser como respirar.

en la universidad, el primer algoritmo de clasificación que menciona su libro de texto de algoritmos es (probablemente) clasificación de burbujas (también conocido como clasificación de gnomos o clasificación estúpida) , fácil de entender, fácil de codificar, pero tan pronto como lo hace, el libro de texto le indica la complejidad de tiempo promedio ( n al cuadrado) es pobre y n * (log n) es realmente posible usando algoritmos más sofisticados. Entonces, ¿por qué no olvidarse de la clasificación de burbujas y aprender, por ejemplo, la clasificación de fusión? La clasificación de burbujas podría ser el mejor algoritmo de clasificación para su problema. Esto está lejos de ser un caso límite: por ejemplo, la clasificación de burbujas es la peor complejidad de tiempo promedio de caso, pero es la mejor complejidad de tiempo de caso es n (del mismo modo para la clasificación de inserción, pero la mayoría de los algoritmos de clasificación de uso común son n (log n), mejor caso (igual que su caso promedio). Muchos problemas prácticos cotidianos que requieren la clasificación de datos son en realidad el mejor caso (o casi), por ejemplo, es necesario realizar una clasificación “continua” sobre algunos datos, de modo que los elementos se agregan al contenedor, debe volver a ordenarlos.

lo que es más, la ordenación de burbujas es estable (en esencia, los pases múltiples sobre los mismos datos, dan como resultado el mismo orden de clasificación con respecto a los “vínculos”; esta propiedad que no tiene cada algoritmo de clasificación y que podría ser requerida por el problema particular frente a tú.

así que esa es la razón más importante, en realidad, para aprenderlos: los problemas que los implican surgen constantemente, pero a menudo depende del desarrollador hacer esta conexión entre el problema y las posibles soluciones.

La ignorancia entre los desarrolladores de estos componentes básicos es asombrosa. Debido a esto, vemos, por ejemplo, motores de juegos con módulos de búsqueda de rutas con errores compuestos por varios miles de líneas de código, con muy poca generalidad con la descripción de la ruta, un rendimiento por debajo del promedio y que ningún desarrollador quiere mantener. En los pocos casos de este escenario que he visto en los últimos 4 o 5 años, en cada caso, el módulo completo podría descartarse y reemplazarse con una implementación competente de A * en un centenar de líneas de código. más fácil de mantener, mucha mejor abstracción y mejor rendimiento expresado en órdenes de magnitud.

La única razón por la que puedo pensar en un entrevistador que le pide a los candidatos que escriban algoritmos de clasificación es la pereza. No es un trabajo insignificante preparar un conjunto de preguntas altamente especializadas para medir la capacidad de alguien para, por ejemplo, una buena solución de CRM. En cambio, muchos entrevistadores simplemente lanzan preguntas enlatadas de ciencias de la computación que pueden encontrar en Internet, de ahí las preguntas del algoritmo de clasificación.

Moviendo este comentario a la respuesta:
Nunca dijo realmente que apenas * usas * estas cosas en la vida real, pero apenas * escribes * estas cosas en la vida real.
Un buen ingeniero de automóviles no necesita mostrarle a su entrevistador que puede recrear el proceso industrial para fabricar vidrio de buena calidad. El vidrio se usa en todos los automóviles, y es importante que un ingeniero de automóviles sepa qué vidrio es un buen parabrisas, pero la fabricación del vidrio se ha inventado y perfeccionado durante siglos. Si está buscando a alguien que pueda mostrarle cómo hacer un buen vidrio, entonces contrate a un ingeniero de materiales, no a un ingeniero de automóviles. Generalizar un papel como “ingeniero de software” es tan absurdo como generalizar como “ingeniero industrial”. Tome una decisión sobre a quién quiere contratar, un fabricante de automóviles o un fabricante de vidrio, un consultor de CRM o un ingeniero de terminales de punto de venta, o un desarrollador de Linux, o alguien para escribir un algoritmo de clasificación innovador.
Hacer preguntas técnicas que son irrelevantes para las habilidades específicas que estás buscando, solo por hacer preguntas técnicas, es una pérdida de tiempo para todos.

Oh mi dulce niño de verano. ¿Nunca tener que ordenar más de 50 artículos? ¿Apenas molesto con estructuras de datos y algoritmos? Lamento decirte esto, pero ni siquiera pareces saber lo que no sabes. Ve a leer sobre el efecto: efecto Dunning-Kruger

Donde empezar. Ok, los programadores solo usan Wikipedia estas cosas cuando las necesitan. Esto es verdad. A menudo repasaré un patrón de diseño particular o cómo este lenguaje particular implementa diferentes estructuras de datos que pueden satisfacer mis necesidades. Pero no estoy aprendiendo estos conceptos desde cero, simplemente elijo no almacenar algunos de los detalles en mi cerebro. Sé la diferencia entre una lista vinculada, una matriz y una pila, y solo estoy comprobando la implementación de este lenguaje actual b / c, no todos los idiomas usan estas palabras de la misma manera. O sé que probablemente quiero uno de estos dos patrones de diseño y solo los estoy revisando, no estoy aprendiendo todos los patrones de diseño, qué problema resuelven, cómo implementarlos. Tampoco pienso que soy tan inteligente que debería ignorar los patrones de diseño o que mi problema especial de copo de nieve nunca se ha resuelto antes y, por lo tanto, no puedo seguir uno.

De vuelta al efecto Dunning-Kruger. Suenas autodidacta para mí, o como mucho al comienzo de un programa de pregrado. No soy. Fui a la universidad y obtuve un título de CS. Hubo noches en que (impulsado por innumerables espressos) leía la misma página una y otra vez en mi libro de algoritmos, sin entender el concepto y llorando por mi falta de inteligencia. Y los algoritmos pasaron algunos años. En el primer año, era un hecho habitual en el dormitorio de CS que un compañero de clase encontrara un mango de licor barato y luego lo bebiera mientras sollozaba en el piso del pasillo, “No soy lo suficientemente inteligente como para ser una computadora científico”. Sucedió semanalmente, fácilmente.

Y sí, estos son nuestros orgullosos derechos de paso. Pero lo que es más importante en este entorno de educación formal, estuvimos expuestos a personas que no solo eran más inteligentes o tenían más conocimiento que nosotros, sino que * siempre * serían más hábiles en estas áreas. Como no tengo planes de realizar un doctorado, acepto que nunca haré los tipos de contribuciones impactantes a mi industria que * la mayoría * de mis profesores han hecho.

Lo mismo es cierto para muchos de mis compañeros de clase y ex compañeros de trabajo. Si bien me considero “más cercano” a estos compañeros, simplemente no estoy trabajando en los tipos de problemas únicos, difíciles y de vanguardia que son.

… y he tenido que trabajar con datos de más de 50 elementos … como 10,000 a 100,000 veces más grande. Muchas veces. Y ya sabes, no es lo mismo trabajar con un conjunto de datos de 20 y un conjunto de datos de 2,000,000.

Cuando las grandes compañías contratan, no están contratando a una persona para hacer el trabajo X, están contratando a un ingeniero que esperan que se quede con la compañía y se mueva dentro de la compañía. Por lo tanto, no es suficiente que sea un experto en Python al solicitar un trabajo en una empresa como esa, incluso si este trabajo específico no requiere nada más que la codificación de Python. E incluso es una posición jr, por lo que tendrá mucha dirección. Un candidato que entienda las estructuras de datos y los algoritmos puede aplicar ese conocimiento para aprender un nuevo idioma prácticamente al instante, lo que lo convierte en la mejor opción para el alquiler.

Si tú y todos los que conoces (dijiste “todos saben” cuando parece que la mayoría de las personas no están de acuerdo) piensas que no hay nadie en informática trabajando en algo interesante, entonces debes abrir un poco tu mundo. Porque hay MUCHOS problemas interesantes en los que se está trabajando en este momento, en el “mundo real”. Ahora estamos viendo juegos de consola en el navegador. Nuestras propias casas están cambiando con el hecho de que, por primera vez, muchas personas tienen conexiones de Internet consistentes de alta velocidad en sus casas, las computadoras se han vuelto lo suficientemente pequeñas como para hacer que los dispositivos portátiles sean más prácticos, las computadoras se han vuelto lo suficientemente rápidas para hacer posible el procesamiento de grandes datos y lo suficientemente barato como para hacer que el acceso sea más amplio que nunca. Las personas que resuelven estos problemas y dan forma a cómo se ve el mundo incluso dentro de 10 años serán personas que entiendan la teoría lo suficientemente bien como para aplicarla en nuevas situaciones.

Perdón por derribarte. Quise decir más para mostrarte cuánto más alto es el campo de la informática que solo la codificación / implementación.

Estoy en el medio de mi doctorado en Ciencias de la Computación, la última vez que necesité escribir mi propio algoritmo de clasificación fue en una clase de algoritmos … Habiendo dicho eso, creo que dice mucho sobre el proceso de contratación para ingenieros de CS.

Si está entrevistando para un trabajo y le piden que escriba un algoritmo de clasificación, pero no usará ese conocimiento en su trabajo, ¡EJECUTE! Eso significa que una persona de RR. HH. Está leyendo un guión o un gerente de CS agotado le está haciendo preguntas de entrevista de 10 años. Además, durante la entrevista no es una mala idea preguntarles por qué quieren que saques ese algoritmo de un sombrero cuando puedes buscarlo en línea.

Por otro lado, aunque no haya escrito mi propio algoritmo de clasificación en varios años, no significa que no creo que sea importante. Principalmente, escribir algoritmos es una habilidad que debes mantener (ordenar o no). Si confía únicamente en ‘frameworks’ y ‘paquetes’ para hacer todo su trabajo por usted, sus habilidades de CS se volverán débiles y rechonchas. Me di cuenta de esto cuando recientemente me senté a redactar un algoritmo de sistemas distribuidos y me di cuenta de que no pensé en media docena de casos de esquina hasta que fue demasiado tarde … ¡utilízalo o piérdelo!

Tiendo a estar de acuerdo en que hay demasiado énfasis en algoritmos y estructuras de datos. Esto es particularmente cierto cuando esas preguntas provienen directamente de una clase CS 200 o 300, pero no se usan realmente para la ingeniería de software cotidiana.

Es complicado encontrar un buen material para una entrevista. La mejor pregunta debe ser “alta discriminación”, no discriminación en el sentido de racismo, discriminación en el sentido de una prueba de quién es bueno o no. Una pregunta que es demasiado fácil no es una gran discriminación, porque todos obtendrán la respuesta. El truco está surgiendo con esas preguntas de alta discriminación que identifican a las personas que serán empleados realmente buenos de aquellos que son promedio o están por debajo del promedio.

Personalmente, intenté durante años hacer una variedad de preguntas oscuras sobre temas como Classloaders y la implementación de JVM. Descubrí un poco más tarde que esas eran malas preguntas, porque en realidad solo estaba probando si el ingeniero tenía experiencia escribiendo su propio servidor de aplicaciones. Casi nadie podía responder mis preguntas, luego finalmente me encontré con alguien que escribió un servidor de aplicaciones, y respondieron perfectamente a todas. Eso es lo que no quieres, porque estaba probando las cualidades incorrectas en un candidato. Estaba probando si habían escrito un servidor de aplicaciones, no si serían grandes ingenieros para mi equipo.

Lo mismo para las preguntas de estructura de datos, porque solo prueba si el candidato tiene un título de CS y recuerda sus clases de CS 300.

En C ++, es un poco más fácil formular preguntas de alta discriminación, porque los programadores novatos generalmente no entienden las sutilezas de las operaciones de puntero, mientras que cualquiera que haya realizado una cantidad significativa de programación lo entiende por dentro y por fuera. Por lo tanto, es bastante fácil distinguir entre un programador de C ++ experimentado y un novato.

Cuando entrevistamos a candidatos en nanorep, tratamos el conocimiento íntimo en estructuras de datos y algoritmos básicos como la posición inicial básica.

Si no podemos confiar en que elija el algoritmo o la estructura de datos correctos cuando implemente nuestra función más nueva o solucione un error, nunca lo dejaremos cerca de un teclado.
Tenga en cuenta que al escribir código para sistemas de back-end, elegir una estructura de datos puede significar la diferencia entre un servicio suave y sedoso y un desorden tartamudo y que no responde. Sin mencionar el número o los servidores que tendremos que activar para millones de usuarios que interactúan con nuestro servicio en cualquier momento solo porque elegiste usar una matriz en lugar de una tabla hash.

Esto también puede significar grandes diferencias en las compensaciones de CPU y RAM (generalmente elige si optimizar para un mayor costo de CPU o un mayor costo de RAM, pero no ambos, a menos que sea muy inteligente) que debe comprender.

Por lo tanto, comprender el funcionamiento interno de cada estructura de datos y algoritmo y comprender las diferencias, debilidades y oportunidades de cada uno es esencial.

Por cierto, en algunos casos, nuestro equipo de front-end también necesitaba este conocimiento cuando lanzamos algunas interfaces que se ocupan de ordenar y administrar datos relativamente grandes en una aplicación web, y nuestros chicos redujeron el tiempo de representación de la página de 10 segundos a 5 mili simplemente cambiando el algoritmo subyacente (por cierto, deberíamos haber notado que el algoritmo no era correcto en primer lugar, pero el punto sigue en pie; P)
Esto también es cierto especialmente cuando se crean marcos de front-end.

Sin comprender estas cosas, está limitado en las cosas que puede lograr, especialmente cuando maneja datos cada vez más grandes.

Si planea crear sitios HTML5 y CSS3 o aplicaciones móviles estándar, no se moleste.

Cuando me entrevistan, no puedo evitar sentir que lo que realmente están probando es qué tan bien he leído el último libro de entrevistas de programación. No siempre recuerdo los puntos más finos de una búsqueda de árboles de primer orden entre conciertos. A algunas personas les encantan esas cosas, a mí no, y no las guardo. En el software empresarial, casi nunca tienes la oportunidad de usar esas habilidades. La mayor parte de mi tiempo lo paso descubriendo cómo conectar los datos A con el servicio B, cómo probarlos, cómo implementarlos y cómo asegurarme de que no exploten y le cueste dinero a mis empleadores, verificando StackOverflow cuando se produce un error arcano Nunca he oído hablar de ventanas emergentes, y luego documentar todo lo que hice si me atropella un autobús, alguien más puede hacerse cargo.

Dicho esto, creo que hay algunas razones por las que este estilo de entrevista es tan predominante:

1) Poco tiempo para que un desarrollador codifique. He tenido sesiones de codificación entre pares y fueron divertidas. También tuve tareas para llevar a casa, pero una vez que entran en el rango de más de 5 horas, rechazo. Pocas empresas merecen ese esfuerzo.

2) Los algoritmos son una cosa fácil de evaluar porque generalmente hay una respuesta o “truco” correcto y, por supuesto, el entrevistador se asegura de saberlo.

3) Corolario al n. ° 2, si hace una pregunta más amplia, corre el riesgo de que el candidato demuestre que es más inteligente o más experimentado que usted y que aumenta las posibilidades de que hable sobre un tema en el que no puede evaluarlo.

4) Los entrevistadores no consideran para qué se están entrevistando, simplemente están haciendo lo que todos los demás hacen en una entrevista.

5) Son entrevistadores aficionados y no tienen capacitación u orientación. Es fácil infringir la legislación laboral mientras se realiza una entrevista (“¿tiene hijos?”) Pero pocas empresas capacitan a sus empleados para realizar entrevistas.

6) Algunos realmente creen que la única medida verdadera de un desarrollador es su capacidad para recordar y comparar algoritmos. Por lo general, esos son los desarrolladores cuyo código odias revisar porque ha sido “optimizado” al infierno, es casi ilegible, prácticamente no se puede mantener y tiene un mal diseño OO.

7) Algunos creen que es parte de una buena medida de la habilidad de un desarrollador. Puedo entender y respetar este punto de vista, pero si solo me hace preguntas sobre algoritmos durante la entrevista, lo categorizaría en el # 1-6.

8) Mi razón personal: ver cómo piensa un candidato. Siempre hago una y solo una pregunta algorítmica por candidato. Les digo que es una pregunta un poco engañosa, y no se sienta mal si no la entiende, solo quiero ver su proceso de pensamiento. Ya sea que el candidato discuta o no el problema con usted, le haga preguntas aclaratorias, cuán difícil es para ellos entender el problema, cómo manejan el estrés de la entrevista, etc., son excelentes señales de cómo serán para trabajar . No me importa si descubren cuál es el truco, pero si obviamente son terribles en el proceso de resolución de problemas, es una gran señal de alerta.

Cuando entrevisto a alguien, le digo al candidato que no me molesto demasiado con los algoritmos porque puedes leer un libro de entrevistas para eso y, en cambio, quiero ver cómo construyes el software. A menudo están visiblemente molestos por esto. Ese tipo de entrevista es realmente difícil de preparar y no puedes fingir fácilmente ese tipo de conocimiento y experiencia.

No conozco al “todo el mundo” que menciona el interrogador, pero si un ingeniero de software no conoce las estructuras de datos y los algoritmos, no es útil en ninguna organización de software de la que haya sido parte. Si una persona no puede descubrir las ventajas y desventajas de los algoritmos bien conocidos, no podrá construir de manera inteligente sobre ellos. Si una persona tiene la ambición de trabajar para las principales compañías de software, tendrá que conocer los conceptos básicos.

En cuanto al ejemplo de clasificación específico: si se trata de conjuntos pequeños, utiliza las bibliotecas de clasificación para cualquier idioma que esté utilizando. Es cuando se trata de conjuntos grandes que necesita escribir el suyo. He tratado con conjuntos de datos por millones antes de trabajar para una compañía de “big data”.

La vida real requiere este conocimiento. Si no entrevista bien (veo que el inglés en la pregunta es tosco), puede probar formas alternativas de demostrar habilidad, como codificar muestras.

No, definitivamente necesitas conocer algoritmos y estructuras de datos para ser un “desarrollador” decente. Es posible que no los esté implementando a diario, pero si ni siquiera puede razonar sobre ellos, no tiene casi ninguna posibilidad de elegir algo específico para cada problema que necesita resolver.

Y de todos modos, no es como si las bibliotecas existentes ya hubieran implementado todos los algoritmos y / o estructuras de datos imaginables para cada caso de uso. A veces necesita usar la ordenación en combinación con alguna otra modificación, a veces necesita combinar una estructura de árbol y un hashmap. Sin mencionar que es posible que no pueda simplemente cargar todos los datos a la vez en la RAM, lo que significa que necesitaría generar su propia técnica de almacenamiento en búfer y luego combinarla en un algoritmo, no es muy fácil si todo lo que sabe es cómo llamar La función qsort. Si no puede, su código no será muy útil, eficiente, fácil de mantener, de rendimiento, de recursos frugales, etc.

Diría que las cosas más importantes para aprender en cualquier carrera de programación son algoritmos y estructuras de datos. Son incluso más importantes que los idiomas, los dominios, las bibliotecas, las API, los marcos, etc. por el simple hecho de que no cambian en las diferentes versiones de todos ellos. Es posible que no necesite conocer todos los algoritmos posibles que se hayan inventado, pero conocer los más comunes ayuda mucho, y conocer algunos más ayuda un poco más; sin embargo, hay rendimientos decrecientes en promedio (por lo que en algún momento podría no tener sentido probar en Algún algoritmo esotérico, casi nunca utilizado).

Pero clasificando? En serio … es probablemente el conjunto de algoritmos MÁS utilizado. Sin mencionar que el lenguaje divide-n-conquer de la mayoría de los tipos también es muy útil en otros algoritmos.

Editar: Aquí hay una buena publicación de blog que muestra exactamente lo que mi respuesta (y la mayoría de las otras respuestas) están tratando de transmitir: Una gran razón Los gerentes hacen preguntas de codificación – Dice News

Es decir, no ver si memorizaste un algoritmo en particular, sino que puedes decidir qué usar de entre varios disponibles, y cómo haces para tomar esa decisión.

Esta pregunta, creo, es muy fácil de responder con una cita.

Torvald dijo: “De hecho, soy un gran defensor del diseño de su código en torno a los datos, en lugar de al revés, y creo que es una de las razones por las que git ha tenido bastante éxito … De hecho, afirmaré que La diferencia entre un mal programador y uno bueno es si considera que su código o sus estructuras de datos son más importantes. Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones “.

Las pruebas de coeficiente intelectual que usted describe prueban que si el candidato las aprueba, se le puede enseñar a ser un buen programador. Sin embargo, si no puede, se pierde toda esperanza.

Gracias A2A

” apenas nos preocupamos por todas estas cosas ” – Esta es una comprensión absolutamente incorrecta. Dejame explicar.

La base de cualquier buen software es DSA. Sin DSA no hay desarrollo lógico ni codificación. Un lenguaje es solo una implementación de la lógica y la arquitectura que se ha desarrollado. Y el desarrollo de la lógica y la arquitectura no es nada sin la estructura de datos y los algoritmos. Una vez que tenga la arquitectura lista, puede implementarla con cualquier idioma.

Por ejemplo, si me piden que imprima mi nombre 10 veces, tengo numerosas formas de hacerlo en mi mano, como bucle, recursión, etc. Ahora, la mejor forma es la que requiere menos tiempo para ejecutarse y La mayoría de la memoria optimizada. Para definir eso necesito estructuras de datos y conceptos algorítmicos. Una vez que se establece la mejor manera, eso se puede implementar en cualquier idioma.

Entonces, lo que miran los entrevistadores es cuán fuerte eres para resolver un problema o desarrollar lógica y arquitectura para las tareas asignadas. El conocimiento del idioma es importante, pero eso viene después del DSA.

Espero que esto aclare la confusión.

Gracias por leer.

En primer lugar, me gustaría expresar mis puntos de vista sobre la segunda parte de la pregunta:

En la vida real apenas nos preocupamos por todas estas cosas …

Data Structures se trata de organizar los datos de manera adecuada, al igual que mantenemos las cosas de la vida real de manera adecuada.

Veamos algunos ejemplos de las estructuras de datos inspiradas en la vida real …

Matrices :

Los arreglos bien organizados de camisas, pantalones, zapatos. Al igual que las matrices de int, float, caracteres en Data Structures.

Pila :

Pila de platillos

Tipos de datos:

Al igual que mantenemos cualquier líquido en un contenedor, se han definido varios tipos de datos en las estructuras de datos para manejar los datos adecuados. Por ejemplo, int, char y float (para que no fluya en el suelo: p) para manejar adecuadamente la información del tipo respectivo.

Sí, nos molestan estas cosas! La diferencia es que no relacionamos las estructuras de datos con la vida real. 🙂

Llegando a la pregunta:

De qué sirve examinar ingenieros de software sobre estructuras de datos y algoritmos en entrevistas de trabajo …

Ingenieros de software Desarrollan el software. También requiere una visión artística junto con la codificación en el desarrollo de un software. es decir, cómo deben llevarse a cabo las cosas, cómo deben organizarse los datos adecuadamente, de modo que la recuperación sea más fácil y con el menor esfuerzo.

El candidato debe ser capaz de resolver correctamente un problema de la manera más corta posible utilizando recursos existentes limitados (es decir, la menor complejidad de tiempo y espacio).

Es por eso que se requiere examinar ingenieros de software sobre estructuras de datos y algoritmos en entrevistas de trabajo.

Reacciono muy negativamente a la parte UPD, porque revela un malentendido básico de la lógica formal. Lo que, en un interesante ciclo de retroalimentación, puede arrojar algo de luz sobre la pregunta original.

La primera oración “¿Cómo puede alguien esperar que puedas mejorar algo cuando ni siquiera lo entiendes adecuadamente?” No tiene sentido. Es una forma de hablar común de expresar la declaración (que puede o no ser cierta, pero creo que muchas personas la comparten):

No “entender” implica no “poder mejorar”

No puede responder a eso con la declaración:

“¿Cómo puede alguien esperar que puedas mejorar algo cuando lo entiendes adecuadamente?”

¿Significaría eso?
¿”Entender” implica no “poder mejorar”?
(Creo que la mayoría de la gente estaría totalmente en desacuerdo con esa afirmación)
o
“Comprender” implica “¿Puede mejorar o no puede mejorar”? Lo cual es una tautología y ya es la conclusión que está sacando.

Significa que la estúpida conclusión que está sacando usando la lógica formal (¿en serio? No vi la lógica formal aquí) no proviene de la declaración inicial, sino completamente de la respuesta que proporcionó.

Y en serio, las preguntas formuladas en las entrevistas generalmente no se parecen en nada a lo que usted dice. Los entrevistadores rara vez preguntan acerca de los detalles de todos los métodos de clasificación existentes (la clasificación es un ejemplo), lejos de eso. Preguntan sobre métodos de programación muy básicos muy conocidos. Es muy improbable que algún entrevistador le pregunte acerca de tipos paralelos, o de ordenamiento uniforme, incluso de montón. Pero se espera que todos tengan alguna noción de bubbleort y quicksort para alguien que reclame conocimientos básicos de algoritmos. Al igual que se espera que alguien que dice saber el lenguaje C conozca la lista completa de operadores disponibles y su precedencia. Entrevisté a programadores que afirmaban tener 5 años de experiencia en programación en C ignorando la existencia del operador de módulo y los operadores binarios, incapaces de distinguir entre stream io (fread / fwrite) e io usando un descriptor de archivo. Eso no es conocimiento crujiente, es conocimiento básico.

Cuando se hacen preguntas algorítmicas, es más o menos una forma de observar cómo reacciona un candidato y tratar de resolver algo nuevo. Si un candidato determinado se siente demasiado a gusto con una pregunta, mi reacción como entrevistador suele ser “OK, ¡estaba preparado para eso, la pregunta es inútil! Tendré que hacer otra.

Por lo general, también haré varias preguntas de varios dominios de habilidades que el candidato afirma tener (sus afirmaciones), incluso si estoy buscando a alguien que trabaje con otras tecnologías además de las que le estoy preguntando.

Como entrevistador, estoy interesado en ver si está realmente a gusto, si es una especie de principiante con una mentalidad de aprendizaje, o si no tiene ni idea y / o no le importa o mintió sobre su Reclamado experto.

Los expertos o los principiantes pueden estar bien, pero las otras categorías, por supuesto, trato de evitarlas.

¿Contrataría a un taxista sin saber qué tipo de combustible debería poner en el tanque o creería que está mintiendo? ¿Que probablemente ni siquiera es su auto … y que dejarlo conducir podría ser peligroso? Por supuesto, saber lo que hay en el tanque no tiene ningún impacto en las habilidades de conducción … sin embargo.

No estoy seguro de que muchas personas pregunten sobre la clasificación, dudar y ‘pensar en voz alta’ debería estar perfectamente bien, y creo que el trabajo tiende a ser todo sobre estructuras de datos y algoritmos, pero entiendo su punto.

Creo que la motivación para las preguntas es establecer si la persona realmente tiene la comprensión y el nivel de experiencia que afirman en su currículum. La justificación para este tipo de preguntas se encuentra cuando realmente escucha algunas de las respuestas que las personas dan a las preguntas.

Creo que los equipos deben tener cuidado de no dejarse llevar y comenzar a hacer preguntas que pretenden impresionarse entre sí, en lugar de evaluar las calificaciones del candidato.

También puede consultar la respuesta de Jeff Nelson a ¿Cómo es tener una entrevista de trabajo con Jeff Nelson?

No espero que alguien pueda describir los algoritmos de CS en detalle a menos que esté entrevistando para un papel muy específico.

Esperaría poder iniciar una conversación sobre cómo abordaría la clasificación de datos para un problema. Me preocuparía si no preguntaras qué tan grande es probable que los datos sean comunes, así como casos inusuales.

Obtendría puntos de bonificación por preguntar si el tiempo de clasificación era parte de un flujo de trabajo perceptible para el usuario y qué más está sucediendo en ese flujo de trabajo. Por ejemplo, si estamos clasificando los resultados de una recuperación de datos de 10 minutos, no me importa si su clasificación tarda 0,5 segundos o 10 segundos; es más probable que me importe la solidez y el tiempo de implementación.

Uno de mis problemas con los grupos de encuentro de Agile en los que he estado es que muchas de las conversaciones sobre la gestión del desarrollo y el esfuerzo del software parecen asumir cosas sobre la complejidad del software similares al autor de esta publicación. El mundo del software también incluye un código especializado mucho más difícil.