Why are GraphQL field names like getEmployee or payslipsFromHrisV2 discouraged?

## A field is a property, not a procedure The unit a GraphQL schema exposes is a field on a type, and a client reaches it by selecting it inside a selection set. Read that way, a field name is best understood as the name of the data it yields, not the name of the operation that yields it. `Employee.manager` names a person. `Employee.getManager` names a subroutine, and it is the only clue in the schema that whoever wrote it was thinking about the call they were wrapping rather than the graph they were exposing. The redundancy is the easiest half of the argument to make in an interview. A document already declares its operation type: `query` or `mutation`. Every field reachable from the query root is a read by construction, so the `get` prefix restates in each field name something the document already says once at the top. ## Names are the client's data shape The stronger half of the argument is that field names are not internal. The response object uses the response key for each selected field, and absent an alias that key is the field name itself. So a payroll graph with `Query.getEmployee` and `Employee.getManager` does not merely read awkwardly in the schema; it produces `data.getEmployee.getManager` in every response body, and that path is what application code destructures, what a normalized client cache stores under, and what a typed generator turns into a property name. The noise is copied into every consumer. Nesting compounds it. `employee { manager { department { costCentre } } }` reads as a path through data. `getEmployee { getManager { getDepartment { getCostCentre } } }` reads as four function calls and hides the fact that it is one traversal. ## A name that encodes the backing call ages badly `payslipsFromHrisV2` or `employeesFromLegacyLedger` is a different failure with the same root: the name describes the implementation rather than the data. Schemas outlive their backends. When the payroll system behind that field is replaced — and on a benefits and payroll graph it will be, because those systems are bought and migrated on a cycle of a few years — the field either keeps a name that is now a lie, or it has to be renamed. Renaming is the expensive path: shipped mobile builds, saved documents and generated client code all carry the old name, so the name outlives the system it was named after and the mistake is paid for continuously. The same reasoning rules out putting the return type in the name. `employeeList`, `payslipArray`, `planMap` all restate what the schema already declares in the field's type, in tooling that already shows it, and all three become wrong the day the field's shape changes. ## The read/write hazard There is a sharper version of the verb problem. A field named for an action tends to *be* an action. A payroll graph that exposes `Query.approveTimesheet` has put a write on the read root. GraphQL describes a query operation as a read-only fetch and a mutation as a write followed by a fetch, and only mutation fields at the top level of an operation are given serial execution — but nothing in the language enforces read-only-ness, and a server cannot detect that a resolver wrote something. What actually goes wrong is human and procedural: the reviewers, the write-path guards and the audit tooling that all watch mutation fields never look at query fields. In one such graph the approval was executed on the read path and the permission check that should have gated it ran too late, in a downstream consumer, long after the timesheets had been approved. The name is what routed the field away from everyone who would have caught it. ## What to name instead Name the field for what it returns, and put the criteria in arguments: `employee(id: ID!): Employee`, `payslips(payRunId: ID!): [Payslip!]!`, `benefitPlans(effectiveOn: Date!): [BenefitPlan!]!`. Use a plural noun for a list. Keep computed reads nouns too — `projectedNetPay(payRunId: ID!)` is a calculation, but what the client wants is the number, so the number is what the field is called. Verbs do have a home. A mutation is named for the business action it performs, and that convention — along with the input-argument and payload shapes that go with it — is the neighbouring concern, not this one. The rule that survives is narrower and easier to apply: on any field reachable from the query root, or on any object type, a verb in the name is a signal to stop and ask what is really being modelled. ## How to argue it in an interview Interviewers read naming as design taste, and the answer that lands is not "because the style guide says so". It is that field names are part of the contract, appear in every response body, outlive the systems behind them, and are expensive to change — so a name should describe the data, be stable under a backend swap, and not disguise a write as a read.