How to interview a Business Analyst

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:

  1. 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!
  2. The case study simulates being able to work quickly and accurately under pressure.
  3. 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!
  4. 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.


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.

Simplify your data: stop capturing data you don’t need

One of the most common issues I see when trying to simplify all kinds web pages, and even offline paper forms, is asking for information that isn’t being used anywhere. This applies to sign-up processes, sales funnels, insurance applications: pretty much everywhere you are capturing data from a user.

It seems almost trivial to say this, but for each piece of data you capture, it’s worth asking how that data will then be used. How will it be processed? What decisions will be made based on this piece of data?

If it turns out the data is not being used at all, or is not being used meaningfully, then consider removing that field and not capturing that data any more.

Why simplify your data capture?

There are three main reasons to consider making your data more simple:

1. Simplifying data will save time for the user filling in the information, and especially in cases where you can remove more than one field this might make the difference between a user filling in a form, or giving up and going elsewhere. Often (but not always), the less information you ask for, the more people will fill in the form (so the higher your conversion rate, if you’re building a sales funnel.)

2. Simplifying your data will make processing the data easier too. Every line of code in software theoretically needs testing, and might also fail regression tests and break during later changes to the software, so there is a maintenance overhead and a cost for every piece of information that you capture.

3. In the UK, the Data Protection Act 1998, Schedule 1, states that, “Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.” So by simplifying the data you capture, and removing fields that are no longer used, you’ll help with legal compliance too.

Action Points

Review the places where you ask for data from users. For each piece of data you capture, decide whether it is being meaningfully processed or used to help with decision making. If not, consider not capturing that data any more.