An interview question…
A couple of days ago I read an article "One of the toughest job-interview questions ever". I was reminded of it by this posting…
I found the original post interesting – mostly because I liked the answer the technical writer gave. A bit of background – someone interviewing for a technical writing position is asked what is clearly a "hard core, heads down, write code programmer question". The question seemed entirely inappropriate for the position – but – the answer given was great (I thought)
The answer consisted of lots of questions – in effect – a lot of push back. Define this, specify that, clarify this – need more information.
I can relate.
What surprised me was that a lot of the feedback was negative. A lot of people said "would never hire you", "you missed the point".
All of the time I was reading though, I was nodding my head saying "yeah, what about that". I would have hired him on the spot. Critical thinking, push back, give me the details, tell me what you are really trying to do.
The programmer that rolls over and just answers the question – without enough information to actually answer the question – should send the interviewer running away. But that is apparently what a lot of interviewers are looking for.
I’ve been known to have three to four very simple interview questions for "Oracle people". They are designed to test the simple to the sublime. They are:
I have a table:
create table t ( ….., month number, ….. );
Month is always a number between 1 and 12.
I ask three questions about this table:
1) how many rows are in the table
2) how many rows BY MONTH are in the table (i want to know how many rows for month one, month two
and so on)
3) what MONTH has the most rows (and for a special bonus, tell me why this question is ambiguous)
The fourth question is more of a "do something for me" – and that is "go to the white board, draw a picture of Oracle and tell me how it works".
As the link says – a surprising number of people *struggle* (seriously) with the first question. The second – gets *most* (seriously) of the rest. The third question freaks them out mostly. Especially the parenthetical part. The fourth question – sends people running out of the room.
That is why I liked the article I originally read – the author was poking around, developing derived requirements, fleshing it out, figuring out what really needed to be done, not rolling over and saying "you got it, I’ll be right on it, we’ll do that straight away". Developers (DBA’s, whatever) that don’t push back, that don’t dig into the question, that don’t try to convey "this is more complex than you think, we need to go a bit into this to figure out what you really need" – well, I don’t have any patience for them. They do not belong (in our profession).
Will that person (the interview-e) annoy you? Sure, from time to time (I’m sure that every now and then – someone is annoyed by me, probably).
Will you ultimately be really happy they were there? Absolutely.
Will the person that rolls over annoy you? Absolutely – every time – most of the time probably. Especially after they really mess you up the first time they are so "flexible". Will you ultimately be even a little happy they were there? I doubt it.
I’ve said many times – there are only TWO answers to all technical questions. They are:
- WHY (why do you want to do that)
- IT DEPENDS (it really does, and it requires digging around, poking, probing to figure out what it depends on…)
poke, probe, ask, discuss, dive deep, play stupid (it works, really) – but get the information…
