We’ve been doing a lot of interviewing at work of late. You see, we’re looking for good Windows DevOps candidates, and the local market is… well… let’s just say that next-gen Windows guys are a little thin on the ground around here.
This is a problem. Because while next-gen windows candidates are thin on the ground, resumés claiming next-gen Windows skills are emphatically not thin on the ground. In fact, I have actually – literally – lost count of the number of resumés I’ve seen where PowerShell is touted as a key skill, only for the candidate to fail some very simple PowerShell questions in the initial screening. So let’s just run through a few basic principles so that we don’t all waste each other’s time.
Principle one: If you do not know what the pipeline does, you do not know PowerShell
The pipeline is integral to how PowerShell works. If you don’t know what it does, this is a problem, because first of all you’re not going to understand half of what our existing codebase does, and secondly you’re going to write some horrible, inefficient and verbose code that will infuriate your colleagues and make you much less productive than you ought to be.
We like to joke that our developers sometimes “write PowerShell like a C# dev”, which is true. PowerShell is not C#, and the pipeline is a key differentiator. Sure, you can write PowerShell that looks a bit like C#, and it’ll work just fine, but if you want to use PowerShell every day, make it your business to learn about the pipeline and use it. Properly.
Pay especial attention to writing functions that accept pipeline input, because I ask about that in interviews. Or at least, it’s in my list of questions for later. I very rarely get that far.
Principle two: If you do not know how to make an HTTP request in PowerShell, you do not know PowerShell
We live in the era of the API. It’s incredibly difficult to get anything meaningful done in the modern, cloud-oriented, API-centric world of DevOps if you don’t know how to hit an HTTP endpoint from your chosen scripting language.
For the record, In a modern Cloud-oriented shop like ours, you’re going to be typing Invoke-WebRequest and Invoke-RestMethod so often that I also expect you to know the built-in aliases for those two commands – and their parameters – from the get-go. After all, as employers we have a duty of care to prevent repetitive strain injuries.
HTTP is so integral to what a modern ops team does that frankly I’m appalled by anyone who fails this question. Even our Linux specialists know the answer to this. Seriously guys, come on.
Principle three: If you do not know how to use Get-Help, Get-Command and Get-Member, you do not know PowerShell.
PowerShell is internally documented. That means you don’t need to go off to Google to find an answer. You can find that out from within the PowerShell environment, using Get-Help.
The fact that it’s right within the environment also means you can even explore the system programatically. You can do a Get-Help on Get-Help or a Get-Command on Get-Member or a Get-Member on Get-Command and then Select-String on the pipeline for Parameters then drill into that that list for parameters of type CIMInstance or String or Object or whatever .
You literally never – NEVER – need a web browser to find out about PowerShell. Which is why, if you come for an interview and make it as far as a tech test, I check the browser history of the EC2 instance you do the test on, and if I find anything in there, you’ve basically failed.
Principle four: If you cannot describe the Verb-Noun naming convention within PowerShell, you do not know PowerShell.
In fact at this point I’m just going to go ahead and assume you’ve never written any PowerShell in your life, and you’ve only ever copy/pasted from Stack Overflow.
So, rant done, what should one do about this? Criticism is no use if you don’t make it constructive, and I’m not writing this to disparage anyone. I want to hire good people, and I also want you guys to be better at stuff. PowerShell is a joyously fun language sometimes, but if you don’t know it well, you won’t enjoy it. I want people who’ve flunked a PowerShell test to go away, fix their fundamentals then come back and blow us all away. Nothing would please me more.
So, what should a prospective candidate do to ensure they ace the PowerShell questions and end up writing Windows automation for one of Australia’s niftiest Continuous Delivery shops?
First things first: Get over to Microsoft Virtual Academy and do their PowerShell jump starts. Actually do them. Type along with the examples and get your hands dirty. Actually write some PowerShell code as you watch. Then once you’ve done the jumpstarts, watch the advanced sessions and maybe look into DSC.
Try interacting with some public APIs, drag down some data and play around with filtering it and persisting it out to JSON files, then pick up those JSON files from another script use the data to call other APIs. Grab some logfiles from somewhere and fiddle around with parsing them. Package your stuff up as a module. Try some DSC.
Above all else, don’t neglect the fundamentals and try not to rely on Stack Overflow or Google or ExpertSexChange for answers, because those answers might work, but they might also be wrong, or at the least inelegant. Seriously, when you spend all day writing PowerShell, you’ll be glad of the elegant option.
Oh, and one last tip: when I ask you what the most important Cmdlet in PowerShell is, don’t say New-ADUser or I might have you escorted out of the building by security.