In GraphQL SDL, how do `[Skill!]!`, `[Skill]!`, `[Skill!]` and `[Skill]` differ?

## Two wrapping types, and why order matters GraphQL defines exactly two wrapping types: **List**, written by surrounding a type in square brackets, and **Non-Null**, written by appending `!`. Everything else in a type reference is a named type — an object, interface, union, enum, input object or scalar. Because wrappers nest, a written type like `[Skill!]!` is not one exotic type but a stack of three: Non-Null wrapping List wrapping Non-Null wrapping the named type `Skill`. That stack is exactly how it travels over introspection, where each wrapper is a type with a null `name` and an `ofType` pointing one layer inward. It is also why the only reliable way to read a list type is **one position at a time, from the inside out**. Read `[Skill!]!` as: a `Skill`; that is never null; a list of those; that list is never null. ## The four combinations, precisely Take a job-board graph. A `JobPosting` type carries, among its 37 fields, these four: - **`requiredSkills: [Skill!]!`** — the field always appears, always as a list, and every element is a `Skill`. A caller can iterate without a null check on the list and without a null check per element. - **`screeningAnswers: [String]!`** — the field always appears as a list, but any entry inside may be null. The classic honest use is a positional list: answer three of five screening questions and the two you skipped are null at their positions. A caller must null-check each element. - **`niceToHaveSkills: [Skill!]`** — the field may be null altogether, but a list that does arrive contains no nulls. A caller checks once, at the top, then iterates freely. - **`previousTitles: [String]`** — both the list and the entries may be null. This is the fully permissive shape and it forces callers into two levels of checking. Notice that the inner and outer promises are genuinely independent: knowing one tells you nothing about the other. That independence is the whole point of the question, and it is why interviewers ask it by showing you a type rather than asking for a definition. ## Empty is not null The single most common error is reading `!` as "non-empty". It is not. `[]` — an empty list — satisfies **all four** of the types above, including `[Skill!]!`. Non-Null removes null from a set of values and does nothing else. A job posting with no required skills yet is perfectly representable as `"requiredSkills": []` under the strictest of the four types. This also means the four types give you no way to distinguish "no skills" from "we could not load the skills" if you chose the strict shape — and, conversely, that `[Skill!]` deliberately makes a null list available as a distinct signal from `[]`. Whether that distinction is worth having in a given schema is a design judgement of its own; reading the four types correctly comes first, and it is what the interview is testing. ## Deeper nesting Nothing stops the stack from being deeper. `[[Float!]!]!` — a matrix of scores, say — reads inside out as: a `Float`, never null; a list of those, never null; a list of *those*, never null. So neither the outer list, nor any row, nor any cell may be null. Change it to `[[Float!]]!` and rows may be null while cells may not; change it to `[[Float]!]!` and cells may be null while rows may not. Each bracket pair and each `!` is one independent decision, and the reading rule never changes. ## Why this shows up as a real defect The four variants translate straight into the shapes a typed client generator emits. A field declared `[String]` becomes something like an optional array of optional strings, and the calling code has to unwrap twice; a field declared `[String!]!` becomes a plain array of strings. Teams that reach for the permissive shape by reflex hand every consumer a pile of checks that will never fire, and the checks rot into casts. The mirror-image defect is worse. A field declared `[Skill!]!` whose backing store hands back a list containing a null cannot be serialized as written — the null is not permitted at that element position, so the server raises a field error instead, and because neither the element nor the list tolerates null the consequence reaches beyond the one bad entry. When a whole list field disappears from a response over a single bad row, this type is usually why. ## The habit to demonstrate In an interview, do not recite the four as a memorised table. Show the reading rule and derive them. Point at the bracket, say what the inner mark governs, point outside the bracket, say what the outer mark governs, then read the given type aloud in that order. That is the skill the question is actually probing: whether you read GraphQL types structurally or by pattern-matching on shapes you have seen before.