💬 Behavioral Questions
Tell me about a time when... How did you handle...? These questions show how you think and act.
We were three weeks into a five week sprint on a customer portal. Friday, Finance came to us with a major change: billing requirements needed to be different due to a new partnership. My first instinct was to protect the team's commitment.
I did three things. First, I got detailed clarity on what exactly changed and why. Second, I analyzed the impact: this would add about two weeks of work. Third, I facilitated a conversation with Product and Finance about options. Could we defer some of it? Could we simplify? What's truly critical?
We ended up deferring non critical requirements to the next phase and extending the timeline by one week instead of two. The team understood the reasoning, felt heard, and delivered quality work. Finance got what they needed, just on a different timeline.
The lesson: Changes happen. Your job isn't to prevent them. It's to understand them, assess impact, communicate clearly, and find the best path forward with the team.
- You didn't panic or resist change automatically
- You took time to understand the requirement fully
- You thought about impact on the team
- You communicated with stakeholders
- You found a solution that worked for everyone
- You emphasized team and quality
"Requirements always change so I just accept whatever they ask for." This makes you sound like a doormat. Or "I told them no because we were committed" which makes you sound rigid.
A VP wanted to add a brand new feature mid sprint that would have taken three weeks to build. I didn't just say no. I asked why they felt it was urgent. Turned out they had heard customer feedback and wanted to respond quickly. I understood the motivation.
But I looked at our sprint capacity and current customer feedback data. Only 2% of customers mentioned this need. Four features currently in flight had 30% customer request rate. So I proposed: let's finish what's in flight first, track this request, and prioritize it next sprint if demand increases.
I was saying no to the timing, not to the feature. And I backed it up with data. The VP appreciated the clear thinking. The feature did go into the next sprint. But it wasn't rushed in.
- You understood their reasoning before saying no
- You had data or logic to back up your position
- You were respectful, not dismissive
- You offered an alternative path forward
- You preserved the relationship
Sales wanted to prioritize an "easy" feature to demo to potential customers. Engineering wanted to fix technical debt that was slowing down development. Both made sense.
I brought them together in a room. I had each explain their priority and why. Then I asked: what's the intersection? We found a feature that would help sales demo value AND solve part of the technical debt. We built that first. Everyone got something.
- You didn't pick sides immediately
- You got both people to explain their position
- You looked for win win solutions, not compromises
I wrote requirements that were too vague. I thought they were clear because I understood the context. But the dev team interpreted them differently. We built the wrong thing.
I could have blamed the developers for not asking questions. Instead I realized I hadn't made my assumptions explicit. I had failed to make it easy to understand.
Now I use a checklist: Can someone who doesn't know the context understand this? Are edge cases covered? Do I have testable success criteria? It's saved rework multiple times since.
The lesson: My job is to be clear enough that there's only one way to interpret what I'm asking. If it's ambiguous, that's on me.
- You took responsibility (didn't blame others)
- You understood what went wrong
- You learned something from it
- You changed your behavior as a result
🛠️ Technical BA Questions
These test your knowledge of BA practices, tools, and methodologies.
A requirement is the "what" the system should do. "Users should be able to reset their password."
Acceptance criteria are the specific conditions that define "done" for that requirement. For password reset:
- User enters email and clicks forgot password
- System sends reset link to that email within 2 seconds
- Link is valid for 24 hours
- User can set new password meeting minimum complexity
- System confirms reset success with email
Requirements tell you what to build. Acceptance criteria tell you when it's built correctly.
Waterfall: Plan everything upfront, execute to the plan, deliver at the end. Good for regulated industries, fixed price contracts, hardware dependencies, or when requirements are very stable.
Agile: Plan iteratively, deliver working software every sprint, adapt based on feedback. Good for startups, customer centric products, when requirements evolve, or when you need speed.
I worked on a healthcare compliance system using Waterfall because regulations were fixed and couldn't change. I worked on a customer portal using Agile because we needed to gather feedback and adjust based on actual usage patterns.
- You can explain the core differences clearly
- You understand the trade offs
- You have examples of when you used each
A use case is a detailed story of how an actor (user or system) interacts with the system to accomplish a goal. It includes main flow, alternative flows, and error scenarios.
They're useful because they show how a system actually gets used in practice. They help you think through edge cases and error scenarios that simple requirements miss. They also make great test cases.
🎬 Scenario Questions
These test your problem solving and decision making in real situations.
I wouldn't start building. I'd start asking:
- Who is struggling with the current dashboard?
- What specifically is hard? Finding data? Understanding it? Acting on it?
- What would success look like? (quantify if possible)
- How often do they use it?
- What other tools do they use alongside this?
Then I'd look at data: Which dashboard features are used most? Which are never used? Is there a pattern in support tickets about the dashboard?
From that, I'd narrow "better" to specific improvements based on actual usage and pain points. "Better" becomes measurable.
- You didn't start building immediately
- You asked to clarify what "better" means
- You gathered data, not just opinions
- You made the problem specific and measurable
First, I'd understand why. I'd ask the dev team: What made you interpret it this way? What gap in my specification led you there?
Then I'd think: Is what they built actually better than what I specified? Does it solve the customer problem?
If the answer is yes, I'd ask: Should we ship this and mark the original requirement as solved differently? Or do we need the original version?
If the answer is no, I'd ask: How much rework? Can we finish this sprint with both?
I'd definitely not blame them. The spec was unclear. That's on me. I'd fix the spec to prevent this next time.
- You took responsibility for unclear specs
- You didn't automatically demand rework
- You asked if the solution actually solved the problem
- You worked with the team to find the best path
💡 Interview Tips & Strategies
How to answer questions effectively and leave a great impression.
For behavioral questions, structure your answer clearly:
- Situation: What was the context?
- Task: What was your responsibility?
- Action: What specifically did you do?
- Result: What was the outcome? (measurable if possible)
"I decided X" is weak. "I considered A, B, and C. I chose B because [data/reasoning]. The result was [outcome]" is strong.
Interviewers want to see HOW you think, not just WHAT you decided.
Everyone makes mistakes. Not talking about them makes you look inexperienced or inauthentic. Talking about them with what you learned makes you look mature and self aware.
Don't just answer questions. Also ask:
- What does success look like in this role after 6 months?
- What's the biggest challenge your BA team is facing?
- How does your company decide between Agile and Waterfall?
- What BA tools do you use?
This shows genuine interest and helps you assess if it's a good fit.
Have 3 4 real project stories ready. A story about: handling conflict, managing scope, dealing with ambiguity, learning from failure. Adjust which story you use based on what they ask.
Stories are memorable. Generic answers are forgettable.
They might ask: What tools have you used? Why that tool for that job? What do you like and dislike about it?
Be specific. "Jira for user story management because it integrates with our dev tools and gives visibility to the whole team" beats "I've used lots of tools".
Know why you're excited about this role, this company, this industry. Don't say "I just want a job". Say something like: "I'm drawn to this because [specific reason]. I see your company [specific insight] and I think I can help with [specific value]."
Do this:
- Listen fully before answering
- Ask clarifying questions if you're unsure
- Use examples and stories, not abstract concepts
- Be yourself, not a robot
- Show enthusiasm
- Make eye contact and smile (basic but important)
Send a thank you note within 24 hours. Mention something specific you discussed. Keep it short. Example:
"Thanks for the conversation about your Agile transition. I enjoyed hearing about your BA team structure and I'm excited about the possibility of contributing to that effort."