WTF does being a good communicator in a coding interview mean?
Tips that landed me offers from 10+ tech companies
“Show off your communication skills in your coding interview.”
“Technical skills get you the interview, communication skills get you the job.
“You need to be a good communicator to get a job offer.”
This “good communication” advice gets thrown around a lot. But if you’re anything like 26-year-old Dawn, you’re wondering… how in the world do I show off good communication skills in a coding interview?
It took me a while to figure this out, but when I did, I landed offers from 10+ different tech companies. So let me break down what being a good communicator means in a coding interview and how to show that off in your interviews.
The biggest misconception around coding interviews is that you’re only evaluated on your code. This is colossally untrue. In every coding interview, you’re also evaluated on your problem-solving skills, business sense and communication abilities.
There are 3 main ways to show off strong communication skills
Stating your assumptions about the question, data or business
Explaining your trade-off decisions
Evaluating your code and approach, including edge cases and testing
Let me go deeper into each of these (plus example statements that you an use directly).
Tactic 1: State your assumptions
When given a coding question, we are often making a bunch of assumptions in our head. The assumptions help us simplify the question, so that we can solve it. But the important thing to note is that our assumptions may not be right*,* and articulating them can not only help us stay on track in the interview — but also show off strong communication skills. **
Here are some example statements that you can use:
“I am assuming that the way the business makes money is by taking a commission on every transaction is that correct?”
“I believe that the numerator and the denominator of this metric are <insert numerator and denominator>. Would you agree with this?”
“It looks like the primary key in the transactions table is transaction_id and the foreign keys are user_id and product_id — is my understanding correct.”
But how do you know what assumption you’re making? This is the tricky part. The way I do this is to listen for ambiguity — anytime something in the question could be interpreted in more than one way, that’s where an assumption lives.
Tactic 2: Explain your trade-off decisions
There is never just ONE way to solve any coding problem. In a coding interview, I would recommend getting to just one solution fast, and locking it in — get the “credit” for a right answer first. But once you have that one solution right, you should discuss trade-offs and explain why your solution is preferred (or suggest an alternative better solution).
You might consider trade-off decisions like:
Speed — how important is execution time vs. development time?
Scalability — will this solution still work efficiently as the data size or user base grows? Is this an important consideration?
Readability — can another Data Scientist or Engineer easily understand or maintain this code later on?
Accuracy vs. simplicity — are we sacrificing precision for speed, or over-engineering for a rare edge case? What is the right choice for this specific use case.
Some example statements that you can use:
“I chose this approach because it’s easier to implement and explain, even though it’s not the most efficient in terms of runtime.”
“This approach works well for smaller datasets, but if we were scaling to millions of rows, I’d consider a more optimized algorithm.”
“Between readability and speed, I decided to prioritize readability — it’s more maintainable given that I expect other team members will be looking at this pipeline too.”
Tactic 3: Evaluate your code and approach
Once you’ve walked through your solution, don’t stop there. A strong communicator doesn’t just move on to the next thing — ****they step back and evaluate it. This means identifying possible edge cases, testing scenarios, and acknowledging what could go wrong or be improved.
By the way, if you manage to poke holes in your code — it doesn’t make you look like a noob, it makes you look like a pro.
For me, I like to think about how the code might break.
What happens if the input is empty or null?
How would this handle unexpected data types or outliers?
What would break if the data doubled in size?
Feel free to use some of these example cases directly!
“Let me think about some edge cases — what if the table has duplicate user IDs?”
“I’d also want to test this with missing values to make sure the join logic still holds.”
“If I had more time, I’d refactor this part into a helper function so it’s easier to test and reuse.”
I promise you working on your communication skills is one of the highest ROI things you can do. This is what will land you offers. And remember strong communication skills doesn’t mean talking MORE. This is a classic case of quality over quantity. Say only what is important!
One last thing — I am hosting a FREE SQL challenge in December! It’s the SQL Advent Calendar 2025 🎄 Sign up here: www.interviewmaster.ai/advent
Key details:
24-days of SQL coding challenges (ranging from Beginner to Advanced)
AI coach & hints to help you get to the right answer
Questions released at 9am ET every day, but you have until December 31st to complete the challenge
Totally free to participate!