Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Recent Posts

Syndication

Tags

View more

Archives

Advertisement

Jeffrey Palermo (.com) » Hiring technical people, take 1 - level 100
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Hiring technical people, take 1 - level 100
With unemployment at essentially ZERO these days, it's hard finding the best people, especially skilled knowledge workers like programmers.  Every company needs programmers, so the good ones who happen to be looking are few and far between.  By contrast, the mediocre to poor programmers are abundant and available.  Wading through the duds to find the right guy can be a daunting task. 

In-person interviewing is the most expensive part of searching for new employees.  It requires real time from the people in the department.  Each time a candidate is turned away because of an interview, the company has lost time and money.  The trick is to keep the bad candidate from making it to the in-person interview.  I've recently employed a few techniques to minimize time spent by my team on interviews.  My goal was to bring a candidate to interview only if I felt we would be making an offer.  Here are the things to do to weed out the folks who are unlikely to make it to the offer stage:
  • Do a technical phone screen on every candidate.  Ask basic questions about levels of experience on required technologies and 3rd party libraries.  For instance, if your team uses 3rd party tools like CruiseControl.Net, Resharper, NAnt, NUnit, SVN, NHibernate, Rhino Mocks, etc, then it's a plus if a candidate has used some of them.  This phone call should also ensure that you aren't wasting each others' time.  Make sure the candidate is interested in the kind of team you are running.
  • Given them a "take home test".  Make the questions appropriate for the technology (no insulting trivia).  Good questions are ones that a good programmer could answer easily.  The duds will fail the test, and you will have saved some time.
  • Ask for a sample of code including code and SQL.  What they give you is a good indication of the types of things they have worked on and are confident in. 
  • Give a coding assignment.  Call it an audition if you wish.  This can be any small coding task, but make it a prerequisite to the interview.  The interview is the most expensive part of the recruiting process.  I like to find a technology the candidate is not familiar with and ask them to produce something with it.  This ensures that the candidate can pick up new things and produce quickly.
I fully recognize that recruiting is not a science.  The worse thing to do, however, is to just talk in the recruiting process.  I'm going to ask my programmer to write complex software, and talking about it is little indication of that aptitude.  I prefer to see some example of the professed ability.  When a candidate easily progresses through all the above steps, it's pretty certain that the in-person interview will be a "getting to know you" gate that opens easily to an employment offer right away.

Technorati Tags: , , , , , , ,
Posted 07-29-2006 9:59 PM by Jeffrey Palermo
Filed under: ,

[Advertisement]

Comments

Eric Wise wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 9:43 AM
Interesting about the take home assignment.  For myself, I find it to be not so helpful because you are so limited in what you can ask people to do with their spare time.

This draws from my own experience... if a hiring manager asks me to do a take home assignment that is going to take more than 90 minutes of my time, they can pretty much forget it.  In addition, when you interview candidates, make sure to no have them come in more than 2 times.  If you make candidates dance around, getting off their real job to come in and interview multiple times as well as doing takehome assignments, it says to me that you don't respect my personal time or my dedication to my current employer.

For a stringent interview process I find it better to do a short phone interview, then block off an entire morning, 3-4 hours.  Give them a personality check with your HR person first, and ask any followup tech questions you have.  Then put them in a conference room or something with a short test/coding assignment.  Explain that code is pseudocode and that they should try to get the syntax right but without a compiler it's not a requirement.  If they don't know at all, have them write what they would do to find the answer (imho being able to find answers is more valuable than being a walking dictionary). This also ensures they aren't using the internet or friends to get answers.

If they're working on a close knit team, you should also have them meet team members during a light tech talk.  The more people come in contact with a candidate the better feel you can get for personality match.
Sahil Malik wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 11:17 AM
I like to do the audition if I can help it.

But I usually ask them about something they think they are james bond in. The spectrum of technology is so vast, that it is unfair to expect everyone to know everything.

So I turn them tables on them, and ask them, what they feel they are good in. And then cook up a real problem on the spot for them concerning what they said they were good in, and ask them to solve it in the real conditions they will be working on - A computer, an internet connection, coffee and peace.

10 minutes later, I check up on the progress, and question them on their approach.

Usually that works out pretty well for me.

Wait, that's a lie!! It is difficult finding qualified people anymore, so it still takes a lot of time to interview candidates - frankly I don't like doing that, because the dudes that you turn down run into you somewhere else and then it is really uncomfortable. :-/

So the best way to interview is to delegate it to your team member. Frankly they are the ones who will be working with them anyway.
Jason Haley wrote Interesting Finds: July 30, 2006
on 07-30-2006 11:39 AM
Jeffrey Palermo wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 12:53 PM
Eric,
". . . if a hiring manager asks me to do a take home assignment that is going to take more than 90 minutes of my time, they can pretty much forget it.. . ."

I agree with it not being a huge assignment, but if there was a position that you were really motivated about, you would probably do anything asked of you.  If you respected the company and the person doing the hiring, why would you snub your nose at a 2-hour assignment?  

My goal is to make the interview a final step before an offer.  I don't want the interview to be a large part of the evaluation process.  If I don't know before the interview, then I haven't learned enough about the candidate first.
Jeffrey Palermo wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 12:56 PM
Eric,
". . .they should try to get the syntax right but without a compiler it's not a requirement."

This is completely subjective, but I like to put them in similar conditions as the real work environment.  They will be given good tools on the job, so I think giving them the same tools in the audition is appropriate.  If a programmer knows how to find everything out with Google, more power to them.  After all, isn't that what we ALL do?

I don't like asking someone to write code without the proper tools.  I don't think it tells me anything concrete about them.
Jeffrey Palermo wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 1:01 PM
Sahil,
". . .10 minutes later, I check up on the progress. . ."

Wow, your candidates must be fast!  It would take me about 30 minutes to an hour to produce anything worth showing.  The design process in my head takes a while.  Sure I could Wizard my way through to some crap code, but I wouldn't want to do that.

Having them do it in-house is a toss-up when I could have them do it before the interview.  That way, they can spend the appropriate amount of time on it.

-------------------------------
"So the best way to interview is to delegate it to your team member. Frankly they are the ones who will be working with them anyway."

I'm sure my situation is different being a manager for an ISV product team, but I would never hire someone "who is good enough only to work with someone ELSE."  I evaluate from the perspective that I will be working with them. . . because I will.  We're all going to be in the same bull-pen.  If I didn't have a stake in it, then I shouldn't be evaluating.
Eric Wise wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 6:07 PM
Yeah, I would give them a computer loaded with VS etc if it was an option, it just isn't at my current job.  I really think that you have it backwards on the time response though.  

"If you respected the company and the person doing the hiring, why would you snub your nose at a 2-hour assignment?"

You said yourself in the posting the truth of the matter is that good candidates are hard to find.  They certainly are!  This is why the company should be respecting the person's time, being sensitive to needs by providing VPN, laptop, and work from home abilities as needed, and also be sure to provide the tools and environment for success.  Highly qualified people can and will pick and choose their positions, so attraction and more importantly, retension are a key.  If a company is going to ask me to take 3 days off work, spend several hours programming at home during my personal family time, that always comes off to me as a company that doesn't respect the work/life balance and drives me away.

Some people don't mind running the gauntlet, I know that many experienced, family men like me take exception to it.  *shrug*
Jeffrey Palermo wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 8:24 PM
FYI: I'm coming from the perspective of the hiring manager, and I have to balance screening a candidate with attracting the very best.  I completely agree with respecting the candidates time, and I would never ask anyone to take 3 days off of work (or even 1).  I think we are talking past each other a bit.  What I've described isn't a gauntlet, it's merely a low-impact screening process that's saved me a lot of time.  
Vikas Kerni wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 10:45 PM
Fact: Good programmers are staying in job market for only one or at most two weeks.

A good  hiring process has to take notice of that also.

Non-technical recruiter asking technical questions may be a big turn off for some canidates.
Eric Wise wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 10:56 PM
Yeah, the three days off comment was for those companies that like to have you come in multiple times.  I prefer once, twice at most, and no more than that unless I'm really really into the company.

It also depends on the level of the candidate, there's a big difference in process for someone you plan on grooming versus someone you plan on hitting the ground running or taking a leadership role.  =)
Jeffrey Palermo wrote re: Hiring technical people, take 1 - level 100
on 07-30-2006 11:33 PM
Vikas,
"Good programmers are staying in job market for only one or at most two weeks"

I think that's true.  If the first phone screen uncovers a strong candidate, the process must move along quickly to avoid losing to another company.

Sahil Malik wrote re: Hiring technical people, take 1 - level 100
on 07-31-2006 2:28 AM
Jason Follas wrote re: Hiring technical people, take 1 - level 100
on 07-31-2006 7:00 AM
I also give a small take-home programming assignment to my candidates that pushes their comfort level a little bit.  I've got to know that my guys can use Google to find answers on their own, so that while on the job, they don't sit there shellshocked waiting for me to check up on them before they ask how to do something.

I try to come up with assignments on-the-spot, but for the most part, they've come from little programming challenges that I had to solve within the past year or so.  If the candidate Googles hard enough, they might even find the answer in my blog.  ;-)  (But, to date, nobody has blindly plagerized me)

For instance, I've asked people to write a word-wrap function: I'll provide a long string of text and a column width, and they must return that string with inserted /r/n at appropriate places.

And, if they've never listened to a Mondays or DNR, then I also give an assignment to write a program to pull down one of the RSS feeds, discover the enclosure URL, and then download the binary file.  (This is actually a fun little assignment to see what they know about System.Xml and System.Net)
Gary wrote re: Hiring technical people, take 1 - level 100
on 07-31-2006 12:49 PM
"With unemployment at essentially ZERO these days,"
Not to nitpick but the unemployment stat is not the only indicator of the state of the labor market. For example, the employment doesn’t take into count the millions (http://www.nytimes.com/2006/07/31/business/31men.html) of discourage workers that fled the market after the downturn in 2001. The true unemployment rate, as calculated by Federal Reserve of Boston (http://www.bos.frb.org/economic/ppb/2005/ppb052.htm) , is actually about 1-3% (or 1.6 million to 5.1 millions unemployed workers) higher.
Community Blogs wrote Interviewing
on 08-02-2006 4:44 PM
.. the most awful thankless part of any job. Jeffrey Palermo has shared his opinions on Interviewing.
Noah Coad's Code wrote Articles + Posts to Check Out
on 08-16-2006 2:59 PM
When I see a blog post or article that I want to read, investigate, follow up on, etc, I jot it down...