Talking While You Code in an Interview: Fourteen Sentences for Checking the Question, Explaining an Approach, Stating Complexity, and Testing Your Own Code

🌏 中文版

My three earlier interview posts (general patterns, my own stories, and what the teaching materials cover) all dealt with behavioral interviews: introducing myself, describing projects, asking questions. A large part of an engineering interview is writing code on the spot, and I had not practiced a single sentence for that part.

The Google mock-interview quotations use automatic captions, which may misrecognise individual words. Treat them as expression examples rather than an audio-checked verbatim record. This lesson does not teach how to pronounce O notation or compare British and American speech. Continue with thinking time and system design interviews for other situations.

What I was trying to say

A coding interview is not about solving the problem in silence. Meta's official preparation guide puts this first in its list:

Think out loud. We pay a lot of attention to the way you solve problems, which can be as important as having the right answer.

So what I need to practice is what to say at four points:

1. After hearing the question, to check that I understood it
2. Before I start, to explain how I plan to solve it and why
3. While writing, to say what I am doing
4. After writing, to test it myself

I can say all of this in Chinese. In English I am left with um and long silences.

I read the body text of four kinds of sources this time:

• An employer's official demonstration: Google's Example Coding/Engineering Interview video, in which two Google engineers act out an interview. I read the automatic captions, up to about the point where the code is written and the candidate starts checking it
• An employer's official guide: the Meta Careers page on preparing for the software engineering interview
• University careers guidance: Northeastern University's Interview Type: Technical, which gives sentences you can say as written
• A community resource for software interviews: the Tech Interview Handbook's Coding interview cheatsheet

There are no language teaching materials this time. The interview units from the BBC and the British Council teach self-introductions and behavioral questions, and have nothing on coding interviews.

What you can say in this situation

1. After hearing the question, check it

The first two come from Google's example interview. After hearing the question, the candidate says I guess what I'm trying to figure out is, you're looking for a pair of numbers that add up to eight, and I replaced the opening with So. The candidate then asks can I assume that they're like in memory, an array or something, and the interviewer uses the same word in the answer: you can assume they'll always be integers. Cambridge defines assume as accepting something to be true without proof, with the example Let's assume that they're coming.

Is the input array sorted? is quoted from the Tech Interview Handbook, which states its purpose plainly: deciding between binary search and linear search. The handbook also asks for at least two or three questions:

Do not jump into coding right away. Coding questions tend to be vague and underspecified on purpose to allow the interviewer to gauge the candidate's attention to detail and carefulness. Ask at least 2-3 clarifying questions.

The sentences about negative numbers and about speed or memory are quoted from the Northeastern University page. The same passage also has Is it always valid input? and Is this meant to scale to millions of users?.

2. Before you start, explain the approach and the trade-off

The candidate in Google's example interview does not jump straight to the best solution. The candidate first says the simplest solution of course is just comparing every single possible pair, judges it right away with that's obviously not very efficient, and then says I think that that would be quadratic. My cards drop of course and the repeated that.

There is a habit here I did not know about: the candidate almost never reads out O notation when talking about complexity. Throughout that passage the words are quadratic, linear, an n log n solution, and a constant time lookup.

The sentence comparing two approaches is quoted from Northeastern University, where it continues with I think hash table is simpler here because…. The same page gives a pattern for describing steps, I'd approach this by first [step 1], then [step 2]. I'd do this because…; sorting and two pointers are content I filled in myself.

For choosing a language, the interviewer in the example interview asks what coding language would you prefer to do this in, and the candidate answers I prefer C++ if that's okay. I changed it to Python.

3. While writing

The first sentence is the answer to the interviewer's follow-up about why this is faster than binary search. The words in the captions are in this case I just need to do that moving, scanning the one time, so it's linear solution, a sentence formed while thinking, and I tidied it into one complete sentence.

The second sentence is quoted from Northeastern University, from the passage about not bluffing, where it continues with Let me think through the logic…. This actually happens in the example interview: the candidate forgets which method adds an element to a C++ unordered set, says I don't remember, I think it's add for an unordered set… it's either add or insert or something, and keeps writing.

4. After writing, test it yourself

After writing the code, the candidate in the example interview says I feel like I probably need to go through an example… to make sure that this is correct, and then let me go through some examples to make sure. I merged the two into one sentence. Later the candidate also checks the empty input unprompted: what happens with an empty….

The Tech Interview Handbook states this step as a rule:

Once you are done coding, do not announce that you are done. Interviewers expect you to start scanning for mistakes and adding test cases to improve on your code.

Meta's guide asks for the same thing: Find and fix the bugs by yourself. Don't wait for the interviewer to find them for you.

Can I also say it this way?

Say it again with different content

Read the Chinese, say it yourself, and then look at the reference version.

1. 所以你要找的是清單裡最長的單字？
   • So you're looking for the longest word in the list?
2. 我可以假設它們已經排序了嗎？
   • Can I assume that they're sorted?
3. 輸入會有重複的值嗎？
   • Does the input include duplicates?
4. 最簡單的解法就是把每一個可能的子字串都檢查一遍。
   • The simplest solution is just checking every single possible substring.
5. 我會先數每個字母出現幾次，再比較次數。
   • I'd approach this by first counting each letter, then comparing the counts.
6. 我需要先排序，所以是 n log n 的解法。
   • I need to sort it first, so it's an n log n solution.
7. 如果輸入只有一個元素，會發生什麼事？
   • If the input has only one element, what happens?

All seven are source sentences with the content changed by me; none is quoted from a source.

A short dialogue

This is a practice example I wrote myself. It is not a real interview and not the conversation in the source video.

A: I'll give you a list of numbers and a target. Tell me if any two of the numbers add up to the target.

B: So you're looking for a pair of numbers that add up to the target?

A: That's right.

B: Is the input array sorted? And does the input include negative numbers?

A: It's not sorted, and yes, there can be negative numbers.

B: The simplest solution is just comparing every single possible pair. I think that would be quadratic.

A: Can we do better?

B: I could do this with a hash table for fast lookups, or sort the data and use binary search.

A: Let's go with the hash table.

B: Let me go through some examples to make sure this is correct.

The last line is said after the code is written. Can we do better? is the sentence the Tech Interview Handbook mentions interviewers often use to ask for a better solution.

Without looking at the English, how would you say it?

The standard for rating yourself is whether you can get the meaning across, not whether the words match exactly.

Overall

Of the fourteen sentences, six are quoted from the sources and eight are source sentences that I tidied or filled with different content. The five for checking the question are the ones to practice first, because every question needs them, and because they are questions: once you say one, the other person replies, and you do not have to carry the whole stretch alone.

The biggest difference from the earlier posts is that the sources include one complete example interview. It showed me something the written materials do not say: the engineer in the demonstration does not speak fluently. The candidate often restarts a sentence halfway through and admits on the spot to having forgotten the syntax, yet says what they are thinking at every step. What needs practice is saying the thinking out loud, not making each sentence polished.

As for evidence, there are no language teaching materials this time, no testing with native speakers, and no frequency comparison. Whether these sentences work rests on one official example interview, one university guide, and one community handbook.

Updates

• 2026-10-25: Joined the unified speaking series; moved research to-dos into working notes and retained the lesson’s source and use limitations.

References

• Life at Google: How to: Work at Google — Example Coding/Engineering Interview: the actual dialogue of an example interview; checking the question, the simplest solution, how complexity is stated, testing your own code
• Meta Careers: Preparing for your software engineering interview at Meta: the expectations to think out loud, find your own bugs, and ask questions when stuck
• Northeastern University: Interview Type: Technical: sentences for checking the input, comparing two approaches, describing steps, forgetting syntax, and checking empty input
• Tech Interview Handbook: Coding interview cheatsheet: questions for checking the problem, and the rule to check your own code before saying you are done
• Cambridge Dictionary: assume: the definition of assume and its example