I Said 'Char' Like 'Car' in a Job Interview — And Got Corrected on the Spot
Last October, I interviewed for a backend position at a company in San Francisco. The role was remote-friendly, which was perfect since I'm based in Shanghai. The first two rounds — a take-home project and a system design discussion over Zoom — went well. I felt confident going into the final round.
Then came a question about character encoding.
The interviewer asked me to explain how I'd handle multi-byte characters in a streaming parser. I dove into the technical details eagerly. I talked about buffer boundaries, UTF-8 sequences, and partial char reads. Except every time I said "char," I pronounced it like the English word "car" — /kɑːr/.
After maybe the fourth time, the interviewer gently interrupted: "Just so you know, most people say /tʃɑːr/, like the beginning of 'charcoal.'"
I froze for a second. Not because I was embarrassed — well, maybe a little — but because I realized I'd been saying it wrong in every team meeting, every code review discussion, and every technical conversation for roughly six years.
The word I never thought to look up
Here's the thing about char: I knew exactly what it meant. I could write charset detection code in my sleep. I understood the difference between char, wchar_t, and rune across five programming languages. The pronunciation just never came up as something I needed to verify.
In Chinese, we often refer to types by their written form. When my colleagues and I discussed code, we'd either say the Chinese term or just read the English letters. Nobody corrected each other because we were all pronouncing it the same way — incorrectly.
After the interview (I did get the offer, thankfully), I started wondering what else I'd been getting wrong. So I made a list of every technical term I used regularly and checked the pronunciation for each one.
The results were humbling.
A short inventory of my mistakes
I'd been pronouncing cache as "ka-shay" (two syllables, with emphasis on the second). It's actually one syllable: /kæʃ/, rhyming with "cash." This one is extremely common among Chinese developers because the pinyin reading of the letters naturally leads to a two-syllable pronunciation.
I'd been saying daemon as "day-mon," which is actually debatable — some native speakers say it that way too. But the more standard pronunciation is /ˈdiːmən/, like "demon." I'd never even considered that possibility.
Null I was pronouncing as "nool" (rhyming with "pool"). It should be /nʌl/, rhyming with "hull." This one genuinely surprised me because I'd heard native English speakers say it many times in videos — I just hadn't registered the vowel sound correctly.
The list went on: sudo, wget, OAuth, Kubernetes. Each one had a subtle or not-so-subtle difference from what I'd been saying.
Why this matters more than you'd think
Some developers argue that pronunciation doesn't matter — "everyone knows what you mean." And sure, in written communication, spelling is unambiguous. But as remote work grows, developers speak English in meetings, presentations, and interviews more than ever.
When I mispronounced "char" in that interview, it didn't cost me the job. But it did create a small moment of friction. The interviewer had to pause the technical discussion to address pronunciation. That's a few seconds of lost flow, a slight shift in the dynamic. In a tighter interview, that could matter.
More importantly, mispronunciation can undermine confidence. After the "char" incident, I caught myself hesitating before saying technical terms in the next few meetings. I'd mentally rehearse the pronunciation before speaking, which slowed down my participation. That hesitation was worse than the original mistake.
What actually helped me fix this
I tried a few approaches. Dictionary apps were tedious — I'd have to search each term individually, and half the time they didn't have programming-specific entries. "Char" in a regular dictionary means charcoal or to burn slightly, which doesn't help when you're looking up the C data type.
I eventually found DevGlish, which has a database of tech terms with IPA pronunciation and audio. What made it useful for me was the context: it explains not just how to say a word, but what mistakes speakers of specific languages tend to make. For Chinese speakers, it flags things like the cache/ka-shay pattern and explains why our instinct leads us there.
I spent about two weeks doing a few lookups per day — just the terms I actually used at work. I wasn't trying to memorize a dictionary. I focused on the words I'd say out loud in my next standup or code review.
The unexpected benefit
The biggest change wasn't in how others perceived me — it was in how I perceived myself. Once I stopped worrying about whether I was saying things correctly, I participated more freely in discussions. I volunteered to present in team meetings. I started doing more pair programming sessions with colleagues in other time zones.
It sounds like a small thing. A single vowel sound in a three-letter word. But language confidence compounds. Each correctly pronounced term gave me a tiny bit more willingness to speak up, which led to more practice, which led to more fluency.
If you're a developer who learned English as a second language, I'd suggest doing what I did: pick 10 technical terms you say out loud regularly and verify their pronunciation. You might be surprised. And if you find mistakes, don't beat yourself up — I spent six years saying "char" wrong, and I turned out fine.
Well, mostly fine. I still can't decide whether to say /ɡɪf/ or /dʒɪf/. But that's everyone's problem.