I think you pretty much got it there. There really aren't many ways to improve it, our best method is a slow one! (though our human brains instinctively would love to find something better for such a simple problem)
Though I'm imagining, when I think of recursive back-tracking, I think of an algorithm to solve a rubiks cube, or a sudoku puzzle. Which is just brute-forcing the problem, and it'll be slow no matter what. There are millions or billions or pathways to check, to see if we get a solution, and even then we might not get the best one.
However, if you're willing to step away from recursive back-tracking, there are some algorithms that will "smartly" try to find you a good answer really efficiently. Imagine when a human tries to solve a rubiks cube, they don't try every combination possible.
Computerphile has a good video on it: https://www.youtube.com/watch?v=ySN5Wnu88nE
The general idea of it, is you model all of your possible options/choices/moves as a massive decision tree, or graph. You're attempting to find the shortest path from the start, to the solution, but because we don't know how far away from the solution we are, we have a heuristic function, which gives us a guess of how far away we are.
This is the A* algorithm, almost like a Dijkstra, but it involves our heuristic function.
We selectively explore the paths which we guess will find us the solution the quickest. I applied this to a bubble sorting game once, my brute-force would explore 100000 different pathways and give you the BEST solution which takes only 9 steps to solve the game. But my A* algorithm with a good heuristic would explore 100 pathways, and give you a really good solution (but not the best), which took 10 steps. 1000x faster, but not guaranteed to be the best solution.