They ask: "Walk me through the role of a Business Analyst — what do you actually do day to day?"
A BA exists to close the gap between "what the business needs" and "what gets built" — without that role, requirements live in someone's head, get reinterpreted at every handoff, and the team ships the wrong thing correctly. The job is elicitation (finding out what's really needed, not just what's said), analysis (structuring it, spotting conflicts and gaps), documentation (making it unambiguous and traceable), and validation (getting stakeholders and the team to agree it's right before a line of code is written).
Day to day that's running elicitation sessions, writing and maintaining requirements artifacts (user stories, use cases, SRS sections), facilitating between business stakeholders and the delivery team, and owning requirements changes so nothing gets lost between "the client asked for X" and "the team built X."
Say it: "My job is to make sure the team builds the right thing — I turn ambiguous business need into requirements precise enough that a developer and a stakeholder read them the same way."
Red flag: Describing the BA as "the person who writes documents." Documentation is an output, not the job — the job is closing the understanding gap between business and delivery.