If you’re not familiar with what a business analyst does, if we’re talking about producing software then it’s the business analyst who will understand the requirements for what the software should do, and will document this for the business people and the software developers. The business analyst acts as a bridge between the business and the technology.
A while back, when I was a candidate applying for roles as a contract Business Analyst, I went to two or three interviews before I found a role that I wanted to accept. I was struck by just how bad a job some of these companies were doing at interviewing Business Analysts. I also was very impressed by another company, whose offer I accepted, so I’ll talk about their Business Analyst interview process too.
Aims of interviewing a Business Analyst
First decide what your hiring process is aiming to achieve, then figure out a way to achieve it.
As I see it, the primary aim of a job interview is to let the candidate prove his or her skills and show his or her ability to fit in with the team. You can then choose the best person for the job.
Notice that I’m saying “prove” his or her skills, not merely talk about them. To my mind, you should be thinking more in terms of auditions than interviews. More of that later.
Competency-Based Interviews: the bad way to interview a Business Analyst
Let me fill you in on a horror story. I showed up for what turned out to be a Seriously Bad Interview. It was being run by two people; one seemed in some way to be connected with software development, but I wasn’t really sure what he did. He didn’t seem like he would be my manager though. The other person was from HR (Human Resources, Human Remains, you know the kind of thing.)
So straight away, you can see that at least one of the two interviewers, maybe both of them, doesn’t really understand the Business Analyst role, what a BA does, how it’s done, and what separates a good BA from a bad BA. Presumably the HR person was there for some kind of spurious compliance reason, to make sure some kind of obviously massively flawed process was being properly followed.
The type of interview was what in the jargon they call a “Competency-Based Interview”.
The questions were all of the form, “Give an example of a time where…”. And yet the scenarios were all so boring, so bland, and so commonplace that I seriously doubt that any candidate has ever given an interesting and illuminating answer that allows them to prove their skills. They were asking for the sort of things that you do all day every day, without really giving it a second thought, don’t tend to stick in the mind. “Give an example of a time you have held a pen.” It was that kind of moronic thing! No way to sort the wheat from the chaff.
There are two main problems with this kind of competency-based interview approach:
Problem #1: As a candidate, you really need to see the questions in advance to be able to think of interesting and enlightening scenarios that fit the question you’re being asked. Although tedious, some of the scenarios I was asked to give an example of were actually quite complicated. You’ve got about two seconds from when they ask the question to search your memory banks, combing through every day of your working life, to pluck out the most relevant and interesting scenario. That’s never going to happen! You’re probably just going to pick out the first thing that comes to mind. So even if the question tries to get at something interesting or useful to discuss, the candidate probably isn’t going to come up with the best example of that work on the spot, so as an interviewer you’re never going to see the best of them.
Problem #2: You’re likely to favour someone who talks a good game, even if they can’t actually do the job. As an interviewer asking questions, you’ll probably weed out the total fools who somehow slipped through the CV /resume screening process. That gets rid of maybe the bottom 50% of candidates. But of the remaining candidates, how do you know who’s best? You’ve got a base level of competence, but beyond that, it’s anyone’s guess as to how they’ll actually perform. If you were this kind of interviewer, and someone asked you “Are you 100% sure this person can do the job? What proof do you have?”, then you have to answer that no, you’re not sure, because you have no proof beyond the candidate’s assurances of their miraculous powers to analyse the business benefits of the water that they walk on! You haven’t proved anything!
The result: No candidate can possibly shine under this kind of amateurish questioning, and no interviewer can confidently identify the best candidate.
After this interview, I turned this role down. I reasoned that if the quality of the interviewing process was so poor, then the quality of the people I would be working with would probably be poor too, since there was no effective quality gate to identify the best people. Also, if this was the process that had been designed and rigorously followed (thanks to the HR policing), then whoever designed the process (and was likely to be in charge of something important) probably wasn’t much good either!
I hope whoever accepted the role is now enjoying it. (They won’t be.)
Case study interviews: The good way to interview a Business Analyst
The good company, whose contract role I accepted, decided to do an interview based around identifying requirements in a case study. The study was based on a real-world scenario that the company has actually faced, and then feeding back the requirements from this case study to the interview panel. The panel was made up of a senior business analyst, and also a senior software developer and project manager from the project the successful candidate would be working on.
I don’t want to say too much about the details of this exercise, since I’ve heard it’s still in use by that company and I don’t want to spoil its effectiveness for them.
There are some important lessons to learn from this approach:
- The case study approach isn’t just about talking the talk, you’ve actually got to do some work and prove your skills! Show, don’t tell, as they say in Hollywood!
- The case study simulates being able to work quickly and accurately under pressure.
- The interview panel has a senior business analyst, who understands the job, does the job himself, and knows what to look for. He’s not a generic HR person!
- The interview panel has people from the actual project that the candidate is being recruited for, so that the chemistry between the existing team and the candidate can be identified. The BA usually sits as a bridge between the development team, the project manager and the business, so it’s good to have multiple perspectives on the interviewing panel.
As a candidate, I felt that the case study approach let me demonstrate my analytical skills and my communication skills. It also let me slip in some facts and figures about the company I was being interviewed for, and their industry, to show I’d done my homework! (I’m always amazed by people who turn up to interviews without knowing anything about the company… and are surprised at how short the interview is for them!)
The case study approach was a much more effective way of simulating the real-life job than a competency-based list of half-remembered scenarios that happened several years ago!
During the time I was feeding back on the case study, I said various things that hinted at my previous experience, and along with the notes on my CV/resume this formed a second part of the interview, where the interview panel asked direct questions to get a feel for my level of experience on past projects in certain areas.
Conclusion
I’m sure there’s more than one way to effectively interview for the role of Business Analyst, and maybe a competency-based interview by a more skilled interview panel could be more useful, but a case study exercise, where the candidate proves their effectiveness with a real-world scenario, is a good place to start. When I was a software developer, interviewing other software developers, we used a technical test based on a computer programming exercise – a similar process with similar good results. It’s not a perfect process, but it definitely gets you a lot further than competency-based interviews! As a candidate, you can’t BS it, you can either prove you know your stuff or you can’t.
Action Points
If you’re interviewing someone for the role of Business Analyst:
- Find a good case study based on some work you’ve actually already done, so that you know the points that a good candidate should pick up on.
- Prepare a checklist of things the candidate should identify from the case study. Split the checklist into two: essential issues the candidate must identify, and secondary issues that give them bonus points.
- Prepare two or three questions to give to the candidate that relate to the case study, asking them to identify and analyse the case study. Then you can talk about this during the interview and get them to verbally give you their findings, as they would in a project meeting.
- Find an interview panel that represents the people the successful candidate will be working with.