Pratique du Shadowing: Business Analyst Interview Questions & Answers - Scenario Based Questions - Apprendre l'anglais à l'oral avec la vidéo
Choisissez un mode d'entraînement
Chaque mode ouvre une salle d'entraînement en plein écran.
205 phrases
Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.
1
I'm going to be trying my best to answer 12 scenario -based questions to try to assess a candidate's practical knowledge,
2
problem -solving skills, and ability to apply business analysis techniques to real -world situations.
3
scenario A stakeholder provides vague requirements for a new requirement.
4
How would you proceed to clarify and document these requirements?
5
The first thing I would do is try to paint a bigger picture of what the situation is.
6
So I'm going to want to learn more about the context.
7
Like, why are we even trying to solve this problem?
8
What is the problem that we're trying to solve?
9
What is the intended value that we're trying to get?
10
at the end of this project or this requirement.
11
And really, all of those things that should have happened prior to somebody giving me a vague requirement, usually -- What you'll see is if the requirements fake,
12
then it's possible that some of that upfront work hasn't been done properly that's kind of strategic analysis.
13
So I really start to help build or paint that picture who for whoever the stakeholders, so they could better understand what it is that they're trying to accomplish and then go back and clarify those requirements.
14
You are working on a project with conflicting stakeholder interests.
15
How do you manage and align these interests to ensure project success?
16
Very similar to the last one.
17
Your goal is, again, is to make sure everyone's aligned on what the actual goal of the project is.
18
What's the objective?
19
What's the value that we're trying to achieve at the end?
20
And then you take these conflicting requirements, these conflicting needs, these conflicting asks, and you align them to what the objective is and what that value is that you're trying to deliver,
21
and then get those stakeholders to come into the room and say, "Hey, these are the things that you guys are asking for
22
but these are the goals of the project and these are how they do or don't align to that.
23
So how can we make adjustments to make sure we're building things
24
and doing the right things that actually align to the goals of the project itself?
25
You have a list of requirements.
26
But due to time and budget constraints, not all can be implemented.
27
how do you prioritize which requirements to work on first?
28
That's a great question, and pretty much the day -to -day of anybody working on a software team that you know, trying to build something that's productive and valuable.
29
And the way you do it is essentially you document all those requirements.
30
You document characteristics about those requirements that help you weigh them against one another.
31
For example, if there's a particular value that you're trying to achieve with your initiative for which these requirements exist, or your product, or whatever it is,
32
to make sure you document in some way how to -- how rank how much value
33
that these things are delivering and also how much effort it takes to deliver these things.
34
You may find that you'll have something
35
that provides a lot of value that's low effort and if there's a lot of those, it's better to put those up front
36
and do those first than to do something that doesn't provide a lot of value but requires a lot of effort.
37
So then you waste a bunch of time doing one thing that wasn't even that valuable.
38
And so you essentially
39
capture attributes or information about these requirements to help you rank them
40
and understand how difficult they are to help you best organize which items to prioritize first.
41
A major change request is introduced in the middle of a project.
42
How do you evaluate and manage this change?
43
Depending on the methodology that you're working on that I'm working on would
44
or rather the methodology that I'm working with will determine how I deal with the change in waterfall.
45
uh, it's much harder to make changes because Waterfall is very phase -based
46
and gate -based and almost contractual in a way
47
because you get something approved and then you do what was approved
48
and then you get something approved and then you do what was approved.
49
And so you're essentially changing waterfalls.
50
Um, what you're going to be doing based off of something that was already approved.
51
So typically that means you need to evaluate the change, make sure everybody who previously approved, you know, what we're going to do understands why the change might need to be made,
52
how it might be valuable to them.
53
and how it's better to go forward with a change than proceed with the way things are going.
54
Usually, organizations have pretty well thought out change -- well, I shouldn't say that, not all organizations,
55
but some organizations have well thought out change management processes or change request processes to facilitate this.
56
If not, then it's up to you as a business analyst to make sure you're talking to all those stakeholders, aligning it to the objectives, making sure everybody understands that we're doing something different now,
57
but it's for the better of the project.
58
You need to develop use cases for a new system.
59
What steps would you take to ensure they're comprehensive and accurate?
60
The mechanism I usually use is a functional decomposition.
61
That's really starting at the kind of top.
62
to say what are the business objectives, What are the different features and functionalities that we want to meet those business objectives?
63
And how are each of those features
64
and functions going to work for all the different users who are going to be in the system, right?
65
And so if you're talking about...
66
Say something like an ATM.
67
right there's the interfaces that i need to withdraw money deposit money all those things there's interfaces
68
that administrators maybe cash managers who have to come in
69
and you know open the thing up add cash
70
and essentially input how much they put in there
71
so the system understands how much money is in the machine
72
and so then you you get through all those use cases so you kind of
73
have to go to the full scope of your product all the things it needs to do, all the people who need to do those things, and then you get down to your use cases,
74
and that should give you a pretty comprehensive view of all the different functionalities.
75
And due to the nature of use cases, which are very scenario based, and you have to kind of essentially.. document in the line what things need to be true for the specific scenarios.
76
It allows you to think through both positive and negative scenarios or maybe scenarios that would happen side by side.
77
Or if, you know, I'm doing something, what things an administrator or an operator might need to do on the other side of things to facilitate that.
78
So the use cases themselves on top of
79
going through this functional decomposition actually help you create a comprehensive kind of bank of use cases when creating a project.
80
You have identified a bottleneck in an existing process.
81
How would you approach improving this process?
82
Well, first and foremost is to document the process.
83
Ideally, in this scenario where you're specifically trying to improve a bottleneck in the process,
84
it's important to use a more stringent version of business process modeling notation,
85
because that more stringent version actually forces you to document things in a more realistic way
86
that allows you to do a very specific kind of analysis on the different gates
87
and choices and tasks and activities that happen in a process flow.
88
which would essentially allow you to see areas for improvement, things that could happen in parallel, things that have to come for one before the other, things that could be automated.
89
That's really why BPMN was invented in the first place.
90
So the way I would approach this is to document it with strict BPMN notation.
91
And if I have a tool available, you could even simulate a business process diagram if you use that notation.
92
So you can say, you know, at different volumes, this is the way it might work.
93
And then you could simulate the new version, the 2B version, and see how it might potentially work fix the problem.
94
So I would definitely create a business process model using strict BPMN notation, or at least as strict as necessary to document it accurately.
95
You were given a large dataset with no clear insights
96
What steps would you take to analyze the data and extract meaningful information?
97
First, I would take an inventory of the data that's been
98
made available to me to try to make sure I understand as much of it as possible.
99
So I would, you know, see what's there, see what fields are available, see what tables are there, and try to make sense of it.
100
It may not be feasible to understand all of it right away, but you could take note of the things that you do understand, the way the information is structured.
101
then of course you go start asking questions
102
and try to get some context around around the business as
103
a business analyst um that's extremely important to me to kind
104
of understand what's the context of the business what's the context
105
of this data how is it gathered where is it coming from what are maybe some of the challenges
106
that that that portion or
107
that context of the organization might be facing to kind of
108
wrap my head around what data might be valuable important for the business
109
no data provides any valuable if it's not solving any real problems
110
so you have to kind of Also on the other side of it understand the context of the business
111
and the problems that they might be facing.
112
And that's how I would go about kind of starting that analysis mining process is really just to understand my landscape, both the data as well as the business that's producing this data.
113
Different team members use varying formats for documentation.
114
How do you standardize documentation?
115
process--practices across the project.
116
It kind of depends on the nature of how I'm coming in.
117
Obviously, in this scenario, say I just got hired and I'm trying to understand the lay of the land, then the first thing I would do is try to understand why everybody's doing things in different ways.
118
the same things, which ones are the better versions at capturing it,
119
and essentially try to put together a singular standardized version that captures everybody's needs,
120
and is essentially the best version of what everybody has kind of put together, but also in a mechanism that doesn't create a whole bunch of overhead and simplifies things for people.
121
So that's important too because if you come up with something that makes everybody take more time to do their job, they're not going to necessarily want to do it.
122
And so if you could do something that makes it easier for everybody to do their job, maybe even putting it in a system that allows them to more easily capture and align things,
123
you know, even better, But ultimately, it's really about what do we need to capture to be successful on the project,
124
standardize those things, and focus on those things.
125
A UAT phase is scheduled, but stakeholders are unfamiliar with the process.
126
How do you ensure that UAT is successful and stakeholders are engaged?
127
First and foremost is to communicate, teach, and help them understand why UAT, or user acceptance testing, is valuable.
128
If you're reaching out to them, that means they're some kind of stakeholder who will care about the outcome of whatever software
129
or hardware or whatever it is that you're producing.
130
at this point is going to be good for whoever their end users are, whoever their stakeholders are.
131
So, before anything, before even understanding what we're going to be doing, they already understand why it's important for them to be doing it.
132
From that point forward, then it's really just a matter of explaining to them how you're going to be conducting UAT, the processes they're going to follow, the steps they're going to take,
133
how to give you feedback to ensure that the product is the best
134
that it can be and it meets all the needs for their constituents, whether it's stakeholders, end users, or them, they themselves.
135
Two key stakeholders have conflicting requirements that cannot be easily reconciled.
136
How do you handle this conflict?
137
Well, you're going to have to come to an understanding of why these two requirements are in conflict.
138
It could be that two systems have very different needs, and so you may need to understand why this system needs the information that way,
139
and this system needs the information in a different way, and really, come to an understanding of does it need to be that way?
140
If so, how can you work around that?
141
If not, how do we negotiate who's who's requirement supersedes the other.
142
Sometimes it might mean going back to the objectives, going back to the project sponsor, going back to the value that you're trying to deliver and see which one aligns.
143
Sometimes it could just be that these two systems work in different ways,
144
they have different needs, and you may need to make some or build some additional requirements to help satisfy both.
145
Maybe a translation table that says, when it goes to this system, write it this way, when it goes to that system, write it a different way.
146
So that way both groups get what they need and nothing breaks along the way.
147
But more so than anything else, it's understanding why the conflict is there what's really needed by those two requirements,
148
and then you find out how you kind of get to
149
a point where both of those requirements can either be met
150
or the need for both of those requirements is no longer there.
151
You are working in an agile environment and the sprint is not going as planned.
152
How do you address issues and keep the team on track?
153
This is kind of a Scrum Master activity, but as a business analyst and a member of the team, everybody's kind of accountable for the success of a project.
154
I would say that I would kind of take inventory, take stock with all the team members as to why they believe things aren't going well,
155
what going well should look like, and then how we can kind of cross that bridge.
156
Sometimes it might mean that we're too dependent on other teams, and so we're creating stories that we legitimately can't complete in a sprint unless another team.. is doing it,
157
or we're creating stories based off of a space that we don't understand well enough.
158
So it's too complex, too big.
159
And so, our estimations are wrong and what we think we can accomplish is just not there, which means, you know, maybe the team needs to take a step back
160
and take some time to understand their domain and the scope of what they're working on.
161
Sometimes it could be that the requirements keep changing.
162
Maybe the product owner or stakeholder keeps you know, saying they want one thing, and then once they see something, saying they want a different thing.
163
And then so it might mean getting agreement with those stakeholders
164
and the team on how you can get to understanding or being in a position to deliver the most likely,
165
best, correct thing or thing that they want prior to the sprint starting, so that way you're not going back and forth and changing requirements.
166
There could be a lot of things.
167
Obviously, it would take investigation.
168
team kind of gets together reflects on those things, talks about it, figures out ways to deal with it.
169
It's usually called a retrospective.
170
It usually happens at the end of the sprint.
171
It usually comes or the result is usually some kind of action item, some kind of new thing that the team was going to be doing immediately to try to resolve that.
172
And over a few sprints, after you have a few retrospectives, you kind of, you know, form, storm, norm, and all of those things.
173
that's when you really get to the point where you're really cruising along.
174
You understand how your stakeholders are thinking.
175
You understand what the development team is capable of.
176
on and on and on.
177
until you get to essentially a well -oiled machine of a team.
178
Ensuring that all requirements are met throughout the project lifecycle is critical.
179
How do you maintain requirements traceability?
180
I maintain requirements traceability via functional decomposition.
181
That means you start out with your objective, you break down that objective into business requirements.
182
Like these are the key things that your business is going to be doing now that it wasn't doing before.
183
And then you break that down into the functional or solution requirements, which is how the system is actually going to do those things.
184
And then, you know, on and on data requirements and all of that.
185
But all of those trace backwards, right?
186
There's no data requirement that doesn't tie back to a functional requirement, that doesn't tie back to a business requirement, that doesn't tie back to an objective.
187
And if at any point there is one, you need to question what that item is and why it exists in your project.
188
And if you do it that way and you always, every requirement always comes from a decomposition, then everything will always naturally just be traced.
189
depending on your nomenclature at your organization, down to a user story level, and then sometimes down to a task level.
190
But again, everything traces up, everything has a parent, and if it doesn't, then you need to be questioning why you're working on that requirement.
191
That was my attempt at running through these 12 scenario -based business analysis questions without any prep.
192
I find it a little bit more fun to do these without prep.
193
If I was actually planning on sitting for an interview, I probably would prep for these, usually by going through them, thinking about projects that I've been on where I've done some of these things
194
so I can give real -life examples and kind of have that in the back of my mind, which is not always easy to do on the fly, which is why I didn't give a ton of real project examples that I've worked on.
195
If I sat down and thought about it a little more, I probably could.
196
And if I prepared for them, I definitely would.
197
And so that would be the main difference that I would say if you were preparing for these
198
specific questions to think about actual scenarios where you dealt with these things
199
and talk about how you resolve them in those scenarios.
200
If you can, if not, obviously just talk through how you would go about solving that.
201
But anyways, I hope that was helpful.
202
If you have any additional questions, let me know in the comments.
203
or create a video just like this one to answer your question.
204
So subscribe to see your questions get answered.
205
And thanks for watching.
Télécharger l'application
Tout pour parler couramment
Prononciation IAChaque phrase notée
Phonétique (IPA)Maîtrisez chaque son
VocabulaireEnrichissez votre lexique
Jeu de vocabulaireApprenez en jouant
FOR YOU
Vidéo recommandée
C13
102 phrases
Essential Questions to Ask during stakeholder Interviews and Workshops - Business Analyst Techniques
Business EnglishInterview EnglishWorking Adults
B235
32 phrases
Senior Leadership Interview: Turning Around a Struggling Team
American AccentBritish AccentBusiness EnglishInterview EnglishWorking Adults
C14
24 phrases
Financial Analyst: Top 3 Interview Questions & Answers
Business EnglishInterview EnglishUniversity Students
C12
257 phrases
A/B Testing in Data Science Interviews by a Google Data Scientist | DataInterview
Business EnglishInterview EnglishUniversity Students
C17
99 phrases
How to Answer System Design Interview Questions (Complete Guide)
Business EnglishInterview EnglishUniversity Students
C12
148 phrases
SCRUM MASTER Interview Questions & ANSWERS for 2024! (How To PREPARE for a SCRUM MASTER INTERVIEW!)
Business EnglishInterview EnglishWorking Adults
![[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008](https://img.youtube.com/vi/Bo4ARkCDQLk/mqdefault.jpg)
C12
160 phrases
[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008
TOEFL PrepBusiness EnglishInterview English
C1126 phrases
What Is a Pricing Analyst? - Responsibilities, Career Path & Skills
Business EnglishInterview EnglishUniversity Students
C12
263 phrases
Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley
Business EnglishInterview EnglishUniversity Students
C1239 phrases
Learn how to SOLVE a data analytics case study problem
Business EnglishInterview EnglishUniversity Students
C13
195 phrases
QA Automation Engineer Technical Interview questions and answers
Business EnglishInterview EnglishUniversity Students
B111
31 phrases
Phone Interview: Talking About Salary Expectations
American AccentBritish AccentBusiness EnglishInterview EnglishWorking Adults
Vocabulaire et conseils d’expression pour cette leçon
Cette leçon d’expression orale de niveau C1 s’appuie sur la vidéo « Business Analyst Interview Questions & Answers - Scenario Based Questions ». Les mots qui reviennent le plus souvent : requirement, project, stakeholder. Cette vidéo contient 205 phrases et 3239 mots à répéter en shadowing. La partie parlée dure 17:08. Le locuteur parle vite, environ 189 mots par minute : attendez-vous à des liaisons et à des sons réduits. 87 % des mots font partie des 3 000 mots les plus courants en anglais ; le reste mérite d’être vu avant de commencer.
Vocabulaire clé de cette vidéo
Les 15 mots les plus avancés de la vidéo, avec leur prononciation et leur sens :
| Mot | Prononciation | Sens |
|---|---|---|
| stakeholder nom | /ˈsteɪkˌhəʊl.də/ | agent d'entiercement, plaideur |
| align verbe | /əˈlaɪn/ | aligner |
| approve verbe | /əˈpɹuːv/ | approuver |
| sprint nom | /spɹɪnt/ | sprint |
| decomposition nom | /diːˌkɒmpəˈzɪʃən/ | décomposition |
| preposition nom | /ˌpɹɛpəˈzɪʃən/ | préposition |
| waterfall nom | /ˈwɔːtəfɔːl/ | cascade, chute d'eau |
| bottleneck nom | goulot, goulot de bouteille | |
| prioritize verbe | /pɹaɪˈɒɹ.ə.taɪz/ | prioriser |
| retrospective adjectif | /ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/ | rétrospectif |
| simulate verbe | /ˈsɪm.jə.lət/ | simuler |
| stringent adjectif | /ˈstɹɪn.d͡ʒənt/ | strict |
| traceability nom | /ˌtɹeɪsəˈbɪlɪti/ | traçabilité |
| functionality nom | fonctionnalité | |
| methodology nom | /ˌmɛθ.əˈdɑ.lə.d͡ʒi/ | méthodologie |
Les verbes à particule que vous entendrez
| Mot | Prononciation | Sens |
|---|---|---|
| go back verbe | rentrer, retourner | |
| go through verbe | traverser | |
| put together verbe | assembler | |
| break down verbe | tomber en panne | |
| come up with verbe | inventer, imaginer | |
| figure out verbe | cerner | |
| find out verbe | découvrir, savoir | |
| get through verbe | /ɡɛt ˈθɹu/ | franchir |
Des phrases à répéter
Des phrases courtes et complètes de la vidéo, à réutiliser dans la conversation de tous les jours :
- What is the problem that we're trying to solve?
- What is the intended value that we're trying to get?
- What's the value that we're trying to achieve at the end?
- How do you evaluate and manage this change?
- What steps would you take to ensure they're comprehensive and accurate?
La grammaire de cette vidéo
Les structures que le locuteur utilise le plus, avec les mots exacts de la vidéo :
| Structure | Dans la vidéo |
|---|---|
| Phrases conditionnelles if + proposition, will/would + verbe — une condition et son résultat | if I prepared for them, I definitely would |
| Voix passive be + participe passé — l’accent est mis sur ce qui arrive, pas sur qui le fait | been done · can be implemented · is introduced |
| Present perfect have/has + participe passé — une action passée qui compte encore maintenant | hasn't been done · have identified · that's been |
| Propositions relatives who / which + proposition — une précision sur une personne ou une chose | people who need · cases, which are · there, which means |
Prononciation à surveiller
Le locuteur utilise 60 contractions et formes réduites, comme you're, we're, I'm. Prononcez-les sous leur forme courte, telles que vous les entendez.
- Les sons « th »: methodology /ˌmɛθ.əˈdɑ.lə.d͡ʒi/, withdraw /wɪðˈdɹɔ/
- Les sons « sh » et « zh »: decomposition /diːˌkɒmpəˈzɪʃən/, notation /noʊˈteɪʃən/, preposition /ˌpɹɛpəˈzɪʃən/, documentation /ˌdɑkjəmɛnˈteɪʃən/, accomplish /əˈkɑm.plɪʃ/
- Mots longs — placez bien l’accent: decomposition /diːˌkɒmpəˈzɪʃən/, preposition /ˌpɹɛpəˈzɪʃən/, prioritize /pɹaɪˈɒɹ.ə.taɪz/, retrospective /ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/, traceability /ˌtɹeɪsəˈbɪlɪti/
Les sons difficiles pour les francophones :
- /h/ — il se souffle, il n’est pas muet: stakeholder /ˈsteɪkˌhəʊl.də/, overhead /ˈəʊvəˌhɛd/
- /tʃ/ et /dʒ/ — à ne pas adoucir en « ch » et « j »: stringent /ˈstɹɪn.d͡ʒənt/, methodology /ˌmɛθ.əˈdɑ.lə.d͡ʒi/, contractual /kənˈtɹæk.t͡ʃ(u)əl/, nomenclature /ˈnoʊmənˌkleɪt͡ʃɚ/, adjustment /əˈd͡ʒʌst.mənt/
- /r/ anglais — langue recourbée, sans frotter la gorge: approve /əˈpɹuːv/, sprint /spɹɪnt/, preposition /ˌpɹɛpəˈzɪʃən/, prioritize /pɹaɪˈɒɹ.ə.taɪz/, retrospective /ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/
Comment s’entraîner avec cette vidéo
- Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
- Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
- Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme stakeholder, align, approve.
Qu'est-ce que la technique du Shadowing ?
Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.