You need to come up with your own questions, because the ones you get on the Internet tend to already have canned answers on the Internet. (Interview candidates read this site too.) Presumably you want your candidate to give you an answer they've thought about, not just something they memorized.
You need to be specific about what you want, and that should drive your questions and your hiring decisions. Manual testing and automated testing are two different skill sets, and automated testing can mean a lot of different things.
For manual testing, I like to ask broad questions that don't have single, correct answers, because testing is as much a way of thinking as it is the application of domain-specific knowledge. To reduce bias, you should vet the questions ahead of time, and discuss what kinds of answers you are looking for.
For automated testing, the questions depend on the kind of automation you are interested in. You might need to decide whether UI automation is important to you. Decide whether you want them to write unit tests, or other tests that use the same programming language that you use for the product. Decide whether you want them to write performance tests. It isn't enough to say, "I want them to be able to do anything.". You probably won't find generalist who wants to test, so you need to prioritize what you want from them.
Once you have priorities, you may be able to apply what you know about interviewing developers to interviewing a test person.
Broad questions with no single, clear answer are good for automation candidates too. Again, you should vet the questions ahead of time, and you should decide what kinds of answers you are looking for.