I'm trying to find a devops role, and the interviews I've had are all over the map. As far as I can tell, the closest thing to a devops filter is a SRE filter. A lot of the necessary skills are the same between the two roles, but SREs are more webapp oriented and devops is often internal enterprise work which might or might not include web apps.
The problem is that there's no single definition for devops. Aside from involving automation, companies all mean different things when they say devops. Some companies want to migrate to CI/CD type deployments for their webapp, some want to move to DSC instead of RDPing into everything because they just grew to 1000 Windows machines, and some want to deploy OpenStack because VMware wants to renew their contract at 2x the price. There's no single interview process which can reliably predict a successful hire for all of these examples.
If I were trying to hire for such a role, I wouldn't do whiteboard interviews or look at their github page or any of that. I'd look for flexibility in their career history. The ideal candidate would have two of SWE, system admin, or network administration roles on their resume on a variety of platforms (or all three, like me.) Then there's the security aspect intersecting all of those, and finding someone who's done real whitehat work on top of that is just impossible to hire for.
Like it or not, devops tooling is in a constant state of flux. Regardless of what you're running now, you want someone who can adapt to changing business circumstances on the fly with the best technology they can find. It's not uncommon for the chosen solution to be something no one in the whole company has ever worked with before. You want someone who adapts quickly and learns fast.
As far as interviewing goes, the more mature companies I've interviewed at have had me do multi-hour projects (usually involving Hashicorp products) in a virtual container somewhere. Let them use man pages, autocompletion, etc. Look over their shoulder and have them explain their thought process out loud. Have the candidate do the same things they're going to get paid to do if they're hired. Why would you want to filter them any other way?
Less mature companies do whiteboard interviews about things that you'll never do on the job, usually involving recursion or binary trees. I think the idea is that they're using that as a proxy for general intelligence or CS knowledge, but that doesn't matter if you're trying to add vswitch redundancy throughout your clusters and slinging ruby and XML around all day.