the google question
Thursday, January 17th, 2008my never ending quest to hire a subordinate continues, and it appears the only way to make this happen here is to lower the bar substantially. this doesn’t mean hiring losers, but it may mean waiting for a superstar to emerge is not realistic. the person we bring on just won’t have as many tools to work with.
the challenge for me then is to determine which attributes you can give up on, without it being an indicator that their overall value is seriously diminished. it’s the difference between having a dull blade that can be sharpened, or one that is just made out of wood or plastic, which really limits your capacity for bloodshed.
I’ve also learned the truth about the ‘I can pick up that language if I need it’ lie. maybe you can pick up the syntax and grammar, but things like best practices, patterns, etc., are things no book or website will give you. you need to work with people that are good, and even then, you need a strong fundamental base of understanding. if your start in this field was hacking webpages as the ‘techy guy’ in your old job, I don’t care what else you taught yourself to do all by yourself - chances are, it’s all a big mess.
the biggest issue I have with all the candidates I have seen so far, is that I never make it to the google question.
the google question used to be the microsoft question - those brain teasers you would ask to check problem solving ability, or just problem diagramming skills. or, you could ask very obscure technical questions (implement strcpy) to see where their base of knowledge lies. the biggest problem with these questions (among the best candidates), is that everyone has already heard them, and/or everyone has just gotten good at solving brain teasers. google has since moved to more open ended, solution-less questions (how many phonebooks are there in the seattle area), but even then, once you know not to panic, there is almost no way to outright fail.
you can always ask someone if the know why a solution works (such as the balls and scale question, etc.), but if they don’t know the answer, what have you really learned? they don’t pursue useless knowledge? it’s a plus if the do, it’s not a minus if they don’t.
these people though - whew. I’m stumping them with doozies like, “How can you set up 2 batch jobs, so the that the second job doesn’t start if the first one isn’t finished?” like the google question, this one has many many answers that are not wrong. a good example of a wrong answer though (I have learned), is “that sounds like a unix-y thing - I don’t do unix.”
ultimately it’s the apathy most employees have for their careers here on the rock is also present in the tech market. with no real options for rapid climb in return for hard work, people are content to do what their told, and learn when sent to training. employers are more than happy to not train anyone, and just keep paying ‘analysts’ $35k/yr to write procedural code that does nothing special.
no diamonds in this rough, and no one to throw google questions back and forth with…