I used to get annoyed initially when i joined my job and people would refer to me as a "resource". I guess it goes away with time or may be as you move along and start refering to others as "resources", you start accepting it.
I never got around to interviewing a full time employee back when i was running my startup in indore so it's safe to say my interviewing/recruiting virginity was still intact when i joined my new company. I've figured there's no fixed set of steps or tests that let you evaluate the best member for your team. There are tried and tested methods out there but they are again based on different environments and that they would work well for your team, is just pure speculation.
I've "talked to" a few people as my manager calls it, in these last 8 months since i've joined this team and since i'm already known for not always being politically correct, i'll say that i've had a few good and bad experiences. I really wish i could find out how the people who brought me on feel.
The real problem i see with bringing a new member onto a team in big organizations is time. A few things to note before i make my point:
- The recruitment wasn't necessarily done keeping your needs in mind.
- You may have never talked to the person who went out and hired these new guys.
- You can't even be sure if the person who hired a bunch of new guys did so after fully evaluating their capabilities, keeping the organization's need in mind at all times and with a non-biased view.
- Every recruitment drive brings in more candidates than there is time for.
- The candidate's authenticity can not be verified immediately.
- The candates must be judged on 1 short interview and past experience (which you haven't yet verified) and you just don't get to find out if they can write any good code.
- The candidate's interest are not necessarily known to the company and they may train him/her to fit their needs but you just end up with a confused disgruntled employee.
- The department that initiates recruiting drives or allocates a new member to your team doens't necessarily understand your needs or the candidate's capabilities.
- The resource allocation department is also under immense pressure as every day that an employee is on the bench is costing the organization dearly. This affects the way they allocate employees to the different teams adversely.
- The team leads and managers get only a limited number of options, they must evaluate them in a short time and they don't get any trial runs. They must give a final yes or no very soon.
Keeping in mind that recruitment drives are a hectic and costly process, the area where we can actually improve is the allocation of these candidates to different teams once they've already been recruited. An employee on the bench won't cost you as much as a loss of a client or a law suit. Bear in mind, one weak link can affect the whole team and you can't afford to lose your best team members.
How would i rather do it?
- Give the teams a change for a test run. You don't always need a guru. A keen programmer who's interested in your work and is a quick learner is usually always a good fit with the rest of the team. Give them a small test drive of your project with a tiny little mockup may be or just a small module under supervision.
- Always, ALWAYS ask candidates to write code before you bring them on to the team.
- Try and see if the employee's enthusiastic about the project rather than going for the one with more experience.
- Ask about their contributions to other projects, specially open source projects as the transparency in such projects will help you evaluate their strengths and weaknesses.
- If your team's small you'll need an all rounder. Even in the case where a new member's intended to replace an old one, you'll need an all rounder. Try and find a candidate who can fit in with the team with any role he/she is alloted. Give them varied tasks during the trial run.
- Now i may be a little biased about this particular thing but i feel if the communication skills aren't up to the mark, try and avoid getting the employee onto the team. I guess that's too stringent and unhealthy but you should atleast make sure the candidate can communicate what they intend to, properly. Language, grammar, pronunciations and body language can always be worked on but they better be able to communicate or it's going to cost your team dearly. It'll lead to loss of time, short tempers and at times mistakes that will cost you many man hours to fix. Ask them to draft a few mails during the trial run, see how well they communicate with the rest of the team. If you have an offshore client, a good communicator will be a boon to your team.