In PowerShell, what do the `@()` and `@{}` literals each create, and how do you add an item to each afterwards?

## Two literals, two different data structures PowerShell has one operator for making a list of values and another for making a lookup table, and they look confusingly similar — parentheses versus braces after the `@` sigil. `@( ... )` is the **array subexpression operator**. It evaluates whatever is inside and guarantees the result is an array: ```powershell $servers = @('web01', 'web02', 'web03') $servers[0] # web01 - zero-based index $servers[-1] # web03 - negative index counts from the end $servers.Count # 3 $empty = @() # an empty array ``` You do not strictly need `@()` to make an array — `$a = 1, 2, 3` works too, because the comma is the array operator. The value of `@()` is that it *forces* an array even when the expression produces zero or one object. `@(Get-ChildItem -Filter 'nothing*')` is an empty array rather than `$null`, and a single result becomes a one-element array rather than a bare object. That is the standard defence against "my `.Count` blew up because the result was a scalar". `@{ ... }` is the **hashtable literal**. Entries are `Key = Value`, separated by semicolons on one line or by newlines across several: ```powershell $config = @{ Name = 'db01' Port = 5432 } $config['Port'] # 5432 $config.Port # 5432 - property-style access works too $config.Keys # Name, Port (order not guaranteed) ``` The result is a `System.Collections.Hashtable`. Keys are unique and lookup is by key, not by position — there is no `$config[0]` unless you literally used `0` as a key. ## Adding to each This is where the two diverge, and it is the part interviewers actually probe. A hashtable is mutable in place. `$config['Ssl'] = $true` adds the key if it is absent and overwrites the value if it is present. `$config.Remove('Port')` deletes one. `$config.Add('Ssl', $true)` also works but throws if the key already exists, which is why index assignment is the common idiom. An array is **fixed size**. PowerShell arrays are ordinary .NET arrays, and .NET arrays cannot grow. So `$servers += 'web04'` is not an append: PowerShell creates a brand-new array one element longer, copies every existing element into it, adds the new one, and points `$servers` at the result. For a handful of items that is invisible. In a loop over tens of thousands of items it becomes a real performance problem, and the fix is a growable collection such as `[System.Collections.Generic.List[string]]::new()` with `.Add()`. ## Ordered hashtables Hashtables make no promise about key order — the order you see when you print one is an implementation detail, not the order you typed. When order matters (building an object whose properties should appear in a fixed sequence, or emitting configuration a human will read), cast the literal: ```powershell $ordered = [ordered]@{ Name = 'db01'; Port = 5432 } ``` That produces a `System.Collections.Specialized.OrderedDictionary`, which keeps insertion order and additionally supports index access by position. ## Where hashtables show up beyond storage A hashtable is not just a container in PowerShell; it is a language mechanism. Two common uses worth knowing: - **Building objects.** `[pscustomobject]@{ Name = 'db01'; Port = 5432 }` turns a hashtable into a real object with `Name` and `Port` properties — the standard way to emit structured output from your own code. Cast from `[ordered]` if you care about property order. - **Splatting.** If a hashtable's keys match a command's parameter names, `Get-Thing @params` passes them all as named arguments. The sigil changes from `$` to `@` at the call site. This is how long parameter lists stay readable, and it is why hashtables turn up in scripts that never needed a lookup table. ## The common confusions Writing `@{ 'a', 'b' }` is a syntax error, not an array — braces mean key/value pairs. Writing `@('a' = 1)` is equally wrong. And `$hash.Count` counts keys while `$array.Count` counts elements, so a `Count` of 2 tells you nothing about which structure you are holding; check with `$x.GetType().Name` when in doubt.