help me describe the IT worker that I need, then evaluate the candidates

It reads like a junior sysadmin position to me, and you could emphasis in the job description the communication requirements. Off the top of my head - "In addition to the sysadmin requirements, this job also requires collaborative problem solving with both technical and non-technical people alike, and communicating proposed solutions in a manner understandable by everyone." For the interview, I'd warm up with the basics, basic sys-admin type questions. Thais is where you test their knowledge of all the tailing, grepping, rpmming, sshing, etc that you care about. If they fail here, you're done. If they do ok, you can move onto the next phase of the interview. But keep in mind the specific details of the usage of rpm (or whatever) are easily looked up and learned, and are not the definition of pass/fail. This is the crappy part of interviews -- if i was at my desk, I can use man pages to my little hearts content, as long as I know what i'm looking for. Not so much in an interview or on a whiteboard. For this second part, I'd propose to them some of these real life problems (sanitized as necessary) and ask how they'd solve them. The actual solution they come up with is at best only equally as important as the questions they ask to clarify the problem, so you can be a little deliberately vague or unclear, as non-techs (and techs as well) sometimes are. I'd say here you care more about how they think and how they communicate the solution to you than the actual solution itself (unless it's completely bonkers, of course).

linux sysadmins don't point and click. you are safe to use this description, imho. i would ask some questions related to: how environment variables are set what /proc is all about how to secure mysql/postgres monitoring of system limits on space/files/memory

I suggest you check out this https://www.usenix.org/lisa/books/job-descriptions-system-administrators-3d-edition book. The https://www.usenix.org/system/files/lisa/books/usenix_22_jobs3rd_core.pdf chapter is available free, on-line, and might serve as a useful jumping off point.

Lots of really good stuff on serverfault such as this http://serverfault.com/questions/3270/how-to-interview-a-sysadmin-candidate

In addition to the idea of whiteboarding an answer to a programming question, maybe also have them respond to a typical support question so you can get an idea of how they explain things to a less technical user.

I would just use the position description to generally describe that you're looking for a junior Linux sysadmin (along with the support skills, soft skills, etc...) rather than specifically listing things like familiarity with the file system, permissions, file handling, etc... Similarly, if I were to hire a Rails developer to work on a web application, I'd just say that in the description, but I wouldn't include details like "read parameters from http requests" or "output potentially relevant information to application logfile." Once you get applicants, you can phone screen them for basic technical knowledge. If they don't know what /home is, you can be rid of them very quickly.

I don't want to list "Linux administration" because I'm afraid that someone who's done point-and-click admin on some graphical OS will think they are qualified. This is what we have phone screens for. But if you really don't want to use the term Linux administration, what about Site Reliability Engineer? Cuz really, "site" doesn't have to be a website, if that's not what you're supervising. As far as evaluating candidates, we have some questions of the following nature: 1. Here's the output of a ps command; explain what each process is doing. 2. Here's some sample output from netstat, and a pipeline using sed, awk, grep and other coreutils. Walk us through it, and explain what the output means in English. 3. Explain what happens when a user types in www.yourdomain.com into a browser and presses enter. Finally, as far as motivation goes, a lot of that is up to management (which sounds like you?). Set some quarterly goals, and discuss how they contribute to the organization's mission, and give positive feedback for jobs done well. Maybe even rewards.

I agree with everyone that junior sysadmin with people skills is a good description of the position. Have you personally done much hiring before? Something that I got wrong, then got better at, was listening to my instincts about the person; tbh, the technical capabilities for a job position are the easiest part to check for - do a few whiteboard tests, ask them how they got the skills and what they've used them for in the past, and you can be pretty sure whether they've got experience or are just bluffing/remembering last night's cramming. You get a much better sense of whether someone's right for the job by talking about almost anything else. Depending on the candidate's age, I ask about how much they enjoyed their degree course, whether they do anything recreational with their tech skills, what they learned at their last job that wasn't related to the mechanics of doing their job, that sort of thing. You'll warm to some candidates, and be cool on others. Trust that instinct, at least to the extent of deciding between two people who could both do the job and the one you like more looks worse on paper.

At least at the places I've encountered it, Site Reliability Engineer is a senior sysadmin++. It's someone who has serious sysadmin chops as well as software development skills (well beyond just scripting). Maybe it varies, but the SREs I know would be extremely overqualified for this. Junior sysadmin sounds about right to me.