[ 3 Offers] business analyst interview questions and answers | business analyst interview questions

friends good news multiple job offers are back today's business analyst interview questions were shared by a member of her WhatsApp group she recently received three offers from companies like CGI bio and deoy hello everyone and welcome to ker stock my name is ran Sharma I'm agile consultant based in Netherlands and on this channel we invite industry experts to share their valuable experience and insight with all of us before we get started if you are new to our Channel please make sure to hit the subscribe button and join our career Stock family at the end of

the session don't forget to smash that like button leave a comment to let us know what you thought about this session your support means a lot to us and it help us to keep bringing you valuable content so without further delay let's get started welcome Nia and thank you for joining us today Nia over to you thank thank you Sunan for having me in this session so my many of my friends have watched your channel and got uh job offers so it's my pleasure to be here as a guest speaker thank you thank you okay

so if you allow shall we start yes sirman okay uh so the very first question is you are analyzing user behavior for a mobile app and you notice a significant drop off at a specific stages in the user Journey so how would you investigate the cause of this drop off and what different methods would you use to gather and analyze all these you know data from the user journey to identify the potential improvement over the period of time yeah over to you uh for this question I would uh typically uh you bring in two or

three multiple components from a business analyst point of view first is a data analysis I would start with a quantitative data to pinpoint where exactly this drop off occurs and uh there will be different metrics that any app form monitors when we were uh in that area we used to monitor conversion rate session duration all this will give you enough uh insights on what exactly is happening we also have new tools like Google analytics Firebase which can help me to drill down the pattern based on the user profile and uh typically I would need to

do a user Journey mapping because I need to know which exact place or flow where in this drop off occurs whether it is at a payment Gateway whether it is expecting some response from some other system this would like help me determine what exactly is happening in that area and once I find that out based on this quantitative and qualitative data I will do a root cause analysis typically many companies have many ways of doing it so we generally go with five wi or fishbone diagram to drill down to root cause of why it is

happening once it is done I'm still not clear on this drop off I would also take a user feedback or service uh definitely user feedback or survey in terms of people who have successfully cleared that path and got a final end to end and and also those who has dropped off so your user survey population has to be wide enough to C all this two segment and uh once I done I will also do a usability testing of my app see there there can be multiple ux issues also so when we were in doing that

mobile app for our internet banking uh site we noticed that people click in the non-clickable areas like uh because of design issues so adjusting the button or giving a contrast and simple things like that can could also be an issue so I would also do a round of usability testing once all this is done I would uh do a performance analysis technical performance analysis like API failure or Crasher and uh I would also do a testing for solution validation and then keep monitoring this you user stats or uh this quantitative and qualitative data I will

keep on monitoring till I am sure that this solution is finalized so this is how Sunan I would approach this problem wonderful yeah yeah thank you for that elaborated answer yeah so shall we move on to the next one sure okay so let's say that your team is working on developing a new feature for let's say e-commerce platform and during a spint planning uh session a developer raise a concern about a user story that is not you know detailed enough so how would you approach refining these user stories to ensure that it is clear and

you know actionable for the developers so if you can share what steps would you take to gather more information that will be great okay so in our team we typically have something called uh definition of ready like when are this user stories ready to be taken up by the development team so develop technical team they generally have some criterias right ux element should be finalized mock should be ready and uh a requirement should be frozen so unless all those are ready development team will not pick up a particular story so we have something called this

definition of already so I would insist that all the jail teams should follow this because it makes uh it makes a product owner really commit to his story and give him all the detail before uh user story is being picked up in this case also I would make sure that my scrum team follows this and then uh few other uh items like uh I would uh start revisiting the user story Purpose with the team if it definitely lacks detail I would gather more details from the business team and uh also in our company we follow

this all the user stories should follow the inverse criteria inverse criteria is very common in aile world and uh everyone would be knowing that it is independent negotiable valuable estimat small and testable so if the user story is following all this criteria that is a definition of uh of a good user story so we generally follow it and also many of the problems like uh developer typically faces would be clarified if we have a clear acceptance criteria so I would try to clarify or provide it acceptance criteria as clear as possible and then um we

also have a user story refinement section with QA developers and testing team we have it on schedule at every week so does many agile many scrum team so this this would be a pra if this is a practice then developers or the technical team will not come to us uh while during the Sprint and say that user story is lacking detail so I would also insist this as one of the best practice and then uh I would also gather information from other scrum teams on how they are following their standards in the uh in the

story and if the typically many of the problems would occur because we have a large story so we break it down into smaller story some some of the teams won't even accept smaller story but smaller the story easy it is to manage so this is another uh thing I would follow and then if there is a documentation issue like assumptions and dependencies so many of us missed to noted down that especially a technical dependency or technical ass assumption all those should be documented in a user story or there should be at least a reference point

where these things can be referred so definitely I would follow all the steps to make the user story uh clear so over to you Sunan hope this answer is clarified yes yes yes great yeah thank you for that okay uh let's move on uh to the next one so let's say during a project uh you are presented with a proposed software architect that you believe might not scale well you know as the user demand increase over the period of time so how would you evaluate the proposed architecture and what factors would you consider like how

would you communicate your concerns to your team and other stakeholders so if you can throw some light that will be great okay uh so typically every business analyst comes across the software architecture at the beginning of the project so some of us would have even faced this scenario and those who are in inter uh mobile app or uh internet app kind of projects definitely we would have faced it so most likely I would go for load handling so how much load my app can uh currently handle I would also uh project it with the the

data on current number of uses and current number of transactions and how much this proposed architecture can handle it and whether it has uh horizontal scaling capability like if I add more features how would the architecture behave or if I add more number of uses how would the architecture behave next is uh these days everything is modular so if the architecture is limited but it can be scaled easily based on uh some other technical aspect we are fine with that too as long as that scalability issues are addressed we are fine I would check that

whether the architecture has that modular design also on data storage and management So currently this is the capacity what happen once if we have Forex growth that we are projecting whether the data storage and management aspects are handled and uh how about the fault tolerance like uh redundancy failover how are those handled once I have assertain this data I would most of the key thing as a product owner is communicating so we have to communicate in a language that all the stakeholders Buy in from us rather than projecting it as a mistake or something we

can project it as an opportunity for improvement uh so our growth is 10x from the current uh user uh uh user count so this architecture doesn't seem to have that uh 10x growth factor and the cost of implementing we can also utilize those data points like cost of doing it once right rather than scaling up at a later stage and trying to switch over to a different architecture at a later State and rather than find going on a fault finding mode we have to go and propose a solution like catching mechanism consider micros services or

cloudbased scalability tool all those are very much being used by any uh mobile Appy so I will also suggest that and then uh I will also help to collaborate different sections with uh existing teams and uh already teams who has already done in a large scale I will also do that and moreover as a business analy we should always take it back to the business impact we should uh say that in terms of stakeholders to uh perspective in terms of our business perspective this is what is uh expected in another two or three years so

given this architecture we will not be there in another three years so the all those reasons along with proper communication would resolve the issue so sonan this is how I would approach wonderful yeah thank you for that great okay uh let's move on uh the next question is let's say you are supposed to integrate a new payment Gateway API into the existing application and U during the initial review you discover that the API documentation is incomplete so how would you manage this kind of situation and what different steps would you take to ensure a successful

integration while you have to address all these gaps in the documentation part okay uh I should say that I have even faced the scenario in real time so in this case what I have done is that gone through the documentation and uh seriously identified gaps where exactly those details are missing say some of those might be uh some sections which are it is a real documentation issue not an Gap in terms of uh feature so in those case I would highlight those and go back to the concern payment provider technical support team and ask for

the clarity on missing detail if they have a specific say some many of those technical support team has online documentation so if they provide any online documentation that would be good else uh I would try and understand uh from the team on the target asking the targeted questions on uh accurate information otherwise uh if there is an kind of a forum or Community for this kind of payment app many of the payment apps have the community from or focused Forum in which I can also take those detail second is uh we we have many sandbox

environment to test the apas whether it is a sample call or end to endend checkpoint all those things we can do it nowadays so I will use this documentation to do a round of uh testing in the sand box environment and uh I would also make sure that uh uh whether all the scenarios are captured in the documentation say for example some error handling all those things are not captured I would note all those down and I would take the support of technical uh Team in those case the vendar team to get those answers for

that and update it myself I would also use my company's existing projects who has been using this uh particular payment FPA if they have been using I would take their help too I can also take help from uh jet Hub or any other development communities where these kind of uh examples or how to approach this situation would be available main thing is I should also document all this thing and make this comprehensive as I work through this integration I should also keep all the stakeholders like we should have the business team or technical management team

all our hups informed about all those process because all this will be a trial and error process many times an incomplete documentation can several things so we should also keep them informed so this is how I would approach this situation Sunan yeah wonderful yeah thank you for that great let's move on to our next question uh next question is on uat so let's say you are leading a u phase for a critical software release and some of the stakeholders are reluctant to participant like they are coming up with some excuse let's say they are having

a busy schedule and things like that so how would you um encourage stakeholder to participate in a u and you know how do you ensure that their feedback is incorporated properly into the final product yeah okay uh in this case uh though we and a jail and ronment and everyone should be working in a Sprint many of the time the clients if they have to involve in testing they have lot many things to handle and they don't generally come to the uh testing participation this is what I have observed in our case typically for my

day-to-day project I inform stakeholders will in advance of this is the typical time where I would require you for testing I would also give them enough notice so that they are available second um most if they aren available I would take the business scenario from them uh generally we have two different testing team and then a final business testing the what our internal testing team test will be nowhere relevant to what business want so the taking those testing scenarios from the client and then giving to our QA team would make sure that there scarios and

all those concern areas are addressed internally this is something we will do and uh so typically client testing would be done by our internal QA team so that it is addressed and then I will schedule a demo wherein I would say that this was your requirement this is how we have tested and this is how it is would you like to participate if they are not we would do the testing on their behalf and then uh send the screenshots various uh testing evidences to say that at least go through this now and say whether you

are ready to sign this off and then uh take it uh so this is how I would typically handle it one okay wonderful yeah great uh let's move on uh so next question is on uh processing process map so let's say your organization is experienced a delay in Project delivery due to lot of unclear processes so and you have been asked to create a process map to identify all these you know inefficiencies so what step would you take to create a effective process map and uh how are you going to involve the stakeholder into this

process yeah okay sure so I would start with the basics of what exactly is my immediate uh deliverable or what should I focus on an organization can be doing multiple things wrong all those cannot be scope of my process flow or process map so I would just try to focus Break Down The process by focusing my area section by section so I would identify that which of the particular process is causing huge delay and go for the particular process I would also try try and understand what is currently being followed whether it is like many

of the time there would be some existing documentation so I can uh I would go through that and see what exactly is the lag or I can do a job shadowing I would typically try to observe what is being done and then proceed with that if people are uh ready to talk about it I would conduct an interview and workshop to understand what is the current process being followed So based on all this I would have some clear-cut information of current process and then using what I have gathered I would do an initial process map

like like identify key steps activities so major task what is the exact decision point I would create that flow I would also maintain that uh BPM and business process model notation so that it is consistent throughout once this step is done once I have a draft process map I would invite all those stakeholders so I can create a number of process map it is it is going to be of no use unless until stakeholders agrees to follow the process map or tell me where exactly is the problem so I would focus more on conducting a

collaborative sessions with stakeholders to understand how this new process map will work or whether they have any inputs on this new map once I have done that I would also facilitate open communication regarding the same based on this input I would refine this uh process map I would update uh based on those those input and then I would finally share this process maps with all the stakeholders involved and then I would keep it available in a common repository and then train everyone to read the process map and follow the process map so this training is

typically important because we can create the process map what is important is people should understand and follow it once this is done I would monitor for some time to understand the effectivity if it is not effective I would just go back again to the drawing board to refine this so this is again a continuous improvement process I will have to do it for a few iteration till it settled so sonan this is how I would approach this problem yeah wonderful yeah thank you for that great uh let's move on so next question is let's say

you are working on a product requirement document which is PRD uh for let's say some new feature but you one of your uh uh stakeholders expect the features to work differently so how would you align these expectations to make sure that the PRD meets the business needs and uh yeah I mean what step would you take to finalize this document okay so in this question typically I would uh try to understand this uh stakeholders perspective so he might have his expectation and rational for the descided functionality so the best one product owner has to do

is at least have few discussion with the stakeholder to understand the background behind this requirement and uh clarify it so once that is done if the stakeholder has a genuine requirement I would go back to the Book Project scope uh anything uh typical product owner does should always align it back to a business or pro project goal so if it fits the project goal and if I have genuinely missed it I would have to accept it and then include it in our uh project whether it is in backlog whether it is in next iteration is

another thing uh I should include it in the project scope so to do that I would have a discussion with the business team on saying there is such requirement from the stakeholders and uh take their concurrence to includeed in the project scope once this is done uh there is typical need to have a different workshop on how this new requirements would fit in with our earlier requirement this this is required with other stakeholders project managers Etc so I would do that I would take ownership of that and uh clarify this with other uh teams as

well and once uh uh this is done I would document all this requirement with uh in the form of uh PRD and I would communicate it to the stakeholder who has raised it on saying here is how I have documented whether he is okay enough once he is uh okay with the way that requirement has been captured in the PRD I would finalize the PRD and take the sign up this is how I would typically handle this sonan okay great wonderful yeah thank you uh let's move on so let's say you need to uh communicate

a complex U System integation to both Technical and non-technical stakeholders using uh few diagram so what types of diagram would you consider using in this case and U how do you ensure that all your diagrams are understandable by all your audience so they are both Technical and non-technical Okay so Bally a product owner or a business analyst has to talk in multiple languages so to do that mostly most of us would follow different diagram to business it is always about uh what features are getting delivered and when so a higher level flow or something is

typically done for business and for a technical team it is like drilling down to detail so both of them need a different uh type of diagram so in this case I would use a system context diagram so this is this will cover the external entities users systems and data sources this would provide a overall view for non-technical stakeholder and then I would also use data flow diagram this data flow diagram many of us would have used it it is very great to show how data interacts with different process and all that I would uh use

it mainly for the technical team for non-technical team I would use use case diagram use case diagrams are really great in saying how users typically interact with the system so I would use use case diagrams for non-technical audience sequence diagram I would use it for technical stakeholders because they break down a step show the interaction between different systems so sequence diagram is good for technical audience and then for both the audience I would use a component diagram for higher level component diagrams for a non-technical audience once I would break it down to a level for

technical audience so irrespective of whatever uh diagrams I use one thing that has to be maintained this Simplicity and uh labeling so many many of the times uh we produce diagrams which it is not friendly to understand so use lot of visual cues colors icons and symbols to denote uh differentiate uh process component so that it is clear and add those annotations and explanation in those diagrams and also engage with different stakeholders and in terms of explaining this diagram most of the time the issue with diagrams is the readability so if there is inertial understanding

to them on how to read and understand this diagram most of them it will be simple to handle so this hope this answers your question soon yes uh yeah thank you for that yeah wonderful okay so let's move on to our next question so your team U use J for project management but you notice that your backlog is not being prioritized yeah I mean it's not ordered properly so that lead to a lot of confusion among the team member so how you going to address this issue maybe you going to talk to the product own

or let's say what different steps would you take to improve your uh backl privatization and you have to ensure that your team is aligned on the most critical task first right so it's a typical difficult situation and yeah let's see how you going to tackle it to do this I would have to understand what is currently being uh followed so current uh understanding this current prioritization process with a current product manager or the technical team to understand how it is done and uh uh like if there is any gaps say for for the time just

this is in July release so I'm taking it to July release if organization has such policies I can identify that then next step is understand the business goals and vision so there will be typical goals like I I need to have this web page at the end of this quarter or something some other goal so our prioritization process should always take us towards that goal so once uh I would also get those goals confirmed with our uh business team once this is done I I would do a prioritization of by a clog I would identify

those uh we typically follow mosco must have should have could have and don't have during our prioritization process I understand many of the team also use rise model reach impact confidence and effort so I one any one of this prioritization criteria for our current backlog items and then I would schedule this uh backlog refinement session at least uh once uh once before every Sprint or twice in a month we typically have it twice in a month so wherein we will uh discuss about uh which are all the important we do the refinement uh with all

the development team so we review prioritize do everything in this session so I would use that after doing all this jir has many uh custom filters and uh tools to make this prioritization easy so I would use all those to create the custom dashboard so which where in it will highlight the top priority items many of the time Point problem is visibility no we will be following some process but you users or developers or business team would not know that where to find it so I often find those information readily available will solve many of

this problem so I would use all those G dashboards and uh filters to make the things very visible once this is done my backlog would be in correct priority and uh it will be refined so I would communicate this status to our uh technical team and everyone I would also do a regular uh catch up with other stakeholders to understand whether this prioritization is being effective so the since all the prioritization all the refinement is a continuous process I would do this for few iterations to see that whether I am following the correct process so

this is how I would take it soon wonderful uh yeah wonderful thank you ni for that and with this I think we are just came to end of our session so thank you again for sharing all the detail answers and uh yeah all the best for your next assignment and thank you friend for joining us for today's session we hope you found it helpful and informative and if you enjoyed the session please don't forget to like And subscribe to our Channel we hope to see you in our next session until then take care this is

shma signing off bye everyone and thank you Nia one more time thank you thank you sonan for giving me this opportunity it was really wonderful to talk to the audience and interesting set of questions also I should say thank you thank you so