Elias Cobb

The Perfect Candidate

by: Elias Cobb, National Recruiting Manager

So I’m in technical recruiting.  And we get positions from clients in a variety of technology areas.  As everyone in IT understands, one person’s experiences in a specific technology can be much different than another’s, even if their core skill is very similar.  I understand the need to make sure the candidate has the right background for the environment into which they are being hired.  This can be especially true if someone has quit, and left open a position that the company desperately needs to fill. 

But, and I emphasize this, it is a mistake to try and hire someone who has exactly the same technology background as whomever vacated the role!

First and foremost, (and this is the point I think many hiring managers miss), very often, the person vacating the role didn’t come into that role with those exact skills.   They grew into the position, bringing some skills with them, but learning new things as well, once in that position.  The simple fact that most IT environments are different means it will be very difficult to find someone who has the exact same experience as the person who left.  Yet that’s precisely what many hiring managers try to do!

A quick example: I was meeting with a hiring manager who was telling me about an integration developer role he wanted to fill.  There were a variety of skills he wanted in this next hire, primarily SharePoint development and HL7.  I pointed out that SharePoint developers don’t often know HL7, and integration developers working with HL7 don’t often know SharePoint, and that it would be very difficult to find someone who was good with both skills.  He said, “Well, I know SharePoint and HL7,” to which I replied, “Yes, but did you know them both before you started here at your current employer?”  He replied that he didn’t, and then I think my point sunk in.  I don’t think most hiring managers give it thought; they simply look at their environment and put together a skills list for someone coming in.  But they don’t think about the fact that candidates are coming from wildly different IT environments, and may not have the exact mix of skills that exist at the hiring company.

Second, do you, hiring managers, really want to hire someone with the exact same skillset and exact same personality profile as everyone else in your company?  Wouldn’t it make good sense to get someone in who has the core skills you need and the aptitude and attitude to grow, but who possess some other skills?  I think that might bring some fresh thinking, new ideas, and perhaps some new ways of doing things to your company.

Third, and finally, I have seen positions remain open for literally months while the hiring manager waits for the “perfect candidate.”  Months, really?  Imagine all that lost productivity!!  I think it would have made a lot more sense to hire that person early on in the process, the one who had 75% of the skills, and had the core skills down cold and possessed the aptitude to learn.  Don’t you think that person could have learned the other 25% of the job over the six months that the job remained unfilled, had they been there working the entire time?  And think of everything extra that could have gotten finished earlier with that extra person on staff.

Never Memorize What You Can Look Up

By: Elias Cobb, National Recruiting Manager

Never memorize what you can look up…one of my best consultants said that to me one day.  We were discussing interviews, and the questions that come up in many of them.  His basic point, as I took it, was that as a software developer, one cannot truly memorize everything one would ever utilize.  There are going to be things to look up, and the important part of development is in problem solving, and basically using one’s brain power on tackling difficult issues, not rote memorization of something that could be looked up in three seconds.  And that software development has as much artistry to it as it does rigid rules, which means there is often more than one right way to solve a coding problem.

It also took me back to my teaching days, when, on one of my first days, my chemistry students asked if I was going to make them memorize the periodic table, as teachers in the past had done.  I turned around and looked at the gigantic periodic table hanging behind me, then turned back around to the class.  “Why would you have to memorize it?  It’s right here!”  I then made the point – someone doing actual chemistry is not going to rely on their memory of the periodic table for the atomic weight of an element for a calculation; they’re going to look it up to make sure they have it correct.  They will, however, know why the periodic table is organized the way it is, and how to use it in doing chemistry.

So, to get the point…why would one ask “book” questions, things that can be easily looked up, in a job interview?    Is memorizing something like that truly indicative of one’s overall skill as a developer?  I would argue that it isn’t.  I suspect it has more to do with having an “objective” interview process, but I can tell you, you’re missing out on great candidates if you rely on these types of questions.

Here’s another quick, real-life example for you.  I had a consultant several years ago, a COBOL developer, about whom our client raved.  They said they would assign him tasks that took other developers two weeks, and he would finish them in three days.  He had a couple of other clients who loved him as well, and would basically go back and forth between these employers on contract because of the outstanding work he did.  Well, we submitted him to a different client as he had some downtime.  This client gave him a technical test, and let us know that he failed.  He got back to us and said “I could have aced that test right after I graduated, but it mostly covered things out of a book that I never use in actually coding.”  I’ve never forgotten that example, as that client likely missed out on a consultant who could have helped them greatly.

I want to be clear; I’m not advocating not asking technical questions in an interview.  I am, however, advocating making it more of a discussion than a “right or wrong” proposition.  And don’t base your entire decision about a candidate on a technical test.  Perhaps some of the factors mentioned above are in play, or maybe the person is a terrible test taker, but a crack developer.  That’s certainly something I’ve seen as well, and again, you don’t want to miss out on someone who could be a great asset to your team.

Hiring Managers: LinkedIn Profiles are Not Resumes!

By: Elias Cobb, National Recruiting Manager

I want to briefly address an issue I have seen from a variety of companies; this comes from direct observation and from feedback from candidates.

Here’s the issue: A candidate submits a resume to an employer.  Employer sees resumes, looks at the candidate’s LinkedIn profile, and for some reason decides the information on LinkedIn is more accurate or relevant than the information on the resume.  Employer rejects candidate based on assumptions gleaned from LinkedIn profile (not enough experience in X, etc), or because the LinkedIn profile doesn’t match the resume.

So, to any hiring manager who might do this, please keep in mind:  LinkedIn profiles are not resumes!!  People cannot put EVERYTHING they have ever done on their profile.  What people do is put out a general idea of what they have done, and the projects they have covered.  Many people do a terrible job of updating their profile when they switch jobs.  They might not have end dates.  They might not have their most recent title change.  But that doesn’t mean they’re being dishonest.  They put their most recent info in their resume, where it belongs.  They probably tailored the resume to fit the job for which they were applying, which might not be exactly the same as LinkedIn.  That doesn’t mean they’re lying; it actually shows more attention to detail and interest in your job and company!  They took the time to highlight specific skills and duties in the resume they sent to you!  Wouldn’t you think that’s a good thing, instead of something to punish?

In fact, even if there are employers missing on LinkedIn that are present on the resume, or the dates don’t match, I wouldn’t use that to reject the candidate.  Why not bring it up in the interview?  See what the candidate says, and then determine how you feel.  Again, a resume is designed to tell you about the candidate and their skills, and LinkedIn is for networking.