Sorry about the quiet period - it has been a very busy few months for me personally. Trying to understand and define what architecture is for me and the company I work for as well as taking 2 weeks vacation to sunshine filled areas. I have a few posts coming - the first one was just posted.
- A post continuing on the idea of architecture individuals being involved in some day to day programming (or at least having a task or two to accomplish for the programmers/infrastructure folk)
- A post about where I am right now and looking for potential guidance - basically a brain dump of my current thinking
- A post on attempting to ingrain security and testing into what programmers do from day to day
At least these are the ideas bouncing around in my head.
Tuesday, July 8, 2008
Interviews and the New Hire
There has been a lot of posting in the past about what peoples favorite interview question, problem, poser, situation are. Some have even gone so far as to offer descriptions and tips of what to do if you are looking for jobs using head hunters, or provide guidance if you are personally heading to an interview with Google. All of these articles are focused on attempting to discover, in advance, if the person that you are contemplating bring into your organization, startup, Big Co, team or what have you has the chops to do the work. Or if you are like most programmers the new hire is of your caliber or better (although in most cases programmers are not about hiring someone who could possibly show them up which is a short coming in most programmers).
So I wanted to offer an alternative to this point of view. The point of view I am talking about is that all the 'discovery' in hiring someone has to be done before they are made an offer to work for your company. Specifically I wanted to float the idea that the first 90 days (which in most larger companies is the 'trial' period) the time in which the company will evaluate you overall, hopefully spend time hand holding you to help you find your way around the Big Co. hallways also be used to help you determine if the person has the skills needed to do the job at hand.
How exactly can you use this first 90 days to you advantage when attempting to help determine if a new hire has the chops to do the job? I think the single biggest way that this can be accomplished is to prevent new hires from being able to commit code directly to the source tree in that first 90 days. Big Co. or your company should look at the new hires as being still 80% unknowns. There is no telling if the new hire will be overly complex in their code, not follow the company standards, or just plain suck.
I have personally run into the "just plain suck" situation when interviewing people - I personally interviewed an individual that seemed perfectly good on the surface. In the interview he had all the right technical answers - but when it came to actually implementing something all the implementations were mostly done but never complete and they were always buggy and HE WOULD ALWAYS COMMIT THEM to the source tree - which would of course break the build for everyone else. Eventually we had to revoke his commit privilege which lead directly to his quiting.
So here I am saying that while the company decides if you are a good working person - the developers should also be attempting to decide if you can really do the things you said you could do in an interview. For the first 90 days new hires should have a senior shadow - and they should NOT have commit privilege. They should be forced into submitting patches to the code through their company programming mentor.
This has a few benefits:
1) It forces a peer review of the code before it gets into the source tree allowing for a greater discussion about solutions, the why and how of what the programmer new hire has done.
2) It gives the Big Co. programmers the ability to essentially have another way of evaluating the new hire for ability and skill and to really validate if they are a fit.
3) Because in the first 90 days most folk can be fired for almost no provocation it is easier to dump someone who might be a half performer - or might not be the programmer you thought they were before they get ingrained and are near impossible to get rid of.
I know in the end that I would personally have a hard time with this idea myself - but I think I could live with this over taking a test, or other challenge in an attempt to prove what I can do. Just let me PROVE it for real - let me live or die by my own abilities. Both for the company and for myself... I think it could make the whole hiring process better.
So I wanted to offer an alternative to this point of view. The point of view I am talking about is that all the 'discovery' in hiring someone has to be done before they are made an offer to work for your company. Specifically I wanted to float the idea that the first 90 days (which in most larger companies is the 'trial' period) the time in which the company will evaluate you overall, hopefully spend time hand holding you to help you find your way around the Big Co. hallways also be used to help you determine if the person has the skills needed to do the job at hand.
How exactly can you use this first 90 days to you advantage when attempting to help determine if a new hire has the chops to do the job? I think the single biggest way that this can be accomplished is to prevent new hires from being able to commit code directly to the source tree in that first 90 days. Big Co. or your company should look at the new hires as being still 80% unknowns. There is no telling if the new hire will be overly complex in their code, not follow the company standards, or just plain suck.
I have personally run into the "just plain suck" situation when interviewing people - I personally interviewed an individual that seemed perfectly good on the surface. In the interview he had all the right technical answers - but when it came to actually implementing something all the implementations were mostly done but never complete and they were always buggy and HE WOULD ALWAYS COMMIT THEM to the source tree - which would of course break the build for everyone else. Eventually we had to revoke his commit privilege which lead directly to his quiting.
So here I am saying that while the company decides if you are a good working person - the developers should also be attempting to decide if you can really do the things you said you could do in an interview. For the first 90 days new hires should have a senior shadow - and they should NOT have commit privilege. They should be forced into submitting patches to the code through their company programming mentor.
This has a few benefits:
1) It forces a peer review of the code before it gets into the source tree allowing for a greater discussion about solutions, the why and how of what the programmer new hire has done.
2) It gives the Big Co. programmers the ability to essentially have another way of evaluating the new hire for ability and skill and to really validate if they are a fit.
3) Because in the first 90 days most folk can be fired for almost no provocation it is easier to dump someone who might be a half performer - or might not be the programmer you thought they were before they get ingrained and are near impossible to get rid of.
I know in the end that I would personally have a hard time with this idea myself - but I think I could live with this over taking a test, or other challenge in an attempt to prove what I can do. Just let me PROVE it for real - let me live or die by my own abilities. Both for the company and for myself... I think it could make the whole hiring process better.
Subscribe to:
Posts (Atom)
