¿Por qué las estructuras de datos son tan importantes en las entrevistas? [cerrado]

Debo confesar que no era tan fuerte en estructuras de datos cuando me gradué de la universidad. A lo largo de las colocaciones en el campus durante mi graduación, he sido testigo de que la mayoría de las grandes empresas tecnológicas como Amazon, Microsoft, etc. se centraron principalmente en las estructuras de datos. Parece que las estructuras de datos son lo único que esperan de un graduado.

Para ser honesto, me sentí mal por eso. Escribo buen código. Sigo patrones de codificación de diseño estándar, uso estructuras de datos, pero a nivel superficial como en las API expuestas de Java como ArrayList, LinkedList, etc.

Probablemente debido a mi experiencia en Java, en aquel entonces, entendía la eficiencia y la lógica del código solo cuando hablaba en términos de Programación Orientada a Objetos, como objetos, instancias, etc., pero nunca profundicé en el nivel de bits y bytes. No quería que la gente me menosprecie por mi déficit de conocimiento en las Estructuras de datos.

Entonces, ¿por qué todo este énfasis en las estructuras de datos?

La mayoría de las grandes empresas tecnológicas como Microsoft se centran principalmente en las estructuras de datos. Parece que las estructuras de datos son lo único que esperan de un graduado.

No, hay mas. Por ejemplo, también esperamos que sea un aprendiz rápido que pueda aprender nuevos marcos, API o incluso lenguajes de programación en un corto período de tiempo. Esa es una barra mínima. Alguien que tome mucho tiempo para aprender un nuevo marco, API o lenguaje no será un desarrollador exitoso en la mayoría de los equipos de Microsoft.

Y, por supuesto, hay muchos más aspectos en los que nos centramos en las entrevistas, además del conocimiento en bruto de las estructuras de datos. Capacidad para manejar especificaciones ambiguas, por ejemplo, o capacidad para reconocer patrones de codificación que producen código inseguro, o una docena de otras cosas. Pero la capacidad de comprender las estructuras de datos ciertamente es muy grande.

Es particularmente el caso que las entrevistas están sesgadas hacia la prueba del conocimiento de las estructuras de datos para los recién graduados de CS. No se espera que los graduados recientes, la mayoría de los cuales no tienen mucha experiencia en el mundo real, sean buenos en el mismo tipo de cosas en las que alguien con quince años de experiencia en la industria sería bueno.

Debo confesar que no era tan fuerte en las estructuras de datos.

Es bueno que lo sepas sobre ti. Si no puede o no quiere cambiar eso sobre usted, mi recomendación es que no solicite un trabajo que requiera instalaciones con estructuras de datos.

Existe esta perspectiva general de que un buen programador es necesariamente uno con un buen conocimiento sobre las estructuras de datos.

Es tautológico que un buen programador es un programador que es bueno en la construcción de los tipos de programas que deben construirse. Muchos programadores trabajan en tareas que no requieren un conocimiento profundo de las estructuras de datos. Algunos de ellos trabajan en tareas que requieren un conocimiento profundo del diseño de la interfaz de usuario, por ejemplo. O la normalización de la base de datos. O lo que sea. Esas personas aún pueden ser "buenos programadores" en sus dominios.

¿Por qué todo este énfasis en las estructuras de datos?

Hago preguntas de entrevista sobre estructuras de datos porque en mi equipo los desarrolladores diseñan, implementan y manipulan estructuras de datos complejas todo el día todos los días. Ayer tuvimos cuatro horas de reuniones en las que media docena de desarrolladores discutieron los pros y los contras de agregar un solo campo booleano a un nodo de árbol en particular. Probablemente no haya ninguna habilidad en mi equipo más importante que la capacidad de comprender las estructuras de datos a un nivel profundo. Sería una tontería no hacer preguntas de entrevista al respecto, ya que eso es lo que hacemos.

¿No tener conocimiento en estructuras de datos realmente afecta la carrera de uno en programación?

Bueno, ciertamente evitará que consigas un trabajo en mi equipo. Pero como dije antes, la programación es un campo enorme . Hay muchos tipos de programación de computadoras que no requieren conocimiento de las estructuras de datos.

¿Es el conocimiento en este tema realmente una base suficiente para diferenciar un buen y un mal programador?

No. Pero casi siempre es suficiente detectar a los desarrolladores que es poco probable que tengan éxito en Microsoft. Como eso es lo que principalmente me interesa detectar, el conocimiento de las estructuras de datos es uno de los factores que evalúo en las entrevistas.

Un punto importante sobre las estructuras de datos es que son universales y atemporales, al menos para fines prácticos. Cualquiera que haya sido desarrollador en los últimos 30 años debe conocer estructuras de datos básicas como listas de enlaces simples / dobles, árboles binarios o gráficos. Si le pregunta a dos desarrolladores sobre ellos, puede comparar el conocimiento de los desarrolladores por sus respuestas. Esto difícilmente se puede decir de los frameworks o incluso los lenguajes: si le preguntas a dos desarrolladores sobre Rails, y uno sabe mucho más que el otro, ¿qué te dice eso realmente? Como dice en la pregunta, un desarrollador inteligente puede aprender un nuevo marco lo suficientemente rápido, por lo que probar sus conocimientos actuales no tiene mucho sentido.

¿No tener conocimiento en las estructuras de datos realmente afecta la carrera de uno en la programación?

Si. Seguro. A menos que quiera pasar toda su vida escribiendo aplicaciones CRUD.

¿O el conocimiento en este tema es realmente una base suficiente para diferenciar un programador bueno y uno malo?

No, no es suficiente. Pero hay pocas cosas que puede pedir en una entrevista de trabajo que sean suficientes. Y diría que el conocimiento de algoritmos es uno de los mejores indicadores, al menos para las personas recién salidas de la escuela, donde no se puede preguntar sobre experiencias laborales.

Aprendo rápido y puedo aprender nuevos marcos, API o incluso lenguajes de programación en un período de tiempo considerablemente corto.

No suena demasiado duro, pero cualquier desarrollador medio decente podrá elegir un nuevo lenguaje o marco en un período de tiempo relativamente corto.

Las estructuras de datos son universales, son un componente fundamental de la informática: un árbol rojo-negro es básicamente el mismo, ya sea que esté implementado en Java, Python, PHP o lo que sea. Entonces, en lugar de probar lenguajes específicos o marcos específicos, un empleador (al menos, un empleador que busca desarrolladores sobresalientes) probará si conoce los fundamentos de la informática, en lugar de conocer el sabor del mes ''. Actualmente está utilizando.

(al menos, deberían probar los fundamentos además de lo que estén usando actualmente ... no tiene sentido contratar a un asistente de informática si nunca ha escrito una línea de código en su vida)

¿Crees que los corredores de F1 solo conducen autos rápidos? No, entienden el automóvil que conducen y trabajan con los mecánicos / ingenieros para ajustarlo. Por supuesto, un controlador normal solo conduce.

Puedes ser un programador normal / promedio que solo escribe código. No entiendes lo que hay detrás. Tienes las cosas hechas. Eso es todo, nos vemos al día siguiente.

Pero muchas compañías buscan desarrolladores de F1. Personas que se desarrollarán sabiendo qué hay detrás de su código. Personas que también ayudarán a la empresa a construir algo mejor.

Es bastante bueno conocer las estructuras de datos no solo porque las usará mucho en forma "precocinada". También es bueno porque crearás algo que se deriva de su idea.

En mi clase sobre estructuras de datos, lo primero que dijo el profesor fue: Esta clase no se trata de poder buscar realmente rápido. Luego pasamos medio año buscando las mejores estructuras de datos y algoritmos posibles para buscar realmente rápido.

Aún así, se mantuvo en lo cierto. Poder analizar estructuras de datos, aplicar la estructura de datos correcta a un problema determinado o incluso crear nuevas estructuras de datos requiere muchas cualidades de un ingeniero:

• Encontrar abstracciones para modelar un problema concreto
• Ser capaz de descomponer problemas
• Ser capaz de razonar lógica / formalmente
• Creatividad
• etc.

Cuando Amazon y Microsoft contratan personas, no hacen preguntas sobre las estructuras de datos porque esperan inventar el próximo resumen rápido . Quieren asegurarse de contratar a alguien con las cualidades mencionadas anteriormente.

Por supuesto, es posible tener un gran conjunto de estas cualidades y aun así apestar a las estructuras de datos. Pero entonces, si ese es el caso, no le llevará mucho tiempo convertirse en un experto en estructuras de datos.

Dicho esto, todavía existe el problema que ArrayListsimplemente no escala. Cuando los sistemas se hacen grandes, se requieren soluciones mejor adaptadas para realizar el trabajo. Y sin una buena comprensión de las estructuras de datos, no podrá encontrar y componer estructuras y algoritmos que escalen en general en su escenario concreto.

En general, los algoritmos y las estructuras de datos se consideran dos de los temas más "básicos" en la programación. Esto se debe a que hay una gran cantidad de trabajo e investigación con respecto a ellos en informática. También atraen a los programadores típicos del "lóbulo izquierdo" que les gustan cosas como las matemáticas y las ciencias (que es un montón de programadores)

Dicho esto, el conocimiento de estos podría afectar su carrera en términos de entrevistas, especialmente si entrevista en lugares de trabajo orientados a la ingeniería como google. Ahora, sin embargo, otras compañías podrían preocuparse por ese aspecto.

En mi experiencia, las demandas de algoritmos / estructura de datos a veces pueden aparecer como "elitismo del programador", donde los geeks alfa están compitiendo para mostrar quién es el más inteligente. Siempre es bueno saber qué hay ahí fuera, pero hay muchos trabajos de programación diferentes en los que nunca necesitará saber cómo usar un árbol rojo / negro o codificar una búsqueda de boyer moore.

Recomiendo aprender más sobre los temas si los encuentra interesantes y tiene algún proyecto personal donde pueda jugar con ellos, de lo contrario, probablemente pueda sobrevivir sin ellos por ahora

PD. El dominio de estructuras de datos rudimentarias (listas vinculadas, diccionarios, tablas hash, etc.) debe ser un conocimiento obligatorio para cualquier programador DS.

Entonces, ¿por qué todo este énfasis en las estructuras de datos?

Dos razones.

Por un lado, muestra que puede pensar en el problema en términos abstractos, en lugar de en términos de un lenguaje de programación específico. ¿Sabe por qué una tabla hash puede ser una opción mejor o peor que un árbol rojo-negro en una situación dada, independientemente de la implementación subyacente?

Por otro lado, hay una cantidad aterradora de personas entrevistando para trabajos que simplemente mienten sobre su experiencia y tienen muy poca o ninguna capacidad de programación; Las preguntas sobre estructuras de datos son una forma rápida de eliminar a estas personas.

Son fundamentales, pero también, ¿en qué evaluarías a los graduados? Pueden o no tener experiencia fuera del trabajo del curso. Su curso puede haber cubierto las tecnologías de Microsoft más que decir Java, o viceversa. Las estructuras de datos son un terreno común.

Muchas veces el mejor código evita reinventar estructuras de datos de bajo nivel. Esto es especialmente cierto en los idiomas de alto nivel. He notado una tendencia hacia preguntas de estructura de datos de bajo nivel incluso en trabajos CRUD. YMMV, pero parece que el énfasis en la experiencia científica de los hackers ha eclipsado las otras habilidades que hacen un gran desarrollador:

• gestión de proyecto / tiempo: poder mantenerse al día con el mundo real que es impulsado por los negocios, no con una nueva lista vinculada que opera un 1% más rápido.
• una cantidad mínima de habilidades sociales: un desarrollador que es arrogante y no puede llevarse bien no es más que un ancla.
• la capacidad de aprender cosas nuevas de forma rápida y continua: las estructuras de datos apenas cambian con los años ... pero todo lo demás sí. Las estructuras de datos son grandes fundamentos y cada desarrollador debe conocerlas bastante bien, pero un contador no se pone a prueba en sus habilidades de división larga cuando van a una entrevista. Los grandes desarrolladores son el tipo de personas que pueden descubrir cosas nuevas y gustarles.

Las estructuras de datos son geniales. Las estructuras de datos son importantes. Todo programador debe comprenderlos. Sin embargo, nos hemos obsesionado con empujar estos fundamentos fuera de su lugar. No se trata TODO de estructuras de datos, y en el 99% de los casos no hay necesidad de hacer preguntas más allá de los conceptos básicos de las estructuras de datos. Si está entrevistando a un contador, asegúrese de preguntarle qué es 81 dividido entre 9, pero si sigue preguntando "¿Cuál es la raíz cúbica de 98425454242412 * 4512324? ... ¡sin una calculadora!" entonces asustará a un buen porcentaje de las personas razonables, inteligentes, talentosas y agradables que podría haber tenido. Pregunte si pueden construir un modelo básico de datos relacionales, pregunte si pueden usar las estructuras de matriz mejoradas proporcionadas por el marco relevante, y pregunte si pueden explicar cuándo una búsqueda binaria es más rápida que la búsqueda plana, pero no tiene mucho sentido ir más allá de eso. Si pueden hacer esas cosas, entonces comience a buscar el más agradable, profesional y creativo del grupo.

Me encanta la escritura de Joel, pero creo que su cosa de "Escuelas de Java" está completamente equivocada. Hay muchas cosas que pueden probar que alguien es inteligente más allá de dominar C ++. Piénselo, puede hablar con alguien durante 10 minutos, sin preguntarle acerca de la aritmética del puntero, y tener una idea bastante buena de si es del tipo que puede hacer las cosas y resolver las cosas. No necesitamos ser así:

Entrevistador: "Cuéntame sobre tus logros".

Codificador: "En mi último puesto, fui el único desarrollador de un sistema ERP personalizado para una empresa financiera de mil millones de dólares. Entregamos meses antes de lo previsto y el sistema ha estado en producción durante los últimos 3 años".

Entrevistador: "Déjame aclarar. Cuéntame sobre tus logros de programación "

Codificador: "Umm ..."

Entrevistador: "Por ejemplo, ¿alguna vez has hecho tu propia lista vinculada?"

Codificador: "... [saliendo]"

Ser un buen programador no se trata de poder aprender idiomas y marcos. Se trata de poder construir soluciones a problemas complejos. Para que estas soluciones sean eficientes y confiables casi siempre dependerán de buenos algoritmos y el uso apropiado de las estructuras de datos. Saber que existen las estructuras de datos no es suficiente. Debe comprender que las estructuras de datos serán suficientes para usar la correcta para el problema. Las listas y los mapas ofrecen algunas características valiosas, pero conllevan costos, y el uso de uno incorrecto puede socavar significativamente el rendimiento de su software.

Un buen entrevistador lo sabe y está tratando de determinar si puede ser valioso para su equipo o empresa. El idioma (s) que utilizará dentro de 2 años puede ser muy diferente, pero la necesidad de algoritmos y estructuras de datos efectivos no cambiará.

Las estructuras de datos, la complejidad del tiempo, la manipulación de la memoria y los punteros son elementos fundamentales que alguien que se hace llamar informático debe saber de forma innata. Cualquier código mono puede aprender un idioma y aprender a usarlo, pero donde los profesionales de CS y los estudiantes deben diferenciarse es saber no solo cómo usar una lista vinculada o un mapa hash, sino POR QUÉ.

El POR QUÉ es lo que realmente nos distingue del script script kiddie, code monkey y gruñido del mundo de la informática. POR QUÉ usar una tabla hash en lugar de una lista vinculada, POR QUÉ mi tabla hash debe estar en una densidad de clúster de aproximadamente .6-.8, POR QUÉ debería usar una lista vinculada circular aquí en lugar de una lista doblemente vinculada. POR QUÉ mi código debería ejecutarse con eficiencia 'x' en el peor de los casos e 'y' en el caso promedio.

Estas estructuras de datos básicas y el conocimiento no solo del CÓMO se usan (el cómo debería estar en cada programador, de todos modos) sino también el lenguaje agnóstico POR QUÉ se usan, lo que tiende a ser más de lo que están buscando en estos casos.

Muchos lugares te harán escribir el código en un lenguaje con el que eres firme, pero eso es más general, ya que C realmente ya no es el idioma franca del mundo de la programación, y estructurar el pseudocódigo puede ser un revoltijo y todo sobre el lugar y, en la mayoría de los casos con pseudocódigo / p & p code que realmente no se enseña, es imposible tratar con él.

Las estructuras de datos son la base fundamental de todos los programas. No necesariamente necesita tener una comprensión profunda de ellos, pero absolutamente debe saber cómo funcionan.

¿Por qué? Porque todo su código interactúa y manipula datos. Si el conjunto de datos no se puede almacenar en una estructura, no se puede usar. Los datos son como los materiales de construcción de una casa. Hasta que lo juntes en una estructura, solo tienes una pila inútil de tablas.

Una vez que haya decidido sobre la forma de pensar y definir el conjunto de datos, entonces se puede empezar a usarlo para hacer las cosas, la parte algoritmo clásico del dúo. Cada uno de los programas que escribe usa una estructura de datos, aunque en muchos casos esta estructura es tan simple que casi no existe. ¡Algunas variables para datos de estado y hemos terminado!

Una vez que va más allá de los programas triviales, casi todo requiere una estructura de datos. ¿Cuál preferirías, un arquitecto profesional que diseña tu rascacielos con las mejores prácticas y matemáticas, o el tío Joe Bob que inmediatamente comienza a construir?

Para construir sobre lo que dice @Pelshoff , es demostrar que sabes lo que estás haciendo. Si usa una LinkedList para todo, eso puede mostrar que no sabe lo que está haciendo o que no le importa detenerse y pensar sobre el problema. Además de eso, al menos el curso de estructuras de datos que tomé cubierto, la teoría básica y compleja de esas estructuras de datos que, cuando se trata de grandes conjuntos de datos, es muy importante. Esa sería la razón por la cual compañías como Amazon o Microsoft harían tal cosa.

Debo decir que antes de tomar una clase de estructura de datos pensé que no eran importantes, pero al menos poder reconocer cuando una lista vinculada (o ArrayList) no es práctica o cuáles son sus desventajas.

Si escribes un buen código o no es una declaración subjetiva. Es importante saber que el código funcional no siempre es un buen código.

Dicho esto, las estructuras de datos son importantes porque son como los trabajadores detrás de escena que usted, como programador, está dirigiendo. Es cierto que puede llamar a métodos en una estructura sin comprender realmente lo que está haciendo y puede utilizar una estructura sin realmente saber cómo se almacenan los datos, pero conocer estos detalles lo preparará mejor para comprender cuándo es apropiado usar una estructura sobre otro.

Saber, por ejemplo, que puede atravesar en ambas direcciones a través de una lista doblemente vinculada y solo hacia adelante a través de una lista individualmente vinculada puede ayudarlo a determinar qué estructura es importante al almacenar datos. Puede tomar una decisión aún más educativa al saber que una lista vinculada individualmente puede tener una sobrecarga menor en términos de consumo de memoria (ya que no contiene punteros a elementos anteriores), por lo que, si solo necesita iterar hacia adelante a través de una lista, Puede guardar algo de memoria utilizando una estructura adecuada.

Estos son solo pequeños ejemplos y, en última instancia, si siente que le está yendo bien en su carrera sin un conocimiento íntimo de las estructuras de datos, entonces tal vez no necesite aprender más. Sin embargo, comprender lo que sucede debajo del capó puede realmente ayudar a convertir el código funcional en un buen código.

Las estructuras de datos son bloques de construcción de muchas cosas que desea hacer. Si conoce los usos de cada estructura de datos, sus puntos débiles y sus puntos fuertes, puede resolver fácilmente los problemas.

Por ejemplo, teníamos el requisito de administrar miles de objetos. De vez en cuando necesitamos actualizar la marca de tiempo de un objeto de acuerdo con su ID. De vez en cuando necesitábamos eliminar los objetos que no se actualizaron durante más de X minutos.

Si conoce sus estructuras de datos, puede definir fácilmente el problema, y ​​también es muy fácil encontrar una solución. Cuando un programador que no conoce suficientes estructuras de datos trató de encontrar una solución, su solución fue incómoda. Era como tú: inteligente, programador de códigos, capaz de aprender marcos rápidamente. Pero sin un conocimiento de las estructuras de datos, tuvo que inventar la rueda solo. Más que eso: tuvo dificultades para comprender soluciones más simples ya que se basaban en estructuras de datos que no entendía, como los árboles rojo-negros (su antiguo TreeMap en Java).

Entonces, diría que lo importante es saber cómo y cuándo usar cada estructura de datos sin tener que pensar en ello. Pero no creo que haya ninguna forma de lograrlo sin comprender realmente cómo funcionan.