How to Explain Your Code in a Technical Interview in English

A technical interview in a language that isn't your first is a unique challenge. It’s not just about solving a problem; it’s about demonstrating your problem-solving process out loud, in real time. Interviewers want to understand how you think, and that requires clear, confident communication.

This guide provides a structured approach and specific English phrases to help you narrate your coding process. We'll cover everything from clarifying the initial problem to walking through your final solution, helping you show your technical skills and your communication skills at the same time.

Before You Start Coding: Clarify the Problem

One of the most common mistakes candidates make is diving into code too quickly. Before you write a single line, you must be absolutely sure you understand the problem, its inputs, its outputs, and its constraints. This shows the interviewer that you are thoughtful and methodical.

Start by rephrasing the problem in your own words to confirm your understanding.

Phrases for Clarifying Requirements

• "So, just to make sure I understand correctly, the goal is to write a function that takes [input] and returns [output]?"
• "To clarify, are we expecting the input array to contain only numbers, or can it have other data types?"
• "Could you give me an example of a valid input and the expected output?"
• "When you say 'most frequent,' if there's a tie, which value should be returned?"

Phrases for Discussing Constraints and Edge Cases

• "What are the constraints on the size of the input? For example, how large can the array be?"
• "How should the function handle invalid inputs, like a null or an empty list? Should it return an error, or a specific value?"
• "Are there any performance requirements I should be aware of, like time or space complexity?"
• "I'm thinking about edge cases. For instance, what if the input list contains duplicates? Or what if all elements are the same?"

Taking a few moments to do this not only prevents you from solving the wrong problem but also gives you valuable time to think while engaging the interviewer.

The "Think-Aloud" Method: Narrating Your Thought Process

Interviewers use coding challenges to evaluate your thinking. A perfect solution delivered in silence is less valuable than a good solution that was clearly explained. You need to narrate your journey from the problem to the solution.

Stage 1: The Initial Approach

Start by describing your first, simplest idea. This is often the "brute-force" solution. It shows that you can find a working solution before you try to optimize it.

• "My first thought is to approach this with a nested loop. I can iterate through each element and then compare it with every other element."
• "A straightforward way to solve this would be to sort the array first. That would simplify finding the duplicates."
• "Initially, I'm thinking of a brute-force approach. It might not be the most efficient, but it would work. From there, we can look for optimizations."

Stage 2: Analyzing and Refining

After stating your initial idea, analyze its trade-offs, especially its time and space complexity. This demonstrates a deeper understanding of algorithms and data structures.

• "The time complexity of this nested loop approach would be O(n²), which might be too slow if the input is very large."
• "This solution has a space complexity of O(n) because I'm creating a new data structure to store the results."
• "We could optimize this. If we use a hash map, we can reduce the time complexity to O(n) by trading off some space."
• "I think we can do better. Let me consider an alternative approach using a two-pointer technique."

Stage 3: Structuring Your Code

Before you start typing furiously, outline your plan. Explain the functions, variables, and logic you intend to use. This acts as a roadmap for both you and the interviewer.

• "Okay, my plan is to first initialize an empty dictionary to store character counts."
• "I'll write a main function that takes the array as an argument. Inside it, I'll have a loop to iterate through the elements."
• "I think I'll need a helper function to handle the logic for reversing this part of the string. It will make the main function cleaner."
• "I'll start by handling the edge cases we discussed, like an empty input array."

While You're Coding: Keep the Conversation Going

As you write your code, continue to explain what you're doing and why. Don't just read your code aloud. Explain the purpose of each logical block.

• "Now, I'm creating a for loop that will go from the beginning of the array to the end."
• "This variable, max_so_far, will keep track of the largest value we've seen."
• "Inside the loop, this if statement checks if we've encountered this element before. If we have, I'll increment its count in the map."
• "I'm using a while loop here because the number of iterations isn't fixed; it depends on the values of these two pointers."

What if you get stuck? Silence is your enemy. It's perfectly normal to need a moment to think. Just communicate it.

• "Let me take a moment to think about the best way to structure this next part."
• "I'm just double-checking my logic for this condition. One second."
• "Hmm, I think there might be a small issue here. Let me trace the execution with an example input to find it."

If you're focused on the logic and the right English words aren't coming, it can be stressful. An assistant that can suggest professional phrasing can be helpful. For example, Subtl's AI prompter can draft phrases like "Let me think through the logic for this edge case" in real time, helping you maintain a smooth conversation without breaking your concentration.

Handling Hints and Feedback

If your interviewer offers a hint, it is not a sign of failure. It's an invitation to collaborate. How you receive and incorporate feedback is a critical skill they are testing. Listen carefully, acknowledge the hint, and explain how you'll use it.

Phrases for Acknowledging a Hint

• "That's a great point. Using a set here would indeed make the lookup much faster. I'll change my approach."
• "Thank you, that clarifies it. I see now that I was overcomplicating the base case for the recursion."
• "Ah, I didn't consider that edge case. You're right. I need to add a check for that before the loop starts."

If you are truly stuck, it is better to ask for a nudge than to remain silent. It shows self-awareness and a willingness to ask for help.

• "I'm a bit stuck on optimizing the space complexity here. Could I perhaps get a small hint?"
• "I'm considering two data structures for this part, a dictionary or a simple list. I'm leaning towards the dictionary for performance, but I'm not sure. Do you have any thoughts on that?"

After You've Coded: Testing and Explaining

When you finish writing your solution, don't just say, "I'm done." The interview isn't over. You need to verify your code and discuss its performance.

1. Test with an example: Manually walk through your code with a sample input. This catches bugs and proves you understand what you wrote.

   • "Let's test this with the example input [3, 1, 4, 1, 5]."
   • "First, the map is empty. In the first iteration, we add 3 with a count of 1. In the second, we add 1 with a count of 1. In the fourth iteration, we see 1 again, so we increment its count to 2."

2. Discuss complexity again: Reiterate the time and space complexity of your final solution.

   • "The final time complexity is O(n) because we iterate through the list once. The space complexity is O(k), where k is the number of unique elements, because of the hash map."

3. Talk about improvements: Briefly mention how the code could be improved if you had more time.

   • "If this were production code, I would add more robust error handling for different input types."
   • "Another possible optimization, if memory were a major concern, might be to modify the input array in-place, although that has its own trade-offs."

Common Mistakes to Avoid

• Working in silence. This is the biggest mistake. The interviewer cannot read your mind. Over-communicate your thought process.
• Jumping straight to code. Always clarify the problem and discuss your approach first.
• Ignoring or arguing with hints. View the interviewer as a collaborator. Incorporate their feedback gracefully.
• Giving up when you get stuck. It’s okay to pause, but communicate that you are thinking. Try to debug your own code out loud.
• Forgetting edge cases. Always consider empty inputs, nulls, duplicates, and other non-standard scenarios.

A Note on Consent and Tools

If you plan to use any tool for live transcription or assistance during a call, you must be transparent. In many jurisdictions, all parties must consent to being transcribed or recorded. Always inform the interviewer at the beginning of the call if you are using such a tool. For more details, you can review general guidance on call recording laws. See our guide at /law/.

Explaining your code out loud in English is a skill that you can build with practice. By structuring your communication, using clear phrases, and treating the interview as a collaborative session, you can effectively demonstrate your technical abilities, even if English is not your native language.

To prepare for high-stakes interviews, practicing with a tool that provides real-time feedback and translation can build confidence. Subtl for Mac gives you a live transcript of your conversation, so you can review what was said, and helps you formulate clear, professional responses. Learn more about using it for /use-cases/interviews/.