Software coding is never easy. We all know that. But what if you were given a challenge? In particular, what if you were asked to write a program to generate a maze, using any language you like, from Python to SQL to C#? The only constraint? To be able to demonstrate what you’ve done, and how you did it.
We did it as part of our drive to find people who can write great code to solve real problems. Forget the CV or the redbrick university, the formal advertising for a job and the rigid application process. We wanted to have some fun while discovering people who can write code that surprises us for its visualization capability, or its terse implementation, or its ingenious simplicity. You get the picture.
That was the plan, but what happened? Did anyone take up the gauntlet?
The Redgate Coding Challenge winners
They did. In fact, dozens entered the challenge and our hardest task was deciding who the winners should be. Every entry had merit, there was really clever thinking, and some people literally amazed us with their code (and we had some heavyweights on the judging panel including Jeff Foster, Head of Product Engineering at Redgate, Andrew Hunter, Redgate’s .NET expert who came up with the idea of the challenge, and Chris Whitworth, Software Engineer).
Best Visualization: Ollie Dawes
Ollie Dawes took home the coveted Parrot Bebop 2 Drone because his entry really did surprise the judges, who commented:
“Just stunning. I mean, look at it. Also a really genuinely innovative and unusual approach to generating mazes, using protein-folding simulation as a jumping-off point. Completely unlike any other entries we received. We were genuinely blown away by this.”
You can see Ollie’s thinking behind his idea on his own website.
Tersest Implementation: Jonathan Gough
Jonathan Gough said of his own entry that it wasn’t the shortest possible maze program, but nevertheless a tiny ‘hard’ maze. Our judges agreed and commented on the four lines of code (yes, there are just four lines of code):
“Even when un-minified, it was a remarkably compact and neat implementation of a maze generator.”
Ingenious Simplicity: Matthew Arcus
I wanted to win the Sphero BB-8 Droid for Ingenious Simplicity, but I can’t code. Fortunately, Matthew Arcus stepped in with his solution that looks like something from a sci-fi movie. The judges commented:
“Leveraging some previous work he’d done using Three.js to visualise polyhedra, this was a very neat way of generating impressive-looking mazes from OFF model files. The insight that the edge geometry of the models was a space that could be explored was ingeniously simple, and the results are suitably impressive.”
Find out more about his solution on his 3D mazes website.
Rube Goldberg: Lee Chapman
A Rube Goldberg contraption is one deliberately over-engineered to perform a simple task in a complicated fashion. Lee Chapman earned his reward of a Steampunk flash drive for his mazes based on a tessellation of squares and triangles. The opinion from the judges was:
“Although not really Rube Goldberg, in that the code is actually clear and well structured, Lee used an unusual approach compared to everyone else that I really liked. He constructed a tesselation geometry and then used maze generation algorithms to explore that, rather than just using the straightforward 2D grids that most other entries used. It’d be fun to see what other kinds of mazes could be constructed by building other tessellation descriptions.”
You can find out more about how he did it on his website.
There were lots of other entries, but the judges particularly want to mention Milosz Krajewski, Tomasz Swider, Dean Coakley and Richard Jones for their efforts.
“Milosz wrote an excellent series of posts on implementing a large number of maze-generation algorithms in various functional languages (F#, Scala and Kotlin). Really interesting reading for anyone interested in algorithms, functional programming or maze generation in general. The stack-shaking trick for increasing the branching factor in the randomised DFS implementation was really nice.”
Tomasz took a different approach and shows on his website how to generate a maze based on an image (my favourite is the Mickey Mouse one). The judges commented:
“A really creative solution that attempts to incorporate a supplied image into the maze itself. We liked this a lot.”
Dean explains on GitHub how he developed MazeGenerator, a simple maze generator using Kruskal’s algorithm and a Union-Find data structure. The judges really like it:
“Dean’s implementation of Kruskal’s algorithm in terms of merge-find sets was nicely explained and a good implementation. Dean’s solution also has nice rendering – he was the only person to have customisable tiles.”
Finally, Richard Jones took yet another angle by creating the maze as a web page, as he outlines on his GitHub page. I love this one because he also created a website where you can generate a maze online … and then get it to cheat for you by showing the solution. The judges said about his entry:
“We received a number of entries that did something very similar to this – animated the maze generation algorithms – and this one stood out for it’s nice, clean presentation and also the animated demonstration of the A* search for solving the maze afterwards.”
We ran the coding challenge because we like coding and we like talking to people who code. Generating mazes sounds simple, but as you can see from the entries above, there are lots of ways to do it, and some of them can be as complicated as they are fun. We’ve also ended up talking to many people about working at Redgate so in the end, we got the best of both worlds. We encouraged people to code, and people were encouraged to talk about coding for Redgate.
We’ll probably run another challenge next year, so watch this space.
Also in Blog
Whether you’re exploring the advantages of DevOps or already fully immersed in the journey, including the database brings additional advantages. But how are you performing compared to the competitio...
Also in Software development
Slow, unreliable tests prevent teams doing great work, and make continuous delivery impossible.
This was true for our SQL Source Control team when I started working with them. From pushing a commit t...