One thing I would do is to stay away from terminology. I remember I had a pretty good grasp on the differences between pointers and values before I knew what semantics even meant. Of course, if someone knows the meaning of value semantics, you can save a lot of dancing around. The point is, even people who don’t can be competent. So my way of talking about value/reference semantics is assigning a value into another variable, changing the first one and then asking how the second one changes and why.
I would also be careful with implementation details such as COW. Of course, without COW Swift would not even get off the ground, but from a simple programmer’s viewpoint things just magically work & work fast. Not having to care about the language implementation is good.
With Swift in particular, I think the difference between structs and classes is a good topic, naturally leading to value/reference semantics, structural/referential equality, composition, inheritance, immutability and other important topics with far-reaching consequences.
Also the concept of optional types is a good one IMHO. It’s no rocket science, so you can quickly separate beginners. If you allow a little psychology, I have noticed that experienced programmers tend to get a bit misty eyed on the topic of optional types, probably in memory of the long, dark hours spent debugging stupid bugs with nullable pointers :)
Error handling is a good way to judge API design. Can the candidate choose well between trapping, optionals and throwing? (Pro tip: You may also spend a day or two arguing about the best way to design a Result type ;–)
My favourite topic is state. Ways to minimize mutable state, ways to get explicit state transitions, ways to share state, etc. But that’s a lifetime hobby, so it may be more practical to approach it from a particular point, like singletons, for example. Does the candidate know the pattern, does he know what’s problematic about it, how to build without it?
So these are my random tips, hope you will find some of them useful.