A: It is O(1) on average because the hash function computes an array index directly, so finding the bucket is arithmetic rather than search, and if keys are well distributed each bucket holds a small constant number of entries. It becomes O(n) when all keys collide into the same bucket, because the lookup then degenerates into a linear scan of that bucket's chain. Collisions cluster like that when the hash function is poor, when the key distribution is pathological, or when an attacker deliberately crafts colliding keys — so the average case depends on an assumption about the input that is not always safe to make.

A: Objects that are equal must return the same hash code; the reverse need not hold, since unequal objects may collide. If you override Equals without overriding GetHashCode, two equal objects can hash to different buckets, so you insert an item and a lookup with an equal key searches the wrong bucket and reports not found — the item is in the dictionary and unreachable. The third rule is that the hash must not change while the object is in use as a key: mutating a field that GetHashCode reads strands the entry in its old bucket, where it can be neither found nor removed. That is why immutable keys, such as records or init-only types, are the safe default.

A: The load factor is the ratio of stored entries to bucket capacity, and it measures how crowded the table is. As it approaches one, collisions become common and the average chain length grows, so lookups drift from O(1) toward O(n). Implementations therefore resize when the load factor crosses a threshold — allocating a larger bucket array and rehashing every existing entry, since bucket assignment depends on capacity. That rehash is O(n), which makes individual insertions occasionally expensive even though n insertions cost O(n) overall. Passing an expected capacity to the constructor avoids every intermediate resize.

A: It is a denial-of-service attack where the attacker submits many keys deliberately chosen to hash to the same bucket, collapsing the table's O(1) behaviour into O(n) per lookup — so n insertions become O(n²) and a single modest request can burn enormous CPU. It historically hit web frameworks through form fields, query strings, and JSON properties, which are all parsed into dictionaries with attacker-controlled keys. .NET defends by randomising string hash codes per process, so the attacker cannot precompute a colliding set offline. A direct consequence is that GetHashCode values are not stable across processes or runs and must never be persisted or transmitted.

A: Whenever you need ordering — sorted iteration, minimum or maximum, range queries, or "the next key after this one" — because hashing deliberately destroys any relationship between key value and position, so those operations require a full scan and a sort. You should also avoid it when the worst case matters more than the average, such as under a hard tail-latency budget or with attacker-controlled keys, where a balanced tree's guaranteed O(log n) is worth more than a hash's average O(1). Finally it is a poor fit for very small collections, where a linear scan of an array is faster in practice and allocates nothing, and where hashing overhead exceeds the search it replaces.

A: Because its operations are not atomic — an insert may need to write an entry, update a bucket's head index, and possibly resize and rehash the whole table, and a concurrent reader can observe that sequence half-applied. The consequences go beyond a lost update: a reader can follow a partially-updated chain of next-index links and loop forever, pinning a CPU core, and concurrent writers can produce duplicated or lost entries and an internally inconsistent table. The fix is ConcurrentDictionary<K,V>, which uses lock-free reads and striped locks for writes; note that its GetOrAdd factory can execute more than once under contention even though only one result is stored, so that factory must be idempotent.

A: With separate chaining, each bucket points at a collection of entries that hashed there, so collisions extend a chain and the table tolerates load factors above one, with deletion being a simple unlink. With open addressing, every entry lives in the main array and a collision probes for another free slot by linear, quadratic, or double hashing, which gives much better cache locality since there is no indirection, but performance collapses as the load factor approaches one, and deletion requires tombstone markers so probe sequences are not broken. .NET's Dictionary uses a chaining variant implemented over flat arrays with index links, which captures most of open addressing's locality benefit while keeping chaining's graceful degradation.

A: It must distribute keys uniformly across the table so that no bucket attracts a disproportionate share, it must use every field that participates in equality so that equal objects agree and unequal ones separate, it should be fast because it runs on every lookup, and it should avalanche — a one-bit change in the input should change roughly half the output bits, so structured inputs like sequential IDs or common prefixes do not cluster. In .NET you get all of this from HashCode.Combine, which applies a proper mixing function; hand-rolled alternatives such as XOR-ing fields are a classic mistake, because XOR is commutative so swapping two field values yields an identical hash.