Seu maior objetivo na contratação de um administrador de sistemas deve ser evitar um charlatão. O produto de trabalho de um administrador de sistemas é um conjunto de sistemas em interação que não está desmoronando, o que pode ser conseguido sem tocá-lo ou sendo bom em seu trabalho, para que um charlatão possa andar de skate sem precisar tocar em nada por alguns meses, se eles se esforçam para evitar ter que fazer alguma coisa. Quando pressionados, no entanto, eles falham, e você fica preso com uma merda quebrada para consertar.
Pense em um desenvolvedor que falha em verificar seu código nos primeiros dois meses de trabalho: é um caso simples de práticas de codificação ruins / anti-sociais, ou eles estão escondendo o fato de que são ruins? Os administradores de sistemas estão em uma posição semelhante, exceto que raramente existe o grau de controle de alterações para a codificação. As ferramentas de programação de sistemas, como o puppet, são boas para corrigir isso porque (se forem usadas como o único meio de administração de sistemas), elas podem tratar a configuração do sistema como um projeto de software e você usa as mesmas ferramentas de auditoria que usaria com codificadores (por exemplo, confirma mails).
Na minha experiência, certs são irrelevantes na melhor das hipóteses e enganosos na pior das hipóteses. Nunca, jamais, contrate alguém com base nos pontos fortes de suas certificações. De todos os currículos que eu já vi, as melhores pessoas técnicas não colam logotipos de certificado, quando os possuem, em um currículo - é um grande sinal de que alguém depende mais de seu pedigree do que de suas habilidades reais. As provas de prova escrita são perguntas de palpites múltiplos, baseadas em verbos específicos do livro didático em que se baseiam. Estou confiante de que entendi o RFC4601, projetei e implementei um sistema multicast seguro e global entre domínios e recebi 67% da última vez que fiz um exame prático do CCNA. Enquanto isso, meu subordinado de segundo nível com certificação não pode grok que não há nenhuma funcional diferença entre RFC1918 e endereços públicos ...
Ao contrário do que outros disseram, currículos mais longos são melhores que os mais curtos: eles fornecem perguntas mais específicas para pesquisar e fazem perguntas na tentativa de evitar charlatães. Faça entrevistas por telefone em vários níveis, se for necessário: use o primeiro para mostrar o que eles estavam realmente fazendo e o segundo depois de descobrir quais são as perguntas certas para as tecnologias fornecidas.
Seu segundo maior objetivo deve ser encontrar alguém com experiência nos sistemas que você já está usando. Encontre alguém que tenha lidado com os problemas que você está enfrentando agora ou que possa enfrentar no futuro (crie sistemas e métodos de implantação, sistemas de monitoramento, segurança, dimensionamento). Procure contratar alguém que tenha trabalhado em situações comerciais semelhantes às que você tem agora e esteja preparado para lidar com os problemas inerentes à sua situação. Um engenheiro com um MS em rede que está acostumado a ter orçamento ilimitado, departamento de compras e ciclos de projeto que duram um ano não vai funcionar em uma startup. Por outro lado, o anarquista do Linux não se sairá bem quando for solicitado a sofrer o procedimento de controle de alterações do ActiveDirectory no seu Fortune 50.
Se você precisar criar um departamento à medida que cresce, não contrate alguém que não tenha contratado ninguém antes; se você precisar lidar com 20 TB de dados altamente disponíveis, não contrate alguém que nunca usou uma SAN antes, etc.