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.
Subscribe to:
Post Comments (Atom)
4 comments:
You're talking about me, aren't ya?!
hahaha - no, not directly because while you work for Big Co. you are considered a contractor. While I would like to do the same to contractors - I would bet that would be even MORE contriversial.
Also no - because I like you. 8-)
Point of view concerning preventing new hires from committing code is totally moronic^H^H^H^H^H^H^H corporate. I joined a company a little while ago and found none of my code was getting reviewed (let alone committed) by the previous hire who insisted he look at it all. We did the tests, we had the weekly meetings showing the new code operating to spec, and he just didn't do his part.
It was a japanese company so there was always going to be some unnecessary pain for the sake of conformity, but it was unacceptable to be scolded for not progressing to the next project by the guy who hadn't released the old one yet!
Giving old hires a unilateral ability to strangle the work schedule of new hires is just a license for bullshit. If you're suffering from the delusion you're some kind of great programming sensei go teach it in a school or college, learn how hard that role is.
Be glad the incomplete programmer you hired committed his bad work to source control- it's just the proof you need to terminate the contract during the initial trial period. As slimier employee will use the handicaps caused by this delayed oversight system to generate lots of busy-work instead of stepping in to be measured up.
Maybe it is 'corporate' - but not totally as the idea was/has been adopted by a alot of large open source projects as a way to have a mechanism of control over what types and styles of code make it into source control. Each company has its own style and they have their own 'idea people' attempting to drive a big picture. Sometimes this picture might just be a 'Get it Done Fast' tactical point of view, and other times it will be a very corporate highly strategic point of view.
Really I look at preventing new hires in their review period (Usually the first 90 days) as a way to educate someone new to any company, big or small, what the code style and direction are for that company. You are right, like most things this is no silver bullet and like most things should be taken as a suggestion and not gospel. You will always run into the people that will hide behind someone else and say its 'not my fault because policy said she was supposed to review my code and didn't commit it to the tree', but then you have to wonder what the motivation for that is. Is this person so enamored with themselves that they think your code sucks or are they overloaded, or something else.
You are also correct - some people will use this as an excuse for busy work. My trade off in saying to 'prevent check-in without review' (or stated another way submit patches) is that I am trading off one persons review time for the whole of a larger team not getting held up with code that was poorly written, or poorly tested, or is just plain broken. When you are talking about a whole team of folk the time taken to understand what broke build for a 'bunch' of people is far higher then taking the time to help the person into the company.
Trust me - I suffer from no delusion that I am a great programming sensei (god, deity, minor deity or what have you). I am rather attempting to pass along some observations I have made in my career so far. Free advice if you will, but caution your mileage may vary.
Post a Comment