The Interviewee's Perspective

So I find myself sitting still for a technical interview with a faceless corporation that’s hiring contract programmers. Right away the answer to all my problems is “don’t do that!” But anyways, I did it, and here’s how it goes…

I meet four junior-ish programmers that pepper me with Java and SQL questions. I get it all just about right, although I was unsure about one of the SQL questions. They seemed satisfied, but maybe they don’t bother to shake their fingers at hapless interviewees when they blow a question…

When I get home I try it on my laptop and discover I’d left something out of my SQL answer. I get it right and like a good brown noser I send them an email thanking them and correcting my answer, being careful to explain that I’d tried it like a hands-on person rather than googling the answer like a student.

This wins me a second interview, and once again I get technical questions, these ones a little better. The first set were all right and wrong answers, these ones include an opportunity to share your thinking, such as:

“What’s the difference between an Abstract Class and an Interface? Explain when you would use one versus the other.”

All goes well until I’m asked to explain the difference between static and instance methods, and give examples of how to call them. I do so, and write out a series of calls including this one:

    someInstance.staticMethod();

I explain that it’s allowed by the compiler but I never do that. The lead tech guy shakes his head, saying no, it’s not allowed. Okay, I’m not perfect, I explain that I thought it was allowed but not a good idea, but I could be wrong. Either way, I’m not writing that code.

They finish by asking me to write code for permuting strings. I include command line flags, help, JUnit tests, I go all out and take thirty minutes. He seems impatient for me to finish, even though inside sources told me they’ve hired people who took forty-five minutes to complete the code.

When it’s all over, he’s escorting me to the elevator. I ask him how it went. “Some good, some not so good.” He says. You can guess where this is going… He explained that I got the method code wrong, and that really was not so good.

What can I do? Of course, when I get home, I check the answer. I’m deflated to discover that I was right. This doesn’t help, I’m not going to get a job by telling him he got it wrong. I’d rather be wrong and admit it.

Of course, some people would shrug and say it’s a minor detail, they don’t mind getting it wrong. I’m one of those people. But if I’m interviewing, I don’t hold those details against people. This guy seems to think that knowing the details of the language are important. So I’m not going to tell him he would fail his own test.

So all I can do is blow off a little steam on the web and look forward to interviewing elsewhere.

Thanks for listening, I feel better now.

(This originally appeared in the Joel on Software discussion group shortly after the interview: time has mellowed my perspective since then.)

Follow up: In hindsight, this is good for a laugh. What are your thoughts about interviews like this? Should I have respectfully disagreed with the interviewer? Should I have deliberately left any anti-patterns out of my answer? Perhaps I missed an opportunity to turn the discussion towards one of my strengths?

Labels: jobs

  ¶ 12:12 PM