Praticamente tutto nel software opera sulla quantità. Questo è ciò che fanno le strutture dati: forniscono un modo per contenere la quantità. Strutture diverse hanno diverse caratteristiche di performance.
Di gran lunga, la più spesso incontrata è l'array. Gli array sono tradizionalmente statici. Questo significa che la loro dimensione è nota in anticipo e un nuovo array deve essere creato per contenere una quantità maggiore. La maggior parte dei linguaggi fornisce un array dinamico di qualche tipo: a volte chiamato Vector, List, ArrayList, ecc. È una struttura dati che astrae i dettagli del ridimensionamento di un array quando necessario. Questo dà la sensazione di poter continuare ad aggiungere/rimuovere elementi senza dover gestire direttamente la memoria.
Linguaggi dinamici come Python, PHP, JavaScript implementano effettivamente un array come una DoublyLinkedList sotto il cofano, e ottimizzano la semantica dell'array se e solo se gli indici sono numeri sequenziali.
Quando si usano API di sistema di basso livello in Windows/Linux si incontra spesso la necessità di utilizzare puntatori a quelle che sono ovviamente liste collegate (piuttosto che array). Ai vecchi tempi, suppongo, le LinkedLists erano preferibili probabilmente perché risparmiavano memoria rispetto a grandi allocazioni di memoria come un array richiederebbe.
La prossima struttura dati che ho incontrato più comunemente è lo Stack. Gli stack sono incredibilmente utili per lasciare briciole di pane, tracce di stack, ecc.
E poi direi la coda. Ma non incontro spesso una coda in memoria, ma più una coda di messaggi per gestire le comunicazioni distribuite. Queste code scrivono sul file system o sulla rete piuttosto che sulla memoria.
Un file system sul disco rigido, sulla scheda flash, sul CD-ROM, ecc. sono tutti alberi. L'idea di una gerarchia di cartelle e file... è un albero. Internamente è un albero B* di qualche tipo. Ma tecnicamente è un albero non ordinato.
L'unica volta al di fuori della preparazione di un colloquio che ho incontrato un grafico è stato quando ho dovuto scriverne uno, usando un ordinamento topologico, per costruire un compilatore C# distribuito per ridurre un tempo di compilazione di 49 minuti (per 500+ progetti C#) a 20 secondi. Il grafico tracciava le dipendenze e a quale livello in modo da poter determinare il livello di parallelismo e quando costruire cosa, insieme a un file system distribuito in modo che gli altri nodi non dovessero costruire la stessa dipendenza. Nei giochi, incontrerete spesso i grafici anche per definire il percorso dei nemici per trovarvi.