Perché le strutture dati sono così importanti nelle interviste? [chiuso]

Devo confessare che non ero così forte nelle strutture di dati quando mi sono laureato fuori dal college. Durante gli studi universitari durante la mia laurea, ho visto che la maggior parte delle grandi aziende tecnologiche come Amazon, Microsoft ecc. Si concentrava principalmente sulle strutture di dati. Sembra che le strutture di dati siano l'unica cosa che si aspettano da un laureato.

Ad essere sincero, mi sono sentito male per questo. Scrivo un buon codice. Seguo schemi di progettazione standard di codifica, utilizzo strutture di dati ma a livello superficiale come nelle API esposte Java come ArrayList, LinkedList ecc. Ma le aziende di solito si concentrano su aspetti complessi di Strutture dati come la manipolazione della memoria basata su puntatori e complessità temporali.

Probabilmente a causa del mio background Java, allora, ho capito l'efficienza del codice e la logica solo quando ho parlato in termini di programmazione orientata agli oggetti come oggetti, istanze, ecc., Ma non ho mai analizzato il livello di bit e byte. Non volevo che la gente mi guardasse dall'alto in basso per questo mio deficit di conoscenza in Data Structures.

Quindi, davvero, perché tutta questa enfasi su Data Structures?

la maggior parte delle grandi aziende tecnologiche come Microsoft si concentra principalmente sulle strutture di dati. Sembra che le strutture di dati siano l'unica cosa che si aspettano da un laureato.

No, c'è di più. Ad esempio, ci aspettiamo anche che tu sia uno studente veloce che può apprendere nuovi framework, API o persino linguaggi di programmazione in breve tempo. Questa è una barra minima nuda. Qualcuno che impiega molto tempo per apprendere un nuovo framework, API o lingua non sarà uno sviluppatore di successo nella maggior parte dei team di Microsoft.

E naturalmente ci sono molti altri aspetti su cui ci concentriamo nelle interviste oltre alla semplice conoscenza delle strutture di dati. Capacità di gestire specifiche ambigue, ad esempio, o capacità di riconoscere schemi di codifica che producono codice insicuro, o una dozzina di altre cose. Ma la capacità di comprendere le strutture di dati è certamente molto grande.

In particolare, le interviste sono distorte per testare la conoscenza delle strutture dati per i neolaureati. I neolaureati, la maggior parte dei quali non hanno molta esperienza nel mondo reale, non dovrebbero essere bravi nello stesso genere di cose in cui qualcuno con quindici anni di esperienza nel settore sarebbe bravo.

Devo confessare che non ero così forte nelle strutture di dati

È bello che tu lo sappia di te stesso. Se non sei in grado o non sei disposto a cambiarlo, allora la mia raccomandazione è di non candidarti per un lavoro che richiede una struttura con strutture dati.

vi è questa prospettiva generale secondo cui un buon programmatore è necessariamente uno con una buona conoscenza delle strutture di dati.

È tautologico che un buon programmatore sia un programmatore che è bravo a costruire il tipo di programmi che devono essere costruiti. Molti programmatori lavorano su attività che non richiedono una conoscenza approfondita delle strutture di dati. Alcuni di loro lavorano su attività che richiedono una profonda conoscenza della progettazione dell'interfaccia utente, ad esempio. O normalizzazione del database. O qualunque cosa. Quelle persone possono ancora essere "buoni programmatori" nei loro domini.

perché tutta questa enfasi sulle strutture dati?

Faccio domande di intervista sulle strutture di dati perché nel mio team gli sviluppatori progettano, implementano e manipolano strutture di dati complessi tutto il giorno ogni giorno. Ieri abbiamo avuto quattro ore di incontri in cui una mezza dozzina di sviluppatori ha discusso i pro e i contro dell'aggiunta di un singolo campo booleano a un particolare nodo ad albero. Probabilmente nel mio team non ci sono abilità più importanti della capacità di comprendere le strutture di dati a un livello profondo. Sarebbe sciocco non porre domande al colloquio al riguardo, poiché è quello che facciamo.

La conoscenza delle strutture dati non influisce davvero sulla carriera di programmatore?

Beh, sicuramente ti impedirà di trovare lavoro nella mia squadra. Ma come ho detto prima, la programmazione è un campo enorme . Esistono molti tipi di programmazione per computer che non richiedono la conoscenza delle strutture dati.

la conoscenza in questa materia è davvero una base sufficiente per differenziare un programmatore buono e uno cattivo?

No. Ma è quasi sempre sufficiente rilevare gli sviluppatori che difficilmente avranno successo in Microsoft. Dal momento che questo è ciò che mi interessa principalmente rilevare, la conoscenza delle strutture di dati è uno dei fattori per cui testare nelle interviste.

Un punto importante sulle strutture di dati è che sono universali e senza tempo, almeno per scopi pratici. Chiunque sia stato uno sviluppatore negli ultimi 30 anni dovrebbe conoscere le strutture di dati di base come elenchi singoli / doppi, alberi binari o grafici. Se chiedi loro due sviluppatori, puoi confrontare le conoscenze degli sviluppatori con le loro risposte. Difficilmente si può dire per framework o addirittura lingue: se chiedi a due sviluppatori di Rails, e uno ne sa molto di più dell'altro, che cosa ti dice davvero? Come dici nella domanda, uno sviluppatore intelligente può imparare un nuovo framework abbastanza rapidamente, quindi testare le loro conoscenze attuali non ha molto senso.

Non avere conoscenza delle strutture dati influenza davvero la propria carriera nella programmazione?

Sì. Decisamente. A meno che tu non voglia passare tutta la vita a scrivere applicazioni CRUD.

O la conoscenza in questa materia è davvero una base sufficiente per differenziare un programmatore buono e uno cattivo?

No, non è sufficiente. Ma ci sono poche cose che puoi chiedere in un colloquio di lavoro che sono sufficienti. E direi che la conoscenza degli algoritmi è uno degli indicatori migliori, almeno per le persone appena fuori dalla scuola, dove non si possono chiedere esperienze di lavoro.

Sono uno studente veloce e posso apprendere nuovi framework, API o persino linguaggi di programmazione in un tempo considerevolmente breve.

Non sembrare troppo duro, ma qualsiasi sviluppatore decente sarà in grado di acquisire una nuova lingua o framework in un periodo di tempo relativamente breve.

Le strutture dei dati sono universali, sono un elemento fondamentale dell'informatica: un albero rosso-nero è sostanzialmente lo stesso, sia che sia implementato in Java, Python, PHP o altro. Quindi, piuttosto che testare linguaggi specifici o quadri specifici, un datore di lavoro (almeno un datore di lavoro alla ricerca di sviluppatori di rilievo) verificherà se conosci i fondamenti dell'informatica, piuttosto che qualunque sia il sapore del mese " stai attualmente utilizzando.

(almeno, dovrebbero testare i fondamenti oltre a qualsiasi cosa stiano attualmente utilizzando ... inutile assumere un mago di informatica se non ha mai scritto una riga di codice in vita sua)

Credete che F1 piloti appena guidare auto veloci? No, capiscono l'auto che guidano e lavorano con i meccanici / ingegneri per metterla a punto. Ovviamente, un normale driver guida.

Puoi essere un programmatore normale / medio che scrive solo codice. Non capisci cosa c'è dietro. Fai le cose. Questo è tutto, ci vediamo il giorno dopo.

Ma molte aziende cercano sviluppatori di F1. Le persone che si svilupperanno sapendo cosa c'è dietro il loro codice. Persone che aiuteranno anche l'azienda a costruire qualcosa di meglio.

È abbastanza buono conoscere le strutture di dati non solo perché le userete molto spesso in un formato "precotto". Va anche bene perché creerai qualcosa che deriva dalla loro idea.

Nella mia classe sulle strutture di dati, la prima cosa che il professore ha detto è stata: questa classe non riguarda la possibilità di effettuare ricerche molto velocemente. Abbiamo quindi trascorso un anno e mezzo alla ricerca delle migliori strutture dati e algoritmi possibili per effettuare ricerche molto velocemente.

Tuttavia, è rimasto giusto. Essere in grado di analizzare le strutture di dati, applicare la giusta struttura di dati a un determinato problema o persino inventare nuove strutture di dati richiede molte qualità di un ingegnere:

• Trovare astrazioni per modellare un problema concreto
• Essere in grado di scomporre i problemi
• Essere in grado di ragionare logicamente / formalmente
• creatività
• eccetera.

Quando Amazon e Microsoft assumono persone, non fanno domande sulle strutture di dati perché sperano di inventare il prossimo quicksort . Vogliono assicurarsi di assumere qualcuno con le qualità sopra menzionate.

Naturalmente è possibile avere un ampio insieme di queste qualità e succhiare ancora le strutture dei dati. Ma in tal caso, non ci vorrà molto tempo per diventare un esperto in strutture di dati.

Detto questo, c'è ancora il problema che ArrayListnon è abbastanza ampio. Quando i sistemi diventano grandi, sono necessarie soluzioni meglio adattate per eseguire il lavoro. E senza una buona conoscenza delle strutture dati, non sarai in grado di trovare e comporre strutture e algoritmi che si ingrandiscono nel tuo scenario concreto.

In generale, gli algoritmi e le strutture di dati sono considerati due degli argomenti più "fondamentali" nella programmazione. Questo perché c'è un enorme corpus di lavori e ricerche che li riguardano nell'informatica. Inoltre attirano i tipici programmatori del "lobo sinistro" che amano cose come la matematica e la scienza (che è un sacco di programmatori)

Detto questo, la conoscenza di questi potrebbe influenzare la tua carriera in termini di interviste, soprattutto se intervisti in luoghi di lavoro orientati all'ingegneria come Google. Altre aziende potrebbero ora preoccuparsi di questo aspetto.

Nella mia esperienza, le richieste dell'algoritmo / della struttura dei dati possono talvolta presentarsi come "elitismo programmatore" in cui i fanatici dell'alfa stanno facendo jockey per mostrare chi è il più intelligente. È sempre bello sapere cosa c'è là fuori, ma ci sono molti diversi lavori di programmazione in cui non avrai mai bisogno di sapere come usare un albero rosso / nero o programmare una ricerca da ragazzo.

Ti consiglierei di saperne di più sugli argomenti se li trovi interessanti e hai qualche progetto personale in cui puoi armeggiare con loro, altrimenti potresti probabilmente cavartela senza di loro per ora

PS. Competenza con strutture di dati rudimentali (elenchi collegati, dizionari, hashtable ecc.) Dovrebbe essere una conoscenza obbligatoria per qualsiasi programmatore DS.

Quindi, davvero, perché tutta questa enfasi su Data Structures?

Due ragioni.

Per prima cosa, mostra che puoi pensare al problema in termini astratti, piuttosto che in termini di un linguaggio di programmazione specifico. Sai perché una tabella hash può essere una scelta migliore o peggiore di un albero rosso-nero in una determinata situazione, indipendentemente dall'implementazione sottostante?

Per un altro, ci sono un numero spaventoso di persone là fuori che intervistano per lavori che semplicemente mentono sulla loro esperienza e hanno pochissime capacità di programmazione; le domande sulla struttura dei dati sono un modo rapido per eliminare queste persone.

Sono fondamentali, ma anche, su cosa vorresti fare i laureati? Possono o meno avere esperienza al di fuori del loro lavoro di corso. Il loro corso potrebbe aver riguardato le tecnologie Microsoft più che dire Java, o viceversa. Le strutture di dati sono un terreno comune.

Spesso il codice migliore evita di reinventare strutture di dati di basso livello. Ciò è particolarmente vero nelle lingue di alto livello. Ho notato una tendenza verso domande di basso livello sulla struttura dei dati anche nei lavori CRUD. YMMV, ma sembra che l'enfasi sull'esperienza degli scienziati hacker abbia messo in ombra le altre abilità che rendono un grande sviluppatore:

• project / time management: essere in grado di tenere il passo con il mondo reale che è guidato dal business, non un nuovo elenco collegato che opera l'1% più veloce.
• una minima quantità di abilità sociali: uno sviluppatore che è arrogante e non può andare d'accordo non è altro che un'ancora.
• la capacità di apprendere nuove cose in modo rapido e continuo: le strutture dei dati non cambiano quasi mai nel corso degli anni ... ma tutto il resto. Le strutture di dati sono fondamentali fondamentali e ogni sviluppatore dovrebbe conoscerle abbastanza bene, ma un contabile non viene testato sulle loro lunghe competenze di divisione quando partecipano a un colloquio. I grandi sviluppatori sono il tipo di persone che possono capire cose nuove e apprezzarle.

Le strutture di dati sono eccezionali. Le strutture di dati sono importanti. Ogni programmatore dovrebbe averne una comprensione. Tuttavia, siamo diventati ossessionati dall'aver spinto questi fondamentali fuori dal loro posto. Non si tratta di TUTTE le strutture di dati e nel 99% dei casi non è necessario porre domande al di là delle basi delle strutture di dati. Se stai intervistando un commercialista, chiedi loro che cos'è 81 diviso per 9, ma se continui a chiedere "Qual è la radice cubica di 98425454242412 * 4512324? ... senza una calcolatrice!" allora spaventerai una buona percentuale delle persone ragionevoli, intelligenti, di talento e gradevoli che avresti potuto avere. Chiedi se possono costruire un modello di dati relazionali di base, chiedi se possono usare le strutture di array avanzate fornite dal framework pertinente, e chiedere se possono spiegare quando una ricerca binaria è più veloce della ricerca semplice, ma non ha molto senso andare oltre. Se riescono a fare queste cose, inizia a cercare il più simpatico, professionale e creativo del gruppo.

Adoro la scrittura di Joel, ma penso che la sua cosa "Java Schools" sia completamente sbagliata. Ci sono molte cose che possono dimostrare che qualcuno è intelligente oltre a padroneggiare il C ++. Pensaci, puoi parlare con qualcuno per 10 minuti, senza chiedere loro del puntatore aritmico, e avere una buona idea se sono il tipo che può fare le cose e capire le cose. Non abbiamo bisogno di essere così:

Intervistatore: "Parlami dei tuoi successi".

Coder: "Nella mia ultima posizione sono stato l'unico sviluppatore di un sistema ERP personalizzato per una società finanziaria da un miliardo di dollari. Abbiamo consegnato mesi prima del previsto e il sistema è stato in produzione negli ultimi 3 anni".

Intervistatore: "Vorrei chiarire. Parlami delle tue realizzazioni di programmazione "

Coder: "Umm ..."

Intervistatore: "Ad esempio, hai mai creato la tua lista di link?"

Coder: "... [uscendo]"

Essere un buon programmatore non significa saper imparare le lingue e i framework. Si tratta di essere in grado di costruire soluzioni a problemi complessi. Perché queste soluzioni siano efficienti e affidabili si baseranno quasi sempre su buoni algoritmi e un uso appropriato delle strutture di dati. Conoscere le strutture di dati esistenti non è sufficiente. È necessario comprendere che le strutture dati saranno sufficienti per utilizzare quella giusta per il problema. Gli elenchi e le mappe offrono alcune funzionalità preziose, ma comportano costi e l'utilizzo di quello errato può compromettere in modo significativo le prestazioni del software.

Un buon intervistatore lo sa e sta cercando di determinare se puoi essere prezioso per la sua squadra o compagnia. Le lingue che userete tra 2 anni potrebbero essere molto diverse, ma la necessità di algoritmi e strutture dati efficaci non cambierà.

Le strutture dei dati, la complessità del tempo, la manipolazione della memoria e i puntatori sono tutti elementi fondamentali che qualcuno che si definisce uno scienziato informatico dovrebbe conoscere innatamente. Qualsiasi scimmia di codice può imparare una lingua e imparare come usarla, ma dove i professionisti e gli studenti CS dovrebbero distinguersi è sapere non solo come utilizzare un elenco collegato o una mappa hash, ma PERCHÉ.

Il PERCHÉ è ciò che ci distingue davvero dal kiddie di script di base, dalla scimmia codice e dal grugnito del mondo dell'informatica. PERCHÉ usare una tabella hash invece di un elenco collegato, PERCHÉ la mia tabella hash dovrebbe trovarsi a una densità di cluster di circa .6-.8, PERCHÉ dovrei usare un elenco collegato in modo circolare qui invece di un elenco doppiamente collegato. PERCHÉ il mio codice dovrebbe funzionare con efficienza 'x' nel peggiore dei casi e 'y' nel caso medio.

Queste strutture di dati di base e la conoscenza non solo del COME vengono utilizzate (il come dovrebbe essere in ogni repertorio repritoire comunque) ma del linguaggio agnostico PERCHÉ vengono utilizzate, che tende ad essere più di quello che stanno cercando in questi casi.

Molti luoghi ti faranno scrivere il codice in una lingua con cui sei fermamente convinto, ma è più una generalità, visto che C non è più la lingua linguistica del mondo della programmazione e strutturare lo pseudo codice può essere un miscuglio sul posto e, nella maggior parte dei casi con codice pseudo / codice p & p non realmente insegnato, assolutamente impossibile da affrontare.

Le strutture di dati sono il fondamento fondamentale di tutti i programmi. Non devi necessariamente conoscerli a fondo, ma devi assolutamente sapere come funzionano.

Perché? Perché tutto il tuo codice interagisce e manipola i dati. Se il set di dati non può essere archiviato in una struttura, non può essere utilizzato. I dati sono come i materiali da costruzione di una casa. Fino a quando non lo metti insieme in una struttura, hai solo un inutile mucchio di assi.

Una volta che avete deciso su come pensare e definire il set di dati, allora si può iniziare ad usarlo per fare le cose, la parte dell'algoritmo classica del duo. Ogni singolo programma che scrivi utilizza una struttura di dati, sebbene in molti casi questa struttura sia così semplicistica da quasi non esistere. Alcune variabili per i dati di stato e abbiamo finito!

Una volta passati oltre i programmi banali, quasi tutto richiede una struttura di dati. Quale preferiresti, un architetto professionista che progetta il tuo grattacielo con le migliori pratiche e la matematica, o lo zio Joe Bob che inizia immediatamente a costruire?

Per costruire su ciò che dice @Pelshoff , è per mostrare che sai cosa stai facendo. Se usi una LinkedList per qualsiasi cosa, ciò potrebbe mostrare che non sai cosa stai facendo o non ti interessa fermarti a pensare al problema. Inoltre, almeno il corso sulle strutture di dati che ho seguito ha riguardato la teoria della complessità di base di quelle strutture di dati che, quando si tratta di grandi insiemi di dati, è molto importante. Questo sarebbe il motivo per cui aziende come Amazon o Microsoft farebbero una cosa del genere.

Devo dire che, prima di prendere una classe di struttura di dati, pensavo che non fossero importanti, ma almeno essere in grado di ricongiungersi quando un elenco collegato (o ArrayList) non è pratico o quali sono gli svantaggi di essi.

Sia che tu scriva un buon codice o meno è un'affermazione soggettiva. È importante sapere che il codice funzionale non sempre crea un buon codice.

Detto questo, le strutture di dati sono importanti perché sono come i lavoratori dietro le quinte che tu, come programmatore, stai dirigendo. È vero che puoi chiamare i metodi su una struttura senza capire veramente cosa sta facendo e puoi utilizzare una struttura senza realmente capire come sono archiviati i dati, ma conoscere questi dettagli ti preparerà meglio a capire quando è appropriato usare una struttura un altro.

Sapere, ad esempio, che è possibile attraversare in entrambe le direzioni attraverso un elenco doppiamente collegato e solo in avanti attraverso un elenco collegato singolarmente può aiutare a determinare quale struttura è importante quando si archiviano i dati. Puoi prendere una decisione ancora più educativa sapendo che un elenco collegato singolarmente può potenzialmente avere un sovraccarico inferiore in termini di consumo di memoria (poiché non contiene puntatori a elementi precedenti), quindi, se hai solo bisogno di scorrere avanti attraverso un elenco, puoi risparmiare un po 'di memoria usando una struttura appropriata.

Questi sono solo piccoli esempi e, in definitiva, se ritieni di stare bene nella tua carriera senza una conoscenza approfondita delle strutture di dati, forse non hai bisogno di saperne di più. Capire cosa sta succedendo sotto il cofano, tuttavia, può davvero aiutare a trasformare il codice funzionale in un buon codice.

Le strutture dati sono i mattoni di molte cose che vuoi fare. Se conosci gli usi di ciascuna struttura di dati, i suoi punti deboli e i suoi punti di forza, puoi facilmente risolvere i problemi.

Ad esempio, avevamo l'obbligo di gestire migliaia di oggetti. Ogni tanto abbiamo bisogno di aggiornare il timestamp di un oggetto in base al suo ID. Di tanto in tanto dovevamo rimuovere gli oggetti che non venivano aggiornati per più di X minuti.

Se conosci le tue strutture dati puoi facilmente definire il problema ed è anche molto facile trovare una soluzione. Quando un programmatore che non conosceva abbastanza strutture di dati ha cercato di trovare una soluzione, la sua soluzione era imbarazzante. Era come te: intelligente, programmatore di codice, in grado di apprendere rapidamente i framework. Ma senza una conoscenza delle strutture dati ha dovuto inventare la ruota da solo. Inoltre, ha avuto difficoltà a comprendere soluzioni più semplici poiché erano basate su strutture di dati che non comprendeva come alberi rosso-neri (la tua vecchia TreeMap in Java).

Quindi, direi che l'importante è sapere come e quando utilizzare ogni struttura di dati senza pensarci. Ma non credo che ci sia alcun modo per raggiungerlo senza realmente capire come funzionano.