Good code is good code, I don't agree that it takes a vastly different skill set to work on different sized programs. During the interview you can simply ask questions such as "How would you provide the ability to configure various strategies for different users interfaces for this slot machine? Say a web UI, a command line UI, and a native app UI?". "How might you make the randomizer for spinning the slots configurable?". The discussions these open up will tell you a lot about their knowledge of making flexible software.

Again, the test is just to weed out the bad candidates and allow you to only interview worthy people, everything else you'll find out in the actual interview. Interviews will be rare, few people will submit code you'll find acceptable at all. The vast majority of people applying for programming jobs, can't program, it's sad, but true.

There is a set of skills and body of experience that applies to working on large bodies of code. In fact, there are different skill sets for working on bodies of bad code and good code.

You'll note I said vastly different, I didn't say there was no difference.

The language syntax may be the same, but programming approaches might be very different. I've seen parts of a Smalltalk program where it was coded like spaghetti copy-paste Fortran, and it's actually hopeless to try and fully understand the semantics and still meet your deadline. But I was able to use a few tricks to prove that certain modifications wouldn't alter other functionality so I could get my work done. In the same program, there was well factored code with a nice object model, where it would behoove you to understand the part you're working on in a more conventional way.

On reflection, I think you may be right that good code is good code. Size of the system matters most when the code is bad.