I have been running a coding challenge for recruitment for the best part of 13 years. Multiple companies and clients. I enjoyed it so much, I would do it myself even when I was senior director of engineering.

It is time to retire it given two factors:

1. It doesn’t really work well over Zoom, etc.
2. It can be recorded by the interviewee, and perhaps was in 2022

Blackjack/Pontoon/21 as a subject for a series of stories.

The game of Blackjack, also known as Pontoon or 21, is a well-known card game that many are familiar with. The game mechanics are simple and engaging,

However a gambling connotation may not appeal to everyone: Blackjack in casinos. So I referred to it as “Twenty One” when using it for recruitment which was a game from our childhood. Well, some of us with the upbringing I had pre handheld electronics.

Four stories to complete in one hour

The fifth story is a bonus if things are really going well.

Pairing

We’d pair on the same challenge with them leading, obviously. Sometimes I’d come out of role to clarify something that was not clear. Sometimes I’d nudge in the right direction, then go back into role. Sometimes I’d have to nudge repeatedly on the same thing.

Test Driven Development (TDD)

One of my agenda-items up front was to do TDD. Sometimes the candidate had not done that before. That wasn’t a reason for failing them. I’d flip to gentle educator on what that was. That we needed to get back to a test would happen in story #1, and could take a few nudges. The best of the “uninitiated but also open-minded” could be a total convert by the end of the hour.

Of course, I’d sometimes caveat that “we don’t always do TDD here, if you do get the job”

Pace

The aim is for four stories complete inside of that hour. That should be with Git commits to a local repo. If there was time we’d carry on to story five, but that only happened once in all the time I ran it: someone who was ex of ThoughtWorks that I’d not worked with personally, but knew of. In the end for them, we offered the open position to them, but they turned us down anyway. Sometimes the candidate didn’t even complete story #1 by the one-hour mark, and that was with help.

Keeping It Fun

I understood that participants might have some trepidations about any “pair programming” challenge, and promise them that they’ll find it enjoyable and engaging. That’s sometimes promised through a recruiter (internal or agency). To make it more comfortable, candidates could choose the programming language they are most familiar with, ensuring they can focus on solving the problem rather than struggling with syntax. Sometimes I am the learner there (like F# a couple of years ago).

What the candidate got

Regardless of the outcome and a potential “thanks for meeting us, but we’re going ahead with someone else this time” later, my hope was always to leave the candidate excited about pairing, TDD, and (maybe) the refactoring menu of the IDE. On that last, sometimes as “pairing partner” I would ctrl-z the last piece, then redo it quickly with the refactoring menu of the IDE.

Well, excitement was my hope for every candidate, and I feel that it happened a few times, but can’t be sure. One thing I’ve always held myself to is never to ruin someone’s day for attending an interview with you. Once in a while someone would email me a month later and tell me how they’d taken some of the things they’d done into their current employer.

Variations

Switch from “twenty one” to a well known algorithm that’d be able to take four stories that built on each other. You might suggest one of the variants I have also used for employers/clients over the years. I’ll not enumerate here so I might bring one back in due course (if an employer agrees) … in a face to face setting only perhaps.