Use inline autocomplete when you already know what to write and only want to type it faster. Good examples include repeated test cases, simple mappings, boilerplate, and a loop whose pattern is clear from nearby code. You can accept only the useful part and keep working without changing focus.
Use chat when the problem needs discussion or extra context. It is better for explaining an error, comparing designs, understanding a library, or planning a change across several files. A useful rule is simple: choose autocomplete when the intent is already clear, and choose chat when you still need to reason about the intent. Chat also works well for safe exploration because its answer does not change project files unless you ask it to.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
Why does autocomplete get better after you write a clear function name or comment first?It predicts from the code around the cursor, so a name, signature or comment spells out the intent it has to complete.
Is there code you'd write by hand even when autocomplete offers the exact pattern?Name code where a small, plausible error is costly, like auth, crypto or money math, and say why a near-miss suggestion is easy to overlook there.
What you can say
I use autocomplete when I already know what I want to write and just want to type it faster, and chat when I still need to think the problem through.
Autocomplete fits repeated test cases, simple mappings, boilerplate, or a loop whose pattern is already clear from the code around it.
I can take only the useful part of a suggestion and keep going without leaving the editor or losing focus.
Chat fits work that needs discussion or more context, like explaining an error, comparing designs, learning a library, or planning a change across several files.
My rule of thumb is autocomplete when the intent is already clear, and chat when I still need to reason about what the intent should be.
Chat is also the safer place to explore, because its answer doesn't change project files unless I ask, so when I'm unsure I start there instead of accepting guesses.
Weak answers to avoid
Says one mode is always better"I just use chat for everything" skips the actual question. The interviewer wants a rule for picking, so tie each mode to whether the intent is already clear.
Describes the UI instead of the tasksExplaining where each panel lives doesn't answer when. Name concrete tasks, like boilerplate for autocomplete and explaining an error or planning a multi-file change for chat.
Tabs through suggestions on autopilotAccepting whole suggestions without reading them is a red flag. Say you keep only the useful part, since autocomplete writes straight into your file.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
