Collections and LINQ

List<T> keeps order and allows duplicates, backed by a resizable array — list[i] is O(1). Dictionary<TKey, TValue> maps a key to a value with O(1) average lookup, at the cost of no defined ordering.

var scores = new List<int> { 90, 75, 90 };
var byName = new Dictionary<string, int> { ["Nino"] = 90, ["Ana"] = 75 };

if (byName.TryGetValue("Nino", out var score))
    Console.WriteLine(score);

TryGetValue is the idiom for "look this up, and tell me whether it was there" in one call, without a separate ContainsKey check followed by an indexer lookup that walks the same bucket twice.

LINQ

var names = people
    .Where(p => p.Age >= 18)
    .OrderBy(p => p.Name)
    .Select(p => p.Name)
    .ToList();

Where filters, Select transforms, OrderBy sorts — the same three ideas as filter/map/sort in most other languages, chained in the order you think about the problem. None of them mutate the original collection; each returns a new sequence.

Try it

Deferred execution

A LINQ query built with Where/Select does not run when you write it — it runs when something actually enumerates it: a foreach, or a terminal call like .ToList(), .Count(), or .First().

var query = numbers.Where(n => n > 0);   // nothing has executed yet
numbers.Add(-5);
var result = query.ToList();              // executes now, over the current numbers

If numbers changes between building the query and enumerating it, the enumeration sees the current state, not a snapshot from when the query was written — because there never was a snapshot, only a description of what to do once asked. .ToList() at the point you actually want a fixed result is the way to pin one down, the same discipline a LINQ-to-Entities query over a database needs even more urgently, where "run it twice" can mean two round trips.