In a service you joined last week, where should you check an inline completer's suggestions hardest?

seniorshould knowfreq 42%

answer

It follows what recurs
Your unusual code is the exposed part
The common shape reads right anywhere
Being new means the same wrong prior
Find one existing call site first

basics

~20 s

Wherever this service departs from the widespread way of doing something. A continuation follows shapes that recur, so on your unusual code the recurring shape is the wrong one - and it reads as entirely reasonable to anyone new here.

solid answer

~50 s

Completion is strongest where your code resembles code that recurs widely, because that is the shape a continuation is drawn toward. The corollary is the dangerous half: where a service deliberately departs from the common way - a custom paging scheme, a house error convention, a wrapper that exists precisely to stop people calling the ordinary thing - the suggestion leans toward the common version, which is wrong here and looks perfectly sensible. If you joined last week, your own instinct leans the same way, so the check you would naturally apply, does this look like reasonable code, passes. What works is not more suspicion in general but one habit: before accepting anything that sets a pattern, open one existing place in this service that does the same job and compare. In a codebase you do not know yet, the existing code is the specification.

Completion is strongest where your code resembles code that recurs widely, because that is the shape a continuation is drawn toward. The corollary is the dangerous half: where a service deliberately departs from the common way - a custom paging scheme, a house error convention, a wrapper that exists precisely to stop people calling the ordinary thing - the suggestion leans toward the common version, which is wrong here and looks perfectly sensible. If you joined last week, your own instinct leans the same way, so the check you would naturally apply, *does this look like reasonable code*, passes. What works is not more suspicion in general but one habit: before accepting anything that sets a pattern, open one existing place in this service that does the same job and compare. In a codebase you do not know yet, the existing code is the specification.

code

pseudocode · 16 lines

pseudocode

# this file, at your cursor - a service you joined last week
function listOrdersPage(customerId, pageToken):
    |<- cursor

# suggested - the pagination shape that recurs nearly everywhere:
    offset = (pageToken - 1) * DEFAULT_PAGE_SIZE
    page   = orders.findPage(customerId, offset, DEFAULT_PAGE_SIZE)
    return { items: page.rows, page: pageToken }

# what this service does, in every other handler:
#   pageToken is an opaque cursor handed back by the previous call, not a page number
#   orders.findPage(customerId, cursor, limit) -> (rows, nextCursor)
#   and the caller needs nextCursor back, or it can never ask for the next page

# nothing above is misspelled and every name exists.
# the mistake is what pageToken means here.

go deeper

for a junior

Know that a suggestion reading like reasonable code is not evidence it matches this service. When you are new, compare it against one place in the codebase that already does the same job.

for a middle

Explain the mechanism: continuations follow shapes that recur, so where a service departs from the common way, the common way is what arrives. Name the kinds of code where that bites.

for a senior

Show that you locate a codebase's unusual parts quickly - wrappers around ordinary operations, common words with local meanings, boundaries with other teams - and that you raise your checking there rather than uniformly.

for a principal

Own the inversion: where a completer is reliably wrong is a map of where your service departs from what everyone else does. Some of those departures are worth their cost and some are accidents nobody has revisited.

Why a completer is strong on ordinary code

A continuation follows shapes that recur. Where the code you are writing looks like code that appears in a great many codebases - a loop over a collection, a guard on a null, the ordinary way of building a request - the pull is toward an answer that is also the right one for you. That is why completion feels close to telepathic on routine code, and it is a real benefit rather than an illusion.

A convention that recurs only inside your own repository has no such pull behind it. It can still be produced perfectly well - if it is in view, the material around your cursor establishes it and the suggestion follows it. The exposure appears exactly where your local convention is not established by anything in the request, and something widespread occupies the same slot.

The failure that reads like a success

where you are	what the suggestion leans toward	how it reads to someone new	what actually catches it
ordinary code	the common shape, which is also yours	right	nothing needed
code that deliberately departs from the common way	the common shape, which is not yours	right	comparison with an existing call site
a common word that means something specific here	the widespread meaning	right	knowing this service

Every row in the middle column reads well. That is the point: this class of mistake does not arrive looking like a mistake. It arrives looking like competent, idiomatic code, because it is competent idiomatic code - for somewhere else.

Why this is worst in your first weeks

Your own prior and the suggestion's pull point in the same direction. You are new, so "does this look like reasonable code?" is close to the only check you can run quickly, and it is precisely the check that cannot separate the ordinary way from our way. Two independent judgements agreeing feels like corroboration, and here it is the same judgement made twice.

This is why the answer is not "be more careful". Carefulness with the wrong reference point produces the same result more slowly.

Where a service's unusual parts are

Wrappers around an ordinary operation. Someone wrote them to stop people doing the ordinary thing, which means the ordinary thing is exactly what a suggestion will reach for.
Common words with a local meaning - a token, an id, a page, a status. The word is everywhere; what it denotes here is not.
Boundaries with another team's code, where the contract is theirs and nothing near your cursor states it.
Anything a reviewer has corrected twice. Repeat corrections mark house conventions more reliably than documents do.

The habit: find the second example

Before accepting a suggestion that establishes a pattern - the first paging helper, the first error path, the first call into a shared component - open one existing place in this service that does the same job and read it. This is cheap, it is specific, and it works precisely because it swaps your general prior for this codebase's actual one.

Do it for the first of a kind, not for every line; after that the file around you establishes the pattern and the suggestions follow it.
Prefer a call site over a document: the document may be out of date and the code is not.
If no existing example exists, you are writing the first one, and it deserves the attention of a decision rather than the attention of a keystroke.

The inversion: its mistakes map your service

There is a use for all of this beyond defence. Where a completer is reliably wrong is a fairly good map of where this service departs from what everyone else does. That map is worth having in your first month, both because it is what you have to learn anyway and because some of those departures turn out to be load-bearing while others are accidents nobody has revisited.

So the answer to "should I turn completion off in a codebase I do not know" is no. The suggestions are one of the fastest ways to see what the ordinary shape of this kind of code is, and the places they are wrong are the places worth asking a colleague about.

Answering this in an interview

Give the mechanism first - continuations follow what recurs, so your deliberate departures are the exposed surface - then the reason it is worse for a newcomer, then the habit, in that order. If you can name a real example where a suggestion was idiomatic, plausible and wrong for your codebase, that single story does more than any general statement about trusting tools.

## Why a completer is strong on ordinary code A continuation follows shapes that recur. Where the code you are writing looks like code that appears in a great many codebases - a loop over a collection, a guard on a null, the ordinary way of building a request - the pull is toward an answer that is also the right one for you. That is why completion feels close to telepathic on routine code, and it is a real benefit rather than an illusion. A convention that recurs only inside your own repository has no such pull behind it. It can still be produced perfectly well - **if it is in view**, the material around your cursor establishes it and the suggestion follows it. The exposure appears exactly where your local convention is *not* established by anything in the request, and something widespread occupies the same slot. ## The failure that reads like a success | where you are | what the suggestion leans toward | how it reads to someone new | what actually catches it | |---|---|---|---| | ordinary code | the common shape, which is also yours | right | nothing needed | | code that deliberately departs from the common way | the common shape, which is not yours | right | comparison with an existing call site | | a common word that means something specific here | the widespread meaning | right | knowing this service | Every row in the middle column reads well. That is the point: this class of mistake does not arrive looking like a mistake. It arrives looking like competent, idiomatic code, because it *is* competent idiomatic code - for somewhere else. ## Why this is worst in your first weeks Your own prior and the suggestion's pull point in the same direction. You are new, so "does this look like reasonable code?" is close to the only check you can run quickly, and it is precisely the check that cannot separate *the ordinary way* from *our way*. Two independent judgements agreeing feels like corroboration, and here it is the same judgement made twice. This is why the answer is not "be more careful". Carefulness with the wrong reference point produces the same result more slowly. ## Where a service's unusual parts are 1. **Wrappers around an ordinary operation.** Someone wrote them to stop people doing the ordinary thing, which means the ordinary thing is exactly what a suggestion will reach for. 2. **Common words with a local meaning** - a token, an id, a page, a status. The word is everywhere; what it denotes here is not. 3. **Boundaries with another team's code**, where the contract is theirs and nothing near your cursor states it. 4. **Anything a reviewer has corrected twice.** Repeat corrections mark house conventions more reliably than documents do. ## The habit: find the second example Before accepting a suggestion that establishes a pattern - the first paging helper, the first error path, the first call into a shared component - open one existing place in this service that does the same job and read it. This is cheap, it is specific, and it works precisely because it swaps your general prior for this codebase's actual one. - Do it for the *first* of a kind, not for every line; after that the file around you establishes the pattern and the suggestions follow it. - Prefer a call site over a document: the document may be out of date and the code is not. - If no existing example exists, you are writing the first one, and it deserves the attention of a decision rather than the attention of a keystroke. ## The inversion: its mistakes map your service There is a use for all of this beyond defence. Where a completer is reliably wrong is a fairly good map of **where this service departs from what everyone else does**. That map is worth having in your first month, both because it is what you have to learn anyway and because some of those departures turn out to be load-bearing while others are accidents nobody has revisited. So the answer to "should I turn completion off in a codebase I do not know" is no. The suggestions are one of the fastest ways to see what the ordinary shape of this kind of code is, and the places they are wrong are the places worth asking a colleague about. ## Answering this in an interview Give the mechanism first - continuations follow what recurs, so your deliberate departures are the exposed surface - then the reason it is worse for a newcomer, then the habit, in that order. If you can name a real example where a suggestion was idiomatic, plausible and wrong for your codebase, that single story does more than any general statement about trusting tools.

How do you find a service's unusual parts in your first week?
Look for wrappers around ordinary operations - someone usually wrote them to stop people doing the ordinary thing - and for common words with a local meaning. The corrections you collect in review are the same map, arriving more slowly and more expensively.
Should you turn completion off in a codebase you do not know?
No. The suggestions are one of the fastest ways to see the ordinary shape of this kind of code, and where they are wrong is where this service is unusual, which is what you have to learn anyway. The discipline is comparing against an existing call site before accepting, not switching it off.

saying these in an interview costs you the question

Assumes a suggestion that reads well matches this service's conventions
Believes the tool infers house conventions it was never shown
Treats an unfamiliar codebase as a reason to lean on the tool more
Checks suggestions for names and syntax, never for local meaning
Thinks a convention is honoured because it is written down somewhere

In a service you joined last week, where should you check an inline completer's suggestions hardest?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why a completer is strong on ordinary code

The failure that reads like a success

Why this is worst in your first weeks

Where a service's unusual parts are

The habit: find the second example

The inversion: its mistakes map your service

Answering this in an interview

▾common follow-ups2 questions

▾red flags5 flags

Why a completer is strong on ordinary code

The failure that reads like a success

Why this is worst in your first weeks

Where a service's unusual parts are

The habit: find the second example

The inversion: its mistakes map your service

Answering this in an interview

answer

go deeper