The real-time coding interview

real-time coding interview

I recently found myself interviewing for jobs for the first time in several years. Things have changed a bit since 2011, and the real-time or live coding interview now appears to be all the rage as a candidate screening process. This is when you are interviewed initially over the phone by someone, and then you are asked to open an online code editor app like CollabEdit, CoderPad, CodePen, or the like, and to live or real-time code your solution to one or more given problems while on the phone with the interviewer.

These apps are collaborative real-time editors, allowing the interviewer to see your code as you type, similar to Google Docs, so it is naturally akin to someone looking directly over your shoulder as you write. Now, I have researched this topic to find out what others’ experiences have been like, and I see a lot of disdain toward this practice. I also see a lot of replies to these complaints, defending the real-time coding interviews and explaining their justification. Let’s explore what some of these justifications are.

  • Real-time coding shows how you work under pressure
  • Interviewers want to evaluate your social skills and how you react to conflict
  • The interviewer wants to “see” how you think
  • Interviewers want to know your coding style
  • The interviewer simply wants to make sure you are not a fraud and can do the things you claim in your résumé
  • Interviewers want to observe what kind of questions you will ask to understand the problem before you dive into resolving it
  • The interviewer wants to know how you are at pair programming
  • Interviewers want to know if you are a milquetoast

Some of these reasons are certainly valid, but the problem for the interviewee is, he or she never knows the true intention behind the real-time coding questions and will always feel pressured to get the question right in the shortest amount of time so that the interviewer is not waiting on the phone for too long, and so that he or she does not come off as not knowing what they are doing.

I’ve been a web developer for more than 20 years, and I’ve certainly experienced my fair share of situations under pressure. Most often, a pressure situation is when a bug has been introduced into your production environment and is affecting customers, internally or externally. This requires a quick solution to the bug. I think most developers would agree that this is not a favorable situation, and certainly not something you look forward to encountering. I know from my own experience, however, that I always perform exceptionally well under this kind of pressure. I’ve cured customer-facing regressions time and time again, and in a timely, thereby cost-effective manner.

In none of these situations has my manager or someone responsible for my employment ever been standing behind me, looking over my shoulder, and watching every keystroke I make while I attempt to solve the problem, waiting for me to solve it without giving me any time to think about it at length, allow me to do some research, run some tests, and ultimately come to a comprehensive and well thought out solution. This would certainly add a significant degree of anxiety to my already stressed mindset, given the situation.

Talking on the phone while someone is watching every character I type while real-time coding does not emulate a real world situation I would ever be in while writing software. This situation makes me anxious because I feel like I have to hurry up and write something, and I don’t have time to actually sit back and think about the problem, thereby making my performance lacking.

In addition to the angst inducing element of being subjected to a real-time coding test, I have found that the questions are often not indicative of a real-world problem, making the ability to perform well even less attainable. These questions are most often mathematical, or involve traversing arrays or objects to solve unusual problems.

For instance, I was asked by one interviewer while real-time coding to write a function that accepts a single parameter and returns true if it is a palindrome, or false if it is not. The interviewer made sure to quickly explain what a palindrome is, in case I didn’t know. This was somewhat encouraging, but my next thought was … why would I ever need to do this? Maybe if I was writing educational software for a language course, or something of that nature, would I need to determine if a variable is a palindrome. The company I was interviewing with was nothing like this, however.

Is this an easy question? You could argue that it is, as the shortest answer is actually only a couple of lines of code (or one line, depending on your coding style). Also note that a palindrome can be either a string or a number.

function isPalindrome(val) {
    var str = val.toString();
    return (str === str.split('').reverse().join(''));

The answer I gave works, more or less, but it does not account for whitespace, non-alphanumeric characters, and capitalization. A palindrome, by definition, ignores these factors.

Here is an example of a more sophisticated palindrome:

A dog, a plan, a canal: pagoda.

Handling something like this is a bit more complicated, but it’s still a quick solution if you know a little regex. Unfortunately, under the pressure of doing a real-time coding interview with someone “breathing down my neck,” I was not that thorough. So you could say I answered the question incorrectly.

function isPalindrome(val) {
    var str = val.toString().replace(/\W/g, '');
    return (str === str.split('').reverse().join(''));

Now the isPalindrome() method accounts for whitespace, punctuation, capitalization, and safely handles numbers. Of course, I figured this all out after the interview.

It is also likely, in the case of javascript, that this question is used to discover your knowledge of method chaining. The reality for me, however, was that I had to use a javascript method that I can safely say I have never used in my professional career; the javascript reverse() method. Of course, this problem could also be solved with a for loop, instead of using a prototypical array method. Either way, I would say the question is unfair in that its objective is to solve an unconventional problem that would rarely, if ever, occur in a real-world coding situation, especially for a front end developer.

Upon further research after the interview, I discovered that the palindrome method is actually a common coding interview question. Perhaps I should blame my own ignorance, then, for not knowing how to quickly determine a palindrome. My assessment remains, however, that this is not a good example of a real-world situation, and so while it may demonstrate to the interviewer how you handle pressure, react to conflict, and how you approach a problem, it does not achieve anything constructive with regard to your ability to handle real-world challenges. Keep in mind that this includes the fact that the interviewer is looking at the screen, awaiting your every keystroke, as your mind reels about why the hell you’re even being asked to do this to begin with.

Ok, so maybe that is an “easy” one. Let me present another example which I was asked by a completely different company in another real-time coding interview.

Write a method that takes two parameters, an array and an integer, and have it return whether any two numbers in the array add up to the given integer.

Wait … what? I had to talk through it and ask a few questions to first understand this one. Remember, I’m just being told this by someone over the phone while I’m staring at an empty CoderPad screen. So, after clarifying all the specifics, I had to determine if any two numbers in the given array, no more or no less than two, not doubling any one of the numbers, in any order, summed together, equal the given integer. Ok, that makes sense. Now, where the hell do I begin?

Well, I’ve got to think of a clever function name for something so abstract. I just called it targetNumber, because that’s the term the interviewer used for the integer parameter. Next, I pass in an array, an integer, and now I’ve got to traverse that array somehow. My first inclination was to write a nested for loop and start comparing the values somehow. I knew that couldn’t be the best answer, but there I was, being keenly observed as I clumsily attempted to write a method to do something that I likely would never have to do as a front end developer. Mathematical problems like these should almost certainly be solved on the server side and provided in a REST API response. In actuality, I rarely have to do any kind of math calculations as a front end developer, and those that I do are generally pretty painless.

To cut to the chase, I pretty much bombed this question. I wrote a nested for loop and came up with something of a pseudocode-esque answer. Later that evening, I revisited this problem. Despite my sheer frustration for the interview process and the nature of the question, I had to solve the problem. I created a gist for this, shown below.

Even after taking the time to come up with this solution outside of the real-time interview process, I couldn’t come up with a great method name due to the abstract nature of the problem to be solved, but it is this aspect of my mentality and ability that I wished the interviewer had really known about me. Unfortunately, all they saw was some sloppy real-time coding off the cuff, done to solve an impractical problem. I think it’s fair to say that this particular question is not an easy one to answer, especially on the spot and while being watched.

I have to say, this type of interviewing tactic really turns me off to companies. It tells me that they are not looking for real-world problem solvers that take care to architect things properly and are careful to analyze things throughly before moving forward; rather, they are looking for hackers that can throw some quick and dirty code together to make things work, or they want absolute code nerds that can spit out every javascript method name and tell you what it does. I can say from experience across a lot of companies, large and small, that these types of developers will not last and will not help your company to evolve. To further supplement my case, I have indeed noticed that the companies that use this interview tactic tend to have a lot of turnover at these positions.

When I participate in an interview, the company should know that I am interviewing them as well. When I encounter a real-time coding phone screen, especially when asked abstract questions that don’t generally apply to the real world, I will almost definitely be excluding that company as a candidate in my job search, whether they are interested in me or not.

1 comment

  1. My favorite comment: “When I participate in an interview, the company should know that I am interviewing them as well.” Love that.

    Some random thoughts: I think phone screens are early in the process to do the real-time coding interview, especially if the company has the ability to bring you in in person. (Not remote.) Phone screen should be used to just figure out if you’re interests are in line with the company and position and if there is potential for a mutually beneficial match. As a follow up I would love to read what process you prefer for phone screens, but better yet in person interviews. I’ve been toying with the idea of solving a problem with a candidate together on a computer in a repo for a few hours. There are several pros and cons to that and I haven’t gotten buy in to put that method in practice. I can say this though, I’ve had much better experience doing live coding with a candidate than white boarding, specifically for remote developers. I don’t really see a way around this practice for remote developers. Let’s not get too far into that though.

    Great thoughts here. Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.