This is the programming question I will ask when I interview you (and why)

I am a little proud of my clickbait blog title. Despite the headline, you won't have to read 10 ad-loaded pages to get the answer, like I had to do to find out what happened to the cast of "Gilligan's Island" (answer: not much - they all had happy, boring lives). I hope you continue to read because you're interested in the why I'm writing this. Maybe it will be insightful for interviewers and candidates, even if you disagree with where I ended up.

But to stay true to my word, here is the question: it is the easy question from coding practice sites (rhymes with 'wheat load', wink) where you parse a string and determine if an expression is balanced or not. So if you don't want to read my article, you can leave now and head over to your favorite code-grinding site and read their explanation.

For those curious about the 'why' part...

First, why am I making my question public? Well, our HR department likes us to keep the same questions for the same roles, to be unbiased between candidates. And I defer to them in their areas of expertise. Also, I know there is chatter on Glassdoor, between recruiters and candidates, and candidates and each other. If you are interviewing with my company for a software development position, possibly you already know the questions we ask. So I don't think I'm making the process any less balanced making the information publicly available.

And there's another reason I don't feel the need to keep this question a secret. Whether you know the answer going into the interview is less important to me than how we interact when answering the question. If you don't know the answer, I will work with you in the interview while you figure it out. In some ways, these are the most rewarding interviews, because I get a sense of what a candidate will be like to work with. And the candidate, likewise, gets an idea of what it is like to work with us. And if it's something we can live without, better to find out now, from both sides.

So, why make a candidate program in an interview at all? I'm not a huge fan of working while somebody is looking over my shoulder, and I'm certainly not my best self under those conditions. But over 25+ years of doing these types of interviews, I found I just can't get the information I need from an interview any other way. If a person can't demonstrate any ability to write code in an interview, they tend not have have the ability after the interview, either.

Software engineering is a skill. Facts can be looked up, and I certainly don't need people to do that. But skills require time and effort to develop. Evaluating software engineering candidates is about finding the level of skill, without being so annoying about it that we scare off the best candidates. Asking an accessible programming question, and then discussing and analyzing the result, has proved to be an effective balance.

Answers to programming questions can be googled. But part of this process is to discuss how/why the algorithm works, different approaches, how the computer is storing information, etc. Is it possible to fake all that? Maybe, but I'm not to worried about it. That's not the mindset I want to take to an interview, in any case. Good candidates are hard to find, and I think we need to enter the process with a reasonable amount of trust.

The interview is a practice session for interacting with the candidate IRL. I need to know what it's like to give this candidate programming assignments, and interface with their code. Do they ask questions? Do they take my suggestions if they are on the wrong track, or at least understand them. And can they analyze and understand what their own code does?

So why this particular question? First, it does not require any specific domain knowledge. I've seen questions about the area under a histogram, or how many ways a queen can move in chess, for instance. I'm not saying these questions are never appropriate (if you're interviewing for a job to create a chess engine, for instance). But they seem a bit like parlor tricks to me - easy if you know how to do it, but tricky otherwise. And easy to mess up in an interview. The underlying algorithms may be useful, but these are usually not great technical programming questions.

Also, this question hits some pretty satisfying buttons when it comes to general programming questions. Anytime you see a string parsing operation, your mind should start thinking about a stack. Someone with a good computer science background will understand that a balanced expression can be generated by a Context Free Grammar. They will see that, since a mathematical expression can nested to any arbitrary length, you need arbitrarily large memory to store the expression while parsing it. They might notice that a nested structure is also a recursive one, so, while they need arbitrary storage, the don't need to hunt for the matching part - it's always the last one they put stored. A Finite State Automata, like a regular expression, is not adequate to express that type of structure because it doesn't have arbitrary memory.

Often, people won't have this specific languages to describe it. They may implement the stack without realizing that is what they are doing. Sometimes they'll even go so far as to say they'll push something on to a list, and then take the last thing on the last and take it off first. I consider that a win.

Sometimes, people go off in a different direction. Maybe they'll try to create counters The counters won't work - because this is a language is a CFG, order matters and so you need to store the data in order. A counter is only one piece of information and can't represent order.

But all is not lost! For this reason, I always ask people to describe what they're going to do before they do it. Usually, as soon they start visualizing what the counters do,