To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask how they feel about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask the candidate about their frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask about how they improved documentation at their previous company, or how the documentation they wrote has helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask them to describe an everyday object, and listen closely.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask them about something that you know very well from your own work. E.g. "What is a test automation framework, and what does it really do?"
5 - Ask them to write a manual for an everyday object.
Notes - Maybe your soda vending machine in your office? See the kinds of questions they ask when describing the object. If they do not ask you the right questions, then they will not have the required information to describe it. If that happens, then their description will not be effective.
6 - Ask if they write blogs, GitHub docs, or self-documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code!
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.