If by REST you mean full on HATEOAS then I definitely would not use that as an interview test. Advocates tend to be religious in their intensity, yet few real world APIs are full REST in that sense. Discussions around HATEOAS could be enlightening but requiring people to buy into it not IMO.
I would structure interview questions around APIs rather about distributed systems/transactions, circuit breakers, etc. - practical aspects of running multiple systems talking to each other through pipes.
I let candidate design an API for a problem we solved in real life (and compare their API to the API and db I designed). It really isn't about HATEOAS purism, we chose REST simply as an abstraction candidate should operate in, but they're free to break some principles if they like (for caching etc we already break it). We're mindful of these and are very lenient with candidate's answer. As long as they can show signs of being able to solve the problem in real life, they're good to go. I should note that we use this question mostly for junior candidates, and this is the very final round of interview so all candidates will be asked ~6 45min questions and this is only one of them.
I would structure interview questions around APIs rather about distributed systems/transactions, circuit breakers, etc. - practical aspects of running multiple systems talking to each other through pipes.