You HAVE to hire technical talents! But how?

The lack of technical interview

For the last six months, I have made interviews to hire new persons (trainees or programmers) for short-term assignments. What I realize is that it is hard to say: “Ok, now, you have to pass a technical test”. The candidate may think that I don’t trust him. I know that it is in the process of prestigious American companies as Microsoft or Google, but in France, it is not common. The typical way is a human resource interview and some others with team managers. You may pass logic tests but technical tests are not in the process. When I finished my studies, I applied to 3 opened jobs of well-known companies and one in a rising startup: only the startup asks me to respond to technical tests. (I’m proud to say that I get all the offers :-) ).

The problem with hiring someone without any technical test is that resumes are similar and contain the right keywords: Java, J2EE, .net, MySQL, XML, etc. How to estimate the capabilities of a developer? The one who really knows what is behind these keywords. If we ask only superficial questions (Do you know Java? Which framework do you use?), they will answer with sentences which contain other technical keywords. Google Set can do the same thing with eclipse and java. And a lot of interviewers are “satisfied” by this kind of solution: “OKAY, he knows what he’s talking about, we hire it”. If you have the right keywords, you’ve got a job. I draw here a stereotype, companies ask more, but what we want is getting technical talents: people who solve a simple problem without “googling” for the solution all the time.

Yes, you’re not alone. Get the methodologies of other companies.

So, I’ve decided to prepare some technical questions for the next interviewee and then, I ask myself: Which ones? How to know whether the person in front of me codes well or not? What are the questions which reveal the capacity to solve technical and scientific problems?

As many other developers, I like reading. There’s more to learn in a book or in a article/post than in a long discussion with someone else: I always prefer someone who gives me good pointers on articles or books than someone who talks too much (and at the end, I don’t remember anything of what he says).

So, I “google” for similar requests. I have found Google stories from a canditate and from an interviewer (a great blogger) Steve Yegge. It seems logic questions are the same as in France but algorithmic ones are important too. Steve Yegge has listed technical questions when he was at Amazon and Michael H. Pryor has dedicated his blog to it. I appreciate the Stevey’s list of Checkpoints:

Without further ado, here they are: The Five Essential Questions for the first phone-screen with an SDE candidate:

1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

Read… Always read…

So, after this overview, I had a first idea and I continued: I wanted to get a book on the subject.

I’ve heard about “How Would You Move Mount Fuji?: Microsoft’s Cult of the Puzzle — How the World’s Smartest Companies Select the Most Creative Thinkers”, but the readers comments are mixed (is it up to date?). Then, the amazon’s engine recommends the following book:

Smart&Gets things done

Smart&Gets things done, Joel Spolsky

Joel Spolsky is the author of Joel On Software. He is the founder of Fog Creek Software and he previously worked at Microsoft. His book has been published in 2007 and it is not expensive: that’s it, I bought it :-) . It is easy to read and it will take you only 4 hours to complete it. Joel describes here the process that he has established to find technical talents for his company. Where are they? How to find them? What are they looking for?

It is divided in 7 chapters:

  1. Hitting the High Notes
  2. Finding Great Developers
  3. A Field Guide to Developers
  4. Sorting Resumes
  5. The Phone Screen
  6. The Guerilla Guide to Interviewing
  7. Fixing Suboptimal Teams

I don’t summarize each one here. We receive great resumes in my company and I always prefer meet the persons. So I focus the chapter 5 and 6.

First, if you’re not absolutely sure that the person is the right one then, don’t hire. A distinction between “Smart” and “Gets things done” is given:

People who are smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. [...]

People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. [...]

The title of the book is explicit: he doesn’t want to hire people who are either “Smart” or “Gets things done” but some who have both capabilities. For the interview, he gives a typical plan for interviewing:

  1. Introduction
  2. Question about recent project candidate worked on
  3. Easy programming question
  4. Pointer/recursion question
  5. Are you satisfied?
  6. Do you have any question?

So, it’s a classic interview but the questions 3 and 4 are technical and it’s what is interesting us in this post. The sample are not so different with the ones proposed by Steve Yegge: general questions on technical basics and puzzles. Then, some bad questions are listed:

Avoid illegal questions [...]

Avoid any questions that might make it seem like you care about, or are discriminating based on, things you don’t actually care about [...]

Avoid the questions where you either know the answer or you don’t (anything involving pirates, marbles and secret codes) [...]

I recommend you to read his book if you want to go deeper in this domain.

Conclusion

Before hiring someone, it’s your job to test him/her. Yes, you have to evaluate his team spirit but it’s not enough: general technical tests are mandatories! So, you must prepare some questions which test the 5 points given by Steve Yegge (his post has many samples). It’s just the basic knowledge of a programmer and it is what the interviewee is applying for. If the candidate doesn’t have passion, it won’t change with time: it’s just a job for him/her.

And you, what kind of questions would you ask?

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • Yahoo! Buzz

Comments 3

  1. macmariman wrote:

    “technical talents: people who solve a problem without “googling” for the solution all the time.”

    I think that technical talents have nothing to do with google, someone who uses google knows that the problem was solved before and can save a lot of time with a simple search. Being smart could be just to choose the right solution. Being stupid could be reinventing the wheel.

    Posted 16 Apr 2009 at 5:06 am
  2. coder-friendly wrote:

    Hello Macmariman and thank you for your comment,
    Maybe, the sentence is not well formulated. “people who solve a problem without “googling” for the solution all the time.” What I mean is “googling” and copy/paste the solution they find without understanding it. If we look on the technical forums, we see a lot of “bad-practice” (newbies) which are given as solution. I want to hire technical guys who can choose between solutions, and who know whether it is reliable or not. Personally, I hate the copy/paste practice. I agree that reinventing the wheel is a bad practice too ;-) .

    Posted 16 Apr 2009 at 1:32 pm
  3. coder-friendly wrote:

    Hello,
    Since I’ve found this link on StackOverflow, I just add a comment about it:
    What is the worst interview question?
    Coder-friendly

    Posted 18 Apr 2009 at 1:58 pm

Post a Comment

Your email is never published nor shared. Required fields are marked *

Additional comments powered by BackType