Short version: A Computer Systems Analyst loop is four to five rounds — recruiter screen, technical screen on requirements-gathering and gap analysis, stakeholder round with a business partner, technical deep-dive with a lead engineer, and a behavioral round on ambiguity and stakeholder management. The rubric is not "do you know SQL" — every candidate does. It's whether you can translate an ambiguous business ask into a documented specification the engineering team can build without ten follow-up meetings. Below are 30+ questions grouped by round, with the rubric graders use and a sample answer for each.
On this page
The typical Computer Systems Analyst loop
A Computer Systems Analyst (BLS 15-1211) sits between the business and engineering. The occupation covers about 1.9 million U.S. professionals working under titles that include Systems Analyst, Business Systems Analyst (BSA), IT Business Analyst, Functional Analyst, and Application Analyst. A typical loop for a mid-level role at a mid-market company or a Fortune 500 has five rounds:
| Round | Interviewer | What they screen for |
|---|---|---|
| 1. Recruiter screen (30 min) | In-house or agency recruiter | Comp, systems familiarity, motivation, red flags |
| 2. Hiring-manager technical (45–60 min) | The team lead or manager | Requirements-gathering process, gap analysis, one system deep |
| 3. Stakeholder round (45 min) | Finance, ops, sales, or HR leader | Business fluency, translation from ask to spec, tone |
| 4. Technical deep-dive (60 min) | Lead engineer or architect | SQL, integration patterns, SDLC fluency, edge cases |
| 5. Behavioral / culture (45 min) | Cross-functional peer or skip-level | Ambiguity, disagreement, saying no, judgment |
At some companies, especially those on SAP, Oracle, or Workday, a sixth round exists — a "functional deep-dive" led by a senior architect or a consultant partner. At others, especially early- and mid-stage tech companies, the loop compresses to three rounds. The rubric doesn't compress: whether you meet all five or two of them, you will still be scored on requirements, gap analysis, stakeholder management, technical fluency, and judgment. Prepare for all five even if your loop advertises three.
Phone screen & behavioral questions
1. Tell me about yourself.
Sample answer. "I'm a Senior Business Systems Analyst on the Finance Systems team at Meridian Retail. I own the Oracle Cloud ERP GL, AP, and AR modules and the two-way integration with our Boomi middleware into Salesforce. Over the last four years I've led three major projects — an AP automation rollout that cut invoice-to-pay from 18 days to 6, a subledger clean-up that closed a $3.2M audit finding, and the design of the new intercompany elimination workflow. I'm looking to move to a company where the systems footprint is more integrated — I want to spend more time on cross-system design and less time on ERP-only tickets."
Rubric: system portfolio named, one measurable outcome per year of experience, motivation stated as specific, not personal.
2. Why are you leaving your current role?
Sample answer. "The systems footprint is narrower than where I want to be — 90% Oracle Cloud, and the middleware team owns the integrations. I've done the work I set out to do on the AP side and I'm ready for a broader portfolio. Nothing wrong with the team; I've told my manager I'd like to make this move."
Rubric: pull, not push. No blaming. Names the specific gap in the current role.
3. Walk me through your résumé.
Sample answer. A 3–5 minute arc: first system you owned, first project that had a measurable outcome, the pivot to your current specialty, one representative project in the last year, and the specific reason this role is your next step. End on why this company, not on a summary.
Rubric: chronology visible, one project per role, one number per project. No system name gets past you unnamed.
4. Tell me about a time you had to gather ambiguous requirements.
Sample answer. "The Chief Revenue Officer asked for 'better commissions reporting.' I sat with three sales leaders and a finance controller across a week — one hour each — and drew the current state on a whiteboard. The real problem wasn't reporting; it was that the commissions were being calculated in two spreadsheets that didn't reconcile. I documented the current state as a BPMN with three swim lanes and named the four decision points where the two spreadsheets diverged. I sent it back to the CRO and the CFO — one email, one attachment — and asked them to align on which of the four decisions was authoritative. They agreed in a 20-minute call. I turned the agreement into a BRD with seven functional requirements and 22 acceptance criteria. Engineering built it in a six-week sprint. First close on the new system reconciled to $0 variance across 340 reps."
Rubric: framework visible (whiteboard current-state → BPMN → decision points → BRD), stakeholders named, outcome quantified.
5. Tell me about a time you disagreed with an engineer on a technical decision.
Sample answer. "The engineering lead wanted to build a real-time integration between our HRIS and payroll — Kafka topic, event-driven. I pushed back: our payroll runs bi-weekly, and the payroll system's inbound API is rate-limited to 60 calls per minute. The real-time architecture would have been six weeks of extra build for a use case that didn't need it. I brought the two SLA numbers to a 30-minute working session and drew the flow both ways. We agreed on a scheduled 15-minute batch instead. Three weeks to build, no rate-limit incidents in the year since."
Rubric: candidate is not anti-engineering; leads with data (SLA and rate limit); working session, not email fight.
6. Tell me about a time you had to say no to a stakeholder.
Sample answer. "A VP of Ops asked for a new Salesforce field to track a supplier-side data point during a busy sprint. I said no — but I made the trade-off visible. I sent a two-line email: 'Adding this field to the current sprint delays the AP automation go-live by two weeks. If we ship this in the next sprint instead, we hold the go-live date. Which do you prefer?' She picked the next sprint. Two weeks later we shipped the field, and the AP go-live held."
Rubric: no is a trade-off, not a refusal. Written down. Stakeholder made the call.
Requirements gathering & gap analysis
7. Walk me through how you would gather requirements for a new expense management system.
Sample answer. "I'd start with three parallel tracks. Track 1 — current state: pull the last 90 days of expense reports, categorize them, and interview a controller and two frequent submitters to draw the process in a BPMN. Track 2 — stakeholder alignment: a one-page 'guiding questions' doc for the CFO and the head of HR — coverage, policy enforcement, integration with the ERP, mobile UX, corporate-card model. Track 3 — market scan: three vendor demos (Concur, Brex, Ramp, Airbase) with a scoring matrix aligned to the guiding questions. I'd deliver a functional requirements document with 20–35 requirements grouped by must-have, should-have, and nice-to-have, then run a 60-minute prioritization workshop with the CFO, controller, HR lead, and finance systems team."
Rubric: three tracks parallel, artifacts named, prioritization framework visible.
8. Explain gap analysis. When would you use it?
Sample answer. "Gap analysis is the comparison between current state and target state — process, data, systems, controls — with the difference documented as a set of remediations. I use it in three moments: (a) evaluating a new system for purchase — does it cover the requirements, or where are the gaps; (b) M&A integration — where do the two entities' processes diverge; and (c) audit response — what is the delta between our controls and the audit finding. The output is always a table: current, target, gap, remediation, owner, effort."
Rubric: three use cases named, output format specified.
9. What is a BRD and how does it differ from an FRD?
Sample answer. "A BRD — Business Requirements Document — captures the what and why from the business's perspective in language a non-technical stakeholder signs off on: 'The system must allow sales managers to view team quota attainment at any point in the quarter.' An FRD — Functional Requirements Document — translates each BRD line into the how from the system's perspective: fields, screens, calculations, permissions, edge cases. The FRD reads like a spec engineering can build to. I write both, but at smaller companies I collapse them into a single BRD-with-functional-appendix to save cycles."
Rubric: language of audience visible; candidate has an opinion about scale.
10. How do you write a user story?
Sample answer. "The Connextra form — 'As a [role], I want [capability] so that [business value]' — plus three to five acceptance criteria in given-when-then. Example: 'As a payroll administrator, I want to preview the deduction total for a bi-weekly run before I submit, so that I can catch a misclassified benefit before it hits employees. Given a bi-weekly payroll draft, when I open the deduction preview, then the total by deduction category matches the sum of the individual employee lines.' I add a 'definition of done' that includes automated test coverage and a UAT script."
Rubric: Connextra + given/when/then + DoD explicit.
11. What is a use case? How is it different from a user story?
Sample answer. "A use case is a fully documented interaction between an actor and the system, including the main flow, alternate flows, exceptions, preconditions, and postconditions. A user story is one slice of behavior sized to a sprint. Use cases live in the FRD and drive UAT scripts; user stories live in the backlog and drive the sprint plan. I use both — use cases for anything that touches money, compliance, or a customer contract; user stories for everything else."
Rubric: sizing distinction; opinion about which situation needs which.
Stakeholder round
12. A business stakeholder pushes back on a requirement engineering already committed to. What do you do?
Sample answer. "I don't take the pushback to engineering unfiltered. I test it: is this a scope change or a bug in the original spec? If scope change, I quantify the impact — sprint slip, downstream integration, testing — in one paragraph, and I send it to both the stakeholder and the engineering lead so the trade-off is visible. If it's a bug in the original spec, I own it, revise the BRD, and the change flows through the standard change-control process. Either way the stakeholder gets a written answer within 24 hours."
Rubric: distinguishes scope from spec bug; writes it down; 24-hour SLA.
13. Two stakeholders want incompatible things. How do you resolve it?
Sample answer. "I don't try to resolve it — I make the trade-off visible and hand it back to whoever owns the P&L. I write a one-page brief: what stakeholder A wants, what stakeholder B wants, what the technical trade-off is, and what my recommendation is. I ask the decision-owner (usually the VP who owns the process) to pick. If they can't, I escalate to their leader. The mistake is trying to be the tiebreaker yourself — you have neither the authority nor the accountability."
Rubric: candidate names decision-rights explicitly; escalation path is clear.
14. How do you translate a business ask into a technical spec?
Sample answer. "Four steps. (1) Restate the ask in one sentence back to the stakeholder — 'You want new-hire benefit elections auto-loaded into Workday within four hours of offer acceptance, correct?' (2) Identify the systems, data, and integrations that touch it. (3) Draw the data flow — source, transformation, destination, error handling. (4) Write the BRD with functional and non-functional requirements (latency, security, error handling, monitoring). The one sentence at the top is the anchor; if the stakeholder can't agree with it, nothing downstream will land."
Rubric: one-sentence anchor, four numbered steps, non-functional requirements named.
15. A finance leader tells you the system is "broken" but can't say how. How do you diagnose?
Sample answer. "'Broken' is almost never a system defect on the first look — it's usually a mismatch between expected behavior and actual behavior at one specific data point. I ask for one example: one journal entry, one AR customer, one invoice. I trace it end-to-end — source system, integration log, target system field-by-field. Nine times out of ten I find one of three things: bad master data, a business rule the finance team didn't know had changed, or a genuine bug. The distinction changes everything about what happens next."
Rubric: one example; three most-likely causes; distinguishes remediation paths.
Technical deep-dive: SQL, integrations, SDLC
16. Write a SQL query that returns the top 5 customers by revenue in the last quarter.
Sample answer. SELECT c.customer_id, c.name, SUM(o.revenue) AS q_rev FROM orders o JOIN customers c ON o.customer_id = c.customer_id WHERE o.order_date >= DATE_TRUNC('quarter', CURRENT_DATE - INTERVAL '3 months') AND o.order_date < DATE_TRUNC('quarter', CURRENT_DATE) GROUP BY c.customer_id, c.name ORDER BY q_rev DESC LIMIT 5; — I'd confirm the definition of "revenue" (gross vs. net vs. recognized), whether refunds are excluded, and which timezone the quarter is anchored in before shipping this for real.
Rubric: JOIN, GROUP BY, ORDER BY, LIMIT syntactically clean; verifies definitions before treating as final.
17. Explain the difference between an INNER JOIN and a LEFT JOIN.
Sample answer. "INNER JOIN returns only rows where the join condition is true on both sides — customers who have orders. LEFT JOIN returns every row from the left table and matching rows from the right; unmatched rows have NULL on the right. I use LEFT JOIN when I need to see the whole population and count the gap — for example, customers with zero orders in the quarter — and INNER JOIN when I only want the intersection. The most common bug I see analysts ship is an INNER JOIN where the analyst thought a LEFT JOIN was implied."
Rubric: definitions correct; use case per join; common bug named.
18. Explain the SDLC. Which methodology does your current team use?
Sample answer. "SDLC is the software development lifecycle — requirements, design, build, test, deploy, operate. My current team runs a scaled-agile hybrid: two-week sprints, PI planning every quarter, and a change-advisory board for anything that touches SOX-controlled systems. We use Jira for the backlog, Confluence for design docs, and ServiceNow for the CAB. The hybrid works well for enterprise systems where 'ship fast' isn't the whole story."
Rubric: names the phases, names the framework, names the tools.
19. What is UAT and how do you design a UAT script?
Sample answer. "User Acceptance Testing is the business's sign-off that the system does what the BRD said it would. I design UAT scripts as a set of scenarios that map 1:1 to the acceptance criteria — each scenario has a business context, preconditions, steps, expected result, and pass/fail. I recruit UAT testers from the business team that will use the system daily — never from the systems team — and I sit with them for the first hour of testing to catch UX confusion vs. actual defects."
Rubric: script maps to acceptance criteria; testers are business, not systems.
20. Describe how you'd design an integration between a CRM and an ERP.
Sample answer. "Six decisions upfront: (1) direction — one-way or two-way; (2) trigger — event-driven, scheduled, or on-demand; (3) transport — API, middleware (Boomi/MuleSoft/Workato), or file transfer; (4) transformation — where the data model gap gets bridged; (5) error handling — retry, dead-letter, alerting; (6) monitoring — what dashboards, what SLAs, who wakes up if it breaks. For a CRM-to-ERP customer sync, I'd typically pick two-way, event-driven from CRM to ERP for creates and updates, scheduled reconciliation nightly for parity check, middleware for transformation, and PagerDuty for on-call. I'd write it up as a two-page integration design doc before touching code."
Rubric: six decisions named; opinion on defaults; design doc, not tickets.
21. What is master data management (MDM) and why does it matter for a systems analyst?
Sample answer. "MDM is the discipline of maintaining a single, authoritative record for a business entity — customer, product, vendor, employee — across systems. For a systems analyst, it matters because most 'the system is broken' tickets root-cause to master data drift: two systems with different customer IDs for the same account, three vendor records for one supplier, an employee whose org node in HRIS doesn't match the cost center in the GL. Any integration project is 30% integration and 70% MDM; if you don't design for it upfront, you fight it forever."
Rubric: definition + root-cause frame + design-forward mindset.
22. Which ERP or CRM do you have deepest experience with?
Sample answer. Answer specifically. "Oracle Cloud ERP — Financials suite. I own GL, AP, and AR configuration, chart-of-accounts governance, subledger accounting rules, and the reporting layer through OTBI and FRS. I've led two upgrades and one FBDI-based conversion from Oracle EBS." Then name the module you're weakest on and how you're learning it. Never claim expertise you don't have — the technical deep-dive interviewer will test it.
Rubric: specific module, specific artifact, specific concrete task; humility on gaps.
The case / worked example
Many loops include a 60-minute worked example where you're given a scenario and asked to walk through your approach on a whiteboard or in a shared doc. Two are common:
23. Case: We want to consolidate three CRMs after acquiring two companies. Walk us through the first 90 days.
Answer arc. Week 1–2: current-state discovery — inventory of the three CRMs, data-model differences, user counts, integration touchpoints, contracts and licensing. Week 3–4: target-state design — which CRM survives, why (usually the one with the largest data set and the deepest integration footprint), high-level migration approach. Week 5–6: MDM strategy — master data model for customer, contact, opportunity, account hierarchy. Week 7–8: gap analysis and remediation plan — the current-state vs. target-state table by module. Week 9–10: user-training plan and change-management plan. Week 11–12: pilot with one BU; decision-gate for full cutover. Deliverables named at each phase: current-state map, target-state architecture, MDM design doc, migration plan, UAT plan, training plan.
Rubric: phased plan, named deliverables, decision gates, MDM given weight.
24. Case: The sales VP says the pipeline in Salesforce is "wrong." Diagnose.
Answer arc. Ask two clarifying questions before starting: (1) wrong how — under-reporting, over-reporting, missing records, wrong stages? (2) since when — always, since a specific date, since a specific change? Then walk the three most likely causes: (a) master data — accounts with duplicate IDs; (b) process — reps not updating stage at the right moment; (c) integration — a broken feed from a marketing automation platform not creating leads. Propose a diagnostic sprint: pull five specific opportunities the VP flagged, trace each end-to-end, and report by end of week which of the three causes dominates. Then remediate.
Rubric: clarifying questions, three root-cause branches, five-example diagnostic, one-week SLA.
Questions you should ask them
- Which SDLC methodology does the team follow — agile, SAFe, waterfall, hybrid — and what triggered that choice?
- What is the ratio of business analysts to engineers on the team? On the systems I'd own?
- Who owns the roadmap for the systems in scope — the business, the systems team, or a product manager?
- What are the top three systems in this role's portfolio, by ticket volume?
- How is success measured for this role in the first year? Cycle time to sign-off? Defect rate at UAT? Stakeholder NPS?
- Who has held this seat before, and where did they go?
- What's the single biggest change-management challenge on the roadmap right now?
Frequently asked questions
A typical loop is four to five rounds: recruiter phone screen, hiring-manager technical screen on requirements-gathering and gap analysis, stakeholder round with a business partner, technical deep-dive with a lead engineer or architect, and a behavioral round on ambiguity and stakeholder management.
SQL, business process modeling (BPMN, swimlane diagrams), requirements documentation (BRD, FRD, use cases, user stories), one BI tool, ERP or CRM familiarity, API and integration patterns at a conceptual level, and enough SDLC fluency to run agile ceremonies and write acceptance criteria.
Two: "Walk me through how you would gather requirements for X system," and "You have a conflict between two stakeholders on scope — what do you do?" Both test a repeatable framework, not a one-off story.
A 90-second arc: current title and system portfolio, one representative project with a measurable outcome, one skill you're deepening, and the specific reason this role is your next step.
Three that repeat: gathering ambiguous requirements, disagreeing with an engineer on a technical decision, and saying no to a stakeholder. All test whether you can translate business need into a specification without becoming a bottleneck or a doormat.
Refresh SQL joins and aggregations, review one BRD as a walkthrough artifact, sketch one BPMN from memory, know the SDLC methodology your target uses, and have a two-sentence answer for each system on your résumé.
Team methodology, analyst-to-engineer ratio, roadmap ownership, top systems by ticket volume, how success is measured — cycle time, defect rate, stakeholder NPS.
Get help preparing
A rubric is not the same as reps. The candidates who show up sharp for the technical and stakeholder rounds have run three or four mock loops with someone who has interviewed for the role before. Marqee is a Career Concierge: a real strategist runs your interview prep, sits in on your mocks, and gives you the specific edits — where you sound tentative, where the STAR framing falls apart, where you're leaving a metric on the table.
Free tools first — then put a human on it.
Run mock interviews free, or let a dedicated strategist prep you for the loop end-to-end.
Run a mock interview →See how Marqee works