> I think pulling specific ideas from your actual system is full of traps. These are probably problems you've thought of - both actively and passively - for days, months, or even years.
The first time you give the interview certainly, but you have time to formalize and tune the interview. Write down what you're going to ask, what signals you're looking for, the quality of a solution you expect. Socialize this with engineers who weren't directly involved in the design of the system, ask for their feedback.
You can usually iron out a question in 10-20 interviews and make it really stellar within a 100. I know that's a lot of potentially wasted hours, but the ROI in terms of candidate quality is worth way more.
That part about "write down the question" and the "what are you looking for" is a rather important part that most people ignore and just wing it.
By having that rubric down it becomes easier to make the objective choices (that can be backed up with HR). Additionally, that same question (with the same rubric) can be used by other interviewers for other candidates and overall, you would hope that the same candidates would get the same thumbs up / thumbs down evaluation no matter who asked the question or considered them.
The first time you give the interview certainly, but you have time to formalize and tune the interview. Write down what you're going to ask, what signals you're looking for, the quality of a solution you expect. Socialize this with engineers who weren't directly involved in the design of the system, ask for their feedback.
You can usually iron out a question in 10-20 interviews and make it really stellar within a 100. I know that's a lot of potentially wasted hours, but the ROI in terms of candidate quality is worth way more.