Unless you have a lot of experience working with testers, read the first few chapters of Cem Kaner's "Testing Computer Software" to get a feel for the kinds of terms you want to hear: Boundary testing, error testing, happy path testing, functional, performance, security, integration, etc. If you can't speak the language, you won't be able to conduct a good interview.
Give them a spec for a small piece of your system. Ask them to test it. You are looking for organization of thought and their ability to come up with interesting tests. You want to see them break apart the areas of testing in an orderly way, and then drill down into each area, devising more and more interesting test cases. Really good testers can do this for hours with all but the most trivial problems, so you might need to cut them off and have them move on to another category to get a good feel for how they think.
Describe the behavior caused by a real bug in your system that was kind of hard to understand. Ask them what they would do if they saw this bug while testing. Here, you are looking for bug reduction - the ability to find the simplest set of circumstances that can reproduce a bug. This makes debugging much easier for devs, since they have a better guess about what caused the issue, and demonstrates a clear ability to problem solve and a clear understanding of what factors can interact to cause bugs. With your specific product, discussing a race condition might be fun.
Give them a simple command line program you hacked together (maybe seeded with bugs) and a simple spec, and let them sit down at the computer and play with it, with the goal of finding issues. Here you are looking for creativity and the ability to target trouble areas. They should test things like large inputs, small inputs, weird inputs, empty inputs. If they find a bug, ask them to try and figure out exactly when that bug happens (again with the bug reducing!).
Ask them what they would do if an SDE responds to a bug with "No Repro" or "Won't Fix", if they thought the bug is important. Here you are looking for someone who won't just be a pushover, but also won't be antagonistic. Reasonable responses include adding example scenarios that demonstrate more clearly the severity of the bug and then reopening the ticket, talking with the dev to try to understand why things were resolved this way before closing, etc.
Talk to them about your application at a high level. Ask them what kinds of testing they would want to perform. Here you are looking for general areas of testing like functional component testing, integration testing, performance testing, security testing.
If this is an SDET / automation engineer, give them some interview questions for devs with roughly 1/3rd to half their total years of experience.
If this is your first QA person, make sure they can self-start. Ask them what they imagine their first week to month of work to look like. They should say something about gathering requirements and setting up tools, then describe a reasonable approach to getting started on testing. You're looking for someone who doesn't need a boss to tell them how to start testing and can self-manage. If you already have QA staff, this is less important.