Today on the RecruitingDaily Podcast, we welcome special guest and friend Mark Knowlton to take a look at inside the game of technical screening. This is a notably informative episode, so please grab your earbuds and get ready for a show!
Mark is CEO and founder of TechScreen, the world’s only SaaS product that lets recruiters conduct, score and document detailed interviews of IT candidates without requiring underlying content. He recognized the business value of this capability in the 1990s and continued to learn. TechScreen was founded in 2016, allowing recruiters to customize interviews with topics the manager selects or adds, giving the manager insight into the candidate beyond a resume.
A few things we cover today: What is an ideal process after receiving a requisition? How do we break it to the hiring manager when we can’t find candidates with all skills required for a position? How should a sourcer utilize time with skills while still learning and challenging themselves?
There’s a ton more! Of course, you have to listen to learn. Make sure to leave your thoughts in the comments.
Listening Time: 29 minutes
Enjoy the podcast?
Thanks for tuning in to this episode of The RecruitingDaily Podcast with William Tincup. Of course, comments are always welcome. Be sure to subscribe through your favorite platform.
It is Mark's mission to create an entire generation of IT recruiters who can engage with hiring managers and developers on a peer level. TechScreen is pioneering a training program that will produce the recruiting industry's only technical certification for recruiters: TechScreen Certified.Follow Follow
This is RecruitingDaily’s recruiting live podcast, where we look at the strategies behind the world’s best talent acquisition teams. We talk recruiting, sourcing, and talent acquisition. Each week, we take one overcomplicated topic and break it down so that your three-year-old can understand it. Make sense? Are you ready to take your game to the next level? You’re at the right spot. You’re now entering the mind of a hustler. Here’s your host, William Tincup.
Ladies and gentlemen. this is William Tincup. You are listening to the RecruitingDaily podcast. Today, we have Mark on from TechScreen and we’re going to be talking about the inside the game of technical recruiting. As it is of 2021, Mark’s been doing some form of technical recruiting for, we’re just going to say, 20 plus years. So you get to a certain age, experience level where you just say “plus” and you just kind of leave it at that.
So Mark, do us a favor. Do the audience a favor, introduce both yourself and introduce Techscreen.
Okay. Well, thanks very much William. So, Techscreen is a SAS-software company. We’ve been around since 2016 and we introduce a technical interview platform that lets recruiters create and conduct detailed technical interviews without needing to be technical themselves. But what I want to talk about today is how people can get overwhelmed by technology and how, you know they’re buried in the blizzard of buzzwords. And I just want to talk about a couple of things that I’ve done over time that’s helped steer the conversation when you’re doing say, a job intake call, of how to not let the focus be placed on technical terms and the buzzwords, but understanding more about the work that needs to be done. And I think if recruiters put themselves in position to drive the conversation and not have it be based on the buzzwords, because anyone could do keyword matching between a job spec and a resume.
But by focusing on the work these people are being asked to do, I think it’d have much more effective conversations, both with the managers and the candidates. And they could also do a better job of actually encouraging a candidate to apply for the job because a bunch of buzzword isn’t a job description.
And so I remember a long time ago on Quora, the Q and A site, there was a general question, something like, and I’ll paraphrase, “why is it so hard for recruiters to connect with software engineers?”. And there were a lot of answers to the question, but among them there was a guy named Matt Yoel). He’s a software architect, but he frequently blogs on the whole subject. And his message was essentially, “look, buzzwords are not a job description. Take the time to learn what somebody’s actually done and have a conversation about the position. What am I going to be doing? What am I going to be building? You know, how is this going to improve my marketability as a technical professional?”
And I think that it’s very easy to let the manager just drive the conversation toward a bunch of buzzwords because they historically have thought, “well that’s the only and, or best way for a recruiter to understand what I’m looking for” by having a job description that has, like 15 different technical terms. And it’s just not practical that someone’s going to have all of these terms. But if you instead talk to the manager about, “Hey listen, let’s start out this way. Let’s talk about what objective are you trying to achieve? What business workflow process is being supported by the work this position’s going to do?”. And then, “what questions, what deliverables are you going to put in this candidate’s plate? And what’s the question I can ask that actually is going to tell me if the person can produce this work?”.
And so, then get them to describe what kind of objective are you hoping to achieve at the end of this project? Because a candidate wants to know more about what am I going to be building? How is it being used? What kind of problem is solved? Do I think that’s cool? Do I think that’s needed? You know, how is this going to make me better? And you’re going to be able to describe the actual substance of the work and not trip over all the buzzwords. Because the candidates want the substance of the work. They want it to be interesting. They want it to be challenging and they want it to be solving a problem they think is actually worth getting solved. And you are going to separate yourself from all the other recruiters who were just slinging buzzword out there, because they’re largely falling on deaf ears.
So I just talked to, I literally just had the phone call before this one. Well, we were talking about this very topic and how the phrase DevOps, or the phrase Full Stack, or the phrases that a front end essentially have developed over time to represent whatever they represent. So in DevOps, the things that they represent and then potentially some of the languages that you might use or skills that you might need.
So it’s a combination of, like DevOps is an umbrella term that then represents other things underneath it.
People talk about, “we’re just going to pick on DevOps”, but obviously [crosstalk 00:05:34] you pick on any of them, but people talk about DevOps and again, there’s not… You’re looking at LinkedIn and you put DevOps in there. There’s people that do list themselves as DevOps, but by and large there’re folks that don’t list themselves as DevOps, but have DevOps skills.
So I’m [crosstalk 00:05:55], go ahead.
No, no, please. You… [crosstalk 00:05:58] Finish your question.
How do you… What’s your advice for folks when they’re trying to figure out, “okay, I’ve got the req for a DevOps engineer. How do I now know what to think about in terms of skills and experiences?” And again, the things that are going to be important for the candidate, all the things that are going to be important to the candidate.
Yep. That’s a great question. And let me explain it this way. Now this is a great example of why I’ve always been a proponent of when you’re talking about “what kind of search strings do I write for this position?” is to try to avoid like the plague, the inclusion of titles in your string, because… And DevOps is such a good umbrella term, as you described it. But what I would tell recruiters is to first get an understanding of what DevOps accomplishes. So very succinctly think of DevOps as a way to put massive automation and scale through rapid deployments, new deployments of applications and to be able to automate how they attested in some cases or what the end goal is, is to have deployments happen automatically because there was tested automatically and they can rapidly push stuff out.
So what you should be looking for in somebody who’s going to be in a DevOps environment is somebody who’s been accustomed to massive scale production support. Now I’m going to date myself a little bit here, but you remember the old ASPs, the application service providers, the application hosting companies. And so they would employ people that had titles like system engineers, the kind of guys who know networking really well, but they actually had the hands-on ability to write scripts. And back in the day, it would be with Pearl or Shell Scripting like that, the Unix stuff, but they’d be able to write some custom utility that performed a very specific task, or they’d build the lightweight tool that’d helped them execute their job. So look for people who have already been in large scale production environments. You see things on resumes like five nines of reliability, which technically translates to only 15 minutes out of an entire year of being down. People who’ve hosted applications for corporate customers, because they know what downtime means and the business impact.
They understand how you have to set things up in a server farm. Understanding scaling out, versus scaling up. And, so look for the activities that are associated with people who had to support massive production environments, whether it was on-prem and a company did it entirely on their own, or if they were a provider who would host massive enterprise apps on behalf of customers. So make a list of like the old school ASPs, the application service providers, like Exodus, Ingenuity in companies like that, and to find lists of companies who, actually that was their business model. So every single engineer that those companies would hire were doing the same exact activities that you are finding in current quote, unquote “DevOps environments”. They’re completely transferable, but what you do is you’re avoiding the necessity of having a DevOps moniker inside somebody’s job title on a current, up to date version of a resume. They may have been doing DevOps activities for most of their career, they were just doing it under different titles.
Does that make sense?
Oh, it totally makes sense. How do… So the advice to technical sources when they first get the job req, which comes over from a recruiter or directly from a hiring manager in some cases. And again, “we’ll do DevOps [crosstalk 00:09:58] because we’ve been kind of focused on it, which was fine.” What is it… How do you… When you first get a job description or a job req, what’s your process?
So I actually follow sort of a lightweight methodology of the information it starts and I called it “WORK”. It’s a four word acronym. So the “W” actually has three legs to the stool. What are you building and what outcome you’re looking for? What deliverable is absolutely an essential part of what this person’s going to need to do to successfully execute their job. And what question can I ask that tells, me up or down, if this person actually has the competencies to execute this work. And then say, “what’s the business outcome at the end of this project? This system, or this application’s going to perform what function?” And then, after we’ve defined that, then you get into the technical requirements. What specific tools or skills or languages will this person need to bring to the dance?
And then the cave of work is, “what are the key attributes that would separate two equally qualified candidates?” Now, if you did a job intake call, and all you did was define those six questions, you would have every shred of information any recruiter would need to cover that requirement. Because you can define what the actual work is that needs to be built, the critical deliverable that this candidate will actually have to hit, a question that will validate whether the candidate has the knowledge.
You’re going to be able to say and at the end of all this work, this is the business result. The outcome that is going to result from this work. And then we have the technical requirements, the key requirements that the candidates going to need to work with, from a technical stack perspective and tools perspective. And then what would be two things, some key attributes that would separate someone who’s equally qualified on paper, but what would give one the nod over the other. And if I have the answers to those six questions, I could recruit for any position, it doesn’t matter what the skill sets are.
Real quick, before we move on to the next thing. It’s getting people to getting the hiring manager or the recruiter to prioritize.
Right? So they give you 12 things. You say, okay, out of the [inaudible 00:12:40] here’s four. What are the most… Stack, rank them, et cetera. How do you have those difficult conversations with somebody that wants to have all?
They feel like they’ve given you a short list and they want all of it on that list. How do you then, not convince them, but how do you kind of move them mentally to “Okay, for this to actually be done, here’s what actually needs to happen.”
Okay. So, real simple. I would say… So, if you had a manager who just was completely dogmatic about needing all of these different skills and if they’ve got any tenure as a hiring manager, just ask them quickly. Say, “Hey, have you ever landed in a job and you called somebody who you used to work with, because you know they’re a proven commodity?” And you say, “Hey, I want you to come interview for this MTC that I have, right?” And you knew full well that your former direct report, doesn’t have some of the technical tools or languages, et cetera, that’s part of this environment, but you invited them anyways. “Has that ever happened?” And they’ll say, “Of course”, they’re going to say “yes”. Okay, “did some of those people who didn’t have all of the right tools and languages and frameworks, et cetera, on their resume- did they get hired?”
And of course, for many cases, “yes, they did”. And “were they successful in their jobs”? And they’ll say in many cases “yeah”. I say, “Okay, so we’ve just validated the fact that given somebody with the right experience and aptitude and ability to adapt on the fly. Someone could come in here and execute their job, if their resume had less than 100% of all of the desired tools. Can we agree on that?” And because they’re going to talk about instances where they themselves were decision making authority, who purposely reached out for someone whose resume may not have lined up in a one-to-one relationship with the job description. Just get them to admit that you’re not going to have this perfectly aligned wishlist on a job spec with somebody’s resume. It’s just not how things work in the real world.
And you, yourself gave me an example of somebody who’s had a resume that didn’t line up with a specific job spec. But your confidence in their ability to get the job done was verified because you got them hired and then they actually did the job. So let’s focus on the most critical parts. Tell me if there’s a technical skill. Explain why not having this skill will make them fail in this position. I want to really understand for myself. And if they can sit there and explain why these 10 or 12 or “n” different technical terms whose absence on the candidate’s background would lead to an absolute, predictable failure. Then you can say, “Look, I’d love to find someone with all these skills, but you need to explain to me how the lack of Kubernetes or the lack of Kafka or the lack of Cassandra is going to cement their doom and they cannot execute this job. And so that way, we put less emphasis on key-specific buzzwords and more about capability and aptitude and transferability.
So okay, thank you for that. And that clears up the things I needed to clear up. Now…
You mentioned a couple things in… You want to make sure that the candidate is engaged by that.
Okay, so it’s been my experience with technical positions that folks are… There’s both- they want to be challenged.
And they also want to be kind of intrigued. And they want some form of training as well. They want to grow themselves, I guess, is a good way of thinking of it.
So, how do you convey time? How you’re going to utilize your time with your skills? But also how do you convey that excitement of what’s being built and how it’ll help them fulfill on some of the things that they want fulfill on.
Right. So one of the things you want to do from the manager is say, “Listen, imagine you’re applying for this job. What are the things that are going to move the needle for you? If you were calling the ex-colleague to tell them about the open position, what are the first three things you would tell them with the intention of getting them excited about working in your environment? Let’s walk through those. What is in it for them? Get to the what’s in it for them as quickly as possible.” So I want to be able to tell the story you would tell if you had the time to talk to all these candidates. Why should you consider this position over others that may seem similar on paper? How do I tell the story that’s going to excite the candidate to get them to put this one ahead of other opportunities they have? Because they clearly understand the what’s in it for them. And it’s going to be different for every person.
But if you ask the manager, say, “look, you’re calling someone who’s worked for you – two other shops over a period of eight and a half years. So, you know a little something about them. What do you going to tell them as the things that are going to interest and excite them the most about working in this environment?” Let them give you the ammunition on what is going to hit, trigger a candidate to be interested in this position over other positions that seem similar just because of the technical environment of it. Make them excited about what they get if they come work at this particular place.
So two questions, and it’s going to be two T’s. One’s going to be team. And the other’s going to be training. What’s your advice in terms of pitching the team, the project? Not the company per se, like “okay, work for Twitter, that’s cool”, but “you’re going to be doing this within Twitter with this team, et cetera.” So, team. And the other is training. How do you connect the dots for them and say, “Okay, listen. I know you want to grow this particular skill set- Pick, the development language.”
“And I know you want to… I know that right now, you’re probably intermediate, you’re at a certain level and you want to grow that. Here’s what they do to train you. Here’s what they actually will do to help you grow that skillset.” So what’s your advice for folks that want to convey those messages when they talk to candidates?
Ask that about their goals and objectives. “How important is it that your employer offers you formal, informal training? What kind of training have you seen to be effective?” Some people like to go to conferences. Some people like to actually go to How-To schools and learn a brand new language or something. But I would let the candidate tell their stories. Everyone looks at things like training and learning new stuff differently. Some, like to, maybe work at a place where they let you pick the language that you write in, or different tools. Or maybe some places have very strict environments where you can’t make decisions, but what types of ways to enhance your learning have you seen be effective? What kind of learning opportunities or training opportunities are you looking for? Does it have to be formal?
It could just be something where you go at your own pace or the company sends you to conferences so you can learn stuff formally. What have you liked in your past? And once you understand what they like or what they expect or what they demand, you’ll be able to make sure that you find out the answers to the questions from the hiring managers. I’ve got this guy who loves to constantly learn, but he left his position in the past because his buddies would get flown to conferences all the time and his employee never did it. And he finally decided to leave there because he liked to be at a place where they invest in their people and willing to spend a couple of dollars.
So, in the same way you ask the manager to define what would be the key selling points for someone to come and work at your shop or your team, ask the candidate what types of things in regard to learning on the job and, or formal training are you really looking for? What would help you make your decision, by me understanding how you would like to see your new employer? How do they feel about training, how do they handle it? Is it all formal, is it all self paced? Or is it… Do you get to go to conferences and get to do cool stuff like that? And I would like the candidate to define what they perceive as the optimum way of how the company handles learning new stuff and specifically about training.
Love that, okay. And I don’t want to be assumptive here because every source or recruiter, hiring manager goes about this differently.
But technical folks, at least today, because of scarcity, they’re not really super hip on applying for jobs.
Right. This has actually been kind of an issue for a while, but getting somebody to fill out a Google form or some type of application process for a DevOps person that’s in high demand. Not a super successful rate at doing that.
What’s your advice on when you’re talking to the candidate and convincing them either to go through the application process or just skip it? Or how do you get them over the hump of “are you interested?” And if you are interested, here’s the process [crosstalk 00:23:00] that we need to go through. And let them understand. There’s two parts of this question I’m interested in.
One is, how do you deal with their gutteral reaction to filling out forms when then they’re so in high demand. And two, how do you close them?
Right, fair question. So one thing that I always do, if there’s some step you can take as a recruiter or a sourcer, that’s going to push the ball forward and have the candidate be willing to remain engaged with you, is if you can not have them fill out a big web form. And sometimes companies have good intentions to put these things out, to help automate. So they can gather a bunch of information upfront, but you’re right though. Most candidates aren’t going to spend the time that some of these forms… Which can take quite a bit of time, they just don’t want to do. So, I would do whatever it took to get them uploaded into the system, so they actually… There were a record in the database so you can attach them to a job. Because a lot of times those forms are when a candidate is deliberately searching for opportunities.
But if you’re talking to them, engaged and trying to convince them to be interested, be the one to upload them into the system so you can attach them to whatever jobs you like to. And just avoid that step, that time consuming step of them having to fill in a bunch of forms. I mean, I’ve heard people say, “well, if they want a job here, they have to fill the form out.” From my perspective, some of the candidates aren’t going to be willing to do it.
So make it easier for them. Take away their excuse of not wanting to pursue a position because you insist that they fill out a form. Get them uploaded into the ATS, associate them with one or more jobs that you have that you’re trying to fill, and then get them in the process and not have to go and fill out a bunch of screens that might just turn them off and have them say, “I don’t need to do this, because my buddy called me and he wants me to meet his boss for lunch next week. I think I’ll just stick to that.” I mean, it’s a necessary evil when you are putting your jobs out and you hope people apply for themselves online, but if you’re talking to somebody, get them up in your ATS, if they’re not there already and let them sidestep the painful, tedious process of doing all that data entry.
Right. So last question, and it’s a rejection response, right? So, what is the most common just in your experience) kind of typical rejection from a technical person when you’re trying to kind of woo them into a new bit. What’s that common rejection and how do you overcome it?
So I want to make sure I understand the question correctly. So you’re asking me, with my recruiters hat on?
And working, internally focused to try to fill an FTE for X, Y, Z, Inc.? Right. And I’m talking to somebody who seems to have the right skills and how do I convince them to come?
And apply for this job?
Yeah. And you know how the rejection is? It’s like sales rejection management, right? There’s a universe of no’s.
And so that universe of nos, what’s the number one way that they try to say no? And how do you as a sourcer or recruiter or even a hiring manager, how do you flip that now?
Right. Well, you always want to try to understand their motivations, right? Sometimes it’s going to be money. Sometimes, and this is going to be less and less relevant – distance. How long is a commute? And now we’re in a different world where that’s not going to be as big a play. But try to get them to define their motivations. What’s going to make them decide on a position and just reinforce what this position represents, how it actually lines up with the things that they’re trying to accomplish in finding a new gig.
And by understanding their objectives and understanding the “what’s in it for them”… So have the question, that conversation with the manager. So we define the “what’s in it for them” stuff for the candidate, find out as much from the candidate about what’s going to make them move to another position and try to connect as many of those points as possible. So they’re making their analysis and their evaluation on real, empirical, measurable, and tangible things about why someone would want to go take another job. And have it less be on things they assume about the company or the position, because…
I love that. [crosstalk 00:27:41] Yeah, because what you’ve done is you’ve made it “them”, the candidate centric.
It’s not so much you’re selling culture, values, all this other stuff, which of course you’re going to get to. You’re going to get to all that stuff because it’s important, but you’re not selling that. You’re finding out what’s important to them. And then you’re centering the discussion around them and their needs.
Yep, exactly. And everyone has their own likes and dislikes, but find out what drives this person, this candidate.
And then you have that Jerry McGuire conversation with the manager, “help me help you”. [crosstalk 00:28:18] Give me the [crosstalk 00:28:19] bullet points that you would call your former guy, who’s your indispensable bug finding, troubleshooter guy who could solve any technical problem, doesn’t matter what language it’s in. How are you going to excite them to come work for you in your team?
That’s it. Drops mic, walks off stage, Mark.
Thank you so much. Thanks for coming on the show. Thanks for also breaking this down. It’s been very important and I look forward to having our next succession and thanks for everyone that listens to RecruitingDaily’s podcast. Until next time.
You’ve been listening to the recruiting live podcast by RecruitingDaily. Check out the latest industry podcast, webinars, articles, and news at RecruitingDaily.com.
William is the President & Editor-at-Large of RecruitingDaily. At the intersection of HR and technology, he’s a writer, speaker, advisor, consultant, investor, storyteller & teacher. He's been writing about HR and Recruiting related issues for longer than he cares to disclose. William serves on the Board of Advisors / Board of Directors for 20+ HR technology startups. William is a graduate of the University of Alabama at Birmingham with a BA in Art History. He also earned an MA in American Indian Studies from the University of Arizona and an MBA from Case Western Reserve University.