Mob Programming Interviews Changes Everything

This article is from the pre-AI coding era, originally published pre-2025 on my Medium account and ported here.

I’m a fairly mediocre human being.

• Decent developer who’s had plenty of practice.
• Relatively open to failure.
• Not an academic by a long shot.

One thing I’ve always loved, however, is debugging.

Debugging code and humans#

I enjoy debugging software bugs, and my favorite technique is using breakpoints, something you use to freeze an application during execution at any given line of code (AKA placing a breakpoint), letting you peek at the state of the entire application to see what happens just before a fatal error occurs.

Some people prefer logging values they think they might need to the screen to try to deduct what’s wrong, but what makes it so flawed is that it only shows you what you think you’re looking for. It’s like inspecting a room with binoculars.

And now dear reader, it has also convinced me that most companies could do job interviews that are vastly better by employing breakpoints in humans. By vastly, I mean off the charts better.

Let’s step into it.

Buggy humans are buggy#

“So, you wanna break people’s arms during interviews?”.

Maybe just a little!

People are buggy. Far beyond the software they make, they also make conclusions based on subjective truths. We’re scared of AI, yet our own sentient minds are already up to all sorts of random things every day.

So when you sit down at an interview, looking to gain an understanding of whether the candidate is all that you’re hoping them to be, you are logging specific output from these individuals.

You ask them to log whether they’re a team player or not. If they output “yes”, what else can do you with that information? A seasoned interviewer might reply “well I’d obviously ask a more indirect question to find the truth written between the lines”. That’s all fine, but not all of us are expert interviewers, and perhaps we don’t strive to be. We just want more good people around us doing the work we’re most passionate about.

Instead, let’s shift to the breakpoint mentality. Let’s inspect this person’s state while running it through its job.

Now bear with me.

Mob programming quick intro#

Mob programming is an incredibly powerful way to craft high-performing teams. It consists of having one person at a computer (driver), taking and asking for directions on what to do, and the rest of the group giving the instructions (navigators). The mantra is “From mouth to keyboard”, and it gives the group the ability to discuss the actions before coding, because there are always hundreds of ways of doing the same thing, and some are better than others. As a big bonus, you learn to adapt and learn from each other (actual team-building by the way) and make more consistent decisions in the future, all of which reduce noise in your day-to-day work.

This leads to less tech debt, easier onboarding, better work management (without full-time Jira taskmasters, or what some might think of as “scrum masters”), and a more fun workplace to be in.

The idea#

Now if a mob programming session gives the group so many benefits, why don’t we bring it to the interview? Simply put, let the candidate join a group of 1–2 potential teammates, pick a random code challenge (keep things non-favorable for the teammates, don’t give them the edge of knowing all the answers), grab a timer, and get started for about 1.5 hours. What you’ll get is a wide range of insights.

Insights given from mob interviews#

An actual display of the candidate’s personality#

When the person expressed being a team player (either thanks to a biological bug or because of genuine origins), you will see a scale of teamwork ranging between really taking input from the team, to someone who freely violates the ground rules to get their point across, like coding by himself while being at the keyboard (sounds like a small thing but it’s a big tell). After kindly reminding them of the rules, you will also get to see whether they’ll take a strong defensive stance, or if they’ll admit that they got a bit carried away. Beats the heck out of any interview question aimed at answering the same question, don’t you think?

Skill insights#

The typical bring-home code challenges pale in comparison to this style of interviewing. Not only do candidates appreciate a fresh way of interviewing, but seeing how they interact with the challenge, together with a team, gives you the ability to “debug” their behavior in real-time, looking at how they reason with code as much as they write the code. Do they have a fundamental knowledge of the programming language, enough to know easily how to loop and iterate? It’s easy enough to Google for specific solutions, and with a bring-home code challenge you’d probably not be able to get a clear insight of how much they understand the code they present to you.

The team gets a say#

A guideline I find useful in any mob programming session is finding the team within the team and finding people that enjoy working together. To help accomplish teammates with high social compatibility, your team should have a say in who should join it. Letting team members be part of the interview in a mob programming session gives them the means to answer the most important question: “Would I be content working with this person every day?”. Managers who don’t involve teams during the interview always take a gamble in this aspect, a move that can become extremely costly in the long run.

It’s simply fun#

Many studies point to that effective team building isn’t about the workshops and fun distractions from the regular work, it’s about doing the regular work together. Mob programming is a team-building activity because it puts the developers in the same room, solving tasks together. I love to take little detours in mob sessions when the group is feeling it because it’s a sign that the group is bonding and learning more about each other. If a team isn’t normally doing mob programming for some reason, having them participate in mob interviews at least gives them an opportunity to bond further, with or without the new candidate getting hired in the end.

What do you need?#

Hopefully, you’re intrigued at this point but unsure where to start.

While not required, to get up to speed with the usual formats for mob programming, I recommend you to read this https://mobprogramming.org/mob-programming-basics/.

With mob programming in mind, I’d like to offer a few tweaks for the interviewing aspect.

Lowering the candidate’s guard#

Most candidates will be nervous when in an interview, and if they keep their guard up, it will be difficult to assess their actual behavior. It will also be difficult for them to perform well in this state since humans can’t multi-task. Normally I witness candidates getting engulfed by the code challenge sooner or later, but it helps to employ a few tricks to get them to this state as soon as possible.

• If you’re going for the well-preferred method of driver/single-navigator, let your colleagues hold the driver and navigator roles when starting off the first rotation. This will make the candidate stop and realize that they’re not always in the spotlight, and it helps to combat candidate nervousness. If they contribute anyway, that’s fine of course, another insight for you.
• Don’t point fingers at the candidate or single them out. Instead, be slightly more inclined to go with their suggestions, but if it’s leading in what you believe to be a bad direction, communicate to the group (as a group member, not as some kind of director) rather than to the individual who suggested it. Additionally, if I feel we’re going outside the ground rules of mob programming I usually tell the group that I’ve now got my facilitator hat on before I let them know, so they know that I’m just trying to help the group and not pushing my own opinions.
• Don’t set an end time for the interview. If you feel the candidate is not well matched with the team by reading the room, this gives you the chance to mercy kill the mob session and avoid taking up time for the entire group.
• Employ TDD. Each added test should expect a small piece of functionality in the overall challenge, so the group can go steadily forward together in tiny increments. Remember, only write the code that solves the test no matter how ugly it may be. You can always choose to refactor it when the tests are passing.
• Be wary of the infamous “I know we should take it a step at a time, but I think we need to plan ahead a bit before we do anything further”, followed by a long oral explanation by a single member, or worse, someone taking over entirely what code should be written and where without explanation as to why that code should be there. This is a slippery slope down to getting nothing done, with only half of the group (or less) reaching an actual understanding of what we should be doing. Focus on the tests, and when the code has too much spaghetti, refactor it as needed, together. This is also known as “Red, Green, Refactor”. Remember that you can remind the group with your fancy facilitator hat to try to steer them back in the right direction.
• Use cyber-dojo.org. Why? Because giving anyone the benefit of working in their favorite IDE is bad. You want to keep advantages to certain individuals to a minimum. This is important in order to give the candidate the feeling of being on equal footing with the others and helps combat potential nervousness.

Summary#

There’s a lot to talk about when it comes not only to mob programming but mob interviews. I hope this will give you the means to find out why I believe it’s the best tool for hiring developers, giving yourself a reputation for hiring in a fun way, and building a culture engaged in building a real community.

My close friend and ex-coworker Henrik Stahl has written a great article about mob interviewing, so if you’re thirsting for more, head over to his article!

Thanks for reading.