Tuesday, August 12, 2008

Hire the Right People

I believe my team of engineers has been very successful. This is no accident. I look for, and like to, surround myself with smart people. I'm not being egotistical. I don't consider myself the sharpest tool in the shed, but I do know a sharp tool (smart engineer) when I talk to one.

Hiring the right person is harder than it sounds. The top two impediments, in my experience, to hiring the right person have been "Hiring People that are Non-Threatening" and "knowing nothing about the job you are hiring for."

Non-threatening can mean a lot of things. A non-threatening person can be a yes-man. Yes-men will agree with you on everything and never make you uncomfortable by pointing out flaws in your plan. Yes-men are often hired on the basis of philosophy rather than actual skill. Non-threatening people can also be that dull-tool that won't outshine the person who hired them. In both cases the company is stuck paying wages to an under performer.

More often, though, I have seen poor hiring decisions made by managers that have no idea how to judge candidates for a job. These managers tend to rely heavily on applicants' resumes and sets of nebulous questions about work ethic or previous projects. Lacking a basic understanding of engineering practices and what makes a good engineer, these managers usually hire based on a feeling.

So, how do I hire....smart people? First, I give a basic skills test. I actually test each applicant on basic problem solving skills using pseudo code. If they do well on the test, then I send them a practical exercise. I look for three things in the practical exercise: how well they followed the directions, coding style, and does it work.

The test and exercise help me weed out those applicants whose time would be wasted on an interview. If I am happy with the test and the practical exercise, I schedule an interview. I'm also a true believer in team buy-in on all new hires so I get as many engineers involved in the interview as we can afford.

The interview includes some basic questions about relocating and what technologies the applicant is interested in, but the real meat of the interview is a set of problems the applicant must solve, interactively, on a white board. The problem solving progresses, "lecture style," with the applicant lecturing us on how the problems could best be solved.

Engineers are free to ask questions and the applicant is encouraged to show all his work. After the interview, I discuss the applicant with the other engineers and prepare for the next interview.

Once we have an adequate pool, we all sit down together to review, compare and contrast all the applicants.


Darius Damalakas said...

You know, actually most of the things you write a very very correct.

i know when i talk to smart people, and as soons as i recognize, i actualy give up pretening that i know something about programming. Yes, i know a little bit, i've programmed all of the core features in my company, but sadly, i'm not as smart as some people are and whom could take my place and do a much much better job.

when two weeks ago i hired a programmer, we wrote a web server on paper. the funniest part was when i pointed out to the candidat that his code returned all the page script in plain text if the parser (i.e. php/ python/ whatever) crashed. That was really funny, and would work well in banking system, where the most critical code would show up to the user. Nice and funny.

But what i actually saw was the way the applicant was thinking and how he responded to various cituations. And regardin his age and position everything much better than the average result. So now he works already for a few days and he cracks tasks slowly, but steadily. And the tasks are not really that easy to go.

So nice article! thanks

Juan Hose said...

Hi! Click here to order essay by best essay writer, if you need some help with your assigment.