@Lavonia Joyner-Banks with that experience you could easily look at PM roles as well. I would suggest doing a deep dive learning into the Agile Scrum methodology. This is how your skills translates to Manual QA - Collaborated with cross-functional teams to gather and validate requirements, ensuring project deliverables aligned with stakeholder expectations and reduced risk to project outcomes. - Monitored project activities and conducted quality assurance checks throughout the project lifecycle, identifying issues early and supporting resolution to maintain performance standards. - Conducted data collection and analysis (surveys) to evaluate system/process effectiveness, ensuring accuracy and supporting informed decision-making. - Identified potential service disruptions and provided alternative solutions, demonstrating strong problem-solving and defect identification skills. - Supported pre- and post-implementation phases by validating workflows and ensuring minimal operational disruptions, similar to regression and user acceptance testing. - Maintained detailed documentation of meetings, processes, and outcomes, ensuring traceability and clear communication across internal and external teams. - Managed and updated tracking systems/databases, ensuring accurate data entry, organization, and reporting — aligning with test tracking and defect management practices. - Monitored overall project quality and compliance, ensuring deliverables met defined standards and expectations throughout the lifecycle.

@Janaia Guy these are great translational skills. How this translates to Manual QA * Performed detailed data validation and quality checks on medical claims, ensuring accuracy, completeness, and compliance with business rules. * Verified insurance and patient information by cross-referencing multiple data sources, demonstrating strong data integrity and defect identification skills. * Analyzed Explanation of Benefits (EOB) documents and entered data into systems, ensuring accurate data processing and system reliability. * Identified discrepancies and inconsistencies in claims data, escalating issues for resolution — aligning with bug/defect reporting practices. * Executed structured review processes to determine claim approvals or denials, applying business logic validation and decision-based testing. * Reviewed documentation such as property appraisals and surveys, ensuring alignment with system and business requirements. * Evaluated financial data (credit scores, debt-to-income ratios) to support decision-making, demonstrating analytical thinking and validation of expected outcomes.

@Lavonia Joyner-Banks The number one question that has come up in 97% of my interviews is “Tell me about yourself.”

I don't want to sound so cliché, but Practice makes Perfect! I have practiced my "Tell Me About Yourself" answer so much that I say it with confidence. With interviews in general, there is a level of nervousness. But I make sure to study the company and interviewer prior to the interview. This helps build a level of confidence, since I know most people don't go that extra mile so I'm coming to the table with extra tools in my belt.

@Brandon Mccray this is a really solid answer—you’re thinking exactly how a real QA should 👏🏽 You explained the risk clearly, especially around wasted effort and delays. That’s honestly something teams deal with all the time when bugs aren’t labeled correctly. If I could add just a little to what you said: When severity or priority is off, it’s not just a process issue—it can actually hurt the product. Like, a serious bug getting labeled too low might slip into production and now users are frustrated, or worse, something breaks that impacts the business. On the flip side, if something small gets treated like it’s urgent, the team ends up spending time on the wrong thing while bigger issues are sitting there. And I really like that you mentioned user experience, because that’s a big one. Sometimes a bug might not seem “severe” technically, but if users see it right away, it becomes a bigger deal than it looks on paper. One simple way to think about it: - Severity = how bad is it - Priority = how fast do we need to fix it You’re definitely on the right track with this. I’m curious—how would you handle it if a developer disagrees with the severity or priority you assigned to a bug? 👀

Perfect example of an answer to a situational question in the interview. In every interview I’ve had, they ask me about a time that I had a defect or Bug that the developer couldn’t replicate. I answer pretty much like you mentioned above. The third party I mention is the Dev lead.

@Brandon Mccray @Lavonia Joyner-Banks These were my thoughts exactly. “Sized appropriately” is subjective. This is exactly the questions I am going to ask in Stand Up tomorrow. Normally, they have instructions on size that can be seen in Dev Tools that can confirm a validating factor. But if that validating factor isn’t mentioned…they can come back on me and say it wasn’t right. I make sure to note Dev name and put it on the comments section of my testing card.