When I help with government hiring I often give the same suggestions to hiring teams. So I wrote this page as a starting point. I focus on IT hiring but this also applies generally. If these points resonate with you, I'd love to help you with your hiring.

Important note: these are my opinions and I don't represent Environment Canada. Also, what I've written here won't give any candidate an unfair advantage. Just read any "IT interview tips" article and compare.

Starting with the easiest to implement:

1. Do not hire yourself
2. A good job post is good marketing
3. Emergency eject
4. Statistical power of questions
5. Expert questions
6. Many multiple choice options
7. Discuss their code
8. ChatGPT: shields up
9. University degrees: an asset not a requirement
10. Years of experience is misleading and ageist

1) Do not hire yourself

Required experience should be about the problem domain:

Experience using or managing IT platforms for incident response, pager rotation, change management, version control, and monitoring.

and not just specific tools, languages, and platforms for that problem domain:

Experience with PagerDuty, GitLab version 8.1, Kibana and matplotlib.

Otherwise, a good candidate may be an expert in exactly what you need, but maybe they don't even apply. We want a candidate who has experience in tools we don't use. That's how we learn and modernize. Many job posts accomplish the opposite and we just hire people like us.

2) A good job post is good marketing

There must be a simple web page with only a short and exciting job description (with links to the full gcjobs post). For example:

Work on a Linux Supercomputer

The supercomputer used by the government of Canada for weather simulations ranks around the top 100 in the world. This includes tens of thousands of CPU cores and hundreds of petabytes of storage! The Meteorological Service of Canada (MSC) needs talented IT professionals to help support all the science, research, development, and operations of its systems.

Full time, hybrid, in Montreal / Dorval.

In contrast, 1700 words of boilerplate as seen here is going to filter out some excellent IT candidates who have no patience for bloat and bureaucracy. We need more public servants who dislike long bureaucratic processes, not less.

There is also no effective way to share 1700 words on social media. Whereas the paragraph above is designed for it.

If your job post is a huge list of assets, requirements, legalese, and confusing government lingo like streams then your bureaucratic bloat is leaking into your marketing materials. This is bad marketing. It's a bad job post.

3) Emergency eject

This helps shorten long technical interviews.

The hiring team can agree in advance on just two easy starter questions. The answers are clearly correct or not. If the candidate fails both, we can end the interview early.

Careful for false negatives (not hiring a good candidate). Make sure the whole hiring team agrees there is no chance we want a candidate if they fail this.

4) Statistical power of questions

Good questions give candidates many options to show us their best. For example:

• In any programming language, write code that does ...
• In one sentence each, explain 8 of these 10 items
• Here is a section of your code you shared. Explain it to us.

Bad questions force a candidate into a small box. For example:

• with the bottle_abc library, how do you compute request latency given a BottleQueue object?
• what does this one line of code from a specific language do?
• list the four types of X.
• in 2 minutes, explain the software design principle XYZ

If we get a good answer, it's more likely a good candidate. But if we get a bad answer, we didn't learn much. Think about false positives (hiring a bad candidate) versus false negatives (not hiring a good candidate).

Suppose we have two candidates: bad and good. The bad knows just 4 of 10 items, and the good knows 8 of 10 items. If we ask just one long question:

• there's an 8% chance a bad candidate knows the answer, and a good candidate doesn't.
• there's a 32% chance they both answer correctly, and the question was useless.

So don't put candidates in a tight box or try to hammer them on a specific tough question. Give them lots of opportunities to show us their best.

5) Expert questions

No one is an expert at many things. For your most challenging questions, allow the candidate to choose from many options:

• Choose just one of these four questions.

Instead, if you force a candidate to answer one expert question:

• Describe how the changes for bottle_abc version 1.3 to version 1.7 impact bytes storage in BottleQueue objects.

Most candidates (good or bad) will fail and you've learned nothing.

We want to hear what they are best at, not if they got lucky with our choice of question.

6) Many multiple choice options

In the twentieth century, multiple choice was often ABCD (maybe E) because of punch card systems to automatically grade them. Don't do that.

Suppose we provide ten answer options to a multiple choice question:

• 1 correct
• 3 decent answers but wrong
• 6 horribly bad answers

A bad candidate is less likely to guess correctly, and a random guess has a 60% chance of telling the team they are clueless.

This is great for code questions. Write some code, a question, and ten short answers. This is fast to answer, fast to grade, and it's statistically powerful.

7) Discuss their code

Before the interview, ask for a code sample from the candidate:

Could you provide us with a link to a software project you worked on? If it was a team project, identify some sections for us that you wrote. Any programming language. The code doesn't have to work, or be perfect, just something you wrote.

During the interview, find a long or complex section of code. Ask them to thoroughly explain it. Evaluate their communication and knowledge of syntax.

Over the years I have personally seen:

• people unable to explain code that they "wrote".
• people with no code samples to share (for bad reasons).
• people that struggle to share code or share files. Remember, this is for IT hiring.
• people with software engineering degrees who cannot explain basic software principles they used, like class inheritance.

8) ChatGPT: shields up

I already wrote about how to do this here but in short, write your interview questions so ChatGPT cannot (yet) answer them. Or better yet, conduct the technical test in person.

9) University degrees: an asset not a requirement

This section applies best to hands on IT jobs, not researchers.

I've worked at maybe 6 different schools and universities. I studied education. Universities are not what they used to be, with grade inflation and the fall of the faculty. Did you know that most university undergrads are now taught by poorly paid part-timers?

The worst colleague I've ever worked with had a PhD in computer science. He refused to do version control, chose an experimental unsupported language for the core of the business, and scoffed at automated testing.

University degrees should be considered an asset not a requirement. Whatever the academic requirements are for the job classification, require the minimum.

10) Years of experience is misleading and ageist

Suppose we have two candidates. Who is better for a data visualization role? From their cover letters:

1. "I have twelve years of experience advising management and designing solutions for data visualization platforms."
2. "I have one year of experience integrating our ABC data into our XYZ visualization platform."

Suppose the first candidate attends a one hour data visualization manager meeting four times a year for twelve years. That's just 48 hours of experience. Maybe they just sat in a chair and contributed nothing. It's possible.

Suppose the second candidate has been running that XYZ platform with half their full time hours for a year. That's maybe 900 hours of experience.

Requiring "minimum X years of experience" eliminates the second candidate. You're forced to choose the first. This is effectively ageist.

Suppose the position requires management level experience with XYZ. Do you really want that first candidate as described instead of the second?

Suppose a third candidate has a personal project using XYZ. They deployed, maintain, and use their own XYZ instance. How many "years of experience" is that? Are you sure HR will agree?

As much as possible, years of experience should be an asset, not a requirement. Instead require proof of capabilities and skills.

Thanks

Thanks for reading!