Unfortunately, there are better times to be in tech. Every week brings news of another large-scale layoff at one firm or another. That means that many people, like it or not, will be going through interviews to re-establish employment. This situation leads me to think about the various interviews I’ve done – both as a candidate and an employee. What are the questions I should have asked? How do I gauge how well someone knows Jira? There is a good bit that goes into a successful interview, so let’s dig into this.

Baseline: Do you even Jira?

The last time I had to interview potential candidates, our first step was to figure out how well they knew Jira. I thought a lot about how I wanted to do this. Yes, you can always ask questions, but having done my fair share of ACP exams, I get how those can be. Much of what we do on Jira is muscle memory, so asking questions without the context of being on a Jira instance gets tough. No, I decided that the best way to gauge how well someone knows Jira was to see them using it. So, I came up with a test. 

First, I set up a Self-contained Jira Server instance on a local VM. On it, I created a few projects, a handful of users, some permissions schemes, etc. I tried to make it as fully fleshed out as possible. I’d also disable the VM’s network adapter, so they could only get to the Jira Site hosted on the instance. 

Then I broke things. I’ll map out groups to various project roles and add users to the groups. I’ll then leave out a critical permission node on one of the roles – for example, I’d set up a “Scrum Master” Role but intentionally leave out the transition issues permission for that role. 

In another, I’d intentionally mistype a user’s email address. Their name would be “John Doe,” but I’d enter “[email protected].” The point is to make it obvious if you look for the details. 

And lastly, I’d add a condition on a workflow step that prevents users not in a particular project role from accessing a critical transition within a workflow – but I’d select the wrong Project Role – for example, choosing “Administrator” rather than the (usually) broader “Developer” role.  

Then I’d create tickets in the “Jira Admin” project based on the things I intentionally broke. For the first example, the ticket would be from the “Scrum Master,” saying they can do everything in the project except transition tickets. The second would be another user complaining that they are not getting emails from Jira. The third would be from a project lead saying he keeps having to move issues to a particular status, but he feels the entire team should be able to. These aren’t the exact tests on my Jira Test VM, but they are around the same difficulty. The idea here is to have some easier ones and harder ones.  

With that done, I’d create a README.txt file in the center of the desktop that would explain the test, how to access the Jira instance, and what project your tickets are in. Then, at the start of the interview, I’d ask a few warm-up questions, the “Explain how you got started using Jira,” and the like. After a few questions, I’d share the VM with the Zoom call, give the candidate control, and ask them to start by reading the README on the desktop. Then, I’d watch.  

Now, I wrote the README in such a way as to imply this was a time trial, but I was not timing their performance – I just wanted them to feel a bit of pressure. I’d see how they’d navigate the interface, whether or not they struggled to find different areas, how they fixed the issues, and if so, how confident they were in their fixes, etc. I’d be taking notes the entire time to compare later. 

For example, on the first ticket, you can either add the Scrum Master to the developer’s group or fix the permission scheme for the Scrum Master Role – either would work to solve the ask. But the path you chose would tell me something about how you Admin. Should we spend more time fixing things properly now or do the quick-and-dirty fix that might have to be cleaned up later? Do you notice the miss spelled email address, or do you start by debugging outgoing email? How do you go about modifying the transition to allow the requested change? Do you go back and test any changes, and if so, when and how? These are all questions that this kind of test will show you about a Jira Admin, but they would be challenging to capture if you just asked them questions.

But – we still need some questions.

Yes, the test above will answer a lot about how good someone is at Administering Jira, but it won’t do anything. Jira right now is a very diverse toolset – especially between Jira Cloud and Jira Data Center. As I mentioned above, I still ask a few warm-up questions, which are some of my favorites.

Q: Tell me how you got started as a Jira Admin?

The answers people give to this question still fascinate me – as many people I’ve talked to fell into the role. Most people didn’t set out to be a Jira Admin, but someone had to be, so they did the needed work, and hey, what do you know, this turns out to be a profitable skillset.  

Q: What are the three parts of a transition, and what does each part do?

This is a good, hard-hitting question that will tell you how far a candidate has gone on their Jira Admin journey. Most Jira Users are not likely to know this, but every Jira Admin should learn sooner than later.  

Q: What do you see your job is as a Jira Admin?

Again, I love this question as it helps you tell how the Jira Admin sees themselves. Ideally, they should be a guide to users to help them get the most out of the instance. But the flexibility in this question allows you to see how they view their role in an organization.

Q: What is your favorite Jira App?

This is another one where the only wrong answer is, “I don’t know what that is.” Otherwise, it can tell you about some of their experience on Jira, what tools they’ve used, and how they’ve viewed it.  

But what about the candidate?

This isn’t the first time I’ve touched on this – but as a candidate, you should come in with questions of your own. I spelled out a few in a post a few years ago. As a refresher/update, those are:

• Is your instance cloud or data center?
•  How many teams and users does it support?
•  How many projects and issues are on it?
•  What are your governing policies around JIRA?
•  What is the state of your end-user documentation on how to use JIRA?
•  What Apps do you run?
•  Am I replacing another JIRA Admin?
•  Will I be the only JIRA Admin on staff?
•  What is your most significant pain point with your current JIRA usage?

However, while these are important, they are not the only questions you should ask. Eight years ago, I put the question up on Reddit’s r/sysadmin, and honestly, the list I got back still informs the list of questions I bring to every interview. Here are a few of my favorites:

Q: How often will I be “On Call”? How much sick time and PTO are involved?

Both of these questions give you an accurate scope of work. Look, I know it feels risky asking about such things during an interview, but taking time for R&R is crucial for you to be able to do the job long-term.

Q: How many emergency calls did the team respond to last year? 

Again, this question is about figuring out the actual scope of work. For example, if you are responding to a midnight call every other week, that will eventually grind you down. Ideally, you’d want to find that out now rather than after you start the job.

Also, consider the situation where they don’t know. If they are in Data Center, it’s doubtful this answer was Zero (and, let’s be honest, it’s not like Jira Cloud is invulnerable either). In this case, this tells you that their recordkeeping/tracking might leave much to be desired. They may not have an exact number, but they should have some idea.

Q: What is expected of this role?

Being a Jira Admin can mean different things to different orgs. Some want you only to be “the person who pushes the buttons.” Some want you to be a teacher and guide. Most will usually be somewhere in between. Knowing what is expected of you early will help you figure out if this role is for you and, if it is, help you prepare for the role before you start.  

Q: What is the Org Structure I’ll be reporting into?

This can have a massive impact on how you will be working. Are you reporting to IT? They are likely to be more risk-averse and thus have policies around making changes. Are you reporting to development? If so, prepare for the “Most fast and break things” mentality to be your day-to-day. Now let me be clear – both have their benefits and drawbacks. Yes, you have less red tape in a Dev organization, but you are also more likely to have to respond to some emergency due to a change. On the other hand, you are likely to be closer to the people actually using your system, so it’s easier to get things exactly where they need it to be.

Updates:

Since putting this out, fellow Atlassian Blogger Łukasz Przybyłowicz let me know he has also covered this. This honestly feels like a great addition to the post, so if you are looking for more, please check out his post:

• Recruitment questions that you can arm yourself with as a Jira administrator

What do you think?

What is your favorite interview question, and why? I’d love to hear your thoughts on this, so be sure to comment here or on your favorite social media platform! 

You can find links to all my social media profiles on my Linktree! While you’re over there, be sure you like, follow and share the content so the platforms know to show it to more people. It really does make a massive difference!

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”