Business Analyst Interview Questions: 30 Practice Questions With Model Answers

By Stephen Adindu, CBAP, BCS Diploma in Business Analysis, Lead Coach at The Career Accelerators. Last updated November 2026.

Business analyst interviews test whether you can do the core work of the job: find out what the business really needs, write it down so it can be built and tested, and keep business and technology teams aligned. Expect questions in six groups: your background, core analysis technique, stakeholder scenarios, Agile delivery, tools and data, and, if you're new to Canada, your experience and work status. Answer technique questions with a short definition plus an example, and "tell me about a time" questions with a STAR story.

Below are 30 practice questions written by TCA, not taken from any employer or question bank. Each has what the interviewer is checking, a short model answer in the candidate's voice (swap in your own projects) and a common mistake. A one-week preparation plan and questions to ask the interviewer follow.

How should you answer business analyst interview questions?

Job Bank's description of IT business analysts (NOC 21221) lists the work interviewers are testing: meeting clients to identify and document requirements, analysing processes and recommending improvements, testing system changes, and acting as the go-between for business units, technology teams and support staff.

Technique questions ("what is traceability?") check your vocabulary: answer in two or three plain sentences and add an example. Scenario questions ("tell me about a time...") check how you work: answer with a short story. Fit questions (background, Canadian experience, pay) check whether you and the job match: keep them short. For scenario questions, use STAR:

What's in this guide

What background and motivation questions do BA interviewers ask?

1. Tell me about yourself.

What they're checking: whether you can give a short summary that fits this job. Choosing what matters to your audience is itself a BA skill.

Model answer: I've spent six years in customer operations at an insurer, most recently as a team lead. The part I enjoyed most was fixing processes: I mapped how claims came in, found that many files bounced back for missing documents, and worked with IT on a checklist in the intake form. That pulled me toward business analysis. This past year I've trained in BA techniques and written user stories and process models on a project. Your role is about modernising a customer-facing process, which is exactly the work I want to do.

Common mistake: walking through your CV from the beginning. Aim for about a minute: who you are now, the experience that fits, and why this role.

2. Why do you want to be a business analyst?

What they're checking: that you see the job as solving problems with people, not just producing documents.

Model answer: I like working out the real problem before anyone builds anything. In my last job, colleagues came to me when a process broke, and I kept asking BA questions: who uses this, where does it go wrong, what would good look like? Business analysis lets me do that full time, with proper techniques behind it.

Common mistake: saying it's a well-paid way into tech. That doesn't tell them why you'd be good at it.

3. In your own words, what does a business analyst do?

What they're checking: whether you see the role as enabling change rather than taking notes. IIBA's BABOK Guide describes business analysis as helping an organisation change by working out what's needed and recommending solutions that give stakeholders value.

Model answer: A business analyst helps an organisation change for the better. I find out what the business actually needs, turn it into clear requirements the delivery team can build and test, and keep business and technical people speaking the same language until the change works. The documents are a means to that end.

Common mistake: describing only outputs ("I write BRDs") without saying what they're for.

4. Walk me through a piece of analysis work you're proud of.

What they're checking: depth. Can you explain a real deliverable from problem to outcome, and make your own part clear?

Model answer: We were building a booking app for a clinic. I interviewed the front-desk staff and two clinicians and mapped the current booking process in BPMN. The map showed double bookings happened because phone and online bookings used different calendars. I wrote the user stories for one shared calendar, with acceptance criteria for the clash rules, and the clinic approved the new process. I can share the map if that's useful.

Common mistake: picking something too big to explain in two minutes, or saying "we" throughout so they can't tell what you did.

Which business analysis technique questions should you expect?

5. How do you elicit requirements?

What they're checking: that you choose techniques on purpose. The BABOK Guide's Elicitation and Collaboration knowledge area covers preparing for, conducting and confirming elicitation, and the Guide's techniques include interviews, workshops, observation, document analysis, surveys and prototyping.

Model answer: I prepare first: I read what exists, such as procedures, reports and old tickets, and decide who I need to hear from. Then I match the technique to the situation: interviews for senior or sensitive views, a workshop when several groups must agree, observation when people work differently from how they describe it, and a prototype when users can't picture the change. Afterwards I play back what I heard in writing and ask people to confirm it.

Common mistake: saying "I ask the stakeholders what they want." People often describe a solution they've pictured, not the need behind it.

6. What are the main types of requirements?

What they're checking: whether you know IIBA's classification and can use it to sort a messy list.

Model answer: IIBA uses four types. Business requirements explain why we're changing: goals and outcomes. Stakeholder requirements describe what particular groups need for those goals to be met. Solution requirements describe the capabilities and qualities the solution must have, split into functional and non-functional. Transition requirements are temporary, such as data conversion and training to get from today to the new state.

Common mistake: forgetting transition requirements. If nobody plans the data migration or the training, the system can be ready while the business isn't.

7. What's the difference between functional and non-functional requirements?

What they're checking: that you can tell behaviour from qualities, and make qualities measurable. Non-Functional Requirements Analysis is one of the BABOK Guide's 50 techniques.

Model answer: Functional requirements describe what the solution does: "a customer can update their mailing address online." Non-functional requirements describe qualities or conditions: performance, security, privacy, accessibility. I make them measurable, so "fast" becomes "results appear within two seconds for 95% of searches." Some aren't negotiable: in Ontario, designated public sector organisations and businesses or non-profits with 50 or more employees must make their public websites meet WCAG 2.0 Level AA.

Common mistake: writing quality requirements no one can test, such as "user-friendly."

8. When would you write a BRD, and when would you use user stories?

What they're checking: that you can work in predictive and adaptive (Agile) settings and pick the format that fits.

Model answer: A business requirements document suits work where scope is agreed and approved up front, such as a vendor selection or a regulated change that needs one approved record. User stories suit Agile teams that add detail as they go: each story is a small slice of value with acceptance criteria, refined shortly before it's built. Many organisations mix the two: a short BRD or vision for the business case, then stories in Jira for delivery.

Common mistake: calling one format right and the other outdated. They want to hear you'd adapt to their team.

9. How do you model a business process?

What they're checking: that you can map the current process, find its problems and show the future one. Process Modelling is a BABOK Guide technique. BPMN (Business Process Model and Notation) is the Object Management Group's standard notation, also published as ISO/IEC 19510.

Model answer: I start with the as-is process. I walk through real cases with the people who do the work and draw it in BPMN: a lane for each role, the tasks, gateways for decisions, and start and end events. Then I look for delays, hand-offs and rework. The to-be model shows the change, and the gap between the two is what the requirements must close. I use Visio or a similar tool and keep the first draft rough, because people correct a picture faster than a paragraph.

Common mistake: drawing the process as it's supposed to work, not as it actually works.

10. What is a use case, and how is it different from a user story?

What they're checking: whether you know when a flow needs step-by-step detail. The BABOK Guide lists Use Cases and Scenarios and User Stories as separate techniques.

Model answer: A use case describes how an actor interacts with a system to reach a goal, step by step: the main path, alternative paths and exceptions. A user story is a short statement of who wants what and why, with acceptance criteria, and the detail comes from conversation. I use a use case when the flow is complex, like an online insurance claim with document checks, and stories for incremental backlog work.

Common mistake: treating the use case diagram as the use case. The diagram shows actors and goals; the value is in the written flows.

11. What is requirements traceability, and why does it matter?

What they're checking: whether you can show where each requirement came from and where it went. Trace Requirements is a task in the BABOK Guide's Requirements Life Cycle Management knowledge area.

Model answer: Traceability links each requirement back to the business objective it supports and forward to the design, build and test cases that prove it. I keep it in a traceability matrix or as linked items in Jira. It answers three questions: is every requirement tested, does every feature trace to a real need, and if this requirement changes, what else is affected?

Common mistake: describing the matrix as paperwork for auditors. Its everyday use is working out the impact of a change.

12. How do you prioritise requirements?

What they're checking: that you facilitate the decision with the people who own it. Prioritize Requirements is a BABOK Guide task.

Model answer: I agree the criteria first: business value, regulatory need, risk, cost and dependencies. Then I take the options to the decision owners. For a fixed release I often use MoSCoW: must have, should have, could have and won't have this time. The Agile Business Consortium, which publishes MoSCoW as part of DSDM, advises keeping must haves to no more than 60% of the effort, so lower priorities can be dropped if work takes longer than planned. I record the reason for each call, because the same debate tends to come back.

Common mistake: letting everything become a must have. Then nothing has been prioritised.

13. What's the difference between verifying and validating requirements?

What they're checking: precise vocabulary. Verify Requirements and Validate Requirements are separate tasks in the BABOK Guide's Requirements Analysis and Design Definition knowledge area, and IIBA publishes a task card for each.

Model answer: Verifying asks whether a requirement is good enough to use: clear, consistent and testable. Validating asks whether it's the right requirement: does it support the business need and the value we expect? A requirement can pass verification and fail validation, like a perfectly written spec for a report nobody will read.

Common mistake: using the two words as if they mean the same thing.

14. What does a business analyst do during testing and UAT?

What they're checking: that you stay involved after the requirements are written. Job Bank lists testing system changes among the duties of IT business analysts.

Model answer: I make sure every requirement has acceptance criteria testers can use, review test cases against them, and help the business plan user acceptance testing: who tests, which scenarios and what counts as a pass. During UAT I triage issues with the team, separating defects from new requests, and keep traceability current so the sponsor can see what's been tested before sign-off.

Common mistake: saying testing belongs to the QA team. You're responsible for making sure every requirement can be tested and the business can see it was met.

How do you answer stakeholder and conflict questions?

Question 15 is a technique question; the rest are scenarios, so the model answers use STAR. Use a true story of your own, from any job.

15. How do you identify and analyse stakeholders at the start of a project?

What they're checking: planning. This is the BABOK Guide's Plan Stakeholder Engagement task, and Stakeholder List, Map, or Personas is one of the Guide's techniques.

Model answer: I list everyone the change affects, everyone with a say and everyone who holds information, including easy-to-miss groups like front-line staff, support teams, compliance and outside partners. I map them by influence and interest, so I know who needs close involvement and who needs updates, and agree who approves what, often with a RACI chart. I revisit the map as the change gets closer to people.

Common mistake: naming only the sponsor and the end users.

16. Tell me about a time two stakeholders wanted conflicting things.

What they're checking: whether you find the goal behind each position and use facts, rather than simply splitting the difference.

Model answer:
Situation: On a membership system replacement, finance wanted pre-authorized debit only, to reduce failed payments. Member services wanted to keep credit cards because members asked for them.
Task: I needed one agreed requirement before the design workshop.
Action: I met each manager separately to understand the goal behind the request, then pulled payment-failure figures by payment method. They showed most card failures came from expired cards, which a reminder before expiry could prevent. In a joint session we agreed the shared goal: fewer failed payments without losing members.
Result: We made pre-authorized debit the default and kept cards, with an expiry reminder added to the requirements. Both signed off that week, without the sponsor stepping in.

Common mistake: going straight to the sponsor, or proposing a compromise before you understand either side.

17. Tell me about a time a stakeholder asked for a solution that didn't match the real need.

What they're checking: root-cause thinking. IIBA's Business Analysis Core Concept Model treats need and solution as separate concepts, and Root Cause Analysis is a BABOK Guide technique.

Model answer:
Situation: An operations manager asked for an extra manager approval on every supplier invoice because "payments keep going out wrong."
Task: I was asked to write the requirement for the new approval step.
Action: I asked which payments had gone wrong and pulled the last quarter's errors, then ran a "five whys" session with two accounts payable clerks. Most errors came from duplicate supplier records, not from missing approvals. I proposed a duplicate check when a supplier is added, plus a one-off clean-up of the supplier list.
Result: Payment errors fell without an approval step that would have slowed every invoice, and the manager agreed to drop the original request.

Common mistake: writing up the requested solution without asking what problem it solves.

18. Tell me about a time requirements changed after sign-off.

What they're checking: change control. Assess Requirements Changes is a BABOK Guide task.

Model answer:
Situation: Two weeks after sign-off on an employee onboarding portal, the HR director asked for electronic signatures on every form.
Task: I had to assess the change without derailing the launch.
Action: I logged a change request, used the traceability matrix to find the affected requirements, screens and test cases, and got an estimate from the developers. I took two options to the change board: add it now and move the date three weeks, or launch on time and add it next release.
Result: They chose the second. We launched on schedule and e-signatures followed in the next release.

Common mistake: saying yes to keep the stakeholder happy, or refusing because the document is signed.

19. Tell me about a time a stakeholder wouldn't engage.

What they're checking: persistence, and whether you change your approach instead of blaming the person.

Model answer:
Situation: On a records management project, the regional operations manager kept missing workshops, and her team would use the system most.
Task: Without her input, we risked building something her team wouldn't adopt.
Action: I asked for 20 minutes one-to-one and opened with what the change meant for her team. She said the workshops clashed with her busiest hours. I moved her sessions to early mornings, sent short summaries she could approve by email, and asked her to nominate someone to join the workshops.
Result: Her nominee became one of our most active testers, and her sign-off came on time.

Common mistake: complaining about the stakeholder, or saying you'd simply escalate.

20. Tell me about a mistake you made in a requirement.

What they're checking: honesty, ownership and what you changed afterwards.

Model answer:
Situation: On a billing change I wrote that invoices would be issued "at month-end."
Task: Finance read that as calendar month-end; IT read it as the end of each customer's billing cycle.
Action: When testing showed wrong invoice dates, I owned the mistake straight away, ran a short session with both teams to agree the rule, and rewrote it with a worked example for each case. I also started a project glossary.
Result: The corrected rule went in before go-live, and I now add worked examples to every date rule I write.

Common mistake: picking a fake weakness, or a mistake with no lesson.

What do interviewers ask about Agile business analysis?

These three test what you'd do on an Agile team. For Agile-heavy questions, such as the Definition of Ready, splitting stories and documentation, see questions 52 to 60 in our 60 Agile interview questions and answers.

21. A story reaches refinement and the developers say it's too vague. What do you do?

What they're checking: that you prepare for refinement and treat questions as useful. The Scrum Guide describes refinement as ongoing work to break items down and add detail, and gives sizing to the Developers who will do the work.

Model answer: I'd thank them, because that's refinement doing its job, and ask what exactly is unclear: the user, a business rule, the data or the edge cases. If I can answer in the room, we update the story there. If not, I take the open questions to the Product Owner or subject-matter expert, come back with examples and a rough mock-up, and we look again before Sprint Planning. Next time I'd check for those gaps beforehand.

Common mistake: defending the story, or answering "how should we build it" questions that belong to the Developers.

22. Write acceptance criteria for this story.

What they're checking: that you can write testable criteria on the spot, including when things go wrong. Acceptance and Evaluation Criteria is a BABOK Guide technique. For example: "As an online banking customer, I want to set up a recurring bill payment so that I don't miss due dates."

Model answer:

• Given I'm signed in with an eligible account, when I choose a payee, amount, start date and frequency and confirm, then the payment appears in my scheduled payments with its next date.
• Given I enter a start date in the past, when I try to confirm, then I'm asked for a future date and nothing is scheduled.
• Given I have a recurring payment, when I cancel it before its next date, then no further payments are made and I get a confirmation.

Then I'd ask about rules I can't assume, such as payment dates that fall on a holiday, or a maximum amount.

Common mistake: writing only the happy path, or restating the story as the criteria.

23. The Product Owner is hard to reach. How do you keep the team moving?

What they're checking: that you support the Product Owner without taking over their decisions. The Scrum Guide lets the Product Owner delegate backlog work, but they remain accountable for it.

Model answer: I'd ask for a short regular slot, even 30 minutes twice a week, and bring decisions ready to make: the options, my recommendation and the impact. In between, I'd keep refining stories with the team and subject-matter experts so there's always ready work. I wouldn't re-order the backlog myself; I'd agree up front which decisions I can make and which need the Product Owner.

Common mistake: making backlog decisions that belong to the Product Owner, or waiting until the team runs out of ready work.

What tools and data questions come up?

24. Which tools do you use, and how do you manage requirements in Jira and Confluence?

What they're checking: that you match each tool to a job, rather than reciting a list.

Model answer: Jira for the backlog: epics for larger pieces of work, stories under them, each with acceptance criteria and links to related stories and test cases. Confluence for what needs more room: business context, process maps, decisions and the glossary, with each page linked to its Jira epic. Visio or similar for BPMN maps and use case diagrams, and a mock-up tool for screen sketches. If your team uses another tracker, the same structure applies.

Common mistake: naming tools you've only watched a video about. Expect a follow-up on how you used each one.

25. How comfortable are you with SQL?

What they're checking: whether you can pull your own data, and whether you're honest about your level. Understanding the data model helps; the BABOK Guide covers it in its Data Modelling technique.

Model answer: Comfortable with the basics: filtering, joining tables and summarising with GROUP BY. For example, to count open claims by region:

SELECT region, COUNT(*) AS open_claims
FROM claims
WHERE status = 'Open'
GROUP BY region
ORDER BY open_claims DESC;

I use queries like this to size a problem before writing requirements and to test data rules in UAT. For complex queries or performance tuning, I'd work with a data analyst or developer.

Common mistake: overstating your level. A live exercise will show it.

26. How do you use Excel in analysis work?

What they're checking: practical data handling, with an example.

Model answer: For quick analysis and checks: pivot tables to summarise volumes by category, lookup formulas to match records from two system extracts, filters and conditional formatting to spot gaps, and simple charts for a steering committee. Without a requirements tool, I also use it for a first traceability matrix or data-mapping sheet. I keep the raw data on its own untouched tab so anyone can check my working.

Common mistake: saying "I'm advanced in Excel" with no example.

What questions do newcomers to Canada get?

In Ontario, since 1 January 2026, employers with 25 or more employees can't include Canadian experience requirements in publicly advertised job postings or their application forms. The rule comes from Ontario's Employment Standards Act, which doesn't cover federally regulated employers such as banks, and the job-posting rules don't apply to the Crown. The Ontario Human Rights Commission (OHRC) also advises employers not to ask about Canadian experience in interviews, and to consider experience from any country. These are Ontario rules, so check your province's if you're elsewhere. Either way, prepare for these questions.

27. Do you have Canadian experience?

What they're checking: usually whether you'll work well in a Canadian workplace: communication, local ways of working and the team's tools.

Model answer: My business analysis experience is from [country], where I spent four years on banking projects: requirements, process mapping and user acceptance testing for a mobile app launch. Since moving to Canada I've [worked on a project, volunteered or worked] with a Canadian team, running workshops on video calls and managing stories in Jira and Confluence. The skills are proven, and I've already used them here.

Common mistake: saying "no" and stopping, or apologising. Answer the concern behind the question.

28. Your last title wasn't "business analyst." Why should we count that experience?

What they're checking: whether you can translate past work into BA terms yourself.

Model answer: Because the work was business analysis, even if the title wasn't. As a customer service team lead I gathered complaints from three channels, found the pattern, mapped the refund process with finance and wrote the change request IT built. That's elicitation, root cause analysis, process modelling and requirements. I've since learned the formal techniques, so I can do it more deliberately.

Common mistake: leaving the interviewer to make the connection.

29. Are you legally entitled to work in Canada?

What they're checking: eligibility. The OHRC says employers can ask whether you're legally entitled to work in Canada, but should avoid questions about citizenship (outside a few exceptions), immigration status or where you're from.

Model answer: Yes, I'm legally entitled to work in Canada. If your work permit has an end date, it's fair to mention it briefly when asked.

Common mistake: telling your whole immigration story. Answer the question asked.

One TCA graduate, Silverlyn, moved from customer service into a business analyst role while on a temporary work permit, with an offer from her first interview. Read her story.

30. What are your salary expectations?

What they're checking: whether your expectations fit their budget, and whether you've done your research.

Job Bank's line for IT business analysts is "Analyst, Business - Computer Systems" (NOC 21221). Annual amounts below assume 37.5 hours a week for 52 weeks. The low and high figures are, in most cases, the 10th and 90th percentiles, and Job Bank says its wages don't account for years of experience.

Source: Job Bank, Labour Force Survey data for 2023 to 2024, wages updated 19 November 2025. Ontario's median is the same, C$45.13 an hour. Ontario postings covered by the 2026 rules (which exclude federally regulated employers such as banks, and the Crown) must also show the expected pay or a range no wider than C$50,000 a year, unless the pay is above C$200,000.

Model answer: Based on the range in your posting and Job Bank's figures for IT business analysts, I'm looking for around [figure], depending on the full package. Is that in line with your range?

Common mistake: naming a number before you've seen their range, or anchoring on the high figure, which is usually the 90th percentile, not a typical starting salary.

How should you prepare in the week before the interview?

For day 1, see our guide on how to research a company before a job interview.

What should you ask the interviewer?

Your questions show how you think about the role. These suit BA interviews:

• How does the business analyst role split with the Product Owner and the project manager here?
• Where do requirements live today: a BRD, Jira, Confluence or something else?
• Who are the main stakeholders for this role, and how often will I work with them?
• How are requirements approved, and how are changes handled after approval?
• What would success look like in this role after 90 days?
• What's the biggest problem you'd want the new analyst to help solve?

For more, and the questions to avoid, see questions to ask at the end of an interview.

How we prepare business analysts for interviews at TCA

Our business analyst course, the Business Analysis Coaching Course, is a 12-week coaching program taught live in a virtual classroom, with no prior experience needed. This program includes a 12-week live project on a real tech product, where you create BA deliverables such as business requirements documents, software requirement specifications and use case diagrams that you can talk through in interviews. You'll work with Jira, Confluence, Visio, MockFlow and Zephyr, learn BPMN and UML modelling and SQL fundamentals, and get one-on-one mentorship, a CV review and an intensive mock interview once you're invited to a BA job interview. The Career Accelerators is an IIBA Endorsed Education Provider.

If you only need interview practice, our Interview Coaching Masterclass is a self-paced video course of 20 lessons for business analysis and project management interviews, for C$100.

Business analyst interview FAQs

Are these real questions from Canadian employers?
No. They're practice questions written by TCA around the duties Job Bank lists for IT business analysts. Use them to practise the skills, not to memorise answers.

Do I need a certification to get a BA interview?
No. Job Bank lists the occupation as unregulated; most employers expect a bachelor's degree in computer science, business administration, information systems or a related field, or a college computer science program. Job Bank adds that some employers may require certification or training from software vendors. If you want a BA certification, the ECBA has no experience or professional development requirements: IIBA only asks you to agree to its policies and terms when you buy the exam. The CCBA needs 3,750 hours of business analysis work in the last seven years, with 900 hours in each of two of the six BABOK knowledge areas or 500 hours in each of four, plus 21 professional development hours in the last four years and two references. The CBAP needs 7,500 hours in the last 10 years, with at least 900 hours in each of four knowledge areas, plus 35 professional development hours in the last four years and two references.

Will there be a practical test?
It depends on the employer. If the posting mentions SQL, process modelling or user stories, be ready to do one on the spot, as in questions 9, 22 and 25.

Can I bring work samples?
Yes, if you're allowed to share them. A process map or a few user stories makes your answers concrete. Remove anything confidential first.

What if they ask a lot of Agile questions?
Start with questions 21 to 23 here, then practise with our 60 Agile interview questions and answers.

Stephen's tip: Pick one deliverable you've produced, such as a process map, a set of user stories or a page of a BRD, and practise walking an interviewer through it in two minutes: the problem, who you spoke to, what you wrote and what changed.

Ready for your business analyst interview?

Our business analyst course combines live training, a 12-week live project and interview preparation, so you have real work to talk about. Want a second opinion on your answers? Book a free call and we'll look at what to practise.

Related reading: how to become a business analyst in Canada, the BABOK Guide explained and how to master business process modelling.

Sources

• Job Bank: Analyst, Business - Computer Systems (NOC 21221), for duties; wages and wage methodology, for pay; requirements, for regulation, education and vendor certification
• IIBA: Structure of the BABOK Guide, for knowledge areas, task and technique names; What is business analysis?, for the definition
• IIBA's Business Analysis Standard: Understanding requirements and designs, for the four requirement types; Requirements Analysis and Design Definition, for the task names; A model for good analysis (BACCM), for need and solution
• IIBA BABOK Guide task cards: Verify Requirements and Designs and Validate Requirements and Designs, for verify versus validate
• IIBA: ECBA, how to apply for the CCBA and how to apply for the CBAP, for eligibility
• Object Management Group: BPMN, for the standard and its ISO number; IBM: What is BPMN?, for its main elements
• Agile Business Consortium: MoSCoW prioritisation, for the categories and the 60% guidance
• The Scrum Guide (2020), for refinement, sizing and the Product Owner's accountability
• Atlassian: Epics, stories and initiatives, for how Jira groups stories under epics
• Government of Ontario: Requirements related to publicly advertised job postings, for the Canadian experience and pay disclosure rules and their exemptions; Industries and jobs not covered under the Employment Standards Act, for federally regulated employers; How to make websites accessible, for WCAG 2.0 Level AA
• OHRC: Removing the "Canadian experience" barrier and Interviewing and making hiring decisions, for interview guidance