How-To Guide for Hiring Developers & Other Tech Staff [StartupCTO]

Last Updated: 27 Jun 2023
|
Author: dordal
Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.
Currently locked by: 3.144.102.239
Lock expires at: Apr 25, 2024 06:55 AM (164 min)
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
= How-To Guide for Hiring Developers & Other Tech Staff =

Hiring technical folks – at least good technical folks -- can be a tough thing to do. Here is a short How-To Guide that will help you. 

== Making a Plan ==

{{ :people:hr:interview_quick_reference.gif|}}Before beginning the hiring process, you need to decide what qualities you need to look for given the position. Certain people will suit certain positions better than others. For example, if you are hiring a technical lead, you'll need them to have good oral and written communication skills, and be able to see both sides of an issue and make a decision. If you are hiring a lower-level programmer, those aren't as important, but having a highly technical mind is.

You should make a detailed list of the qualities you want to look for and the types of questions to ask, before beginning the process.

=== Finding Good Employees ===

Finding employees can be a difficult task, and is usually best accomplished through referrals or similar means. I’ve put together [[people::hr::how-to-find-good-tech-folks|a guide on finding good employees]] with some ideas to get you started.

Good employees have a number of traits, and according to Joel Spolsky's [[http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html|Guerrilla Guide to Interviewing]] (an excellent reference, by the way), but it boils down to only two things. People need to:

* **//Be Smart//**
* **//Get Things Done//**

That's it. In more detail, however, people should have:

 * **Expertise:** You want people to be experts in some area you need. If they have truly mastered one (or more) areas, they likely have the skills to master another.
 * **Commitment:** You must have people that are committed to their project and the company. There are always times when things aren't going well -- how do you pull through?
 * **Attitude:** A positive attitude is critical. Even one bad apple can ruin things for the rest of the group.
 * **Behavior:** You need people that take action, and do so of their own accord. People that simply wait to respond to an external event before doing anything are not as valuable.
 * **Team Skills:** It is critical to have people that work well in a team, and work well with your team.
 * **Thirst for Knowledge:** Good people are always trying to learn more, and to push the boundaries of their knowledge.


=== Pre-Interview ===

Once you hear of a prospective hire, you should get a resume from them, and then do a bit of pre-interview work.

First, review the resume:

 * {{ :people:hr:be_smart.gif|}}Look for depth of experience. Have they spent two years or seven years doing whatever you need (e.g. developing web applications)?
 * Look for 'happy feet'. If they have switched jobs a lot in the past, they may not stay with you for very long either.
 * Look for similar companies. If they've worked with a lot of small companies and startups in the past, they might be good for you. If they've worked with bigger companies; they may be more steeped in process and procedure than you are. //(This is, of course, assuming that you are in a small company!)//
 * Look for sloppiness. Don't excuse someone who has a sloppy resume, doesn't get it to you in a timely fashion, etc. This likely means they won't be very good on the job.
 * Look out for qualifiers. Many resumes are filled with phrases like "knowledge of", "assisted with", "had exposure to", etc. Don't confuse these qualifying phrases with hard hands-on experience and more direct involvement, which might be indicated by phrases such as "delivered", "owned", "managed", "defined", "wrote", "integrated", "drove" and "created".
 * Make sure the person is not going 'backwards' in their job progression. If the jobs are getting easier and easier, it is a bad sign.

=== Phone Interview ===

Once you have reviewed someone's resume, you should conduct a phone interview to make sure you want to spend your time interviewing the person. The phone interview should be fairly short (usually ten to twenty minutes long) and you should try to hit on many of the same points you'll hit in the interview, including:

 * Finding out more about who the person is, and what they do.
 * Finding out what skills they think they have.
 * Asking them about previous employers/projects they've worked with/on.
 * Doing a simple skills test; i.e. ask them some technical questions related to their area. Many people can talk the talk, but not many can walk the walk.

If you like the person, go ahead and set up a tech screening or a real interview. If not, politely tell them that you'll get back to them if you are interested in bringing them in for an interview.
=== Tech Screening ===

If you're hiring an engineer, you may want to put them through a second phone interview; this one is an in-depth tech screening. It will help separate the wheat from the chaff, and potentially save you and your colleagues a lot of time when doing the in-person interview.

My favorite way to do a tech screening is via [[http://www.webex.com/|WebEx]] (or similar). Notify them in advance that you'll be asking them to share their screen with you, and that they should have their development environment ready to go. 

If you don't have WebEx, you can also use [[http://www.ietherpad.com|ietherpad.com]], which lets you both share a common document with no login, etc. required.

When you start the interview, login to the WebEx system and ask them to share their screen. Then ask them to write code for you while you watch. Ideally, you'll want to put them through actual tests, such as the [[:people:hr:good-technical-interview-questions:html-css-questions#htmlcss-test|HTML/CSS tests]].  (If you can't get WebEx to work, you can do a similar thing with a shared Google Doc, but I've found this to be less effective.)

Once you're done, either offer to bring them in for an in-person interview, or let them know that you'll be in touch with next steps later.

=== Interview ===

The in-person interview is the most important part of hiring someone. In it, you will try to determine if the candidate would be a good fit for your company. Interviewing is a skill that takes a long time to master, but here are some ideas to get you started. In addition to reading this and the list of [[/people|potential interview questions]], you should look at Joel Spolsky's [[http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html|Guerrilla Guide to Interviewing]], which even has a guide to developer interviews.

 * Ask open-ended questions. The idea of an interview is to try to draw information out of a candidate, not get them to answer simple questions.
 * Put the applicant at ease. They will have a lot better impression of you, and you will get more out of them, if you can put them at ease.
 * Base your interview from these [[people:hr:potential interview questions]]. In particular, hit on the points of a good employee, outlined above: expertise, commitment, attitude, behavior, team skills, and thirst for knowledge. Also keep in mind the more simple "be smart and get things done" mantra. Remember, you almost always want to hire the people, not the specific skills.
 * Be sure to test the candidate on their skills. The test will take different forms depending on what position you are interviewing for.
 * Ask the candidate whether they have any questions about the company. Try to sell them on your company.

Ending the interview: It is a good idea to give the interviewee clues that the interview is ending, such as pushing back your chair and putting down your pencil. If you are interested in this candidate, let them know of your interest and say you'll get back to them. If you aren't sure, or aren't interested, mention you have other people to see and politely let them know you'll get back to them later.

Be sure to take notes during the interview! Also, I always like to take about ten minutes //IMMEDIATELY AFTER// the interview to write down my thoughts. If I don't do this, my thoughts usually go away.

=== Check References (Optional) ===

Checking references is important - it lets you get an independent view on a candidate. However, it can be hard to do, at least in the United States, because of new state and national laws. 

 * Call references listed on the candidate's resume, and ask them about the candidate.
 * If possible, try to get the names of other people who the candidate has worked for, and call them too.

Don't delay in checking references. It is very important to talk to the candidate before you interview the references, so you can ask them about issues you feel might be of concern.

=== Second Interview(s) ===
In most cases, a candidate will be interviewed by more than one person. This may happen on the same day, or it may happen later. The second interviewer should talk to the first person and be sure to hit any points of concern. 

=== Hiring Them ===

{{ :people:hr:happy_hire.gif|}}Once you have decided on someone to hire, you should do so right away. Call them and offer them the job. Good people are almost universally hard to find, and you don’t want to lose somebody because you took too much time. 

Generally, I like to offer them the job on the phone, but decline to discuss specifics such as salary and vacation time. Those belong in the formal offer letter.

=== Not Hiring Them ===

Once you've made your selection, you'll need to tell everyone else that you aren't going to hire them. You can do this via email or a phone call; I generally prefer a phone call. Email is a cop-out; it's how the person you went out with last night tells you that they want to be 'just friends'.

When you do call them, keep the conversation pleasant and don't burn any bridges. Here's what I suggest:

//"Bob, thanks for taking the time to come in last week. We really appreciate it. Unfortunately, I'm sorry to tell you that we have decided to move forward with another individual, and we won't be able to offer the position to you."//

Some people may ask why, or what the other individual had that they didn't. My recommendation here is to be polite, but honest. It will help the candidate improve themselves in the future interviews.  Here are a few things to say:

 * People Skills/Personality: //"We thought your technical skills were sharp, but there was another individual that really gelled with the team better."//
 * Tech Skills: //"We'll, we really liked you as an person, but the other individual  had three more years of XYZ coding experience."//
 * Communication: //"We thought you were great technically, but this position requires a lot of work with sales/marketing/management/etc., and there was another individual that had a lot more experience doing that."//

Notice how these are phrased: //"You were good, but there was another individual who met our needs better."// Its a way of saying 'you need to work on X' without hurting feelings by actually saying 'you need to work on X'. I recommend you **do not** get into specifics about the interview even if they press; generally comments such as 'we didn't like how you handled your technical demonstration' just breed malcontent.

=== Final Thoughts ===

Hiring people is a hard thing to do, so take your time to do it right. If you're in a hiring boom, you may have to move quickly, but don't rush things. There are studies that say that it costs a company half of someone's yearly salary to find and hire them, so you don't want to make a mistake. 

Remember, unless you're bringing a short-term consultant on board, you're hiring the person, not the skills. Good people can learn new skills. 

Finally, remember to always use your best judgment and trust your gut. If something doesn't feel right, it probably isn't.

Good luck!
Page locked

About Me

Recent Changes

Get In Touch

Follow
