My PowerShell experience has been gained in roles that typically have a mash of other infrastructure skills, Hyper-V, vSphere, all things Windows (and sometimes Linux). It is not often you see dedicated PowerShell development roles come along, like you do with Python for instance. Last year I had the opportunity to apply for such a role which got me thinking that it could be a good topic for a blog article.
You may need to be patient for the right thing to come along. My experience of this process that there were often jobs that would be advertised as some sort of “PowerShell” automation role, but upon closer inspection they were clearly infrastructure with some PowerShell.
First and Second Round Interviews
Have a CV ready. I won’t give CV writing advice as there is plenty of that out there already. However, if you came from an infrastructure background you may want to consider refocussing your CV to be more PowerShell centric. Remember you are advertising your good work and experience, but never put anything on there that you cannot talk about in more depth later on.
It is a great idea to have a blog and a GitHub. Put these on your CV. Allowing a potential employer to look at work you have produced is an excellent way to convince them you should come in for interview. A body of work takes some time to accumulate, so it’s something you need to start thinking about well ahead. Many companies value people who are “community contributors”.
It sometimes pays to do your homework on the people interviewing you. Have a look at their LinkedIn profile, do they have a blog, GitHub or contribute in other ways? What are their areas of interest? This might reveal how the line of questioning will go.
Different companies will have different approaches to interviews, and there is never any harm in enquiring to your recruitment agent or HR representative what the process might be. That said, in my experience there are typically 3 stages:
- Firstly, a general (and usually short) interview with an HR person. This is often referred to as the “sift” and should be straight forward and informal conversation about your background, salary expectations and possibly why you want to work for the company you have applied to. Nothing really to worry about here.
- Secondly, an interview with the hiring manager. This will usually be non-technical to sometimes moderately technical (not always intentionally, techies like to talk about tech). It is likely they will want to talk through your CV, your previous projects, skills and experience. This is their chance to get to know you a little bit and to make sure you haven’t made up a lot of stuff on your CV 😉 Just as importantly, it is your chance to get to know the person you might be working for and to get a better understanding of what you might be doing on a day to day basis. You may get asked BEI style questions, you might get asked how you would approach developing a new solution, how to fix something that’s blown up, or how to eliminate risk in automation (most of us know at least one guy that binned Active Directory with a PowerShell script). As this is not the focus of this post, I’ll let you do your own homework.
The Dreaded Third Round Technical Interview
Definitely this will vary from company to company, but I would expect a “talk the talk” and a “walk the walk” style components, i.e. a technical verbal chat and then a coding exercise of some kind.
As a short aside, a company advertising for PowerShell skills will get many applicants who think using PowerShell as a command shell means they know PowerShell. One place I worked used this piece of code as a simple test:
$a = 1
if ($a = 2) {
Write-Host $a
}
else{
Write-Host $a
}
The question asked would be “what number will be written to the screen?”. Anyone who has done any development with PowerShell would notice that an assignment operator has been used in the IF statement, not a comparison operator 😉
The Technical Chat
This is the piece where you can really prepare well, and preparing well takes a lot of the stress out of the situation. That will come later in the coding exercise 😂 Assuming you know your subject, I always find it useful to ask myself what I would ask someone at interview. The majority of the time, you will come up with a list of questions that you will likely be asked yourself, and therefore be able to prepare for. PowerShell is no exception, and there is a limit to the number of things you could reasonably be asked at interview.
This will not be an exhaustive list, and I will endeavour to add to it as I think of things, or people suggest them.
Advanced Functions
Be able to talk about Advanced Functions and why you would use them. Some important points might be:
- An Advanced Function uses the CmdletBinding attribute.
- They behave more like native Cmdlets than functions.
- They allow for parameter validation, for example Mandatory, ValidateScript, ValidatePattern and ValidateSet.
- They support PowerShell standard output streams (more on these later).
- They allow for safeguards in the form of -WhatIf and -Confirm.
- They support PowerShell common parameters, such as -ErrorAction.
- They may feature a Begin, Process and End block (and more recently, a Clean block).
Some useful resources:
- Adam Driscoll – PowerShell Advanced Functions
- Arcane Code – Fun with PowerShell Advanced Functions
- Microsoft Learn – PowerShell Advanced Functions
Loops
Be able to talk about the various PowerShell loop constructs and where you might use them:
- For
- While
- Do-while and do-until
- Foreach (and know the difference between this and the ForEach-Object CMDlet, discussed later).
- Understand Break and Continue statements.
Some useful resources:
Error Handling
This can get quite in depth and honestly, I’ve never met anyone who knows all of it back to front, and we all have our own preferences on the subject. I would recommend having a working knowledge, and try some things out in a code editor for clarity. Some points of note:
- Write-Error adds a non-terminating error to the output stream.
- Non-terminating errors are not caught by a Catch block.
- Throw creates a terminating error.
- The -ErrorAction Stop common parameter makes all errors terminating errors.
- Use Try/Catch to handle exceptions.
- $_ or $PSItem in the catch block records error details.
- You can throw typed exceptions and use typed exceptions in a catch block.
There are many resources but this one by Kevin Marquette is my go-to reference on the subject, it really is excellent:
ForEach-Object versus Foreach
It’s an interesting question and may come up, some points I have noted on this:
- ForEach-Object is a CMDlet.
- Foreach is a loop statement.
- ForEach-Object can be used in a pipeline.
- Foreach loads all items up front in a collection for better performance, but higher memory consumption.
- ForEach-Object is like a mini advanced function that can be integrated into a pipeline.
- You may want to investigate the new ForEach-Object -Parallel functionality in PowerShell Core.
- You may also want to be aware that there is a ForEach method.
Some useful resources:
- Microsoft Dev Blog – Getting to Know ForEach and ForEach-Object
- SS64 – ForEach (Method)
- Microsoft Dev Blogs – PowerShell ForEach-Object Parallel Feature
Scopes
Scopes are something you should know about:
- PowerShell has the following scopes:
- Global
- Script
- Local
- Scopes nest within each other. The outer scope is the parent scope, any nested scopes are child scopes.
- An item is available in the scope where it is defined and any child scopes.
- Use scope modifiers to set a variable scope.
Resources:
Help
How do you explore a new module or function? How do you examine discoverable items? How do you find what inputs and outputs a CMDlet or function has? Why is this important when writing you own functions? Know how to use:
- Get-Command
- Get-Help
- Get-Member
Resources:
Classes
In my view, PowerShell Classes have comparatively niche use cases. They are also a big topic. Personally, I wouldn’t spend hours learning about them, but it pays to show you know the basics allowing you to build on that if needed. Try some examples out in a code editor and at least be able to say what a class is and why it might be useful.
- Classes are used to define custom object types.
- Classes can inherit from parent classes.
- Classes have a constructor to instantiate them.
Resources:
- Adam the Automator – PowerShell Classes: Getting Started
- Arcane Code – Fun With PowerShell Classes – The Basics
Output Streams
Output streams are certainly something you should know about and be able to list and describe. Again, it’s always worth opening a code editor and trying out some examples. Also be aware of “output stream redirection”.
- Success
- Error
- Warning
- Verbose
- Debug
- Information
- Progress
Resources:
Modules
You should know the anatomy of a PowerShell module. There is a certain element of style and personal preference to this, but generally speaking a module has:
- A manifest with a GUID, author information and what functions to export.
- A root PSM1 module file which executes when the module is imported.
- Public and Private functions.
This is one of my favourite articles on the subject, as always it’s worth trying out some samples for yourself.
The Pipeline
You should be able to describe the PowerShell pipeline and how to use it:
- Inputs accepted ByValue or ByPropertyName
- Use Get-Help to see what a function supports.
- The Process block is required to keep processing objects
- Pipelines process one object at a time.
Resources:
Common Parameters
These are parameters that can be used with any CMDlet or advanced function. There are too many to list, but take a look at the Microsoft documentation.
PowerShell for Windows versus PowerShell Core
As time goes on this becomes less and less relevant, but I still see people using PowerShell for Windows. The reasons for using it are diminishing rapidly, but you may come across the occasional module that is Windows native.
- PowerShell Core is built on .NET Core.
- PowerShell Core is multiplatform.
- PowerShell for Windows is essentially deprecated. There will be no more bug fixes, security updates or feature additions. To me, writing code in PowerShell for Windows means accumulating technical debt.
In general terms, an interview panel is not going to expect you to know everything. However like any technical topic, there are some core questions that will likely come up (anyone that has been to an Active Directory interview will know the AD FSMO roles by memory). An interview panel will also likely be looking for someone that has spent a bit of time preparing (within reason). Open a code editor and just work though examples. Create a “cheat sheet” and have it nearby at all times so you can run through it when you have a spare few minutes during the day. In my case, I gave it to my wife who would randomly ambush me with questions.
The Technical Test
I have seen this done a couple of different ways.
Some companies will give you an assignment to complete in your own time, and then bring the solution to the interview. I suspect that now we are in the AI era that this approach may be less favourable, time will tell. However, be prepared to not only have questions asked about your code, but challenged as to why you made certain decisions. Consider coding best practices, readability, maintainability and performance. Personally I’ve never done one of these, if you are reading and have experience, then drop in a comment and help others out 👍
The other method and the one I find more likely, is for you to be given a task at the interview to complete. This is very difficult to prepare for, and even if you know your subject well, it can be difficult to think and perform under the pressure of an interview envrionment.
In general terms, the initial task should be simple and then you will be requested to add to it and scale it. These types of tests should be “open book”, i.e. you can refer to the internet, and who can do anything these days without Stack Overflow 😉 Knowing this, have some nice examples of code handy that you can appropriate code constructs from. Get your editor prepared and everything ready so you are comfortable. Remember that 99% of people in these situations are not going to do their best work or know everything, so try to relax and do your best. If you get really stuck with something, it’s ok to say you can’t think of something right now. Indeed, it will be expected that you won’t know everything and part of the test is to see how you find out those things you don’t know or overcome challenges. Try to vocalise your thought process, so even if you are struggling with the code, then at least they know what you are attempting to do.
Overall this is a tricky one to predict and prepare for, and there’s really no way around learning your craft.
Conclusion
I’ve focussed on the technical topics that might be covered at a verbal interview. I intend to keep this as a living document, so it is by no means comprehensive and it will be added to. Let me know your thoughts and experiences in the comments.
.The Dot Source 