Q.

 Can you tell me why are you considering leaving your present job? 
A. Regardless of the reason, do not bad mouth your current employer. Negativism will
always hurt you. Good answers include: “There is no room for growth at my current
employer. I am looking for a company with long term growth opportunities”. “Due to a
company restructuring, my entire department is relocating to Florida. I was give the option
of moving, but do not wish to relocate”. “My current company is not doing well, and has
been laying off employees. There is no job security there, and more layoffs are expected”.

Q. How do you handle stress and pressure? 

A. “I find that I work better under pressure, and I enjoy working in an environment that is
challenging.” “I am the type of person that diffuses stress. I am used to working in a
demanding environment with deadlines, and enjoy the challenges.”

Q. We have met several business analyst’s. Why are you the one we should hire? 
A. Give definite examples of your skills and accomplishments. Be positive, and emphasize
how your background matches the job description. Mention any software packages and
spreadsheet software you are familiar with. Also let them know if you have advanced
knowledge of any of the software.

Q. What do you know about our company? 

A. This question is used to see if you have prepared for the interview. Candidates that have
researched the company are more appealing. Companies like prepared, organized
candidates.

Q. What are your greatest strengths? 

A. Be positive and honest. “My greatest strength is maximizing the efficiency of my staff. I
have successfully lead numerous teams on difficult projects. I have an excellent ability to
identify and maximize each of my staffs strengths.” Give examples.

Q. Tell me about your greatest weakness? 

A. It is very important to give a strength that compensates for your weakness. Make your
weakness into a positive. “I consider myself a 'big picture' person. I sometimes skip the
small details. For this reason, I always have someone on my team that is very detail
oriented.” Another good answer: “Sometimes, I get so excited and caught up in my work
that I forget that my family life should be my number one priority.”

Q. What are your goals for the future? 

A. “My long term goals are to find a company where I can grow, continue to learn, take on
increasing responsibilities, and be a positive contributor”.

Hopefully these typical business analyst interview questions will help you. It is important to
customize the answers for your specific background and experience.

PESTLE analysis extends the original PEST analysis, by analyzing the Legal and Environmental factors
that may influence a business.

Legal Environment: refers to laws that are set up to protect individuals.  This may be based on any
number of protected classes such as race, religion, gender, age, etc.  It also applies to laws beyond
protected classes such as minimum wage laws.  Some confuse the analysis of the legal environment with
the political environment since both tend to be based on passed legislation.  But the legal environment
specifically focuses on things that impact the people that are employed by the business, not the business
as a whole.  You can think of political environment as the laws that govern the macro environment, while
the legal environment is those things that affect the business at a much smaller level.

Environmental Factors:  refer to changes in weather, climate, air and water pollution, wildlife
conservation etc.  Changes in weather can have a strong impact on many industries including the
agricultural industry (drought), gas and oil (hurricanes), commercial fishing (wildlife conservation), and
many more.  With greater environmental awareness the environmental factors continue to have broader
reaching impacts across industries. However, not all environmental factors create a negative impact.  The
greater environmental awareness has also produced opportunities in some industries such as travel and
transportation (electric and hybrid cars).

The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce
Tuckman.  He described that most teams follow a consistent path from the point when they are first
assembled to the time when they become a highly proficient, highly effective group.  This path leads them
through four distinct stages; Forming, Storming, Norming, and Performing.

The “Forming” stage begins when new team members are first brought together.  Initially everybody is
very positive and polite to one another.  Some people are anxious, some are excited.  The team members
are fairly unaware of the details of the work ahead (blissfully naïve perhaps) and they look for clear
direction from the leader.  Formal processes and project frameworks are not yet established. This stage is
usually short in comparison to the others.

Next is the “Storming” stage.  At this stage team members become clear about their roles and what is
expected of them.  Processes and project structures are put into full effect. The team may feel frustrated
and overwhelmed by the work as they become more aware of the realities of the job.  They may be
stressed by how much there is to accomplish and they may have uncertainties about their ability to do the
assigned work. Or, they may simply be uncomfortable with the approach that is laid out by the leader. 
Team members still don’t know each other that well as they continue to form opinions of one another. 
They may be jockeying for position within the team or even challenging the leader’s authority.  Conflicts
arise more often during this stage.  A great deal of oversight is needed by the team leader to ensure the
processes are followed and the work is completed to expectations.

The “Norming” stage is where the team begins to catch their stride.  The pecking order of the team is
established and team processes and workflow are beginning to solidify.  Each team member understands
the strength of the other members and they all begin to work more as a team.  They help each other and
provide peer reviews and constructive criticism.  At this point, the team is following the processes and
project framework but may not be working as efficiently as they could be.  They still need oversight but
significantly less than in the storming stage.

Finally, the “Performing” stage is reached.  The team has a solid understanding of the processes and
project framework that have been put into place and follow them efficiently.  The team has become
efficient and productive and it reaches its goals with regularity.  At this stage if a team member joins or
leaves it will have little impact on the rest of the team’s performance.  The team leader can delegate to
team members with confidence and provide minimal oversight. 
 
A use case realization provides a construct to organize artifacts which shown how the physical design of
a system supports the logical business behavior outlined by a used case.  To show this traceability
between the logical and physical design, in the use case diagram each use case is depicted as an oval
shown with a solid-line border.  Then for each use case can you may show a use case realization as an
oval with a dotted-line border.  The use case and its corresponding use case realization are linked using a
realization dependency which is shown in UML as a dashed line with a triangular arrowhead at the end
corresponding to the realized element (the use case).  

Each use case realization will define the physical design in terms of classes and collaborating objects
which support the use case.  Therefore, each use case realization typically is made up of a class diagram
and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or
interaction between physical objects.

Use case realizations allow the analyst to clearly separate the concerns of the logical and physical
design.  Since a logical design (the business behavior and requirements) can be implemented or realized
via a number of different physical implementations, if a physical design changes the logical use case can
remain unaffected.  Also, a use case realization is an excellent form of requirements traceability from the
logical business requirements down to the physical implementation of the solution.
 
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.

RACI is an acronym which stands for Responsible, Accountable, Consulted, Informed.  Since using an
acronym makes for easier recollection, the term RACI Matrix tends to be the most commonly used name
for this tool

The RACI Matrix displays deliverables or tasks along one axis:

 Project Charter
 Business Requirements Document
 AS-IS Process Flow
 Functional Specifications
 Requirements Traceability Matrix, etc.

Then it displays project roles or stakeholders along the other axis

 Project Champion
 Project Manager
 Analysis Lead
 Analyst/Analysis Team
 Development Manager, etc.

Finally, at each intersecting cell the type or degree of involvement is documented (Responsible,
Accountable, Consulted, Informed).

Ultimately, each organization varies a bit in how they define each level of participation in a task or
creation of a document.  The following are some commonly accepted definitions.

Accountable – This is the person who is ultimately on the hook to ensure that the deliverable or task has
been completed and is thorough and correct.  This is usually a lead or manager of some kind.  The
accountable person may be directing the work of the responsible person, but in the end the buck stops
here.  There can only be one truly accountable person.  This avoids finger pointing when something
doesn’t get done or is done incorrectly.

Responsible – The responsible person(s) is the worker bee.  It can be one person, or a team of people. 
They will be the ones getting their hands dirty finding the information they need and putting it to use to
complete the task or create the deliverable.  They may be reporting to a lead or manager who is
accountable for the task or deliverable.  However, for smaller tasks or deliverables, when there is only
one responsible person listed, they may ALSO be listed as the accountable party.

Consulted – The consulted person(s) is a subject matter expert.  They are the person whose opinions or
knowledge of a particular system or process is sought.  They don’t usually participate in completing a task
or deliverable other than by providing the information that the responsible person needs to achieve their
task or deliverable.

Informed – These are the people who need to be kept up to date on a task or deliverable.  They may
need to track the amount of progress being made, but usually these people care only about the
completion of a task or deliverable.  Typically they are either reviewers of the completed document and
provide formal sign-off and approval, or they may be dependent on the information that results from the
task or deliverable. 

What is a database view and why should the business analyst understand it?

While the business analyst usual works in the logical domain, understanding what a database view is and
the advantages of using them can be helpful when the analyst is tasked with documenting requirements
and creating specifications for reports and user interfaces that present data from database queries.

A database view is a stored query that returns data from one or more database tables.  The stored
query, or view, is a virtual table.   Once you have defined a view, you can reference it just as you would
any other table in a database.  Since the view is the result of a stored query, it does not contain a copy
of the data itself.  Instead, it references the data in the underlying base tables.  

Views provide a number of advantages:

 A view can provide additional security.  By creating a view and creating the necessarily privileges,
you can ensure that the users are only able to retrieve and modify data that is exposed by that
view.  Users will not be able to see or access data in the underlying tables that is not exposed by
the view.
 Views can reduce query complexities.  By creating and storing complex queries and exposing
them in the form of a view, the data from the view can be extracted using much simpler queries.
 Since a database view is a stored query, not a copy of the actual data, views consume very little
space.  

Some examples of the ways views are used are:

 To combine data from multiple tables into a single virtual table that can be queried using basic
statements.
 To partition a complex table into multiple virtual tables that are simpler to query. For example, if
a database table contains sales data from the past 10 years, views can be created and
represented using tables names such as SalesData2000 or SalesData2001.
 To aggregate data and perform calculations.  The view (stored query) can request the database
engine to sum or average data in underlying tables.  These sums or averages can then be
queried more easily. 

What are the advantages and disadvantages of using screen mockups in the requirements gathering process
of a system solution?

Screen mockups can support the requirements gathering process when introduced at the right time, but if
introduced too early they can become problematic.   Here are a few key points that an analyst should
remember.

1)  Mockups are nice because they help the business representatives or clients visualize the functionality
of the system.  This can be a big advantage to help analysts and stakeholders identify problems early on. 
However, if introduced too soon in the process the natural tendency is for the business reps/clients to try
and be screen designers.  Instead of stating that the system shall support "x", they beginning saying that
they need a dropdown to capture "y" and a button to do "z".  The client is not a UI designer, in fact few
business analysts truly are, so this can lead to a screen design which does not have an appropriate
emphasis on usability.  Similarly, specifying the controls needed on a screen detracts from the true
requirements of the system and often results in an inadequate level of discussion around why a system
must support certain functionality.

2)  When requirements are captured in screen mockups with no supporting requirements list, it becomes
impossible to know whether an early screen design decision was made because it supports a necessary
requirement or if it was made for some other reason.  How can the analyst and developers know whether
they can eliminate or alter the screen feature without losing an important requirement. Questions like, "Do
we really need to have the control on this screen, or can we capture the data at a later point in the
process?" becomes unanswerable without going back to the original stakeholders.  And, on complex
projects no one stakeholder may be able to answer the question.

3)  Screen mockups alone cannot capture the flow through the system.  Often analysts will accompany
screen mockups with a written description of what happens when certain buttons are clicked or when
certain values are entered within a field or dropdown.   These descriptions are helpful, but they fall short
of describing the end to end processes that the system must support.  Further document such as process
flows or use cases are required, but often overlooked when too much emphasis is place on screen
mockups during the requirements gathering process.  While analysts and stakeholders who are involved
in the screen mockup process may have a basic understanding of the processes supported, developers
and testers will not.

Ultimately, the introduction of UI mockups can be very helpful, but this should only occur after an
exhaustive list of features and usage scenarios (what business process flows need to be supported by the
system) have been documented.  Only then can the UI mockups be generated without introducing major
pitfalls.

How would you assess your value as a business analyst?

This question is not intended to determine how much you are looking to make. If an interviewer asks you
a question like this, they are likely looking for answers to a number of other unspoken questions such as:

Do you understand the real value a business analyst brings to an organization?

Do you ever think about the cost associated with employing you as a business analyst?

Do you have the skillset required to be a marketable business analyst?

Are your expectations of the value of a business analyst realistic?

Companies don’t hire business analysts for fun; they hire them to save money.  It’s that simple.  So how
does a business analyst save an organization money?  You might mention a few examples such as:

 Make a process more efficient saving the company time and resources (which translates as
money)
 Drive out the real requirements of a system, instead of a half-baked solution, ultimately reducing
the amount of rework and re-development required to develop a system that delivers the intended
value (rework means lost money)
  Identify opportunities for increased customer satisfaction leading to greater customer retention
and greater new customer conversions (more money)

If you have quantifiable examples of work that you have produced in the past and know precisely how
much your work saved a company (not the work of the entire team, but YOUR actual contributions) this
information can be very powerful.  This is your true value as an analyst within a similar organization and
role.  But few people have the information required to make this kind of assessment.  In addition, the
value you bring to an organization is very different from your “potential value”.  If an organization has you
writing specs for a system, your opportunity to bring value may be much lower than if you are re-
engineering a multi-million dollar business process to eliminate hundreds of thousands or even millions of
dollars of waste.

This line of reasoning leads us to the question “Do you have the skillset required to be a marketable
business analyst”?  You may have expert knowledge of traditional SDLCs and be able to create complex
analysis diagrams, but if the organizations that are hiring all require you to work in an Agile environment
then what value can you bring them?  Even though your potential value for some organizations may be
quite high, your value to others that use a different range of skills may be quite low.  This example shows
how your value is dependent upon the industry environment and the tools, competencies, and
methodologies that are popular at that time.  It also shows the need to keep your skillset current and then
stress those skills that are most relevant to the interviewing organization.

If you can talk through these concepts with an interviewer, then you will have demonstrated that you don’t
take you value as a business analyst for granted and that you are the type of person that will maximize
your value within the organization that hires you.

What is the Scrum method?

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the
development of information systems.  The Scrum method brings a small team together to work on a
specified set of features over a period of 30-days (called a sprint).

Both the term Scrum and sprint are borrowed from the sport Rugby.  A scrum is where the two teams are
engaged in a huddled to begin play following a period where play has been stopped.  The fast moving
period of play from the point of the scrum until play ends again is called a sprint.

The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team
comes together).  The kickoff meeting lasts a full day and the features of the system to be developed are
discussed.  The outcome of the kickoff meeting is a set of features that will be developed over the 30-day
sprint along with estimates of how long the analysis and development of each feature will take.

In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested,
Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps
due to an initial underestimation of the time required, the feature will be pushed to a later sprint.

Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a
short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up
meeting).  The purpose of this meeting is for the team to discuss what they accomplished the day before,
what they will accomplish over the coming day, and to raise any obstacles that they have encountered
that may impede progress.
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size.  Most
Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.

 Product Owner – identifies the features that will be included in the next 30-sprint and set the
priority of each.  This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesn’t exist.
 Scrum Master – acts much like the project manager.  While the Scrum Master does not micro-
manage the teams deliverables, this person ensures that the 30-day sprint is on track and
enforces the key rules that guide Scrum such as; no new features can be added to the sprint
once it is kicked off, and team members cannot be pulled off to work on other side project in the
middle of a sprint.
 Team Member – unlike traditional software development methods, in Scrum there is little
separation of duties between team members.  Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.

When performing Cost-Benefit Analysis using discounted cash flows, how do you select and appropriate
discount rate?

Cost-Benefit Analysis (CBA) is a critical activity in the work of a business analyst.  While many business
analysts may be brought onto a project well after this activity has occurred, nearly all projects which
require a large amount of resources (time, people, or money) are assessed based on the CBA of the
project.  The activity is typically performed by a business analyst, often one specializing in the area of
financial analysis, though any business analyst can learn this straightforward activity.

The most prominent and well known aspect of CBA is Discounted Cash Flow (DCF) analysis which
discounts future cash flows (both negative and positive) using a Discount Rate to arrive at a Net Present
Value (NPV).   This is represented by the following equation.

NPV = (FVpos – FVneg) / [(1 + i)^t]

where,

 NPV = Net Present Value

 FVpos = Future Value of a Positive Cash Flow at “t” years
 FVneg = Future Value of a Negative Cash Flow at “t” years
 i = Discount Rate
 t = time (years from present)

Future cash flows are discounted using a Discount Rate (i) that is chosen to accurately reflect several
factors:

1. Time Preference – The theory that a person or institution would rather have money in hand now
to spend on immediate wants or needs rather than waiting for future cash flows.
2. Interest – Accounts for the fact that a person or institution that doesn’t receive money for several
years also loses the opportunity to gain interest on the money for that period of time.
3. Risk Premium – Reflects the additional return that a person or institution requires on later cash
flows to account for the risk of future payments not materializing.
While the Discount Rate used for DCF calculations will vary, it becomes clear that the discount rate
should be larger than any single factor above.  If the interest that can be attained on the money that is
being tied up is %5 per year, the discount rate should certainly be higher than 5% to account for Time
Preference and the Risk Premium.