“What Programming Language Should I Interview With?”
Why I somewhat disagree with the common advice that you should interview with the language you are most comfortable with
I won’t make you read the whole article just to hear the answer — the reason I disagree with this advice is that I think it should have a caveat: You should probably have more than one programming language you are comfortable interviewing in, and in some cases you will not have a choice. This is “do what I say, not what I do” territory, but in this post I hope to recount my experiences almost ALWAYS coding in C++ for interviews, and why I think I should stop doing that.
Who says you should interview in the language you are most comfortable with?
— You, I imagine
Google the question, and Yangshun Tay comes up. This is for good reason; Yangshun Tay is a Meta engineer, he made Blind 75, and this blog has been attempting to get his autograph for the last seven posts. Here is his response:
Most companies let you code in any language you want — the only exception I know being Google, where they only allow candidates to pick from Java, C++, JavaScript or Python for their algorithmic coding interviews.
However, the choice you make can impact your performance much more than you’d like to believe — and this is why it is important to pick a suitable programming language early on in your coding interview preparation — and use regularly in practice.
….
Most of the time, it is recommended that you use a language that you are extremely familiar with rather than picking up a new language just for using in interviews.
— Source
I actually disagree with the first paragraph above. I think this is very much a FAANG article (Cramer says we should start calling it MAMAA, but I digress), but from my limited experience I would say that no, most companies do not let you code in any language you want…or at least there are a fair number that do not. Think startups. Think small companies. To be fair, even some large companies have not given me a choice.
The most memorable experience I have is summarized here. I don’t really want to remember, to be honest, as it was the second worst coding interview I ever had. This was for a company you probably have not heard of, but owned by an insurance company you probably have heard of. For a little background, the position was Java developer and HR had asked why my resume did not mention Java at all. A critical thinker would ask why I even applied, but moving on:
I was given a blank text document. There was no highlighter or compiler; it was like a whiteboard. I asked if I could use C++. The interviewer said my question made him very concerned…he was just asking a simple Java question (in this case, using a chosen data structure to store roughly 1 million device IDs). I asked how efficient it had to be, and he said it did not matter. Then I started coding in Java, and he cringed the entire time and asked me at the end if I had ever coded in Java before.
Personally, I don’t think what I had was that far off, and I included Java in the link above and some C++ I wrote the following morning…but who cares what I think? The point is, not every company gives you a choice of programming language.
For the record, I have used Java but do not use it very often.
The Disadvantages of “Obscure” Programming Languages
If you are absolutely sure you want to stick to one programming language and/or you are an expert in it, go for it. Ignore the rest of this post. I personally think this mindset is limiting, though, considering that having more than one programming language at the ready could seriously expand the number of companies you can apply for.
My experience is split between middleware and frontend web development. When I started my job, I said I wanted to be a frontend developer. They gave me a task, and I did not want to be the new hire who complained on the first day, so I spent the next few years doing C++ I would characterize as fairly low-level. I tried to do frontend web development whenever I could.
To a web developer, C++ may be very unfamiliar — maybe even “obscure.” To someone who writes more low-level code, C++ is extremely familiar and maybe JavaScript is “obscure.” Yes, deep in the bowels of certain worlds, you might be surprised to find people who do not keep up-to-date with emerging programming languages and frameworks, but who have an almost encyclopedic knowledge of C++.
The danger here is using a programming language the interviewer is unfamiliar with. In the worst coding interview I ever had, the interviewer was not even tense; I kind of just buried myself in a hole while he looked on. The problem required an unordered_map, but I did not know basic syntax in it…and neither did he, because he did not know C++ and was used to other implementations of the hashmap. A much better interview consisted of this problem, and a hashmap, and the interviewer challenged me on the efficiency of the unordered_map find call. I can imagine what the reader is thinking: But Curt, if you’re going to pick a programming language then you should know stuff like this, period. My counter is that in the actual field, no one will fire you from your software engineering job because you had to spend five minutes reading a document on Google that listed unordered_map calls. An interview is a very short test, relatively speaking, so it is not unfair for an interviewer to give you syntax hints that are not fundamentally tied to the core algorithm you are demonstrating. If anything, this is how a coding interview SHOULD go.
Also, notice I bring up hashmaps a lot. They really do come up quite frequently, which is why I wrote this.
JavaScript
Another brief story: HR told me I would have a choice of programming language in my coding interview, which technically was not true, but she gave me a major hint. She said that HTML would be important.
As it turned out, what I got was a pretty realistic scenario. The interviewers gave me a JavaScript file, an HTML file, and a CSS file. Their challenge was to implement a new UI feature.
And yes, it consisted of a map.
Some Final Thoughts/Complications
Interviewers reserve the right to ask you whatever they want (within reason), and this is where things get interesting. For example, maybe you will use string concatenation and they will ask a follow-up question about efficiency. Depending on the programming language you use, your answer will vary.
So if someone argues with me in the comments and says that you should learn one programming language inside and out, from syntax, to efficiency, to specific features that make it unique, then they do have a legitimate argument. I will point, once again, to my unique perspective as someone who has used C++ on interviewers who did not know C++.
We solve different problems in different programming languages, constantly. Some companies, like Meta, focus more on computer science fundamentals and interview with the philosophy that someone who is good at computer science will also make a good software engineer. Other companies, particularly startups, are simply not like that. They are within their rights to interview for people who know a programming language cold.
In a game of chess, it is advantageous to use an opening that the opponent is unfamiliar with. Interviews are the exact opposite: The interviewer should not be unnecessarily confused, and no one should be defeated, and the two of you should get on a wavelength. This is a practice round for actually working with the interviewer in the field.
Moving On
I was thinking of writing an entire post just responding to comments here. I wrote a response to Atwood’s old FizzBuzz blog post, and commenters on my blog seemed to rally for and against coding interviews in equal measure. Overall, I dislike the notion that FizzBuzz programming interviews are necessary because the vast majority of programmers lack basic competency, rather than that the tests aren’t great.
What I really want to do is get back into LeetCode, maybe in JavaScript (or not, as this is taking a while), then start a new series called Intelligent System Design. The idea there is to mostly read pages out of System Design Primer, but to actually tie in information from corporate blogs to show that this is not just academic.
It’s a nice idea, but I don’t know if it will end up being so simple.
