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.

About these ads

11 thoughts on “Interviewing

  1. The hardest job is to interview for your own replacement; do you seek some sort of clone of yourself, someone better than you or just a clown?

    And as you say, David, there seems to be a lot of this interview stuff going on at the moment.

  2. Pingback: Data Warehouse Architect Position Available — Dayton OH « The Oracle Sponge

  3. hey at least you’re getting both interviews and interviewees. we can’t even get someone to interview for our open DBA position, so we’re going to loose it and be down to just 2 DBAs.

  4. I think the main issue I have seen with companies and tech interviews are that they drag on for way too long- I once had a killer 5 hour interview at Qualcomm for a six month contract Oracle DBA position; and second, that expectations are often unrealistic. No one can know everything. I actually had a DBA want the exact syntax for the Oracle srvctl command to add and remove instances in an Oracle RAC cluster. Strive for real IQ and people skills not just semantics. Then you will find a solid candidate.

  5. Good thoughts, VDBA. Five hours for a six month contract? I think if you can’t get a good idea in the first fifteen minutes and a resolution of doubt in an hour then it smacks of ass covering.

    Syntax is indeed a tricky business. I was recently asked for the syntax to retrieve the department with the second highest average salary in a phone interview — piece of cake to write it down, but verbal SQL is horrible, especially when there are at least three or four ways that spring instantly to mind.

    Yes, intelligence and the ability to relate to people is key, and I think that’s something that Howard Rogers mentioned also. I’d add in the ability to talk about and explain an issue intelligently for architect roles, but that’s not something I’d expect of every technical position.

  6. I agree the 5 hours is ass covering. Interviewees are on their ‘first date’ behavior anyway so that has to be taken into account. So far our collective BS-O-Meters haven’t let us down.

    We try to keep our interviews to 2 hours tech, 1 hour talking to managers, and 30 minutes with HR. That 2 hours tech also includes time for them to ask us questions and time for us to talk about the job duties and expectations.

    The ‘Quiz Show’ line of questions on arcane syntax and command line parameters is the easy/lazy route for interviewers. Sometimes its an ego boost for the person asking all the questions. I think its destructive. We avoid that at all costs and ask questions that can demonstrate a good mix of problem solving ability and people skills.

    — Dave

  7. We had this, “Correct Syntax as interview technique” battle over on Mr. Burns’ blog. He’s probably the other “… um … someone else was as well … “.

  8. Ah yes.

    Well correct syntax shows fluency that it only gained by real-life experience, but sometimes people have not had a genuine need to be using a particular type of statement — not that I’m saying that applies to the case that Doug raised … DBMS_STATS was it?

  9. Pingback: Pythian Group Blog » Log Buffer #29: a Carnival of the Vanities for DBAs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s