So you have submitted an application which has been short listed, you have been invited in for an interview, how can you make sure you do well at the interview and are offered the job? Without a doubt, everyone attending an interview needs to do some preparation. Preparation is the key to a successful interview. One of the best ways to prepare is to research some of the questions which might be asked at the interview, and formulate a response in advance. Below we will take a look at some of the business analyst interview questions which may be asked, why they are being asked and some guidelines towards preparing a suitable answer.
Not a specific business analyst interview question, but one which is almost always asked at every interview, a powerful question and the answer given tells the interviewer a lot about the applicant.
The number one rule when answering this question is never to say anything bad about your current employer. Instead, give reasons why the job is no longer suitable. Suitable answers would include such things as a lack of vertical space, meaning slim chance of promotion, current corporate instability leading to loss of job security and other general reasons. Remember! Do not bad mouth your current employer in any way!
In old sales terms, this is known as a drop sell. You are being put on the spot, and the reason for asking this question is not to merely get the answer, but to judge your reaction to being put on the spot.
The way to answer this business analyst interview question is to explain how your skillset suits the requirements of the post, how you would synergistically fit into the company, and how both parties would benefit from your employment.
This question will almost always be asked in some form or another as one of the business analyst interview questions. The reason for this question being asked is not to find out what you actually know about the company, it is being asked to judge if you have performed any prior research and prepared for the interview.
This is your chance to demonstrate that you can logically research facts, and relate them in a coherent manner. Before the interview you should aim to discern key facts about the architecture of the business, its marketplace and trading history.
Here we start to hit the business analyst interview questions which pertain to the business analyst profession and its skillset. This question is asked to gauge your overall level of your experience.
When answering this question, the best approach is to give an overall indication of the number of business cases you have worked on. Then follow this up with a short description of your role. Now, it is likely that early in your career your involvement was at a more junior level, quickly brush over this early part if you can. When you come to more recent history, explain your more senior role in full. The aim here is to convince the interviewer that you have worked at a senior level and are experienced enough to move on.
A bit of a trick question this, as the interviewers are not really interested in the actual answer; instead they are looking to judge your ability to perform reflective analysis in an unbiased fashion.
A great way to answer this question is to discuss a case you were actually involved in, during the explanation of the case, be sure to highlight your own failings as part of the reason this was the worst case you worked on, and then ALWAYS follow up by telling the interviewer what you learned from these mistakes and how it helped you grow as a business analyst.
Here we are really getting to grips with the technical side of business analysis. If you are asked this business analyst interview question, then you will know you are sitting across from an interviewer who understands business analysis, probably is or was a business analyst himself, you are now in the spotlight.
To answer this question, draw on past experience, and explain certain cases, which went well due to the correct application of the right methodology. Detail why this methodology worked so well, and in your opinion, how it can be utilized to solve future cases. Do not give a wide answer encompassing many methodologies, chose one or two you are the most familiar with and discuss those.
INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.
I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.
N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.
V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.
E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.
S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.
T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.
Business Rules and Policies tend to be complicated for analysts to untangle because they are so closely related. Policies are typically more general assertions or guidance about how an organization is intended to operate, while business rules describe the specific execution of the business policy.
The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a business rule as 'a specific, actionable, testable directive that is under the control of the business and supports a business policy'
The Business Rules Group goes further in their definition of business rules describing it as an atomic statement that defines or constrains some aspect of the business. They categorize business rules as one of three sub-classifications; structural assertion, action assertion, or derivation. The definitions of these get quite detailed and while knowing them, along with understanding things like fact models, may help elaborate one’s understanding of a business rule, at a summary level business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.
Additionally, policies, being more general, typically change less often than business rules which are specific implementations of policies.
To restate, a policy is:
Supports a policy
A business rules is:
Maintenance must be performed in a manner which maximizes the life and value of the car
Renters must have valid insurance
Examples of policies for a car rental company:
All vehicles are required to have a 58 point inspection after every 3 months of use before re-renting.
A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
Tires with less than 1/16th inch of tread must be replaced.
Renters in the state of Texas must have insurance covering $100,000 of liability or more.
Renters in the state of Arizona must have insurance covering $50,000 of liability or more.
Example of business rules that may support these policies:
Notice that each of the business rules are written as a level which is actionable, specific, and testable.
RACI Matrix is the name given to a table which is used to describe the type and degree of involvement that stakeholders have in completing tasks or deliverables for a project or business process. Also sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool used by business analysts and project managers for establishing roles and responsibilities early on in a project. In this way it reduces project risk and sets expectations about the level of involvement that is expected by various stakeholders.
This may seem like an obvious question, as if the interviewer is asking you to say “very familiar, and I make sure I know everything there is to know about ALL things business analysis related”. However, how you answer this question can ultimately reveal a lot about your desire to grow as a business analyst, how well you manage your spare time, and how honest you are throughout your interview.
First, an interviewer wants to assess your eagerness to grow as a business analyst. Are you the type of analyst that is always looking to improve and learn a new technique or skill? Do you feel it’s important to gain and understanding of business analysis techniques that you won’t even use for the foreseeable future? The answer to this question should be yes.
Personas are used as part of User Centered Design methodologies. They are detailed profiles of fictional characters which represent a specific segment of users within a targeted demographic. For this reason, analyst and designers typically use personas together with market segmentation. They are intended to help application designers fully envision and understand the different attitudes and behaviors of users within various demographic segments.
Use case name
Normal process flow
Alternate process flows