The premise that technical people with in-demand skills are hard to recruit has very little to do with the screening process. The screening process is not a difficult problem to solve.<p>The real difficulty in recruiting in this space is <i>finding and engaging</i> these people, not testing them.<p>If this is a Hacker Rank for sysadmins, then great. I'm sure you'll have plenty of users but we're still a long way away from solving the bigger problem.
The Cisco Certified Internetwork Engineer (CCIE) certification used to be <i>the</i> gold standard amongst network engineers 10-20 years ago.<p>Becoming a CCIE required a passing a notoriously difficult hands-on 8 hour in-person lab examination[1]. SysAdminsArena reminds me of a remote version of the CCIE Lab Exam for sysadmins.<p>Fun fact: the CCIE program was established in 1992 and was originally going to be called "Cisco Top Gun"[2], but they had to choose a more serious name.<p>[1] <a href="https://learningnetwork.cisco.com/community/certifications/ccie_routing_switching/lab_exam_v5" rel="nofollow">https://learningnetwork.cisco.com/community/certifications/c...</a><p>[2] <a href="http://www.bradreese.com/blog/how-the-cisco-ccie-program-was-born.htm" rel="nofollow">http://www.bradreese.com/blog/how-the-cisco-ccie-program-was...</a>
There's been a lot of criticism of hackerrank.[1][2]<p>Are you doing anything to make sure your service gets more respect?<p>[1] - <a href="https://news.ycombinator.com/item?id=12825953" rel="nofollow">https://news.ycombinator.com/item?id=12825953</a><p>[2] - <a href="https://news.ycombinator.com/item?id=12667174&source=techstories.org" rel="nofollow">https://news.ycombinator.com/item?id=12667174&source=techsto...</a>
So this is to have a test VM they have to fix? Excellent! I heartily approve of this method for finding a sysadmin.<p>This is a thread where I talk about how we did this: <a href="https://news.ycombinator.com/item?id=8332104" rel="nofollow">https://news.ycombinator.com/item?id=8332104</a><p>We used to use it a lot - a trivial Java webapp running in a slightly misconfigured Tomcat with a slightly misconfigured Apache in front on a slightly misconfigured Unix box - though it's fallen by the wayside because we never quite get around to the faff of setting up a slightly broken test system for them. So having that as a service would be pretty good.<p>If this is what you're doing: I suggest not just keystrokes, but that they keep a log of what they're doing and thinking. Because we never expect them to fix <i>everything</i> wrong with the box, but we do want to know how they approach it.
Speaking of sysadmins, a note for yours. You are currently serving blog.sysadminsarena.com over HTTPS with an HTTP to HTTPS redirect, but are not doing the same for your website. In fact, you don't have an HTTPS endpoint for your website at all. Going to your website by modifying the URL from the blog entry (because clicking your logo takes you to the front page of the blog, not the website) results in a `ERR_CONNECTION_REFUSED`.<p>Just an FYI :)
Interesting problem you're addressing but I've been working on this problem from a completely different set of metrics. Fundamentally, I really don't care how a problem is fixed as long as it doesn't have bad repercussions. If a web server is "slow" users don't care why - giving freedom to admins to approach higher level problems while still measuring them is something I'm confident that can be done while I take a number of issues with assessing anything based upon commands entered even in realtime (I'm mostly concerned from a security / bad or illegal practices in prod perspective, to be frank).<p>The approach I'm working on is easier to do technically but requires some more costs.<p>With that said, glad to see I'm not the only one that's been frustrated with hiring devops / sysadmin / SRE roles. Google's even commented how hard hiring for SREs is for them and I think we have a huge gap between people stuck in the 90s approaching systems and those that modernized.
Isn't everyone hard to recruit? The difference in perception of coders might be that the evidence for a bad recruit is obvious in the code they produce. There could be many bad recruits in all other areas but are less obvious.<p>I generally like the idea of clearer quantification of a persons output but it should be done very delicately. As in, if you are going to measure everything someone produces, maybe that data should only be available to that person and it's up to them how they share it.<p>The uncertainty principle likely applies to people too. Hard to measure people without influencing them. Trick is to do it in a positive way. Managers measuring people for the purpose of firing them would be perceived, and have a negative effect on morale, than measuring people to identify opportunities for education, training or skills development.
When you have a very low supply of high quality people, and at the same time a huge demand for those same people, it is a major problem. You claim to solve this problem, by making it even harder? How does that help?