A Step by Step Guide to Passing a Programming Interview

You chat with your interviewer for a few minutes. Maybe they ask about your resume. Maybe they ask about past projects. Maybe they don’t chat at all and jump right into the question (well that’s terrifying). But at some point you’re given the question: “Given a string, determine if it’s a palindrome”. What do you do?

Step 1: Ask clarifying questions

When I interview people, I always leave a bit of vagueness in the problem. It’s not meant as a “gotcha”, though I understand why people see it that way. I think of it as a chance to show off your skills at detecting when problems are ambiguous. That’s a skill you use regularly as a software developer and hopefully it’s a skill you can show me. In this example, the questions I hope a candidate would ask include

“How should I handle capital vs lowercase letters? Are they considered the same letter?” (And I would say yes, they are the same letter)

“How should I handle spaces and punctuation?” (Ignore punctuation)

“What about non-English characters? Could the input contain ñ or ü?” (Assume your input will only contain English characters for now.)

“Is an empty string or a single character string considered a palindrome?” (Yes)

Good job, you detected multiple cases of ambiguity in the problem. You’re looking like a pro. And you won’t get halfway through the problem and realize that we’ve made different assumptions about how to handle punctuation.

Step 2: Talk through different approaches

You’re probably tempted to jump to the most optimal solution right away but I would recommend against that. My advice is to start with brute force and work up from there, even if you already know the best answer. This shows

You see many possible solutions to the problem

You have a strong understanding of Big O and the tradeoffs between different algorithms. You can discuss why this one is better than the other options.

But won’t I look stupid if I come up with the brute force solution first?

I’m going to say no, but remember this is a conversation and you can be honest with your interviewer. Say something like “I can think of a few different approaches here. To start with the brute force approach, …”

Step 3: Fully run through your algorithm

You’re staring at the clock. There’s 37 minutes left. You better jump right into coding, right?

I’ve given a lot of interviews and I feel pretty confident at this point saying that almost every time someone jumps right into coding, they end up taking longer to solve the problem. Let’s look at our palindrome example. What people often say sounds a lot like this:

"Start at the beginning and end of the palindrome. Work inwards, comparing letters until you get to the middle of the string. If they’re all the same, it’s a palindrome."

What I want to hear sounds more like this:

If the string contains zero or one characters, return true.

Convert the string to lowercase.

Create two pointers, one pointing to the beginning of the string, and one pointing to the end of the string.

In a loop, move both pointers in by one character. If a pointer hits a space or punctuation mark, move it in until it hits a letter.

If the pointers are pointing at different characters, return false.

When the pointers are pointing at the same letter, or the end pointer moves past the beginning pointer, return true.

That didn’t take all that long, but it’s going to save you time in the end. You’re not going to forget edge cases or how to handle the clarifying questions. (In my experience, people love to ask fantastic clarifying questions and then completely forget to handle them in the code.)

In this palindrome example, you could probably recover if you didn’t fully flesh out your algorithm. But that’s often not the case. I’ve seen people start on an algorithm that sounded reasonable, and then twenty minutes into the problem they realize that the algorithm wasn’t going to work for some specific case. Their code doesn’t fully solve the problem. They’re going to have to start over.

But why did the interviewer let me waste 20 minutes on the wrong solution?

I promise, we don’t want you to waste your time either! But if the algorithm you describe is vague to you, it’s equally or more vague to us. We can’t push you in the right direction if we don’t even know the direction you’re going.

Step 4: Talk out loud while coding

This is, in my opinion, the hardest part about interviewing. I’m good at coding. I’m less good at explaining my thought process. But when I’m hiring candidates, I’m not hiring them because they can solve the one specific problem I gave them really well. I’m hiring them because the way they work through the problem leads me to believe that they’ll also be able to work through other problems.

So talk out loud the entire time. Tell me what you’re coding. Tell me why you’re coding it that way.

“I decided to use a hashset instead of an array because inserting into it is constant time rather than linear. The downside is that the input will no longer be sorted, but I don’t need the input to be ordered anymore at this point in the algorithm.”

“I could actually write this in a slightly more efficient way, O(n) instead of O(2n) by doing [something]. But I believe the code is more readable this way and readable code is less prone to bugs. I think that’s a good tradeoff.”

And maybe I disagree with your decisions but if I know why you’re making it then I trust that the decisions you make in the future will be well thought out. I’d rather someone make a decision I disagree with but justify it, than make the same decisions I’d make without telling me why they’re making them.

Step 5: Run through a few examples

You finished your code. Let’s be honest, there’s some bugs in there. And the worst part is that the interviewer has given this problem ten times already and she saw the bugs the second you typed them.

So go find them. Walk like by line through your code with an example or two. It’s okay if it’s a short example, but at least make sure it’s a good one. Think back to your clarifying questions to come up with edge cases you should be testing.

For our palindrome example, I would recommend something like “!Ab,a”. It’s only four characters so it will be a quick walkthrough but you’re handling the cases

Contains a middle character “b” which isn’t repeated

Contains capital and lowercase letters that should be equal to each other

Contains punctuation both in the middle of and on the edges of the string

And walk through what the code does, not what you think it does. I often see people try to rush this step and they end up missing bugs because they’re in a hurry. It’s so uncomfortable as an interviewer to watch someone walk hit the line with the bug that’s been staring at me for the last ten minutes, and rush past it without testing it.

And congrats! You absolutely killed that interview. The interviewer thinks you’re great at finding ambiguity in problems, at discussing tradeoffs between different algorithms, at making smart decisions about your code, and at debugging that code. They offer you crazy amounts of money. You ask for more. They say yes.