Bridget Hudacs

1. Value Stream Mapping, especially documenting the current state, is an invaluable tool to identify key stakeholders for the project and to see the work required to create the future state. 2. Once key stakeholders are identified and the current and future states are mapped, hold a scoping meeting with all stakeholders (functional and technical). * Document the decisions related to in-scope and out-of-scope elements for the current timeline. * Identify who is responsible for the in-scope elements and the delivery timeline. * Keep the document in a centralized location where it can be referred to by all stakeholders. With those 2 tools, you can: * See who is impacted by the changes (whose feedback to incorporate); * What the agreed scope of work is (whose feedback to "ignore"/save for a later project phase).

As the Interviewee: 1. Have a list of interview questions that you tend to be asked (or Google Rev Ops Interview questions for ideas), and have examples from your work or studies that you can share as part of your response that highlight your skill and understanding of the role. 2. Get comfortable answering questions using the STAR method. It is a good framework for sharing examples so that you have clear and concise answers. 3. As you're interviewing, write down any questions that you stumbled over in an interview. Figure out what your answer will be if you're asked the same question in the future. 4. Think about your wants/needs for a future role. Develop questions to ask during the interview to determine if the role/company is right for you. Interviews are about you finding the right role as much as they are about a hiring manager filling a role. 5. Before your interview, review the job description and the company. Identify the parts of your work experience/resume that you want to summarize in 30 - 60 seconds in response to the inevitable "Tell me about your work history" question. (You don't have to summarize every job -- keep your initial response short and tactical. You can always expand if asked.) 6. Once you've done your prep work, relax. As the Interviewer: 1. Make sure that your questions are clear, especially for non-native speakers. Avoid colloquialisms. Vet the questions with colleagues to see if they understand what you're asking. 2. Have a list of questions that you ask all interviewees. You don't have to ask every question, but make sure that you have a few you ask consistently so you can truly evaluate candidates' strengths and weaknesses. 3. In concert with #2, build your questions primarily off of a job description for a role. Crafting the questions for your interview shouldn't be a night-before-the-interview endeavor. 4. Practice responses for candidate questions regarding the company, work environment and/or team. Sometimes you need to be diplomatic, but honest.

I've shared an Interview Template resource with Sharebird that provides the type of questions I use during my interview process. Regarding helpful resources, I believe that the job description for the role is the most important resource you can use when writing questions for the interview process. Without a clear understanding of the role, you set yourself and your candidates up for failure during the interview process. Then, as a hiring manager: * You can work with your Human Resources (HR), Talent Acquisition (TA) or outsourced recruiting partners to share required experience/questions that should be used for initial screening. * I've leaned on this point a lot with hiring. I focus on a few "non-negotiables" for a particular role to ensure that I speak with qualified candidates. I may provide specific questions and responses or, more frequently, qualifying questions that I would ask and the type of response I'm looking for (example: If someone can't give you an example of when they've had to tell someone "no", please don't move them forward). * You have a baseline to compare candidates against to try to minimize unconscious bias in the hiring process. (Here is a great book to help understand unconscious bias) And, as a cross-functional partner: * You can see the expectations of the role, which can help you develop questions for the candidate and ask support questions of the hiring manager. * You have a baseline to compare candidates against to try to minimize unconscious bias in the hiring process. (Here is a great book to help understand unconscious bias)

I hate to type this, but the first gauge of autonomy for a candidate is: How involved are/were their parent(s) in the process? The candidate, individually, should be scheduling interviews, asking/answering questions and making employment decisions. Personally, if I have to engage with someone's parent, then I'm not offering the person the job. I may make an offer to the parent, though (kidding!). Outside of that, I listen to how candidates respond to scenario questions and observe any noticeable response trends: * Are they constantly referring to having someone double-check their work? * When asked about independent decisions they've made, and the outcome of those decisions, do they have an example? Does that example involve cross-checking responses with a manager/supervisor? Sometimes the best way to gauge a candidate's autonomy is to structure questions that specifically speak to that issue. If I get a sense that, beyond nerves, a candidate is not exhibiting autonomy, I'll ask questions like: * What do you see as your level of authority/responsibility in a project team? * Please give me an example of a time when you went to your supervisor for help with an issue. Why you needed to escalate the issue? * Please tell me about a time when you had to adjust a stakeholder's expectations about a project. What did you do? Why? How was it received? From there, I assess how well their answers demonstrate the level of autonomy required for the role. An entry-level position will require less initial autonomy than a senior manager.

I don't have a recommendation for or against this type of detailed preparation, especially if it helps you structure verbal responses that also give a glimpse into how you think, problem solve and can be an asset to the company. But I wouldn't focus on developing unrequested collateral at the expense of having solid verbal responses. I would bring out supporting materials when they support your response to a particular question (ie if asked about what your 30-60-90 day plan would be in the role or what your organizational process is, show the prepared collateral as part of your response). Just be prepared for technical difficulties (internet bandwidth issues, screen sharing issues etc) that may impact how/if you can share these items in the interview itself. And remember, if what you prepared highlights a particular strength that you bring to the role, then you could also include it in a "thank you" email as a follow-up to your conversation.

When interviewing someone for a more junior role, I structure my questions using the journalistic "Inverted Pyramid" technique: 1. Initial Questions: Focus on general knowledge and basic skills required for the position (based on the job description). * These are the non-negotiables of the position, translated into non-work-specific questions. * In a 30 minute interview, I would spend about 10-12 minutes on these types of questions. * For example: If I'm hiring someone in Sales Ops, I'd provide math word problems to see how they would calculate/proof commissions calculations. For Dev Ops, ask about familiarity with coding languages and what projects they've done. This section is also where I focus on communication and team skills. 2. Follow Up Questions: Focus on higher level skills related to the position. * These are skills that will be part of onboarding for the role; the goal of the question is to see if the person has experience/familiarity with the concepts already. * In a 30 minute interview, I'd spend about 8-10 minutes on these types of questions. * For example: * In hiring an Admin for the team, I found that people said they had Excel experience, but they didn't. So, I created an in-interview assessment. The "follow up" question I asked was for the candidates to de-dupe a list of records. Weaker candidates would sort the list and manually review for duplicates. More experienced ones would use the "Remove Duplicates" function after clarifying the key data points for identifying duplicate records. Either method showed me that they understood the skill; one just required more onboarding than the other. * For analyst roles, ask a question like, "How many Snickers bars would fit in a suitcase?" or similar. The idea is to see how the candidate deals with the missing information. Is the candidate asking questions to clarify and provide a more educated response, or is the candidate giving a response based on assumptions? 3. Final Questions: Focus on real-world experience with the role. * These questions are "stretch" questions to see if the person has experience with key aspects of the role. For these questions, most of the time you'll just observe how the candidate handles the inquiry and their response, rather than listen for an actual "right" answer. * In a 30 minute interview, I'd spend 2-5 minutes on these types of questions. If the candidate flounders on the answer, I let them know that I was just looking to see the range of their experience and it's not a problem if they don't have an answer. * For example: * In my Admin example, my Final Question was one that involved creating an Excel formula to do a specific calculation (one that was needed for the reporting the Admin would manage). * For other roles, ask questions related to scenarios your team/this role will experience. The candidate may have had experience in a different context (school project, team sports etc).

The only universal red flag that I experience in initial interviews is when a candidate cannot provide a concrete example for a universal experience (ie telling someone "no", managing conflicting priorities, asking someone to clarify a request). If an interviewee has been fairly general in their answers and then responds, "I can't think of one," when asked for an example of how they've handled one of these universal experiences, that's a big red flag. It indicates to me that either a) they're not going to do well in the role because they're avoidant or b) their language proficiency (if they are interviewing in a non-native language) is not strong.

The mistakes that I notice are: 1. Not providing real world examples to support responses to situational questions. 2. Bad-mouthing former employers. Not every employer-employee relationship is a fit, and it's OK to say that. But, as a candidate, your answers need to express what you're looking to move toward, not what you're eager to move away from (and will spend a 30 minute interview kvetching about). 3. Being late without making an effort to communicate that to the interviewer and/or ghosting the interview, especially when you've requested special scheduling arrangements. As a bonus, the things interviewees may get nervous about, but I don't see as mistakes: 1. Asking to have a question rephrased. 2. Taking a minute or two to compose your answer. 3. Saying, "I haven't had experience with that." Not every candidate has experience with everything on the job description. It's not a problem to admit it, or to continue your response with "But I believe I've had a similar experience in [broader topic]" followed by an example of what you have done. (A personal example: Early in my career, my response to "What's the biggest team that you've managed?" was "I haven't had a role with direct reports. However, in my current role, I'm responsible for executing large-scale projects and managing teams of up to 10 people.")

My experience with blending legacy systems and new technology is to use a middleware to integrate the two. With middleware integrations, there are a few best practices that I support: 1. Limited admins. Have you been in a system where every user is an admin? Seamless integrations are the big reason (especially if you receive pushback on limiting administrator access to tools) to limit who has access to adjust back end settings in a system. Well-meaning people can disrupt integrations by "just adding a field" or "updating the picklist values". (In full disclosure, have unintentionally disrupted systems by being given unnecessary admin access to them) 2. Document the integration. I'm a big fan of a data dictionary that identifies the system, field type, type of integration (single or bi-directional) etc. that is maintained as a living document among tech teams. I also live in the real world. So, within systems, update field descriptions to identify if they're used in integrations. Specifically identify the system and the direction of the sync in the description. From there, you can discuss with integration teams where the particular field maps to in other systems. And, in any tech debt reconciliation projects, you know which fields need special consideration. 3. Ensure that integration discussions are part of the discovery process for new projects. Does a project impact an existing integration? Does a new integration field/process need to be put together? Which system is the system of record? How does the integration support the solution proposed for the project? Project Managers or Business Analysts don't have to be highly technical to work with integrations, but should have a list of questions to ask when integrations are involved so the solution can support the user experience and data integrity.

To foster a culture of continuous improvement, foster a culture of collaboration: 1. Encourage communication between team members and cross-functional teams. In the Kaizen philosophy, you can't improve a process if you're not doing it day-to-day. Listen, and give credibility to, the challenges of those who do the work. The "perfect" solution on paper may not actually work the best in practice. 2. Focus your team on finding ways to make processes 10% better, rather than finding a perfect solution. In Kaizen philosophy, it takes approximately 7 iterations of improving a process before it is optimally improved. Knowing that you don't have to solve everything at once can be freeing to find areas that can provide meaningful improvement: What is the biggest problem that the stakeholders have identified? How can that be improved? 3. Make sure stakeholders (those doing the work) are involved in the User Acceptance Testing (UAT) process. Their feedback is invaluable in ensuring that process improvements work for everyone, and can identify future improvements.