Technical Interviews: How Not to Hire a Good Developer

I just had a technical interview so bad that at one point I stared out the window behind my interrogator at a small pond and prayed. I am not a religious person.

Why, with my 160 IQ and my degree and my twenty years of IT experience, do I still suck royally – I mean blow – at technical interviews? It’s as if every fact I’ve ever learned in my entire life flees my brain. It’s like an out of body experience; you could ask me why it’s important, when walking, to put one foot in front of the other repeatedly and I’d be the proverbial deer in the headlights.

 The thing is, I’m a good developer. I have a track record. I’ve had lots of quantifiable successes. And yet, none of that matters a damn in these kinds of technical interviews.

 One question was, what html tag would you put around a blah (blah being the specific object which my abject terror has erased from my memory banks.)

 This is one of those things I would look up if and when I needed it. If I used it a lot it would become memorable. Generally, since writing html from scratch is about as much fun as cleaning grout with a toothpick, I hack/adapt existing html for my purposes.

 I didn’t say any of that. I said I didn’t know.

 Next question! What’s the difference between these two Java operators:

 a equals(b)   or   a == b

 My answer, which in essence was right, didn’t fly: One is like initializing a variable, assigning a value, and the second is an actual operator performing evaluation.

 I was asked some kind of follow up to the effect of, but what’s the difference between them? To which I said, Huh? Gulped, and finally punted and said, “I’m sorry, I don’t know how to answer that question.”

 And the interviewer was wrong. I came home and looked it up:

 “The equals() method of java.lang.Object acts the same as the == operator; that is, it tests for object identity rather than object equality.”

 Got that? One tests for object identity and the other equality. Which is what I said! (Although not in so many words, unfortunately.)

 Back in the mid-eighties when I was a youngster starting out I had an interview with an IT manager at Memorial Sloan Kettering in NY who asked me how many slots were in an IBM XT. Again, I had the Huh? reaction. I wanted to say one of several things: Who the hell cares? Why don’t you get off your lazy ass, walk around to the back of the computer and look? Is that really relevant to programming?

 Being very young and green and insecure I said none of those things. I didn’t get that job and I doubt I’ll get this one either.

 Back home, tail tucked firmly between legs, I ran a Google search: Intuitive reasoning versus rote memorization.

I was heartened to read that individuals who are good at intuitive reasoning are better learners than those who rely on rote memorization. In other words, the fact that I know where to find the “slots” on a computer and how to get the correct answer is more valuable – and practical – than trying to memorize specifications for every computer model I’m likely to encounter.

 The author used the analogy of drawing versus tracing:

 “Is tracing different from drawing? You bet. Tracing is mimicry -- we don't know why a line is there. We just start in one corner and work our way around.”

 e.g., The geek who can recite Java operators and html tags from memory most likely has no reasoning ability and doesn’t know enough to come in out of the rain.

“Math is similar: we ‘teach’ by tracing a student through the steps of a proof. We're walking the student along the drawing without showing the mindset that created the proof.”

 (This explains why I also sucked at geometry; I hated those stupid proofs. What was the point of mindlessly regurgitating work that had already been done hundreds of years previously? Who cared? No teacher ever told me why I should care.)

 “I've struggled how to reconcile rigor and intuition -- both have their role, but how do they fit? The drawing analogy captures my feelings:

     * Rigor (permanent inked lines) helps cement ideas after the intuitive pencil structure has been put into place

 Focusing on rigor prematurely creates fear and trepidation -- 'What if I'm wrong?', and encourages people to trace the inked results instead of learning how to experiment on their own.”

Bingo! I intuitively know what to do and then cement my ideas later with rigor. That’s it exactly. But how do I translate this to an interview in the corporate world, where I have tweny minutes (maybe) to impress someone with my technical prowess? I can’t say, “I just know what to do.” I can’t say, “I just know which operator to use but I can’t explain why.”

 Which leads to the final point in the article: Creation Vs. Understanding

 “What's the point of education: the results or understanding?”

It's seldom either-or: we want results and understanding. Unfortunately, we focus on results because they're easier to test (Can you plug X into these formulas and get the right answer?).

 And there you have it. Going through life, for me, is like looking down at the earth from 35,000 feet in an airplane. I see patterns, irregularities, structures. I want to make sense of it all. I want to know why.

 You know the old expression, those who can’t do, teach? I’m going to turn that on its head:

 Those who can’t do, test well.

If you want to read the whole article click here.

Comments

[Jodi]

I am with you. I hate technical interviews. I never had any questions when I had to be in them for TRICARE. I go mostly by personality. Figure if someone is in IT they know most of the technical stuff or can figure it out.

You need to admit you use books and the web to find the details you are looking for and that you only know concepts, not the nitty gritty of something you only used once 5 years ago!