What Junior Business Analysts Get Wrong Talking to Interviewers

DESCRIBING DOCUMENTS — READ AS AN
INTERVIEWER:

Interviewer: "Tell me about a requirements
document you wrote."

Candidate: "I wrote a BRD for the payments
module. It had 40 requirements, and I got
sign-off from the PM and the finance lead
in two weeks."

Interviewer: "What was the hardest
requirement to get agreed?"

Candidate: [pause] "I'm not sure. We got
sign-off pretty smoothly."

What I notice:
- The candidate describes the document:
  40 requirements, two weeks, sign-off.
- There's no decision, no disagreement,
  no trade-off.
- "We got sign-off pretty smoothly" is the
  tell: no analysis happened.

What it signals:
❌ Document production, not analysis
❌ No stakeholder tension
❌ No decisions
❌ Note-taker, not analyst

What I do next:
- I ask: "Which requirement did a
  stakeholder disagree with?"
- If they can tell a story, they recover.
- If not, the BA score drops.

The strong answer:
"The hardest requirement was the refund
window. Finance wanted 90 days; the product
lead wanted 30 days to match the
competition. I ran a session with both, and
we settled on 60 days with a manual override
for edge cases. The override was the key —
it let finance keep the longer window for
enterprise customers without exposing the
product to abuse. I wrote the requirement
with the override as an explicit edge case,
and it shipped without a change."

Why it works:
✅ A real disagreement: 90 vs. 30 days
✅ A real decision: 60 days + override
✅ A real trade-off: enterprise vs. abuse
✅ The requirement shipped without change

RECITING TOOLS — READ AS AN INTERVIEWER:

Candidate: "I use Jira, Confluence, Visio,
and Excel. I'm also learning SQL and
Tableau."

Interviewer: "How did you use Jira to
resolve a disagreement?"

Candidate: [pause] "We used it for tickets.
I'm not sure what you mean by resolve."

What I notice:
- The candidate lists tools.
- The follow-up exposes the gap: tools
  without a story.
- They know the product, not the practice.

What it signals:
❌ Tools as vocabulary
❌ No practice story
❌ No reasoning about conflict
❌ Tutorial-level depth

What I do next:
- I ask: "Tell me about a time you used
  Jira to track a requirement that changed
  late."
- If they can tell a story, they recover.
- If they can't, the depth score drops.

The strong answer:
"On the payments module, the finance team
changed a requirement 3 days before the
sprint started — they wanted a new field on
the invoice. I added a Jira ticket with the
change, linked it to the original
requirement, and flagged the sprint risk to
the PM. The PM moved one lower-priority
ticket out of the sprint, and the change
shipped on time. The link between the
original and the change is what let us
trace the impact when the change caused a
downstream bug."

Why it works:
✅ A real story: change 3 days before
  sprint
✅ A real action: linked ticket, flagged
  risk
✅ A real outcome: shipped on time
✅ The tool served the practice, not the
  reverse

THE SMOOTH SIGN-OFF — READ AS AN
INTERVIEWER:

Candidate: "We got sign-off pretty
smoothly. The PM and the finance lead
agreed on the requirements in two weeks."

Interviewer: "What happened when they
disagreed?"

Candidate: [pause] "They didn't really
disagree. We had a good relationship."

What I notice:
- "Smoothly" is the answer to every
  follow-up.
- "They didn't really disagree" is the tell:
  no real analysis happened.
- The candidate avoided the hard part.

What it signals:
❌ No conflict navigation
❌ No analysis
❌ No stakeholder management
❌ Note-taker, not analyst

What I do next:
- I ask: "What's a requirement you had to
  push back on?"
- If they can tell a story, they recover.
- If not, the BA score drops.

The strong answer:
"The finance lead wanted to add a
'reconciliation field' to the invoice that
the product lead thought was unnecessary.
I ran a 30-minute session with both, mapped
the field to the finance close process, and
showed that without the field, the finance
team would need a manual step every week —
about 4 hours of work. The product lead
agreed to add the field but scoped it to
finance-only invoices. The compromise
shipped, and the manual step went away."

Why it works:
✅ A real disagreement: reconciliation field
✅ The analysis: 4 hours per week manual work
✅ The compromise: finance-only invoices
✅ The outcome: manual step went away

NO CHANGE — READ AS AN INTERVIEWER:

Candidate: "The requirement shipped without
a change. The team delivered it on time."

Interviewer: "What did the business do
differently because of the requirement?"

Candidate: [pause] "I'm not sure. We
delivered the feature, but I didn't track
the business outcome."

What I notice:
- "Shipped without a change" is a delivery
  metric, not a business outcome.
- "I didn't track the business outcome" is
  the tell: no connection to value.

What it signals:
❌ Delivery focus, not outcome focus
❌ No business impact story
❌ No measurement
❌ Note-taker, not analyst

What I do next:
- I ask: "What metric would you have used
  to measure it?"
- If they can name a metric, they recover.
- If they can't, the BA score drops.

The strong answer:
"The requirement was a new field on the
invoice for purchase-order numbers.
B2B customers had been emailing the PO
separately, which meant the AR team was
manually matching about 200 emails a month.
I proposed the field, wrote the requirement,
and tracked the outcome. Three months after
launch, the manual matching dropped to
about 40 emails a month — an 80% reduction.
The AR team estimated it saved them about
6 hours per week."

Why it works:
✅ The business problem: 200 emails/month
✅ The change: a new field
✅ The outcome: 200 → 40 emails/month
✅ The impact: 6 hours per week saved

FULL ANSWER — THREE PARTS IN 60 SECONDS:

Interviewer: "Tell me about a requirements
document you wrote."

WHAT YOU SAY:
"Sure. I'll walk through the tension, the
decision, and the outcome.

The tension: I wrote the requirements for
the refund flow. Finance wanted a 90-day
refund window; the product lead wanted 30
days to match the competition. The
disagreement was about enterprise customers
who had longer contracts and needed the
flexibility.

The decision: I ran a session with both,
mapped the refund window to the contract
length, and proposed 60 days with a manual
override for enterprise customers. The
trade-off was some product abuse risk in
exchange for keeping enterprise customers
happy. Finance agreed, and I wrote the
override as an explicit edge case in the
BRD.

The outcome: three months after launch,
enterprise refunds were handled without a
manual escalation, and the support team
saved about 4 hours per week. The override
was used by about 5% of enterprise refunds,
which was within the risk tolerance we
agreed on."

What the interviewer thinks:
- "Tension: 90 vs. 30 days, enterprise."
  ✅
- "Decision: 60 days + override." ✅
- "Trade-off: abuse risk vs. enterprise
  retention." ✅
- "Outcome: 4 hours per week saved." ✅
Signal: strong hire.

Why it works:
✅ The tension is specific
✅ The decision has a rationale
✅ The trade-off is honest
✅ The outcome is measured

WHEN YOU DON'T KNOW — STILL RECOVER:

Interviewer: "What's a requirement you had
to push back on?"

Candidate: "I haven't had to push back on
a requirement yet. I'm junior, and most of
my work has been documenting requirements
others have decided.

What I can tell you is how I'd handle the
next one. I'd start by understanding the
business reason behind the requirement —
why does this stakeholder want this field,
and what breaks if they don't get it? Then
I'd check the trade-off: what does the
requirement cost, and who pays it? Then I'd
bring both to the stakeholder with the
evidence.

I also know the signs of a requirement
that needs pushback: it's vague, it has no
acceptance criteria, or it conflicts with
another requirement. I'd flag those before
the sprint starts."

What the interviewer thinks:
- "They were honest about their level." ✅
- "They reasoned about the process." ✅
- "They named the signs of a bad
  requirement." ✅
- "They showed the analyst mindset." ✅
Signal: recovered. Hire.

Why it works:
✅ Honesty: junior, mostly documenting
✅ Reasoning: business reason, trade-off,
  evidence
✅ Signs: vague, no acceptance criteria,
  conflicts
✅ The gap is named, not bluffed

Junior BA Interview Checklist:

FOR EACH DOCUMENT:
☐ Tension: which stakeholder disagreed
☐ Decision: what you proposed, and why
☐ Trade-off: what you gave up
☐ Outcome: what changed, with a number
☐ Stakeholder: who agreed, and how

FOR EACH TOOL:
☐ A story where the tool helped resolve
  a disagreement
☐ What changed because of the tool
☐ When the tool wasn't enough

FOR EACH GAP:
☐ Say "I haven't done that yet" honestly
☐ Reason about how you'd handle it
☐ Name the signs of a bad requirement

RED FLAGS IN YOUR OWN ANSWERS:
❌ "I wrote 40 requirements" with no
  tension
❌ "We got sign-off smoothly" with no
  disagreement
❌ "I use Jira, Confluence, Visio" with no
  story
❌ "The requirement shipped" with no
  business outcome
❌ No number anywhere
❌ No stakeholder story
❌ The answer is a document, not a decision

THE TENSION TEST:
For each document, ask yourself:
1. "Which stakeholder disagreed, and why?"
2. "What did I propose, and what did we
  give up?"
3. "What changed for the business, and by
  how much?"

If any answer is no, that's the story to
prepare before the interview.

30-DAY JUNIOR BA PLAN:

Week 1 — Audit the documents
☐ Pick 3 documents from your work
☐ For each, write the stakeholder tension
☐ Write the decision and the trade-off
☐ Mark the ones with no tension

Week 2 — Write the decision story
☐ For each document, write the three-part
  answer: tension → decision → outcome
☐ Add one number per story
☐ Practice each in under 60 seconds

Week 3 — The tools
☐ For each tool, write one story where it
  helped resolve a disagreement
☐ Write what changed because of the tool
☐ Practice out loud

Week 4 — Mock interview
☐ Have a peer ask 5 BA questions
☐ Use the three-part answer: tension,
  decision, outcome
☐ If you pause, that's the story to
  practice
☐ Re-run the mock until no pauses

Signs it's working:
✅ You lead with the tension, not the
  document
✅ Every document has a decision
✅ Every decision has a trade-off
✅ Every story has a number
✅ You never say "we got sign-off smoothly"
  without a story
✅ The interviewer asks "tell me more"
  instead of "let's move on"