Interviewing

Everyone seems to be doing it at the moment. Howard Rogers has a nice series about a search for a junior DBA, and … um … someone else was as well … can’t remember who though. So not really “everyone”, I suppose.

Moving along, I have been both interviewer and interviewee recently. I handed in my notice to my current client, not from any great need to do so but more to give myself a kick up the backside to take my own job search more seriously. It’s very easy to become disillusioned with the soul-destroying business of transmogrifying your prior experience into yet another company’s recruitment web-site, only for it to disappear after hitting “submit”, or to see that you are not in consideration for a position for which you think you’d be just right and to have no means of contacting the recruiters involved (Oy, Raytheon!).

I have been on the receiving end of a couple of technical interviews, both of which seemed to me to be aimed at weeding out the idiots more than anything very searching. That was a bit surprising to me as I’d expect companies to be rather more inquisitive before offering to fly me across the country for a face-to-face. Still, I’ll not complain too loudly about that. I’ve certainly dislodged some rust from my unix scripting knowledge in the course of one of them, which was “fun”.

I have also been phone-screening on behalf of my current client for an Oracle data warehouse architect in, or willing to move to, Dayton OH, and preferably bringing their own gov’t security clearance with them. I am (rather graciously, I think) feeling bad about this as the pool of applicants is obviously somewhat constrained by those factors, and I’m sure that the new person won’t have the luxury of being able to work from their home 1,200 miles away with a view of the mountains and a cat asleep on their desk. Pretty good coffee though, and a chance to take part in the traditional ritual of “The Ridiculing Of The Previous Person’s Efforts” with me as the mute victim. Not to be sniffed at.

It’s been quite a long time since I administered technical phone screens to others, and I’m covering quite a lot of ground depending on the previous experience of the candidates — Oracle, of course, then Business Objects, Informatica, data warehouse design, business analysis, dimensional modelling … it adds up to about an hour all told. I suspect that if I was getting the right answers early on then it could be cut quite a bit shorter than that though. It’s a tricky business getting the questions right, as has been discussed elsewhere. I like to blend some very specific questions that I think a qualified applicant ought to know (on slowly changing dimensions, partitioning,  etc) with some higher level questions more aimed at some kind of essay-type answer: “Parallel Query: Good Thing or Bad Thing?”, “Buffer Cache Hit Ratios: How Does Partitioning Affect Them?”. I like that last one in particular — I might even start using it, if I find someone who seems to know enough about partition pruning.

I particularly like those open-ended questions for a couple of reasons. Firstly they allow you to establish an analog scale of competence, rather than the digital “knows it” or “doesn’t know it” that the detailed questions establish. They also give an insight into how well the candidate can organise and present their thoughts extemporaneously, which I believe to be an important quality for someone at the architect level who might find themself called into a meeting with a client to explain to a group of technical lay-persons the differences between entity-relationship and dimensional modelling. It seems to be more and more the case that technical features such as partitioning and pre-calculated aggregates are used as marketing tools, and hence fall within the range of vision of non-technical personages such as CIO’s, project managers, business analysts etc.. If you can’t explain it, how can you make a case for its use?

Anyway, maybe I’ll write more about my Cunning Interview Questions once the process is over with. Probably.