Choosing a Programming Language for Interviews

Last week at the MIT January term course Hacking a Technical Interview, after a class period finished a student asked me the question:

I know many different programming languages. How do I choose which one to use during my interview?

Why choose just one?

Don’t get me wrong—I advocate learning and writing code in many programming languages. But when it comes time for programming interview preparation, I feel it’s important to choose one language to focus your prep on and get to know it very well.

While many interviewers don’t mind you writing pseudocode during the early planning step of answering a question, others I’ve come across really want you to show you can write compilable code without an IDE. Not only that, but that you appear very comfortable writing real code.

How to pick

Now back to our polyglot student—how might they approach choosing just one?

Choose a language you know well

If you’re fresh out of school and throughout your college career you were instructed in Java, C or C++, stick with what you know.

Imagine this: what if I asked you right now, at your computer, to please, using a programming language (not your bash-fu or vimscript):

  1. Read in a file full of numbers, one number on each line
  2. Represent those numbers as integers in your program
  3. Replace each number with that number times its line number
  4. Write the file out elsewhere
  5. And complete the task right now at your computer as fast as possible, you’re being timed

Think—what language would you immediately reach for? Do you start your experimentation with ipython, or irb? Do you pop open Eclipse and write some Java? Or create a new .cpp file?

Make sure it’s widely readable

Ideally you’re most comfortable with a language that your interviewer has used before, but at the very least it should be readable by a wide audience.

Some solid, standard choices for interviewing, then, are: Java, C / C++ / C#, Python, Javascript, and maybe Ruby. PHP, AS3, Lua, Haskell, Go, LISP/Scheme and the ilk are potentially appropriate when the company uses them.

Consider this great visualization of the most popular coding languages of 2013 from the interactive practice problem website CodeEval:

Most popular programming languages of 2014

Most popular programming languages of 2014

If you’re using a non-standard feature of your language that might not show up in others (dense Python list comprehensions, Ruby functional programming techniques, higher-order functions)—it’s a good idea to be cognizant of the interviewer’s comfort with the language and gently offer explanations of concepts they might not have exposure to yet.

Bias towards the one they use

Some advice from the book Programming Interviews Exposed—all things equal, bias slightly towards the language your target companies use if it’s one of the ones you’re most comfortable with.

For example, if the company you’re applying to is primarily a Ruby shop and you’re fairly confident with your Ruby, go with that. If you’re applying to a low-level hardware manufacturer working mostly in C and Assembly, go with that. Game company that uses ActionScript, and you’re writing a game in it now? Go with that.

Here are some oft-used languages at various companies as reported in Cracking the Coding Interview and on Quora:

  1. Facebook: PHP, C++, Python, Java, Perl. High regard for dynamic/scripting languages. (source)
  2. Google: officially C/C++, Java, Python, Javascript, Go (source)
  3. Amazon: Java, Javascript, Ruby, Python, Perl (source)
  4. Microsoft: C++, C#, Java, Python (source 1, 2)

Once you’ve picked your language

Excellent, so you’ve chosen a language to focus your preparation on and to use for your interviews. Now what do you do?

Practice in your language

When you are doing practice problems, try to always write with the language you’ll be using in your interview.

The couple of weeks leading up to your interview, when you’re doing personal projects and hacking on things for fun, try to use that language as well.

Know thy common operations

Make sure you have at least the following operations down pat:

  1. Initializing and using hash-backed maps (dictionaries) and sets
  2. Performing queue and stack operations (whether using an array, like with Ruby’s pop/shift, or an explicit standard library implementation like Java’s Stack and Linked List-backed Queue classes)
  3. Defining classes with constructors and attributes, static and instance methods, and defining a subclass and interface
  4. Throwing exceptions for (1) invalid input and (2) custom messages
  5. Iterating through arrays and dictionaries (both key and values)—including iterating while maintaining an index (Ruby’s each_with_index, Python’s enumerate)
  6. Casting between strings and integers
  7. Strings: get character at index, get range, concatenate
  8. Initializing 2d arrays
  9. Arithmetic: modulus (remainder), division (if the first operand is an integer, will it round the result to an integer?), rounding (ceiling and floor)
  10. (Bonus) Switch statements
  11. (Bonus) Built-in language sorting. Quickly defining a comparator to sort an array.
  12. (More advanced candidates) The 5 standard bit manipulation operations (L/R shifts, not, or, and, xor)

Know the best practices

Especially if the company you’re applying to has experience with your language, it can be helpful to brush up on the best practices for your language. Sometimes you’ll get trivia questions, or be asked about some language-specific patterns.

If you’re going with Java, for example, and applying to Amazon, where Java is heavily used, consider reading through some of the best practices material.

There are some great books like Effective JavaSecrets of the Javascript NinjaEffective C++, and The Ruby Programming Language  which cover language-specific best coding practices.

Have some opinions about it

Some classic “technical chit-chat” interview questions are:

  • What do you like about language X?
  • What don’t you like about it?
  • How does it compare to (another language you profess to know)? Similarities/differences?

Formulating some smart opinions about your language is generally a good idea.

Where does your language fall among the different programming language paradigms? A book like Seven Languages in Seven Weeks is a good starting point if your breadth of language paradigm understanding is lacking.

Programming Language Paradigms

Programming Language Paradigms Table from Wikipedia

Now Prepare!

Now you’ve got your language and some steps to take to know it better for your interviews. Go forth and prosper!

Of course, as noted earlier, it’s not necessary to always stick to one language when not preparing for interviews—learning new languages is fun and can lead you to understand your go-to language better. But the week or few days before your interview, be sure to drill deep into one.

What is Coding for Interviews?

Each week, Coding for Interviews members receive two things:

  1. A programming interview question
  2. A distilled computer science topic review (with silly gifs)

You send in your answer and the next week we review solutions.

We practice a little bit each week. The idea is, the next time our group members are looking for jobs, we will be prepared.

New group members are always welcome!

One email each week. No spam. Easy unsubscribe.

Email

Brian Jordan is a software engineer and game developer in San Francisco, California. Formerly at PopCap Games, TripAdvisor and One Laptop per Child. Brian is the curator of Coding for Interviews, the weekly programming practice newsletter and teacher of the Coding for Interviews course.

Posted in Preparation
  • hatter

    cat source.file | sort | uniq -c >dest.file

    • Brian Jordan

      Hah! Close :) In all fairness, my example is a pretty bad one because it does beg for a dense functional programming paradigm language/solution which tends to be done less often in the interview context.

      But if you busted out an accurate BASH one-liner in an interview with me, that’d be a big plus.

  • Henrique

    def exercise(infile, outfile):
    open(outfile, “w”).write(‘n’.join(map(lambda x: str(x[0]*x[1]), enumerate(map(int, open(infile).readlines()), 1))))

    That exercise would be a good fit for a functional language.

  • http://xmltwig.com mirod

    come on, how could you use anything else than perl:

    perl -n -E’say $_ * $.’ nb.txt > new_nb.txt

    one-liner: check, use of funky special variables: check, code under 10 characters (by removing the optional spaces around the *): check, duck and wait for the “but it’s just line noise” crowd: check. ;-)

    • http://xmltwig.com mirod

      also: can be golfed further: check

      perl -p -l -E’$_*=$.’

  • Gabriele Carrettoni


    runResourceT $ CB.sourceFile "input"
    $= CT.decode CT.utf8 =$= CT.lines
    =$= CL.concatMapAccum (e i -> (succ i, [T.pack $ (show $ i * (read (T.unpack e) :: Int)) ++ "n"])) 1
    $= CT.encode CT.utf8 $$ CB.sinkFile "output"

    Haskell with Data.Conduit package, it is long, but this version doesn’t load all the file in memory but it’s “streamed” and it allows a lot of reusability because if the format of the file changes or anything else, you can swap one conduit for another and keep the rest of the pipeline the same.

    Without conduit you could write


    fmap (writeFile "output"
    . unlines . zipWith (i e -> show $ (read e :: Int) * i) [1..] . lines)
    $ readFile "input"

    or

    readFile "input" >>=
    return . lines >>=
    return . zipWith (i e -> show $ (read e :: Int) * i) [1..] >>=
    return . unlines >>=
    writeFile "output"

    or

    main = do
    ls show $ (read e :: Int) * i) [1..] ls
    writeFile "output" unls

  • Gumnos

    Though Python is my go-to language (see what I did there?) of choice for more complex things, I like the simplicity and readability of awk for solving this particular problem: awk ‘{print $0 * NR}’

    • Gumnos

      Though I’d also want to know whether the line-numbers should be 0-based or 1-based, and what should happen in the event a line’s contents don’t match the spec (multiple numbers on the same line, or non-integer lines)