Just now I’ve had the privileged to be part of a discussion about knowledge of PowerShell, recruiters and employers.
The argument was made that some employers expect an admin or expert to know PowerShell.
So far, so good.
Realistic expectations
But, they expect an IT Pro’s to know all verbs, nouns and/or cmdlets… or at least those of a specific technology (i.e. Exchange or Lync).
So, dear recruiters and employers: Are you nuts!!!???
Would you as a layer to recite the entire law? Or an accountant to name and explain all tax rules and regulations?
Naturally, they would not be allowed to look it up in a book or on the internet.
Because that’s what you’re expecting from the admin/expert you’re interviewing…
PowerShell is created in a way where it teaches you to gain the information you need as you go.
It is discoverable… the same why a law book has a table of contents or an index.
So when you interview an admin/expert, ask about how he would explore and gain the information, not about the information itself.
There are two gotchas here though…
1) An AD admin that doesn’t know about the Get-ADUser cmdlet isn’t suited for his job these days.
2) Some customers ask me to sit next to an technology experts (i.e. Lync) and with his knowledge of the product (which I do not have), I can script whatever they want to get scripted.
Define what you need and what you want
I’ve seen so many job positions where they ask for a whole list of required knowledge… i.e. Hyper-V, System Center, Exchange, Office365, Azure, Storage and Networking, VMWare and AD.
Well, good luck finding a single person that’s an expert in all of those 😉
Because this is the IT version of looking for someone that is the is the IT admin, does the financial administration, marketing, reception and sales… all at an expert level.
Don’t think in people, think in teams and tasks.
When you hire people, you’ll end up with a team. Spread the required knowledge over the entire team, where one is none. So each expertise should be delegated to at least two people.
So you need two experts for each technology? No!
You need (at least) one expert, let’s name that the Product Owner. He/she decides the direction of the solution within the company.
In the absence of that Product Owner, the secondary guy/girl comes into play. He/she knows what the Product Owner wants and can answer questions colleagues may have.
Though, they do not hold any responsibilities about the solution itself… only for their own actions (when they fix something that broke, and break it even further).
So what is the point of this all?
When you, as a company, look at a team the question becomes: What skills am I missing within that team?
Define what you’re missing, which are the ‘what you need’ criteria.
So what skills do you have within the team, but only with one person?
That’s the ‘what you want’ criteria.
Anything else which is considered technical is secondary and should not be placed in the job description.
Written by HR
So many times I’ve read about a job position where the description was clearly written by a non-technical person.
I’ve actually had a phone call from a recruiter asking ‘You are an MVP in PowerShell, so you are good at making presentations?’.
These days I just skip those job positions all together.
If you don’t invest the time in the description, what am I to expect from an actual interview?!
The interview
During most interviews I’ve had at least one tech person sitting in, there are the rare exceptions where there isn’t.
A manager, team-leader or HR lady with no technical knowledge whatsoever had to interview me for a (deeply) technical job.
Though I always remain polite, I have to say that those people tend to make a fool out of themselves without even knowing it.
Yes, I like to tease people. That’s just the way I am.
But in these situations, all I have to do it sit back and watch it happen. No efforts is required from my side whatsoever…
For example: A technical person would never ask another one to name all cmdlets for a product 😉
A request to…
All companies: Either get a tech person sit in for technical questions (ask and receive) or don’t even try to ask technical stuff.
The moment you’ll start mis-using terminology or are asked a question in return, you’ll just make a fool out of yourself.
And let’s be honest, you’re not a fool… so why seem like one?
All recruiters: Do your homework. I’m not talking about the fact that some recruiters contact me about an App-V sequencing job because the term ‘scripting’ in used on my LinkedIn and resume.
Although that also leaves room for improvement.
I am talking about the fact that some of you don’t even have read the resume of the person sitting in front of you!
Next to the fact that I find it rather offensive, it is unprofessional.
Again, let’s be honest… you’re not, right? 😉
So true, Jeff!
Next goal: Convince those, who make the questions for the Microsoft exams, that asking for the correct cmdlet with the correct parameters does not ensure, that the person being tested would be a good IT Pro…
Agreed! 🙂
Interviews should test the higher order knowledge of professionals, rather than the “monkey work.” Anyone can figure out how a PowerShell command works.
Fewer people are truly capable of coming up with an overarching “solution.”
Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell
I must put a link to this page on my CV before my name.