本文发表在 rolia.net 枫下论坛How To Hire A High Tech Employee
This article is for managers and executives who are not themselves technically inclined. It discusses the writer's approach and perspective to hiring high tech personnel.
Hiring in the high tech industry is notorious for unrealistic expectations. This comes from both the employer and the applicant's side.
Here is an example of a typical employment advertisement I pulled (almost at random) from the Saturday, June 2nd Vancouver Sun:
" ... hard core Visual C++ ... work on laser sensors, ultrasonics, data mining, and more. ... TCP/IP. Windows NT. OLE. OpenGL. MFC. ODBC ... sockets and multi-threading ... VB, ADO, SQL ..."
The "and more" is actually in the ad. Here's one pulled (again almost at random) from the Saturday, June 16th Financial Post:
"... financial and tactical planning and forecasting ... degree or diploma, preferably including MCSE ... knowledge of security practices, LANs and WANs, Alpha and Compaq servers, VAX systems, and VB, C+, HTML, ORACLE, Windows 95/98/NT/2000, PKI, and Entrust. A willingness to travel is required."
Non-technical people reading this article are probably saying, "What's wrong?! These ads look good to me. These are the skills we want."
In my experience, however, I've never met anyone like the candidates these ads purport to require. I know exactly what is going on here because I've been consulted on ad preparation both as an outside consultant and as a senior employee. The attitude is frequently, "Well, let's put in everything, and see what we get." I can understand what they are trying to do, but it leads to problems.
Similarly, I have received resumes from applicants claiming programming knowledge in five or more languages or expert knowledge in several CASE tools. Not possible. I get people who claim to know, say, SQL Server. Okay, what part? - Transact SQL? DMO? DTS? Admin? Analysis Services/OLAP? English Query? Can you program OLE DB or ODBC directly? I have the documentation, it is 18 inches thick, what part do you know really well?
Furthermore, colleges and training schools encourage students to put down every language and technology that has been remotely mentioned in class. Discuss CPU registers? Put down assembly language! Compare conditional structures between C++ and Pascal? Put them both down! The Pascal compiler is an old DOS based package? Put down Windows anyway.
Not much wonder businesses claim they are having trouble finding qualified people. No one could possibly be qualified to their criteria.
I am looking for expertise in only two or three core technologies. Peripheral knowledge in other areas is good but not expected. Beyond that, I want someone who has the aptitude to learn and solve problems.
When I hire someone for a software development position, I have tests set up. Tests are easy to hard. I like to sit with them and talk about the problem they are trying to solve - this gives me an idea of their problem solving ability, just as important as tool or language knowledge. The candidate should be able to communicate complex matters in simple terms.
If the applicant has been in the industry for any length of time, I ask about problems they've encountered. No problems, their high tech experiences have been an unending series of unending successes? No way. They must have encountered the problem of changing requirements, of unrealistic development dates set by non-technical people.
I also ask applicants to bring in any software they have developed on their own to show me. I ask for several pages of source code. We discuss it. It is always nice to see developers who have actually tackled an entire application on their own, even a small one.
If an applicant is coming in for a networking admin position, I make sure my networking people get a chance to interview them and ask questions. I tell the networking people to prepare tests - even simple ones to help gauge an applicants real understanding. i.e.: Many so-called network administrators have never really had to re-install from a tape backup.
If an applicant is coming in for a DB Admin position, can they really recover a corrupt database? Many trained DB administrators have never actually encountered, or had to recover from, a corrupt database - they can drop a database and reinstall from a backup, but recovery is a whole other game.
If an applicant claims to be a SAN expert, better get the hardware people in to show the applicant around and ask questions.
I realize that sometimes there is not enough in-house skill to adequately test an applicant. If that is the case, the company should really consider hiring an outside consultant to perform the interviews and assess the applicant.
Technical skill isn't the only thing, of course. The applicant should be well dressed - which shows some respect for the whole process. I am not talking about fashion; I mean neat and presentable. This not only goes for the applicant, but for the interviewer as well. Respect is a two-way street. The interviewer, at the very least, should have read the applicant's resume beforehand and be prepared with questions and an outline for the direction of the interview.
The applicant has to fit in - this is harder to tell considering the stress they are under at an interview. If an applicant is well prepared, as he/she should be, you won't get any bad stuff. You can only make your best judgement.
When you decide you want to hire someone, yes, you should check their references. The only thing I will say here is that you should be respectful of the time you call a reference and of the amount of time you talk to a reference. Don't call references first thing on a Monday morning, for example. Don't try to spend a half an hour talking to a senior level reference - you will only alienate that reference from the applicant.
After you send out the employment offer, and the applicant accepts, the next significant event is the applicant's first day on the job. There are many ways to make an employee feel welcome and part of a team. This is important for a variety of reasons, not the least of which is the sooner a new employee begins to relax in their new atmosphere, the sooner their efficiency maximizes. With one employer, my new boss and another executive took me out to lunch on the first day. This was the first of a series of "you are a valued member of our team and welcome here" gestures, and I was with that company for a long time. This is not an executive responsibility and may not be appropriate under all circumstances, but the company showed some class and respect by welcoming me in that way. If possible (geography being a consideration), I have followed this practice myself when hiring someone into a subordinate position, and I believe it has worked in my favor over the years.
What am I saying here? Old stuff: be realistic in your expectations, be prepared to interview, check references, show some respect, welcome your new employee on their first day. Got it?
- Paul Fulford更多精彩文章及讨论，请光临枫下论坛 rolia.net
This article is for managers and executives who are not themselves technically inclined. It discusses the writer's approach and perspective to hiring high tech personnel.
Hiring in the high tech industry is notorious for unrealistic expectations. This comes from both the employer and the applicant's side.
Here is an example of a typical employment advertisement I pulled (almost at random) from the Saturday, June 2nd Vancouver Sun:
" ... hard core Visual C++ ... work on laser sensors, ultrasonics, data mining, and more. ... TCP/IP. Windows NT. OLE. OpenGL. MFC. ODBC ... sockets and multi-threading ... VB, ADO, SQL ..."
The "and more" is actually in the ad. Here's one pulled (again almost at random) from the Saturday, June 16th Financial Post:
"... financial and tactical planning and forecasting ... degree or diploma, preferably including MCSE ... knowledge of security practices, LANs and WANs, Alpha and Compaq servers, VAX systems, and VB, C+, HTML, ORACLE, Windows 95/98/NT/2000, PKI, and Entrust. A willingness to travel is required."
Non-technical people reading this article are probably saying, "What's wrong?! These ads look good to me. These are the skills we want."
In my experience, however, I've never met anyone like the candidates these ads purport to require. I know exactly what is going on here because I've been consulted on ad preparation both as an outside consultant and as a senior employee. The attitude is frequently, "Well, let's put in everything, and see what we get." I can understand what they are trying to do, but it leads to problems.
Similarly, I have received resumes from applicants claiming programming knowledge in five or more languages or expert knowledge in several CASE tools. Not possible. I get people who claim to know, say, SQL Server. Okay, what part? - Transact SQL? DMO? DTS? Admin? Analysis Services/OLAP? English Query? Can you program OLE DB or ODBC directly? I have the documentation, it is 18 inches thick, what part do you know really well?
Furthermore, colleges and training schools encourage students to put down every language and technology that has been remotely mentioned in class. Discuss CPU registers? Put down assembly language! Compare conditional structures between C++ and Pascal? Put them both down! The Pascal compiler is an old DOS based package? Put down Windows anyway.
Not much wonder businesses claim they are having trouble finding qualified people. No one could possibly be qualified to their criteria.
I am looking for expertise in only two or three core technologies. Peripheral knowledge in other areas is good but not expected. Beyond that, I want someone who has the aptitude to learn and solve problems.
When I hire someone for a software development position, I have tests set up. Tests are easy to hard. I like to sit with them and talk about the problem they are trying to solve - this gives me an idea of their problem solving ability, just as important as tool or language knowledge. The candidate should be able to communicate complex matters in simple terms.
If the applicant has been in the industry for any length of time, I ask about problems they've encountered. No problems, their high tech experiences have been an unending series of unending successes? No way. They must have encountered the problem of changing requirements, of unrealistic development dates set by non-technical people.
I also ask applicants to bring in any software they have developed on their own to show me. I ask for several pages of source code. We discuss it. It is always nice to see developers who have actually tackled an entire application on their own, even a small one.
If an applicant is coming in for a networking admin position, I make sure my networking people get a chance to interview them and ask questions. I tell the networking people to prepare tests - even simple ones to help gauge an applicants real understanding. i.e.: Many so-called network administrators have never really had to re-install from a tape backup.
If an applicant is coming in for a DB Admin position, can they really recover a corrupt database? Many trained DB administrators have never actually encountered, or had to recover from, a corrupt database - they can drop a database and reinstall from a backup, but recovery is a whole other game.
If an applicant claims to be a SAN expert, better get the hardware people in to show the applicant around and ask questions.
I realize that sometimes there is not enough in-house skill to adequately test an applicant. If that is the case, the company should really consider hiring an outside consultant to perform the interviews and assess the applicant.
Technical skill isn't the only thing, of course. The applicant should be well dressed - which shows some respect for the whole process. I am not talking about fashion; I mean neat and presentable. This not only goes for the applicant, but for the interviewer as well. Respect is a two-way street. The interviewer, at the very least, should have read the applicant's resume beforehand and be prepared with questions and an outline for the direction of the interview.
The applicant has to fit in - this is harder to tell considering the stress they are under at an interview. If an applicant is well prepared, as he/she should be, you won't get any bad stuff. You can only make your best judgement.
When you decide you want to hire someone, yes, you should check their references. The only thing I will say here is that you should be respectful of the time you call a reference and of the amount of time you talk to a reference. Don't call references first thing on a Monday morning, for example. Don't try to spend a half an hour talking to a senior level reference - you will only alienate that reference from the applicant.
After you send out the employment offer, and the applicant accepts, the next significant event is the applicant's first day on the job. There are many ways to make an employee feel welcome and part of a team. This is important for a variety of reasons, not the least of which is the sooner a new employee begins to relax in their new atmosphere, the sooner their efficiency maximizes. With one employer, my new boss and another executive took me out to lunch on the first day. This was the first of a series of "you are a valued member of our team and welcome here" gestures, and I was with that company for a long time. This is not an executive responsibility and may not be appropriate under all circumstances, but the company showed some class and respect by welcoming me in that way. If possible (geography being a consideration), I have followed this practice myself when hiring someone into a subordinate position, and I believe it has worked in my favor over the years.
What am I saying here? Old stuff: be realistic in your expectations, be prepared to interview, check references, show some respect, welcome your new employee on their first day. Got it?
- Paul Fulford更多精彩文章及讨论，请光临枫下论坛 rolia.net