CPFAQ: How Do Coding Interviews Differ from Coding Contests?


I’m working on a project this year to build a competitive programming FAQ. This is one in a series of articles describing the research, writing, and tool creation process. To read the whole series, see my CPFAQ category page.

It’s no secret that the popularity of competitive programming depends partly on the popularity of the coding interview, the ubiquitous interview format in which interviewers present candidates with a problem and ask them to to solve it using code. Like candidates for software jobs, contestants in a programming contest also face tough coding puzzles. But programming contests and coding interviews are not the same thing. Even in a company-sponsored contest like Google Code Jam, doing well doesn’t get you a job offer, though it can get you invited for an interview.

A few weeks ago, I wrote about whether programmers should see competitive programming as a way to get a programming job. This week, I’ll go into some similarities and differences between programming contests and coding interviews.


Some companies use platforms like HackerRank as part of their hiring process. A HackerRank evaluation has a similar structure to a programming contest: you go to a website, read a problem, submit code that you hope solves it, and get a verdict.

But before hiring an employee, companies generally want to meet them in person, or at least face to face in a video chat. The problem-solving process in that type of interview is different in several ways from the HackerRank example. You’re submitting your code to a human, not a compiler, so you don’t have to be as precise with your syntax. Most human interviewers forgive lapses in spelling and punctuation, since they know your IDE would take care of those. You could even make up your own names for library functions, as long as similar functions could conceivably exist in the language you’re using.

The process of coding with a human interviewer also involves more back and forth than an interaction with an online judge. Good interviewers see a coding interview as more of a collaboration than an exam. They want to see how you communicate with people, since that’s what you’ll be doing in your job. You can ask any question you want. That’s not to say you can know nothing and still do well in the interviewer. You have to convince the interviewer that you have the experience they’re looking for. But it’s more flexible than the problem -> submission -> verdict process you get with an online judge.


There are multiple types of programming contests, and multiple types of coding interviews. But the most common problems in both cases involve algorithms and data structures: the online judge or interviewer presents the contestant or candidate with a problem and asks them to solve it using a well-known algorithm. Because of this similarity in question type, it seems reasonable to use programming contests to prepare for coding interviews.

But interviews and contests don’t draw equally from the set of all algorithms. Programming contests use a wider variety of algorithms, since they need to come up with many unique problems to challenge contest enthusiasts. Interviewers are less concerned with how many algorithms a candidate has mastered. They draw on a common body of knowledge that candidates should have learned in university CS classes and which interviewers can use to evaluate the candidate’s ability to think like a programmer. But they don’t assume that the candidate is an algorithm specialist.

Beyond algorithms, coding interviews cover other areas of computer science, like networking, operating systems, and system architecture. Some companies might look for expertise in a web development framework or a cloud computing platform, especially when they are hiring for a specific project. Interviews for senior positions are likely to focus more on design and architecture and less on algorithms. Non-algorithmic programming contests exist, but it can be harder for an online judge to test these areas.

As Imtiaz Mohammad describes it on Quora: “Competitive programming (CP) is narrow and deep. … Interview preparation is wide and shallow.”


It’s common to hear that coding interview problems are easier than competitive programming problems. Here’s how Jonathan Paulson puts it:

Interview questions are mostly just easier competitive programming questions where your code doesn’t have to work.

There is some truth to this. As described in the sections above, you don’t have to study as wide a range of algorithms for interviews as you do for a programming contest. And interview code written on a real or virtual whiteboard doesn’t have to satisfy a compiler, so standards can be looser.

But unless you know for sure that your interviewer will only ask algorithm-based questions, you might need to gain real-world experience to convince the interviewer that you’ll be able to start quickly in a new job. Building real systems can be at least as challenging as getting to a high competitive programming rating.

And interviewers can create challenging problems using even the limited set of algorithm interview topics. Bohdan Pryshchenko, who is red on Codeforces and now works at Google, says he finds Google’s interview questions difficult. His theory is that beyond the 1700-1900 range (blue rank), more competitive programming practice doesn’t help with interview skills. Instead, he recommends focusing on sites that specialize in interview questions (HackerRank, Leetcode, etc.) In other words, instead of learning the wide range of competitive programming topics, get better at solving the questions that are likely to come up in interviews.

The Case for Competitive Programming

In order to get good at passing interviews, you should invest your time into interview preparation. Sounds kinda simple and obvious.

Bohdan Pryshchenko

Since the best way to prepare for interviews is to practice interview questions, why not focus on that rather than on competitive programming? If you have an interview in three weeks, or if you tried competitive programming and didn’t enjoy it, that’s a fine approach. But there are reasons why competitive programming practice might be a better long-term strategy.

While interview preparation can be just a chore that you have to do to get a job, competitive programming is more than that. It’s a community of enthusiasts who enjoy competing to solve problems. For like-minded people, that’s more motivational than a book of problems and suggestions. Even a site like HackerRank can’t generate the same excitement as contests on Codeforces, where you can regularly compete with the best competitive programmers in the world.

And since competitive programming is an activity that’s separate from interview preparation, you’re more likely to stick with it long-term, keeping your algorithmic problem-solving skills up to date for any unexpected interview opportunities.

Beyond interviewing, competitive programming is a way to continually refine skills that are useful in programming jobs. Miguel Oliveira writes:

Some companies value competitive programming achievements, but I suggest you see it as a mean to become a better programmer (improve skills that you’ll use while building software) and not as a mean to find a job.

There are many ways in which competitive programming, especially a standard algorithmic programming contest, doesn’t relate to a programmer’s daily work. But every programmer can benefit from being more fluent in a programming language, getting better at solving problems, and improving their ability to get work done fast.

(Image credit: Kai Schreiber)