The Recruitment Hackers Podcast

New insights every single week from top leaders in Talent Acquisition.

    Assessment Strategies with Professional Snoop, Bas van de Haterd

    In this episode of the Recruitment Hackers Podcast, Bas van de Haterd, self-described professional snoop and consultant for TA professionals talks about assessments, from how to choose the r...
    Continue Reading
    All Posts
    Max Armbruster
    Max Armbruster
    CEO Talkpush

    How to Interview Engineers - Alison Daley from Recruiting Innovation

    Episode 64 full coverIn this episode of the Recruitment Hackers Podcast, Alison Daley, CEO at Recruiting Innovation talks about technical recruiting. Most recruiters hiring for engineering or developer positions aren't really tech people themselves. Alison came up with a framework to get tech recruiters ready, ask the right questions, and be able to make informed decisions on talent. Find out more about Recruiting Innovation’s online tech recruiter certification and their approach to hiring!


    Watch the entire episode below.

     

     

    Or listen on your favorite platform:

     

    🎧 Apple Podcasts

    🎧 Google Podcasts

    🎧 Spotify

    🎧 Podcast Addict 

     

    Don't feel like listening? You can read the entire transcript right here. 👇

     

    Max: Hello and welcome back to the Recruitment Hackers Podcast. I'm your host, Max Armbruster, and today I'm delighted to welcome on the show Alison Daley. Alison is the founder and CEO of Recruiting Innovation, a business focused on helping recruiters who don't know how to speak to engineers and don't know how to confidently assess them. And if you know in 2021, I think just about every company out there is promoting themselves as a tech company and mentioning that hiring engineers is their number one bottleneck. So, there's a huge demand for people trying to figure out how to interview engineers intelligently, and this is where Alison is gonna be able to help us, I hope. During our conversation we'll cover methodologies and techniques that can be applied to technical recruiting. Welcome to the show, Alison. 

     

    Alison: Thank you. Thank you so much for having me, I'm glad to be here.

     

    Max: Delightful to have you. And I think you didn't grow up wanting to be a technical recruiting trainer. So, what happened? How did you end up doing what you're doing today?

     

    Alison: That's my favorite question to ask recruiters or people in talent space is like what's your origin story of how you got here because most of us didn't have dreams of working in recruitment, let alone study for it. I actually call myself the accidental recruiter. I've fallen into recruitment four times, and I've kicked it three times and I think it's just that at this point now I'm all in on recruitment and being an extrovert, as extrovert, this is definitely my industry. And at this point, I've recruited for Fortune 500s, boutique [unintelligible] firms, hydro start-ups, and you know I cut my teeth on the top 5 staffing firm in the world. So, I've seen it all at this point and part of where I got, how I am where I am today is that I actually chose to come back into recruitment after I've left it where I thought was gonna be the last time, for real this time. And the story behind that was that my last recruiting role at a hydro start-up here in Colorado, I kind of was burning out.

     

    As an industry, it can be a tough industry to stay, you know, fulfilled in, and especially if you don't feel like you're growing professionally or growing up the ranks, and that was kind of my situation. And so, I had decided I was gonna take my people skills and pivot into user-experience research. I used to be a dedicated UX, user-experience recruiter, and so I used to live vicariously from my UX candidates that's such a great blend of analytical and creative skill set and I did a UX boot camp. I actually landed a role very quickly as a Junior UX Researcher because my network was so big, so strong after being a UX recruiter and got on a software development team and became the person tasked with figuring out who are our end-users, where are they, get them to talk to me, follow the UX methodology of sort of assessing, you know, what were their goals related to the product, their experiences, their frustrations, and synthesizing those stories back to the team to make informed product decisions. And I had this aha moment, maybe 9 months into the role, where I realized that this methodology that exists in software development within a user-experience umbrella, to systematize talking to these end-users, getting their stories, and then sharing them back to the team, I thought, oh my gosh, what if we could take this methodology and we'll bring it to the recruiting space, especially in tech recruiting where it often feels like we're navigating in a foreign language.

     

    Having a methodology to follow to have these conversations would not only give recruiters a leg to stand on with technical talent and learn to speak their language, but it actually would make us more effective at our role. And looking at the market, no one was really out here solving for the very known issue that recruiters don't understand what software development process is, who those different roles are, and how do I engage with them effectively. And so, one year in to my UX role, after having left recruitment in the dust, of course, I actually quit the role in UX and then came back to save tech recruiting.

     

    Max: To tackle a bigger problem. 

     

    Alison: That's right.

     

    Max: Yeah. You mentioned that, you know, your traits include being an extrovert and communicator and high-energy person. I suppose you meant by that that recruiting typically attracts these types of psychological profiles as opposed to perhaps engineering which would be more likely to attract introverts. Just to set the scene a bit, would you say that the majority of tech recruiters are not engineers? I think that's a fair statement. 

     

    Alison: That is totally a fair statement, yes. 

     

    Max: So, I've done a lot of tech recruiting myself and sure, I never had a single one of them where I felt smart. You know you're looking for a certain set of keywords and the interview is over in like 30 seconds when you've gone through them. 

     

    Alison: Yeah, I call it keyword-jousting, when you're just trying to match the keywords from their resume to the keywords in the job description, yeah. That's sort of what we're rendered down to doing if we don't understand the background of what these folks are doing and how to get a story out of them. 

     

    Max: Yeah, yeah. So, I'm your target audience, right? People like me who dread coming into an interview with the sense that they're gonna feel stupid. 

     

    Alison: Yup, been there done that. I mean that's the thing too about our industry in general. As an industry, we really believe in a sink or swim ethos to new hire onboarding, and honestly, I think that that's an old era. We gotta think about what is recruiting look like in the 21st century and that means that we need to be prepared to train and enable our recruiters to meet the insane moment that we're in right now. And so, it requires cohesive training and onboarding. And so, that’s the goal of what I've built is to help recruiters sort of, and teams, circumvent the unnecessary need of just throwing people in the deep end and hoping that if they talk to a few candidates and a few hiring managers, they'll suddenly know that Java's not short for Java Script and, you know, basics like that. But I think having a cohesive training is the way of the future, that's for sure. 

     

    Max: C++ isn’t the latest version of C, and stuff like that, yeah.

     

    Alison: Right. 

     

    Max: But those are very superficial examples. There's never, I mean an engineer is gonna be proud of what they know and proud of the knowledge that they've accumulated, and quick to judge somebody who doesn't ask the right questions as well, so it is a tricky audience. Is your methodology going to go deep into teaching, you know for example all those different languages and those frameworks that developers use so that you can kind of jump from one tech to another while you're doing interviews, or is it more of a general approach that you can apply for any field of software development?

     

    Alison: What we're gonna cover today is the latter. So, what I'm gonna be able to fit in to 10 or 15 minutes today will be specifically around how to have conversations that's sort of an agnostic general foundational level with any type of technologies on a software development team. But my company, Recruiting Innovation, we offer an online tech recruiter certification program where the course includes the framework that I'm gonna kind of highlight today, the alignment framework that I developed. That's what I call the tool kit I developed from the UX tools. But then within the tech recruiter certification, we take that same methodology and then we work with technical experts to become our instructors. And so then, you have a UX designer downloading their workflow and their tool kit and their things, you know, everything that you need to know to recruit someone like them within our model. And so, we combine both the general agnostic, how to have a conversations and do your job. Element of alignment framework that we're gonna cover today, and then we partner with technologists so then you learn specifically about front-end back-end dev ops, UX design and product management, from technologist themselves. And so, it's like a two-prong superpower at that point. 

     

    Max: That is, that's actually very appetizing, I must say. For me, like I'm thinking I need to sign up myself because, you know, I don't like sounding stupid and I have so many times. So, for today, the framework, the foundation, how do you speak engineer and how can you ask questions just on the back of a resume or a LinkedIn profile that can carry a conversation where both sides are talking for 40 minutes to an hour.

     

    Alison: Yes, yes. and that's what's cool about this framework is that it's role agnostic. So, what I'm gonna go through here in a moment is the workflow of people on a software engineering team, and I'll transition to that in a moment, but you can have comfort in knowing that everyone on a software development team, regardless of whether they're a data scientist, a front-end engineer, a UX designer, a product manager, everyone follows the same five-step workflow of software development. And so, once you understand that key workflow approach and then how to ask questions to touch on each of those stages of the workflow, you're off the races, and now you can have engaging conversations and ask good questions and get things back in a story form that a) not only establishes your credibility and actually starts to establish a connection with that technical candidate and get them excited to work with you, but part of our job is always presenting and positioning these candidates to our hiring manager and so this model actually gets a really rich story from the candidate and then it actually, 70% of our write-up on the candidate is done just by facilitating the interview in this way. 

     

    Max: Okay, great. Well, yeah, feel free to take it away. 

     

    Alison: Should we do it? Okay.

     

    Max: Yeah, let's go for it.

     

    Alison: Cool. The way I like to position this is with the alignment framework, so our proprietary training model, the alignment framework teaches recruiters the language of technology and how to talk tech. And so, knowing your audience, you know, you have Europeans, you have Asians, you got people in the US, probably, Africans. You have a global audience, okay? So, most of the people that listen to your podcast speak at least one and a half languages, if not more... 

     

    Max: For sure.

     

    Alison: more fluently. And so, what I'm gonna do is I'm gonna ask everyone to put on their learning a new language hat. So, we're gonna learn the language of tech today. And when we're learning a new language, there's two parts, right? There's grammar, so how to have conversations, how to structure our sentences. And then there's vocabulary, so once you've got the grammar down, it's all about learning as much vocabulary as you can, start populating the sentences, right? So, what I would like to do is first we're gonna talk about the grammar of technology and then we're gonna get into some vocabulary. So, when we're thinking about grammar and the structure of conversations within technology, I really wanna anchor this thought process into a workflow approach. So, everyone on a software development team has this a similar structure of workflow, same with anyone on a recruiting team has the same structure of workflow. So, bring at home recruitment. Our workflow kicks off when we get a new rec, right? So, that's when our process starts. And then we follow either five or six steps depending on your opinion about it, but I say it's six steps.

     

    Now, six-step workflow of a recruiter is you have your new role onboarding kick-off strategy meeting with your hiring manager, also known as the intake, sometimes. So, you have your intake with the hiring manager, then you go out and source, looking for candidates. In tech, you have to do outreach messages, that's not true for every industry, but outreach messages is definitely a step in the workflow. And you've got your phone screen as a recruiter, and you got your team interview, and you then you have your offer and higher stage. And then, once they accept, the role is closed, and your workflow is complete. [unintelligible] right? And so, as I'm going across those stages, I am doing and thinking certain things to solve for each problem of the process, right? So it's in, yes please?

     

    Max: Okay, great.

     

    Alison: Okay. So, taking this workflow approach, right? We have our discrete set of steps to complete our goals and we're doing and thinking certain things to solve for each of those stages, and in recruitment, that's our same process whether it's a marketing role, an engineering role, or ops role, you name it, that's our workflow. Now, in technology and on software development, it's the same thing. It's a very discrete workflow process. A lot of recruiters, if you don't know any better you think that there's some black box where magic happens, and software comes out. Not the case, I'm gonna take the mystic out now. It's a five-step process that everyone follows when developing software. So, yes. 

     

    Max: In recruitments, sometimes you do have specialization where there's like one team that does the [unintelligible] to job description and does the job posting and another team does the interviewing and the screening. And so, when you're hiring engineers, are you finding that they're also just focused on one part or they do the whole project than to end, or is it mixed?

     

    Alison: They have their own flavor of what they do and how they do it, and depending on sort of the methodology of the team. Some things are emphasized over others, but if anyone, you know, any of your listeners have ever seen that sort of famous image of waterfall methodology compared to agile methodology, that's where we're gonna anchor our thought process around today, and I'll elaborate a little bit on that, answering your question on that part, Max. So when you're thinking about waterfall versus agile, so thinking of the waterfall image, right? So, waterfall methodology has its anchor in manufacturing where you start at the beginning, there's a beginning, a middle, and an end to produce an end-result, right? And back in the day, when they're building software, you know, it would be 18 months projects.

     

    Well, with the onset of agile methodology, things sped up and projects got smaller and faster and innovative development happened. But, looking at those images, both waterfall and agile have a five-step process. Those five steps are: research, design, build, test, and deploy. And so, technologist on a software development team, regardless of their role, when they get a new rec for, let's say, a new feature, they are going to follow that process: research, design, build, test, and deploy. And as they're going through that process, they're doing and thinking things, like I said, to solve for each of those stages. So, what I would like to do today is kind of talk a little bit about what are each of those stages and then how do we go back through and ask questions against each of those stages to really get a full technical story from a candidate in a very confident, structured way. How does that sound?

     

    Max: Yeah, that's perfect. And then, to make the interview fit within a normal timeframe for a job interview, you wouldn't have time to cover every project. So, first before you start going into describing the work on a specific project, you gotta pick the right project, I suppose. So, how do you get there in the course of the interview? Because you know if they're working like 20 different projects in the course of a year. 

     

    Alison: We like to lean on within the alignment framework we use a tool called the contextual interview. So obviously behavioral interviews are the gold standard in recruiting. Past behaviors predict future behaviors and has a value to know but it doesn't help us dig deep on the technical skills. Contextual interviews are designed to get us into the context of the story that the candidate or end-user is sharing with us and that teaches us how to ask 360, who, what, where, why, when questions to get a good big picture view of what, how they moved through their process as they solve for the goals that they had. And so, when we train recruiters to do tech interviews, we train them to launch with the contextual interview, anchor question. So, our anchor question is, "Walk me through a project that you're most proud of or that was particularly challenging. What was the goal of the project and how did you go about solving it?" So, we're helping, we're asking them to just highlight something. Take one project, we're gonna go deep on one project. And so, that's how we start the conversation.

     

    Max: It's much better than a leading question like, "Tell me what you did on this or tell me what you did on that." Yeah, go. 

     

    Alison: Right. 

     

    Max: Pick something that you really really sunk your teeth in.

     

    Alison: Yeah, and then they'll light up, right? Because developers, they love what they do. And through all the research I've done, they genuinely wanna have really good relationships with recruiters. They wanna get connected to awesome jobs. But half the time they feel like they have to like throw out the baby with the bath water, right, because it's just they have such a bad experience. But what we're doing with the alignment framework is we're just putting the interview on its head, and so, you know understanding that there's a workflow, there's a research, design, build, test, deploy process for everybody, right? So, I ask that question, “Walk me through a project you're most proud. What was the goal and how did you go about solving it?" 9 times out of 10, our candidates, our technical candidates are gonna talk about that build stage right in the middle, right, they're developers, build build build. And if you don't know there's a discrete process, your wheels are already starting to spin off and you start fumbling for follow-up question and the next thing you know, you're asking how long have you Java’d, right? Java’s not a verb.

     

    So, what we do is we teach recruiters to say nothing. If you ask nothing else, after their first response and to say, “Interesting, walk me through your research process. How did you know React JS was the right framework to use?” You will feel the candidate shift in their chair because you’ve now established credibility as someone who understands their workflow. And so, what we do is we teach recruiters so that the model is, you know, and I can actually probably tell you what each of the stages are as I share follow-up questions through each of the stages we’ll kind of put it together. So, you know, you ask that question, they talk about build. You say, “Interesting, walk me through your research process.” Right? “What was the requirement that you had to design for?” Okay, so, if we’re gonna think about this, research as it sounds, we’re trying to figure out what is needed from this new feature, who’s gonna use it, what’s the code requirement, does it need to fit within the code that we already have? right? Start trying to figure out everything that they need to know before they can move on to that next stage which is design. And so, within the research phase, some of the questions we can also ask is “Who did you reach out to when you were researching? The requirements of the project. What research went into your design decisions? Where did you start and then what was the process of finding out what you needed to know?” Next question, all around designing, right?

     

    Max: I love those because I can imagine myself asking those questions and already being back in the driver’s seat. Like, okay, now he’s thinking and I’m sitting back and listening. 

     

    Alison: Right.

     

    Max: He or she. Yeah

     

    Alison: That’s right. It allows us, what I like to do is I say it gives us a roadmap to have these conversations and so we don’t need to feel like a deer in headlights like we’re trying to think of something on our feet because every step is laid out for us. We know there’s five steps to their process. We’re armed with questions to ask for each of those stages. And let’s say, you know, they start talking about a distributed build system, right, their dev ops candidate. I might not know what a distributed build system is and actually I would even argue, you know, we don’t need to know everything, but because I have roadmap to follow, I can ask these questions, get a full picture of it. I might only know about 70% of what that candidate ends up sharing with me, but because it’s in a story form, who they interacted with, how they problem-solved, the technology they used, when I go and position the candidate to my hiring team, we know that they’ll understand a hundred percent of what they said. And so, it really allows us to get, you know, a full picture from that candidate through the process. So, in this case, so the candidate talks about the research phase, who they interacted with, what was the use case that they were designing for, what are the requirements it had to meet? And then they move on to designing a solution so then these are some of the questions we’ll ask to get a feel for how they designed. It’s like, “What dependencies did you have to consider when designing for the solution? What was the primary use case? Right, is it a check-out flow? What was the secondary use case? Like, what were these users trying to use this feature for? And then also importantly, who did you collaborate with when you’re designing the solution?” ‘Cause the days of solo genius in the basement building everything are over.

     

    You have to collaborate, and a lot of collaboration happens at design. So, now we’re starting to get a good feel for who they’re interacting with, how they problem-solve, what they’re thinking about. And then linearly then we move on to the build process, right? So, you can even say, “Walk me through your coding process. Were you solo-coding? Were you pair-programming? Were you building from scratch or were you able to reuse existing code? And what was the time frame that you had to build this new feature?” Right? And you can hear how these questions are pretty agnostic, you can ask anyone these questions and they will have answers for you. 

     

    Max: Excellent, okay. So, we’re done with the build and then moving onto, if my memory serves me right, is the test to deploy.

     

    Alison: Yes. Yup, gold star, you’re listening Max. Thank you. So then during the testing phase, as it sounds, this is a period when they’re testing what they built to make sure there are no bugs, that it’s not gonna take the system down, that it actually solves the problem that were identified in the research, right? It solves for the requirements; it solves for the use cases. And this is a really good question because every dev team is a little bit different, right? So you can ask about, “What was your build and test cycle like for this project?” Because in agile which is the modern methodology for development, design, build, and test can kind of happen concurrently, so it speeds it up. So, asking, “What was the build and test cycle like for this project?” also establishes that you know that there are different methodologies. You can ask how “How involved were you at testing or was there a separate QA team?”

     

    And then there’s also a thing, there’s to, you know, to learn add in some acronyms, there’s also a thing call TDD which stands for test-driven development. TDD means that once you have established the requirements in the research and design stage, you actually build the test first and then you go and code it. So, it’s sort of like we already wanna sort of define what good looks like and then we’ll build against that, that’s called TDDs. You can say, “Were you using a TDD environment?” Or there’s a thing called continuous integration, continuous deployment. And that’s like dev ops, you know, 5000, right? CICD, which means like you’re, as you’re building code you don’t have some big deployment hoorah. It just it passes its test, it automatically gets deployed. So testing is often an overlooked part of the process, but it’s so critical. And so, during the testing you wanna understand how involved to testing they were, what kind of testing environment they were operating in. And then, once we understand those things, we move on to the deploy, the last stage before, you know, as the code goes live into the world. And again, some teams, depending on the teams, there’s a different team that does actually the deployment. So, you can ask, “What was your involvement in the deployment stage?” Right? These are all agnostic; it shows that you know what you’re talking about without speaking too much. ‘Cause I think sometimes we get nervous and we say some things and then we actually don’t make sense. So, just asking, “What was your involvement at the deployment process, or what sort of release cycle were you working within?” And then, last question we like to ask is, “Who was responsible for the code once it was live in production?” The end, yes. 

     

    Max: I imagine that especially when you get to the test and deploying phases, a lot of engineers will express frustration with an imperfect environment because it’s, as you said, there’s different levels of excellence for testing and deploying code, and I think it’s a shared responsibility for most engineering department, so they’ll be like, “Well, we don’t have this, we don’t have that. It’s not ideal.” And then this could be an opportunity for the recruiter to put on their sales hats and say, “Well those frustrations you have in your current environment, you know, we know them as well, but we’ve addressed them already and so you would join a more mature organization where you can spend more time building less time testing.”

     

    Alison: Right, and I will say on that note, this model that I’m sharing with you on the alignment framework for the technical interviews, we do the same model but then flipped side with the hiring manager and how to ask questions to get a real rich understanding of the open role that you’re being asked to fill. And what is the testing environment here, how is deployment facilitated, what is the build process here, are people pair-programming or is it solo-coding, how involved with research will they be, do they get to help design a solution? And so, you can see it just allows us to understand the components of the software development process and ask intelligent questions both of the hiring manager about the open role as well as of the candidate about their experience. And because it’s the same model, you can see how it really starts to blend and just gives us a floor to stand on, basically. And what are the roles I’m open at recruiting for, and then who are these candidates that I’m talking to. 

     

    Max: Okay, enough methodology talk. Let’s talk money. Let’s talk business.

     

    Alison: Get it.

     

    Max: I’m a 25-year-old. I wanna move out of my parents’ basement. I wanna make some money. Can you help me?

     

    Alison: Oh yeah, oh yeah. 

     

    Max: How fast can you turn me into a credible, technical recruiter?

     

    Alison: Well, it depends on how hungry you are, that’s for sure. But I would say, you know, if you’re asking me with my business hat on, the way we work at Recruiting Innovation is with the tech recruiter certification. It is an all-encompassing, one-stop shop for fundamentals of recruiting. We have a Recruiting 101 class, and we have our alignment framework course, which is this, you know the communication bridge I like to talk about, I call it. And then we partner with the technologists to then download their specialties. So, then we, and the UX class, you hear the UX designer say this is what I’m doing across research, design, build, test, deploy. So, we would say that if you have, you know, 5-10 hours of training, right now it’s $695USD for the tech recruiter certification and, you know, recruiting is such an approachable industry. I wish we have more of a PR globally. I mean, demand for recruitment right now is as high as it is for software engineers, it’s blowing my mind. But, as an industry, we’re not really equipped to the onboard of ton of new recruiters because everything is sort of like one-for-one, you know, take time off the senior to show you, you know, what a tech staff is, if they even know, kind of scenario. And so, what we do is we, Recruiting Innovation becomes that digital onboarding partner for scaling recruiting teams. And I will say, while we’re speaking of it, we are almost going to, we’re soon to launch the 2.0 of our tech recruiter certification program, it’s due in mid-November. Inshallah, that everything, you know, comes through correctly. I’m doing my own product [unintelligible] development, so I’m experiencing it myself. But, with that, we’re gonna have front-end back-end dev ops UX design and product management courses in addition to the alignment framework course. And then the prices go up, from then it becomes $849 USD per person. But anyone that wants to get on a 1.0 price, we’re doing a promo through November to lock in the $695 price to get the old 2.0.

     

    And actually, I also wanna share with your audience, you wanna get to see this in real life, I have some handouts for you. So, if you want to take down this URL, go to the URL, download the handouts, you’ll get not only the template for the technical interview, but then you’ll get the handout that has all the follow-up questions to help you get up to speed. So, if you’re interested in getting your alignment framework handout, it’s a bitly link. So it’s B I T dot L Y so bitly, forward slash talk technical. T A L K T E C H N I C A L. (bit.ly/talktechnical) And so it will take you to a landing page where you can download our handouts and you can learn more about our certification if that’s up your alley and then otherwise, you know, I would love to hear from folks how they’re getting on with trying out the handouts. You can always find me Alison Daley D A L E Y on LinkedIn.

     

    Max: Fantastic. bit.ly/talktechnical.

     

    Alison: That’s right, that’s right. That’s all we do is we help recruiters confidently talk tech. We like to say, “Stop the awkward, start the conversation.”

     

    Max: Perfect. And I do think that there’s a world of opportunity there and people who can have control over their schedule and build a very profitable careers, helping companies hire engineers. and you’re right, it’s very accessible once you shake off the awkwardness. So, wonderful work that you’re doing to help shake off the awkward. And one question I ask a lot of my guests is to take us back to a recruiting mistake that they’ve done in the past, where they hired the wrong person and try to visualize, you know, a specific person that you hired that wasn’t a good fit and share with the audience what you learned from that experience so that they can learn from that mistake. ‘Cause we’ve all made a ton of hiring mistakes in the past.

     

    Alison: Yes, yes.

     

    Max: Is there someone that comes to mind?

     

    Alison: Well, yeah. I mean if I, just thinking on my feet. It was actually for our own team, we were hiring an HR Generalist and we ended up hiring a former schoolteacher who was a really lovely person, super kind and friendly, gregarious. I expressed a little bit of concern, but I didn’t make it very big, but I thought that he was a little bit more creative and extroverted which would suit him more toward a recruiting role than an HR Generalist role, ‘cause they are very different positions and they tend to, you know, attract and require different personality types. Obviously, broad strokes, not true for everyone. I know some amazing introvert recruiters who just get the work done. But he didn’t do that well. He wanted more quickly from that position, and I had a feeling that he would. He really wanted to work at the company, which I couldn’t blame him. But you could just see overtime that he felt like he was bumping into walls and then it’s kind of like by-the-rules HR Manager didn’t really like his kind of creativity-slash-free spirit. So [unintelligible] there is a lot of dissatisfaction on both sides that, I mean, a lot of times it’s like it’s a really awesome person and you could see them in the company but then you kind of shoehorn them into the position that’s available and that’s just not a good fit for everybody in the long term.

     

    Max: Yeah. Don’t try to force a hyper-creative person into a very structured environment where they’re just gonna make enemies all day long. So, that’s a great anecdote. Thanks, Alison. And of course, we’re not saying it’s anyone’s fault there, of course.

     

    Alison: It happens. It really happens. 

     

    Max: Well, you’ve shared a lot of insights so thanks for coming on. And again, bit.ly/talktechnical for people to sign up and check out Recruiting Innovation and launch their, and get rid of the awkward when you’re interviewing engineers. Thanks, Alison, for coming on the show. 

     

    Alison: My pleasure. I hope you all found us useful, and I look forward to connecting in the future. Thank you so much for having me, Max.

     

    Max: Yes.

     

    This was Alison Daley from Recruiting Innovation, teaching us how to get rid of the awkward when interviewing an engineer and how a non-technical recruiter can get out of these interviews not sounding like an idiot. Hope you enjoyed it and if you want more tips on how to get better at recruitment from people like Alison and from technologists, please subscribe and share with friends. 

     

    Don't forget to subscribe on your favorite platform for new weekly episodes.

    👇

    SUBSCRIBE

    share with others

    Related Posts

    Assessment Strategies with Professional Snoop, Bas van de Haterd

    In this episode of the Recruitment Hackers Podcast, Bas van de Haterd, self-described professional snoop ...
    Continue Reading

    Field of Dreams: Closing the Tech Gap in HR with Tim Meehan from Pontoon

    In this episode of the Recruitment Hackers Podcast, VP And Global Head for Talent Acquisition Innovation ...
    Continue Reading

    Assessment Series 4 - Hiring based on merit with “on the job simulations” with Mel Macdonald from Vervoe

    Welcome to the fourth installment of the Recruitment Hackers Podcast Assessment Series. In this series, w...
    Continue Reading