Business Analyst Interview Preparation | Real Mock Interview Session #mockinterview

YourITLearning
8.4K views • April 28, 2025

Interview Preparation for Business Analyst

00.00.40 - Tell me about yourself.
01.55.24 - How do you know that your requirement is complete?
04.11.15- When is the user Story done?
05.31.02 - How do you make sure your requirement is complete per stakeholder?
06.55.15 - Do you like Agile or Waterfall?
09.16.20- How do you plan ahead, or how do you plan your sprints?
10.28.00- What kind of documentation have you prepared, and what tools have you used?
12.13.00- Are you a leader or a follower?
13.25.24- Tell me about your last project.
14.46.11- Describe a scenario where stakeholders failed to allocate enough time to address the requirements they provided.
17.28.06- How do you welcome a new member who joins your team?

#businessanalystcourse
#businessanalyst
#businessanalystjobs
#businessanalystjob
#businessanalystinterview
#businessanalystmockinterview
#businessanalystinterviewquestions
#businessanalystjobsearch
#businessanalystinterviewpreparation
#businessanalystinterviewquestionsandanswers
#BusinessAnalystCareers
#BAPreparation
#BASkills
#BusinessAnalysisJobs
#BAInterviewTips
#businessanalysttraining
#businessanalystinterviewpreparation

0:08 Hey guys, welcome to the YouTube channel
0:10 your IT learning. So today I'm here with
0:13 Kiran. He has uh an interview call
0:16 coming up tomorrow. So I'm helping him
0:19 on a mockup interview. So we're going to
0:21 do a couple of questions related to the
0:24 business analyst, senior business
0:25 analyst and we'll just try to do one of
0:27 the mockup interviews with uh Kiran. Hi
0:29 Kiran. Hi.
0:32 So excited about your interview for
0:34 tomorrow. Yes sir I am. Okay. Yeah. To
0:38 start up with uh the first question as
0:40 uh you know they were going to ask you
0:42 is tell me about yourself. Uh so uh give
0:45 a answer in two to three minutes. Sure.
0:49 Uh my name is Kuran. I've been in this
0:50 industry for a while now. Worked for
0:52 many domains. It could be retail,
0:54 healthcare, finance. Uh been part of uh
0:57 different kind of methodology. It could
0:59 be agile, waterfall, canban. So I've
1:02 worked in all three methodologies. Apart
1:04 from that, I've been a part of entire
1:07 SDLC process. When I say SDLC is
1:09 complete software development life cycle
1:11 starting from requirement elicitation to
1:13 design, develop, test and deploy and
1:15 finally support. Uh I've been there all
1:18 the times. uh so and I have used uh
1:22 different kind of tools and stuff like
1:24 that like MS Vizios and SQL I'm very
1:28 much familiar with the with web
1:30 application mobile application very much
1:33 familiar with those SQL thing uh to
1:35 generate reports and stuff like that so
1:37 if you need uh any specific question I
1:39 can answer in more detail but that's all
1:42 no no it's absolutely great uh the first
1:44 two three minutes discussion is a good
1:46 one to give a brief introduction about
1:48 yourself and Then the other question
1:50 will going to definitely going to come
1:51 is what you have done in your last
1:52 project. Sure. Sure. So how you know
1:56 that your requirement is like you know
1:58 when you gather the requirement is
1:59 complete like it is ready to be brought
2:02 into the first meeting which is called
2:03 the refinement meeting.
2:06 Uh so when I say requirement should be
2:08 complete uh when I was studying my uh
2:11 business analyst courses. So what I had
2:13 learned is like a good user story should
2:15 follow an invest principle. When I say
2:18 invest principle, a story should be
2:20 independent. A story should be
2:21 negotiable. A story should be valuable.
2:24 A story should be small, estimable and
2:26 testable. So when I keep this word in my
2:28 mind, I believe I believe personally the
2:31 story is always uh complete. This is the
2:35 smallest like in a very small terms this
2:37 is what this means. Mhm. No, absolutely.
2:40 Absolutely. You're absolutely right. You
2:42 have to do definitely invest and uh you
2:45 know this question always comes when is
2:46 your user story is complete like user
2:48 story is complete when you feel you have
2:50 enough information to be brought in
2:52 front of the team and you can explain
2:54 them what exactly needs to be done apart
2:56 from that you know you always need to
2:58 put you know requirement gathering then
3:00 you have to put mockup not all the user
3:02 stories will going to have mockup so
3:04 whenever you feel that the user story is
3:07 complete you can bring it to refinement
3:09 because as you have worked u Kiran you
3:11 know the user story is not complete when
3:14 we feel it sometimes takes some time
3:17 effort so it always needs to be reviewed
3:19 and the refinement is a great platform
3:21 where you can bring that to your I will
3:23 say team yeah in my previous experience
3:26 like we usually follow something called
3:27 definition of ready uh by the
3:29 development team and by our stakeholders
3:30 as well so in that definition of ready
3:33 basically means a good user story should
3:35 have a a nice user story and acceptance
3:38 criteria does it have a data mapping
3:39 document does it have process flow
3:41 diagram does it have etc etc etc so so
3:44 these are set of definition and this
3:45 changes every sprint every every retro
3:47 uh the things which are not good we
3:49 remove it the things we need to add we
3:51 will add into the definition of ready to
3:52 make sure with every every spin we get
3:54 better and better so and that's the
3:57 that's the base which I follow uh as a
3:59 definition of ready to write a good user
4:01 story no that's that's good that's good
4:04 u so when you have talked about uh when
4:07 a user story is ready my next question
4:09 will be when the user story is done.
4:12 Okay, definition of done is another
4:15 important thing. Uh when I say when the
4:17 QA when the testing team does its job
4:20 and get it approval, uh that's where the
4:23 point is called definition of done. When
4:24 they say from a development point of
4:26 view, they will do the unit testing,
4:27 they will do regression testing and
4:29 after that it went to QA and they will
4:31 perform all kind of test cases, they
4:32 will write all kind of test cases, they
4:33 create test plans and they will do UAT
4:35 testing and they will also do the API
4:36 testing if it's required. But uh in
4:39 order story to be complete the all the
4:40 checklist in the story whatever the
4:42 acceptance criteria I have written down
4:44 if they if they clearly go line by line
4:47 if they met all the requirements and
4:49 also uh whatever the criteria they have
4:52 mentioned in the definition of done
4:53 requirements I believe the story is
4:55 complete and we finally bring it out for
4:57 the student review meeting with our
4:59 stakeholders and make sure everything is
5:01 good to go. If it is little bit of
5:03 hiccups, a little bit of here and there,
5:05 we'll definitely take those points and
5:07 we'll create a story, put it in the
5:08 product backlog and based on the urgency
5:10 need, uh we'll we'll take up that story
5:12 and and
5:13 and do the regular SDLC process. Cool.
5:17 No, it's very good answer. Yes, you're
5:19 right. If there's anything need changes
5:21 need to be needed, then you we have to
5:22 again write the user stories and need to
5:25 do that one. So my next question will be
5:28 how you make sure that your requirement
5:30 is complete as per the stakeholder.
5:34 Uh I would say requirements would be
5:36 complete only there are first of all in
5:39 order to comment to complete I need to
5:40 talk with stakeholders. There are
5:42 different elication methods which I need
5:43 to either go uh I can talk as a chat
5:45 session I can do interviews I can do
5:47 one-on-one session I can ask open-ended
5:49 question close-ended questions uh all
5:51 together. Uh sometimes stakeholder
5:53 doesn't know what they want. I might
5:54 have to create a mockups or wireframe
5:56 using palsmake or draw.io there
5:58 different type of software. So at the uh
6:01 at the end of the day I need to get the
6:02 requirements. So once we get the
6:03 requirements I'll take the meeting
6:05 notes. I'll I'll I'll I'll go through
6:07 the meeting roles write in my own words
6:09 and for get a formal approval by sending
6:11 out an email to them saying hey these
6:13 are the requirements which you which we
6:15 just discussed and I hope these are
6:17 correct. If you need anything else apart
6:19 from these requirements, feel free to
6:20 contact and if they have any concerns on
6:22 this particular requirements, they will
6:24 say yes uh the requirements are good to
6:26 go. At the same time, I will also
6:27 include my dev leads and QA lead as well
6:30 to make sure this requirements pass the
6:33 physibility check uh as well to so that
6:37 we can we can we can start working on
6:39 those uh requirements as well. Yes. No,
6:41 absolutely. uh and uh everything what
6:43 you do try to get everything onto a
6:45 confirmation as an email uh you know not
6:48 the verbal communication something on
6:49 the paper will always going to help you
6:52 um my next question will be uh do you
6:54 like agile or waterfall
6:57 uh it depends upon the project to
6:58 project I would say uh what I feel from
7:01 a agile point of view it's more
7:03 customercentric whereas the waterfall is
7:05 more uh from a from a backend point of
7:08 view if you're working on lot of API
7:10 services backend system where you cannot
7:12 define from a user point of view. I
7:15 believe those cases uh you you'll tend
7:18 to go in waterfall but when you tend to
7:20 go towards more towards the user
7:21 friendly uh scenario you'll tend to go
7:24 in agile and also the good thing about
7:26 the agile not only that from a user
7:28 point of also good thing agile is you'll
7:30 in every iteration you'll you'll you'll
7:32 get a MVP out of it a minimum viable
7:34 product out of it so every every sprint
7:37 you add small things to make a bigger
7:39 project whereas in waterfall you might
7:41 be seeing a quarterly release or two
7:43 month release where I have to write a
7:46 bunch of uh BR documentation then I have
7:48 to translate those BR then I have to get
7:49 an approval then I transfer those into
7:51 FSD documents function specific
7:53 documentation get an approval from a QA
7:54 lead development lead and then they
7:56 start working on the requirements and
7:57 they no one has any clue during that
7:59 time until it gets released and it might
8:02 be a surprise for the stakeholders it
8:04 may not but usually um if usually it is
8:08 a it is a some sort of surprise on the
8:10 requirements a little bit here and there
8:12 but in order to change then again you
8:13 have to file the change request it it
8:15 gets delayed. Whereas the agile I would
8:18 say if if you don't like what you're
8:20 doing in the first sprint review
8:22 stakeholders say hey I didn't like this
8:25 uh popup or I didn't like this check or
8:27 I didn't like this requirement uh can
8:29 you please modify it? So we can take his
8:31 input we can definitely update the user
8:33 story and put it in the product backlog.
8:35 So by the way so you're continuously
8:37 engaging your stakeholders and making
8:39 things better and better. I prefer
8:42 that's the reason agile is more
8:44 convenient in terms of waterfall. No,
8:47 absolutely absolutely your answer is
8:48 absolutely right. It's not our
8:50 requirement. It's actually the
8:51 requirement of the project. Couple of
8:52 projects will go awesome in agile and
8:54 couple of them I know waterfall is still
8:57 not used but maybe one or two projects
8:59 might be better to be suited for
9:01 waterfall. Uh that's a good question.
9:04 Um so when you are working in your
9:08 sprints
9:10 uh how do you align your next two
9:12 sprints like uh you know how do you work
9:15 uh do you make your next two sprints uh
9:17 in advance one sprint in advance how do
9:21 you uh how do you tackle to all the
9:23 requirements coming to you and how you
9:25 put them into your uh uh sprints next
9:28 two sprints. So as a as a business
9:31 analyst or a business system analyst
9:32 role uh it's our due diligence to make
9:35 sure you are always ahead of at least
9:37 one sprint to two sprints because you
9:39 don't want to keep your development team
9:41 and testing team in idle position. So
9:43 once they're done with stories they they
9:44 never they don't have enough work to do
9:46 it. They don't we have the capacity but
9:48 they don't have enough work to do it. So
9:49 I always make sure at least we run at
9:52 least a sprint ahead so that uh our
9:54 development team has the work for the
9:56 next sprint and it's my responsibility
9:59 how I engage with my stakeholder. It's
10:01 my responsibility how I engage with the
10:03 product owner to get that velocity or
10:05 get that capacity of our work which is
10:08 needed for the next sprint. So I usually
10:10 engage with them, write down the
10:12 stories, go to sprint uh refinement
10:14 session, ask all those questions, if the
10:17 stories are good, get a formal approval,
10:19 put it in the product backlog ensure it
10:21 is ready whenever they want to take the
10:23 stories based on the uh priority backlog
10:25 they can do it. Yes. Okay. What kind of
10:28 documentation have you prepared and what
10:30 kind of tools you have used to prepare
10:32 any kind of documentation? Uh if I start
10:35 from waterfall, I have created a
10:36 business specification documentation. uh
10:38 I've created functional specification
10:40 documentation. Uh I haven't touched that
10:43 much of SRS documentation because that
10:45 is uh very much technical but I have
10:47 involved with the development team to
10:48 write those documentation as well.
10:50 Coming to the agile uh we just I just
10:52 created a project charter project scope
10:54 those are the two primary documentation
10:56 in agile world. Apart from that most of
10:57 the requirement which we wrote it down
10:59 in the form of epics features and user
11:02 stories as well. Apart from that, every
11:05 time you write a story, you always have
11:06 to create those basic documentation like
11:08 data mapping, data dictionary, those are
11:10 always needed because if you are mapping
11:12 any kind of documentation, if you're
11:13 sending or if you're pushing data to one
11:15 system to another system, these are the
11:16 minimum required of documentation you
11:18 need to have. Apart from that, some of
11:20 the key tools which have used is likely
11:22 J, TFS version one. I have familiar with
11:24 those all those tools. It's like uh
11:26 Facebook and Instagram two different
11:28 platform but kind of same job they're
11:30 doing it. I have used vizio uh to create
11:32 my process flows. I have used SQL uh to
11:36 make sure uh I can extract the data and
11:38 I make sure that right data is falling
11:40 into the right tables. So how do I check
11:42 it? I use a SQL to run a query and see
11:45 uh how the data has been falling into
11:47 the database. Ive used SQL as well. I
11:49 have used a little bit of tableau here
11:50 and there just to get those uh tabular
11:53 data into a visual format. It could be a
11:54 bar graph, py etc. We have used those
11:56 tableau or powerbi as well.
12:00 Okay. Okay. Uh, no that's good. Uh, uh,
12:03 that's a great answer and uh, I don't
12:05 have anything to add. So that's why I
12:07 was just thinking.
12:09 Uh, so my next question will be uh, are
12:13 you a leader or a follower?
12:17 Uh, that's a very good question. A good
12:19 leader should be a good follower. First
12:21 of all, if he learns how to respect how
12:24 to follow your leader, then he will
12:26 become a leader. So as a during the
12:28 journey during my start of my journey as
12:30 a business analyst career I've seen lead
12:32 business analyst I've seen product
12:33 owners project manager how they define
12:35 how they engage with other folks how
12:37 they engage in the meeting how they do
12:39 the meeting notes how they collaborate
12:41 with them so you start learning with
12:43 those people so slowly step by step I
12:45 I'm seeing my leaders over there and I'm
12:47 started grasping those things good
12:49 things and and now I have been a role of
12:52 a scrum master I've been a role as a
12:53 product owner in few of my projects I
12:55 have used those uh abilities uh whatever
12:58 I gained in my past experience. No,
13:00 you're absolutely right. You know, it
13:02 depends upon the time uh of the project
13:04 as well. Sometimes it's good to be a
13:06 leader, sometimes it's good to be a
13:07 follower as well. Whatever you know, hit
13:10 and try method can work uh to enhance
13:14 your uh I will say the performance or or
13:16 maybe get the project as soon as
13:18 possible. Uh so there's no harm in being
13:21 a follower or a leader I will say. Uh
13:24 tell me about your last project. what
13:26 you worked on what were the top three
13:28 two or three things you were working on
13:31 uh so the last project which has worked
13:33 on uh was to design a web application
13:35 and that application also can be used in
13:37 iPad and as well as your mobile
13:38 application so it's mostly a title and a
13:40 home insurance application which we have
13:42 created so since we have that
13:44 application needs to be engaged with
13:46 many financial institutions like US
13:48 banks Fargo PNC etc so with a lot of API
13:51 services which we need to make so every
13:54 time whenever we need to engage with
13:56 those institutions. They share us the
13:57 API guide. I usually go through that API
13:59 guide in the JSON format and we uh we
14:02 check in our system what all API service
14:04 we provide and in order to do them data
14:06 mapping. So I'll create a data mapping
14:08 documentation. I'll create a data
14:09 dictionary documentation as well. Uh and
14:11 also create user story based on the API
14:14 requirements. These are these are
14:15 something related to the back end. How
14:17 about the front end? So the front end
14:19 systems are something from our user
14:21 point of view which our agents going to
14:23 use. So I have created multiple
14:25 dashboards, multiple uh security pages,
14:27 multiple homepages, multiple uh other uh
14:31 title related uh service pages I have
14:33 created along with that. So uh and the
14:36 regular BSA work which we need to do it
14:38 in a day-to-day basis, we have created
14:40 that as well. Nice. Nice. Thank you.
14:43 Have you ever been into the situation
14:45 where the stakeholder doesn't give you
14:48 enough time to gather the requirements
14:50 wanted to get his things done as soon as
14:52 possible? Uh I have faced this kind of
14:55 situation before. Uh stakeholder do get
14:58 tough sometimes but uh uh it is your
15:01 responsibility to engage with the
15:03 stakeholders do a one-on-one session ask
15:06 all those question open-ended question
15:07 close-end questions. If he's not clear
15:09 with the requirements, create a mockup,
15:11 create a wireframe, uh if if needed, you
15:14 can always engage your uh dev dev leads
15:17 or your product owners as well to to
15:19 further flush out the requests what they
15:21 are looking for and always keep the
15:22 meeting notes handy with you. And every
15:24 time you're done with your meeting, just
15:27 go through the meeting tell this is
15:28 these are this is what we discussed and
15:29 this is the outcome of this is what we
15:31 decided to do. So if you go through
15:33 these steps I think stakeholder will
15:35 feel they are engaged with the project
15:37 and they love to collaborate with you uh
15:39 in giving uh in providing the solution
15:41 which you are looking for. What are the
15:44 skills you feel a BA should have in
15:47 order to be successful.
15:50 A BA from a from my point of which I
15:53 gained is a good BA should be a first a
15:56 good listener. He has to listen all the
15:59 requirements what whether product owner
16:01 is saying whether your stakeholders are
16:03 saying whether he needs to understand
16:05 what they are saying. He should be a
16:07 good listener before he should start
16:09 speaking. So the good listener is a
16:11 primary thing. Apart from that he should
16:13 have a good communication skills. He
16:15 should have good writing skills as well
16:17 because whatever the requirements you're
16:18 going to write it down those are the
16:19 requirements that going to be
16:20 implemented from a UT point of view or
16:23 from a API point of view. So those three
16:25 are the key things. Next is the
16:27 collaboration skills because he needs to
16:29 continuously engage with the
16:30 stakeholders and your uh development and
16:33 testing team. So good collaboration
16:35 skills as well and he he should be fast
16:38 enough uh whom to involve and how to
16:41 involve and approach the right people at
16:43 the right time because in a big meetings
16:46 there is always a scope going on because
16:48 everyone is from different organization
16:51 different department they will speak on
16:52 their own. you should make sure what is
16:55 aligned with the project. You should
16:56 keep the project scope uh with you and
16:58 make sure everyone is aligned with it.
17:00 So you should be a good facilitator as
17:03 well. So these are the few things which
17:04 I believe a good BA should have. No no
17:07 absolutely at the end of the day the BA
17:09 role is to make sure that the project
17:10 keeps on going step by step in the right
17:12 direction. So you are right you should
17:14 be a good facilitator. If the if the
17:16 meeting is derailing from the topic, you
17:18 should make sure that you bring it back
17:20 to uh the main uh discussion for which
17:23 the meeting has been called. U it is it
17:26 is nice. Has it ever been a situation
17:28 where you are training BAS or you know
17:32 uh bringing on board uh or maybe I will
17:34 say what do you what do you do once a
17:37 new developer joins your team or once a
17:40 new QA joins your team? What are your
17:42 qualifications to make sure that that
17:44 developer or a QA or any other member
17:46 feels comfortable in your team? Uh
17:49 whether a new developer joins the team
17:52 or a QA joins the team whether I stay in
17:55 the team or I left the team it doesn't
17:57 matter. My requirements are so crisp so
17:59 clean so simple even even even a 12th
18:03 grade understand like what kind of
18:05 English I'm using. It's a very simple
18:06 English which a developer and a QA can
18:08 understand what he needs to do. But it
18:10 is my due diligence to understand if
18:12 it's a first time coming on board. We
18:14 definitely going to have one-on-one
18:15 session with him just to tell him what
18:17 is this whole project all about and and
18:19 which sprint are we in what all things
18:21 we have done and what all things we need
18:23 to be implemented. So I will give you a
18:25 overall experience what all things have
18:27 been done. Apart from that I will show
18:29 you this is how the we uh we write the
18:32 user stories. This is the terminology we
18:34 follow as a definition of ready. These
18:36 are set of requirements which you
18:37 follow. If you feel anything different,
18:39 if you feel you want to add something,
18:40 you can always bring this uh points in
18:42 your sprint retro. So you can always
18:44 modify this definition of ready. Apart
18:46 from that, I will talk him about the
18:47 entire system architecture what is uh
18:50 what is there in the organization and if
18:53 you have any questions I ask him like
18:54 you can always feel to engage me in
18:56 terms of requirements. Uh we can we can
18:59 have a call once in two days, half an
19:01 hour call, quick call if you need it
19:03 just to get you in the same level of
19:05 pace. rest uh your dev leads are always
19:07 there. You can always touch base with
19:08 them to make sure uh we got a smooth uh
19:12 flow of the project. Cool. Uh no uh
19:15 you're very good prepared your
19:16 preparation is very well. Do you have
19:18 any questions for me Kiran? I don't
19:20 think I unless uh I don't I I use my
19:23 questions random questions for you. Have
19:25 do you have any questions for me? Uh I
19:27 think uh I I do not like but I have
19:29 prepared some set of questions uh for
19:31 the interviewer like uh what is my
19:33 day-to-day job going to look like and is
19:35 the start of the project or we are we in
19:37 the middle of the project so I have some
19:39 prepared some questions for yeah these
19:41 are very good questions for the end of
19:42 the interview when the interviewer says
19:44 do you have any questions because we
19:46 should always ask some question it's it
19:48 it tells the interviewer that you are
19:51 interested in the job you are there uh
19:54 you are looking forward to join their
19:55 team so yes you can ask them Hey, what
19:57 my day will look like. Is it a new
19:59 project or an old project? Uh once I
20:03 start uh on on my first day, what are
20:06 the things you are looking from me?
20:08 Sure. Or maybe what you want me to do in
20:10 my first week as soon as I start my job.
20:12 So these are very good questions to ask
20:15 at the end. Right. Right. Thank you.
20:17 Thank you, J. Yeah, definitely ask those
20:18 question. Yep. Any more questions? Nope.
20:21 I think I'm good. Cool. Kiran, thank you
20:23 so much for joining us today. Uh it was
20:26 very fruitful. So guys, thank thanks for
20:28 watching our video. Uh we had a mockup
20:30 interview with Kiran. I wish him all the
20:33 success. Uh once he gets a job offer,
20:36 we'll have another interview call or in
20:38 another uh one-on-one session to let
20:41 everyone know what kind of questions he
20:43 got and how he tackled those questions.
20:45 So, thank you so much, guys. Have a nice
20:47 day. Bye. Bye. Bye.