Many weeks have passed since that day. Reflecting on that mistake I made prompted me to write this post and perhaps help anyone out there who is going through a similar experience.
The main points we will cover here are about:
- Understanding the problem domain that your candidate will be working in
- Understanding the core requirements about the job or opportunity for which you are hiring
- Knowing the tools, techniques, or methodologies that the job requires
- Legitimize the need for a new hire
- Selecting the best candidate for the job
This is by far the best advise I can give about this topic. It is also the easiest step. All it requires is self-honesty. No one can tell for sure the actual level of knowledge you have about a topic except yourself. You have to be honest here and acknowledge whether or not you "know" the stuff for what you are interviewing. If you do not have an understanding of the core principles of the domain or area of expertise required for the job, you should not be conducting an interview.
The clear exception here is if you are in an HR type of role and play the initial filter role for someone with more knowledge about the area of expertise for the job. If that is the case, forward them a link to this post. For the rest of you... read on...
2. Understanding the Core Requirements of the Job
The old saying "2 [or more] heads are better than 1" certainly applies here. Get together with one of your colleagues and go over 2 main things: enumerate the goals / objectives of the job and enumerate the characteristics of the ideal person for the job. One key thing to remember in this step is that if you cannot come up with a list of the specific goals and objectives then you are certainly not ready to hire. If you go ahead with the hiring process thinking that you will "figure out objectives for the gig as you go" then you will waste company resources, your company ROI will decrease and you can forget about that pay raise or bonus.
If you do not have a job description catalog for your department, this is a great time to start one. If you do have such a catalog this is a great time to update it and make sure it is in alignment with the tools, techniques and methodologies used in your shop. Next time you need to interview for the same or similar job you'd be glad you have access to an up-to-date catalog.
3. Knowing the Tools, Techniques and Methodologies Used
It is not possible for a single individual to know it all. Although I have met many who do attempt to delude themselves with that idea. Every IT show is unique and it has its own home-grown blend of tips and techniques that everyone can bring to the proverbial table. Some times you will be the in-situ expert and some times you will not. For those times you are not, you owe it to yourself and to your organization: Ask for Help!
Look up the document that best describes the collection of processes that forms part of your IT "business-bus" and use it as a reference to screen the 2 or 3 of resumes that the HR person will send you and the mountain of resumes that those consulting firms' sales representatives will send you. By the way, if you do not have such a document in house, guess what, you own the responsibility of resolving that "bug" in your IT show business-bus. Also make sure that for every tip, technique, or methodology you list you also identify who is / are the resident experts about it.
4. Legitimizing the Need for the New Hire
You have got to be "legit!" This is another one of those things that tend to be forgotten at the time of considering the need for a new hire. Following these steps helps you authenticate the need for hiring a new person. Remember, your are increasing your cost base every time you hire. Make sure that it is for the right reasons and there is no way that your current staffing levels can support that need. You should be in an easier position to make that call. You have 3 things to your favor: an expert in the field (step #1), understanding of the problem domain or area of expertise needed, and a catalog of you resident experts on how to do things in your IT show. Use the power of this knowledge to determine if you need to proceed with the hiring process. Remember, the self-honesty-bit is still in the "on" position.
5. Selecting the Best Candidate for the Job
May I suggest you read step #4 again? Really, you could ensure your value to the company if you can save them the cost and hassle of hiring another employee. Also, remember that if you are doing the hiring you may also be doing the firing... but I digress...
OK. I get it. You still want to hire that new person. Here are some techniques to help you select the best candidate:
- Use Hypothetical Scenario Modeling (HSM) - come up with a "make belief" business case (a book store or video rental are a couple of easy ones that are relevant to most people). Ask the candidate to tell you how they would go about modeling a system for that hypothetical situation. This is possibly the best way to really peek inside someone's brain and actually "try before you buy." Keep this as an informal step of the interview itself. Make sure you keep it strictly technical and make sure if the person knows, for example, U.M.L. (Unified Modeling Language), or they know how to read an ERD (Entity-Relationship Diagram). If you want to formalize this (i.e. create an actual test to be administered to the any applicant for the job) ensure that your HR (Human Resources) and Legal department are aware of what you are trying to do. Some times, as it was in my case, they will tell you not to formalize the test because you "may be discriminating." Now, it is time for me to get on my soap box: You are right Mr. Lawyer I want to discriminate. As an IT manager, I want to discriminate against someone who says they know UML (on paper) and cannot show it in practice and not have to pay the person for 3 months to come up with the same answer.
- Use Actual Scenario Modeling (ASM)- Essentially the same as HSM but instead of using examples of a fabricated story, you use information out of a real business case maybe even the actual project that the candidate would be working if he/she got the job.
- Use a "trial period" project basis. Typically this is a prolonged version of the ASM. It is way costlier. I do not recommend using this, but it is so late at night that the voices in my head are telling me to write it down here. By the way, if you have to go to "trial" chances are you don't understand the domain, the tools or the project. Are you sure you want to hire if that is the case?
- Select finalists (2-3 resumes should do) based on how well they meet the criteria that you identified in steps 2 and 3 above.
- Actually read the resume of those who make the "cut." It seems silly but reading the resume will prevent you from asking questions where the "smartty pants" candidate would start by answering "as I wrote in my resume..."
- Follow up with the references listed on the resume
- Ask the candidate to provide positive anecdotal evidence of how they work
- Ask the candidate to provide negative anecdotal evidence of how they work
- Special items for hiring a consultant
- consider whether or not you want a contract for hire hourly rates and pricing will become negotiable issues. Best of all, you'll be able to avoid unpleasant surprises. For example, if you work in a very complex or sophisticated solution space you will be making an investment in that person. You probably would like to keep / retain that as a full-time employee
Until next time friends!
PS: Are you sure you really "have to hire" more help?
For more insight on that question, I recommend you check out a pod cast at the McCarthyShow link here.
No comments:
Post a Comment