My name is Brian Kelly, and I’m a software professional living near Boston. Most of my career has been spent creating distributed systems. I worked for a number of years building CORBA and Web Services middleware products for IONA Technologies (later acquired by Progress Software) such as Orbix and Artix. Currently I’m the VP of Engineering at TimeTrade Systems in Tewksbury, MA. Brian has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

5 Signs You Should Hire a Programmer on the Spot

05.03.2012
| 27702 views |
  • submit to reddit

Bringing a programmer in for an interview and a coding test can lead to some interesting experiences, both for the interviewer and the interviewee. Most end up with the hiring manager telling them that they’ll “be in touch,” but sometimes a candidate just nails it. That’s when you consider extending a job offer before they get a chance to leave the building.

At TimeTrade we run a coding test during interviews that, for the majority of programmers, should take about 2 hours in total to complete. The whole test is comprised of a number of small problems to solve, each harder than the one before. That gives us a good initial gauge of performance based purely on completion time: if everything has been solved in under an hour, we’ll be smiling. But if two hours pass and even the first problem still hasn’t been solved, the candidate will most likely just be shown the door.

Above and beyond just solving test problems quickly, here are some signs that a programmer is truly awesome and should be handed a job offer before they leave your building:

1. They present multiple solutions

I recently interviewed a programmer who solved an entire set of tests twice: once with iterative solutions, and again recursively. I quickly made him an offer. Finding multiple solutions to a problem is a skill that engineers will need to use every day.

2. They write full documentation

Last year I interviewed someone who was so diligent, so detailed and so professional about his work that he created full Javadoc and comments for his code before he considered the solution complete. He even wrote fully automated unit tests and checked their coverage percentage. When I came back into the room at the 2-hour mark and found him typing furiously I initially thought he was having trouble with the test, but he was actually in the process of adding HTML formatting to his Javadoc. Engineers who do this intuitively are the kind you’ll want on your team.

3. They improve the test

We deliberately create tests that have some minor issues lurking within them, purely to see if the candidate (a) spots them and (b) is willing to fix them. It might be an inconsistent usage of quotation marks for strings, misleading variable names or anything along those lines. Candidates that look at all of the provided code as the test — not just the pieces we’ve asked them to write — are the ones who will do the same in our real product once they join our team.

An engineer who is willing to tell a potential employer that the supplied test contains problems shows that they consider the quality of their work to be more important than just agreeing to do what they’re told. Hire them and they’ll likely work wonders for your product, going above and beyond their assigned areas to make improvements where they are needed.

4. They refactor smartly

Most candidates like to get a solution working, then sit back and breathe a sigh of relief that they finished it successfully. That’s good, but rarely good enough to justify an on-the-spot job offer. The candidates that solve the problem but then jump right back in to refactor it are in a different category entirely. Their choice of algorithm doesn’t feel right, and they can’t ignore the feeling that it could be more efficient. Their code has some duplication in it, and that burns them up inside. These are the candidates who refactor, rewrite and improve their solution until it’s been crafted.

This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship). However if they watch the clock carefully and are able to both solve the problem and refactor their solution before their time runs out, that’s a really good sign that you should consider an offer.

5. All other signs point to “hire”

Sometimes there are plenty of non-technical signs that you’ve found the right candidate. Your other team members take you aside and tell you, “We have to hire this lady.” Their personality feels like a great fit for the team. They have relevant and recent experience in what they’ll need to do. You know some people who have worked with them before and they tell you they are wonderful to have on a team (and that they’d hire them again in a second). The candidate is excited about the company and the opportunity and is hungry to start contributing.

If the candidate passes technical muster and all other signs point to “hire,” why wait? If you do, you may lose the candidate to another employer who knows how to read the same signs faster than you can. Instead, be decisive and make the offer fast, thereby telling the candidate how much the company wants them on board. It will help start the whole relationship off on the right foot, for both parties.

So the next time you’ve got a wonderful candidate in your building, don’t assume someone even better will arrive the next day. Make them an offer and get yourself – and the candidate – back to work.

Published at DZone with permission of its author, Brian Kelly. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jammer Man replied on Thu, 2012/05/03 - 11:44am

My personal opinion: a 2-hour test is too long, and reveals a certain level of arrogance on the part of the technology leadership and staff. 

 

 

 

Tim Garrett replied on Thu, 2012/05/03 - 1:33pm

@Jammer Man +1

Mark Unknown replied on Thu, 2012/05/03 - 2:58pm

I guess is you are looking for JUST a coder some this makes sense. But as posted directly to the blog, I am not sure this makes sense in the bigger picture. 

 

 Also, Code Comments and Unit Tests are things that must be maintained.  Does everything need to be commented and unit tested? I will say generally - no.  The code should speak for itself. Adding JavaDocs to EVERY method, begins to obfuscate the code.  Explain what needs to be explained. If you are writing and "API", then JavaDocs will probably override obfuscation.  As for Unit Tests, not every line of code needs Unit Tests. I have seen code that only exists so it can be Unit Tested.  Do you need to verify a method will throw an exception?

 I do think that if you "know" then you should not play around. The good ones are few and far between.

Chuck Dillon replied on Thu, 2012/05/03 - 3:18pm

#1 - But aren't iterative and recursive two pretty obvious approaches to common problem spaces?  I don't see the example as particularly indicative of advanced skills - but I don't argue with the core point.

#2 - I wouldn't assume this is an indication of an "intuitive" approach.  I'd assume the candidate is going to give you what s/he thinks you are looking for, even if s/he has an aversion to documentation and/or junit style testing.

#3 - Simiarly, a candidate is going to try to give you what s/he thinks you are looking for and so is likely to look for hidden tests, like your purposeful flaws, and assume you give points for pointing them out.  I agree that a candidate that doesn't mention them is likely less experienced/intuitive but that doesn't tell you much about the candidate that points them out, IMHO.

 #4 - "burns them up inside", "crafted", I think you are stretching it just a bit here.  If you have them locked away for 2 hours and they "solve" your problems well before that - they are likely to refine the work to kill time.  What this shows is that they guessed you would value some optimization over pure TAT.

 #5 - IMHO, this should be #1 and the primary means of evaluating the candidates.  Testing, if you must, should be no more than a simple verification of what they claim to be and you can't verify by other means (e.g. references).

Srikanth Nair replied on Mon, 2012/05/07 - 4:21am

You are completly mistaken sir, you can get candidates writes junits/javadocs etc. At this era you should look for people who make use of best technology, logic and good analytic skill (all this points to his interest on programming). If one who have interest in programming can only make a impact. So it must be.

1) Check his interest (will revealed by what technologic he uses, how he is making use of existing framework or APi's etc and his code obviously points too) 

2) Make sure he is a pragmatic programmer over a theoretical one.

3) Think twice before taking a female candidate. 

Last but not least,

Programming is not a Rocket sicence, anybody can program in any language they want all they need to have is PASSION.... 

So check your candidate is PASSIONATE sure he will make the difference.... Or else fire him ASAP. 

 

Jammer Man replied on Wed, 2012/05/09 - 11:52am in response to: Srikanth Nair

"Think twice before taking a female candidate?"  You're an idiot.

Greg Bulmash replied on Thu, 2012/05/10 - 3:32pm in response to: Jammer Man

A two hour test is not unreasonable, but it depends on where it comes in the hiring process.

 

Remember that the candidate's time has a commercial value. They could be earning with that two hours (and the 30-60 minutes of travel time). Quite often, they're taking time off from work to come in. So when you ask them to do that 2-hour test, you're asking them to gamble a hundred dollars, maybe two hundred, of their time. And they're gambling not just on whether you'll make an offer, but whether they'll want to accept. If you haven't already laid the groundwork that makes both sides think those are both good bets, the test is a waste of your time and theirs.

 

When the test is basically a part of the hiring interview, and requires investing time on both sides, I'm okay with it. When it's a hoop I have to jump through to get my foot in the door, I better be damn interested in you already (or damn desperate) or I'll just pass.

Jerry Lumpkins replied on Fri, 2012/06/08 - 11:32pm

Think twice before hiring a femail candidate?

Please let me know that you feel that way in the phone screen.

You will then be free to look elsewhere.

Sadia Sulaman replied on Wed, 2013/05/29 - 2:01pm

 This is my first time visit here.i found so mmany interesting stuff in your blog especially its discussion..thanks for the post!

lavage-de-vitres-montreal.ca

Sadia Sulaman replied on Wed, 2013/07/03 - 1:50am

 Wonderful! Actually wealthy content and extremely helpful in sequence. I got it my answer from over here. I extremely advocate his/her mechanism with the helpful educational information.

bucks party ideas

Sadia Sulaman replied on Mon, 2013/09/02 - 3:07pm

 Great Article. Its really very informatics blog, I just wanted to say that I found this precious blog with the help of Google.

waxing aylesbury

Sadia Sulaman replied on Tue, 2013/10/08 - 3:08am

 A very awesome blog post. We are really grateful for your blog post. You will find a lot of approaches after visiting your post. I was exactly searching for. Thanks for such post and please keep it up.

docteur elise bernier

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.