Choosing a programming language is a huge deal that can make or break a technical interview. It’s like that scene from Indiana Jones and the Last Crusade where Indie has to pick the Holy Grail from a lineup of tempting chalices. Choose wisely and receive eternal life, but choose poorly and bite the dust!

Turns out, though — when it comes to coding assessments — there’s no “holy grail” of programming languages. The best choice for one programmer may legitimately be the worst for another. There’s no universally applicable rules of thumb and about a million factors to consider. In this article, I’ll explain how to balance these factors and optimize for your specific circumstances and skills. You might not be able to choose perfectly, but you can definitely choose wisely if you think holistically.

‘Real languages’ aren’t necessarily better

A lot of engineers are under the impression that languages like Java, C, and C++ are more legitimate than others because they are the “real” programming languages. Some feel that blazing through a coding challenge in one of these languages will help them stand out among other candidates as more hardcore. Some books on interviewing even flatly recommend that programmers choose Java or C++. This is usually ill-advised.

Don’t be a victim of grandiosity. Choosing C or C++ just makes coding under pressure more difficult. Even candidates whose core competency is one of these languages tend to struggle to complete coding assessments because of their sheer unwieldiness. It’s not impressive to needlessly add complexity to an already challenging situation. Mature engineers make trade-offs. They choose the right tool for the job. They choose tools that make a given task easy so they can get the best result.

With that said, you need to balance your current skillset and your audience. Some interviewers will 100% be impressed by your choice of C. Indeed, if you’re applying for a low-level systems role, using a language like C might be strongly encouraged or required. But in most cases, such as the Triplebyte interview it is likely not a good idea. You need to be honest with yourself about the best path for you and swallow any pride that pops up.

Dynamic languages get results (at startups)

For startups especially, I’ve found candidates do better with dynamic programming languages. The type-flexibility alone can make problem-solving markedly faster, not to mention way less verbose. Aside from that, dynamic languages are popular among startups. Often, the person interviewing you will be a user of one of these languages. Many of them (but not all) are considered modern and tech-forward, and by proxy, using them may lead you to be judged as modern and tech-forward. It’s a signal (allegedly) you’re part of the in-group, that you share certain values and will fit in among the other engineers. Is this fair or meaningful in judging your potential contribution? Probably not. It does, however, seem to be a reality of startup culture and often subconsciously influences interview results. Stuff like this sucks. I don’t endorse it. I’m simply stating that it may be a factor that has real impact on outcomes, so you may as well be aware of it.

Some languages can hurt

Along the same lines, bias against certain languages exists at startups, too. While the source of this bias is not definitively clear, I have some thoughts. Java and PHP, for example, tend to pop up in legacy codebases and tend to bring with them connotations of being themselves legacy technologies. This feeling (though not necessarily justified) tends to be at odds with the ever-evolving, forward-moving energy of the startup world and can trigger certain kinds of judgement among engineers who use trendier technologies. Java and C# are also associated with larger, traditional enterprises, and startups tend to dislike candidates with enterprise backgrounds. Again, these ideas may not be fair, and they may not be a useful measure of candidate potential at all. We are on the same page about this. But they are real, so you might be better off avoiding these languages in interviews with startups. An exception would be if your core competency is one of these languages and you don’t have a better alternative that you’re nearly as comfortable with, then this would be a time to go with one of these languages anyway and make a conscious trade-off. Acing with an unpopular language is still pretty great, but bombing with a trendy language is still ... bombing. Besides, if you’re applying to Microsoft or a PHP shop, then using one of these may even be a bonus. Know your audience.

So, should I always choose Python?

That depends. Imagine you’re in a coding interview. You have 30-45 minutes. You’ve been introduced to a problem, maybe clearly, maybe not so clearly. All eyes are on you, and the pressure is building. You finally think of a solution, and go to write it. But you forgot Python class syntax. Maybe the interviewer allows you to Google, and maybe they don’t. Best case scenario: You’re now burning precious minutes on really basic stuff. Then you can’t get your code to compile, because you forgot how to declare a 2D array. Back to Google. Maybe the interviewer is giving you the benefit of the doubt, but maybe they are judging you harshly. That will depend entirely on the interviewer. You finally throw together a solution. Your code looks amateur because style and structure are the farthest things from your mind given the circumstances. You complete fewer steps because of all this time grappling with the basics. It’s not a good look, but it happens all the time.

Your best bet is often the language you know best

You may be a PHP developer, and you may get judged for it. You may only ever work in C or C++, and using these languages may in their own way cost time. But if you choose Python and aren’t clearly familiar with its class syntax, those other dynamic language goodies aren’t going to be very helpful. All the time you could theoretically save by taking advantage of the permissiveness of the language is going to be used by grappling with fundamentals. You may come across as unprepared, or worse, new to programming itself (depending on how much or little the interviewer knows about your background).

A language becomes an option for using in an interview if you have had substantial practice solving problems with it. You need to be able to readily think in that language. It’s syntax for classes and basic data structures should be fresh in your mind. You should not be discovering quirky implications of its memory management model during the interview. And if you want to appear like an actual user of that language, you should be able to take advantage of language-specific syntactic sugar and idioms. An interviewer who knows Python will notice when you use camel-case in method names rather than lower-case words separated by underscores (see PEP 8). You don’t get in-group points if you butcher the language conventions, and you look like an amateur programmer if you can’t even declare a dictionary.

But learning a new language is an option

That said, you’re not stuck with the languages you already know. If you want to reap the benefits of one language or another, practice with it. Practice a lot. Do interview-style algorithm questions like the ones you find on LeetCode. Allow the language to become second nature to you, particularly as you reason through small problems under time-pressure. Build muscle memory with the language features and explore the boundaries of that language’s strengths as you attempt to solve problems. And don’t be discouraged. Your first few problems might take longer than expected and it may take a bit for you to internalize what the language has to offer. But once you do, you may find yourself coasting like an expert. If the language has a style guide, introduce yourself to it. Google the biggest faux-pas in that language and avoid them. You’ll know you’re ready when you feel comfortable and at ease.

Beware of atrophy

Think you’re strong with JavaScript but use C# for your day job? Time and time again, candidates underestimate how rusty they are in their language of choice. Even someone with years of experience will jump into an interview after a three-month hiatus and choke. They confused details with their most recent language and are shocked to discover they cannot recall basics they once knew intimately. Never let an interview be your first time coding in a language after a break. Even a month since you last used it is too much. Do a few problems on LeetCode no more than a week before. Work on a side project. Get yourself back in the mindset of that language. There’s nothing more tragic than appearing weak in something you’re actually strong in, yet I’ve personally seen this more than I can count.

Consider mentioning other languages

As it turns out, there’s a time and place for everything, even showing-off. While it may not be strategic to use some languages during an interview, it can help to mention them. An excerpt from Triplebyte CEO Ammon Bartram’s "How to Pass a Programming Interview" article:

An anti-pattern that some companies screen against is people who only know one language. If that’s the case, you have to rely on your strength in that language. But if you’ve done work or side-projects in multiple languages, be sure to bring this up when talking to your interviewers. If you have worked in lower-level languages like C, C++, Go, or Rust, talking about this will particularly help, [depending on the audience.]

This is how to score hardcore points, or impress with your polyglottal virtuosity — not by risking your progress in a coding assessment.

Domain-specific interviews are different

Of course — it goes without saying — if you are taking a domain-specific interview, you should use the language appropriate for that domain. Front-end interviews are typically done in JavaScript, and most Android roles require depth in Java. That said, there are sometimes multiple options. Kotlin is a rapidly growing alternative in Android, and you can build fully native apps in iOS with Swift, Objective-C, or a combination thereof. So how do you choose?

The logic above still applies: Start with your strongest language. The goal in a domain-specific interview, first and foremost, is to demonstrate strength in that domain. The language is a tool in service of that goal. Interviewers want to know you can hit the ground running with the APIs and understand domain-specific design patterns and best practices. If you can do that best in Swift, then use Swift, or vice-versa. Objective-C isn’t inherently more hardcore, and it doesn’t matter that Swift is more modern and trending. You don’t want your interviewer to mistake weakness in a language for weakness in the platform in general.

That said, there are some caveats. Some companies use one language exclusively. They may require proficiency in their language of choice, or they may be willing to let you catch up after your start date. If you are equally proficient in all the options, why not use the one they prefer. If you’re not, you may want to reach out to your point of contact and ask if they have any hard requirements or strong preferences for the interview. If so, you may need to invest substantial time getting up to speed. Just don’t underestimate the degree to which the languages are different. By the time you take the interview, you should be in the headspace for whichever language is required.

Key takeaways

All of the above is data for you to consider, not hard and fast rules of thumb. Here’s a recap of the key points:

• You final choice will not be perfect. It will have trade-offs, but it will have the fewest trade-offs of all the other options. Think holistically as you decide.
  
• There are no rules of thumb that apply to everyone. You must weigh all data according to your specific skills and circumstances.
• Your audience matters. Startups value one set of things, while larger corporations may value another. Do your research and adjust your choices accordingly.
• Prestige points are real, but they’re worthless if you can’t demonstrate basic strength. Don’t over-optimize for bad-ass points if it’s going to hinder your performance (it’s usually more than you think). A great way to do this is mentioning other languages but using your strongest.
• You should be very strong in (and freshly in the mindset of) whatever language you end up choosing. If you want to use a language for which this isn’t the case, you need to practice a ton before the interview until you are.
• Domain-specific Interviews are a slightly different beast, so research the expectations for your specific domain and add that to your overall data for consideration.

In other words, be an Indian Jones, not a Walter Donovan.