Q:

How do I hire a good DevOps, fitting my company?

Good developers should fit rule 11 of the Joel Test:

Do new candidates write code during their interview?

However, I know little to nothing about Docker containers, how to configure Jenkins or AWS, etc. What would be a good way to test if the person who applies can manage such tasks?
Sub-questions: I believe that a good devops employee can configure the build chain once and it should work from then on out. Can I then also expect him or her to be a developer in the company (DEVops)? As DevOps is a relatively "new" job, is it maybe better for small companies to share a devops employee or hire him or her as a freelancer whenever you need him or her?

My confusion about the term originates from job offers like this, even here on stackexchange (= link where above screenprint was taken from).
I found this helpful, but possible opinionated article you might want to read if you stumble on this question: https://hackernoon.com/devoops-some-common-anti-patterns-1850ac2f5074

A:

It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies, this shift can be shortly described by the “You build it, you run it!” coined by Werner Vogels:

There is no need to distinguish between building and running, and according to Werner Vogels, it is much better than that:

Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

This lesson is interesting, but this particular change in an organization is not always easy to implement.

This shift is concomitant of an increasing importance of continuous integration and deliveries methods. Please note that these ideas are much older than the formalisation of “agile” methodologies, some of them are already present in the NATO Scientific Committee report about software engineering published in … 1968!
While the wording can be overlooked, the short description of the DevOps proposal (this site) mentions “software engineers”:

Beta Q&A site for software Engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure.

Now if you are looking for a software engineer that can help your team getting started with these methodologies, engage them on this topic. Even if you are not familiar with this topic, following the “You build it! You run it!” slogan you can start from a programming problem and lead the interview towards question about deployment and maintenance of the application.

A:

At the risk of getting vote down, off-topic  or even heresy, I going to tell you, 
"Don't listen to the purists telling you that DevOps is not a role."
You are on the right track. It should fit your company. That's what matters when hiring.
If you need a DevOps, to work like a DevOps, produce results like DevOps, it is a DevOps. 

Don't let anyone dissuade you otherwise.
Advertise anyway.
Interview anyway.
Hire anyway.

While at that, find out more about DevOps, how the concept can fit into your company, how does the person fits in.
Distill out more about the role you need to fill. Search for questions you can ask. There are plenty of example, even if you are not subject matter expert. Some good old-fashioned patience and hardwork.
Do you need an employee? Or freelancer? A jack of all trades? Only you know your company well. 
Create your unique culture that is your interpretation of DevOps.

A:

"Hiring a DevOps" will be tough because DevOps isn't a role.  IF you can find an engineer with software development and engineering skills, you're on the right track..
However,
Your hiring process will be complicated by a few factors:

Site Reliability Engineers (Google's term for admin/engineers with coding skills) are rare
Rare skills are expensive
Rare skills are... rare.

The good news is you may not need a fully qualified SRE.
Your use case, as it were, is hiring engineers to establish your infrastructure (AWS) and automate deployments (Jenkins.)  Those skills are not all that rare, but you may have a challenge finding them in a single person.  
You also mention that you yourself don't have those skills.  This is a further complicating factor.  You don't have the skills necessary to evaluate the skills of your candidates.  You must ultimately find a way to develop (or hire, as in an Engineering Manager) the skills needed to manage this type of resource.

