(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, December 08, 2006
  Trick or Bleep?

I like to post fun stuff on Fridays. I also repost old stuff from time to time when my brain is page faulting or when something I’m reading reminds me of an old post. Today both were true: I spotted this post about interviews going wrong and I remembered an interview where I was the hapless victim.

There has been some refreshing commentary on the post and also on reddit. I want to give my thoughts on one issue. Was the interviewer posing a “trick question,” trying to find out how I negotiate conflict? This subject has attracted a lot of attention since Joel Spolsky recently raised the issue, and while it didn’t cross my mind at the time, it’s worth considering.

The question posed to me was, list all of the ways to call instance and class methods in Java. I listed a bunch of things, and at the end, I included:
// calls the staticMethod of someInstancevariable's declared class
The interviewer told me I was wrong, and I shrugged, explaining that I thought I was right, but no big deal if I was wrong, since I never use that style of call, so it wasn’t an issue. The interviewer later told me that he did not like my answer, and indeed I did not get an offer.

If this was a trick question, ok, you had me! I am not afraid to argue points where I believe there is a direct connection between the issue and the outcome of software development projects. If I really believe it is irrelevant, I don’t argue even if I have a personal preference. So I’ll happily go along with any particular coding style you advocate (including none), and if you insist that I use Eclipse for Java instead of TextMate, fine.

The problem with that question (let’s be clear, it’s my problem, not the interviewer’s problem), is that I don’t really care whether Java lets you call a static method via an instance of a class. The reason I don’t care, as I explained to the interviewer, is that I will never allow that code to get into the repository.

For those who are too busy with Lisp to know all of Java’s warts, the problem is that static or class methods are never polymorphic. So if you write:
    // (yes, I know about public vs. private. These are obviously in 'package scope')

class House {
static String doorAction () { return "closes and locks"; }
class S___House extends House {
static String doorAction () { return "bangs"; }
and you do this:
    final House structure = new S___House();
You get closes and locks instead of bangs. Always. This is not what happens with instance methods, and that’s because so-called ‘static methods’ in Java are really global functions that live in class namespaces. The compiler resolves the function doorAction by looking up the declared type of structure at compile time. Its actual type at runtime is irrelevant. C++ programmers recognize this as the difference between virtual and non-virtual functions.

Back to the “trick question.” My problem is that since I never have and never will use this, I’m not going to argue whether it’s legal or not. It will never have the slightest impact on any project I’m on. If you want an argument, let’s discuss why you think we should use this idiom in production code.

I honestly don’t think it was a trick question. If the interviewer knew it was legal and wanted an argument, he could have (and I suggest should have) chosen a different thing to argue, something a little more obvious, such as telling me it is legal and polymorphic, and then seeing whether I (a) know that it is not polymorphic, and (b) argue with him.

I don’t use questions like this, but I can see the value of this second question: a really experienced person knows exactly why it isn’t polymorphic and can discuss the kinds of bugs you will get if you try to write code depending on it.

What do you think? Was this really a trick question? If so, should I have been more aggressive in arguing the subtle points of Java law?

p.s. The interviewer later told me that he did not like my answer, and indeed I did not get an offer: one benefit of much water having passed under the bridge is a more balanced perspective. I no longer assume that this one question is the only reason the interviewer decided I was not appropriate.

“Blink” examines why people make unconscious decisions. It's very relevant to interviews!
I may have been overqualified, too talkative, too reflective, or even too meticulous (when given the programming challenge of permuting a string, I was apparently the only candidate to ask what the output should be when the string contained duplicate letters). Perhaps the interviewer had already decided the interview outcome before this question was discussed.

And do you know what? I’m not so sure I wouldn’t have reacted the same way as the interviewer. One of the big “No Hire” flags for me is a candidate who doesn’t fundamentally “get” a programming language. Anyone can “Learn Blub in 21 Days,” memorizing code snippets and patterns by rote. But such candidates often have no clue how a language works, how its features interact with each other to make those memorized code snippets work.

Let’s say that I’m interviewing and I don’t know that Java (which isn’t particularly OO in theory or in practice) allows this bug of calling a static ‘method’ via an instance of a class. Is that so bad? Of course not, it’s a wart on the language. It’s not like knowing that it is allowed reveals a deep understanding of how Java works. So not knowing this isn’t a fundamental flaw in a Java developer or interviewer.

Now a candidate tells me that this thing works. Well, I might jump to the conclusion that the candidate really doesn’t get the difference between static and instance methods, that the candidate will have trouble understanding the various scoping issues involved with instance members and static members. I could easily believe that this candidate will draw a complete blank when working with inner classes.

An interviewer who didn’t happen to know this bit of Java trivia might reasonably infer that thinking it works betrays a superficial knowledge of Java.

Labels: ,


Comments on “Trick or Bleep?:
IMO questions like these rank barely above useless for determining the quality of the coder being interviewed. A quick run through the compiler will quickly disabuse them of this notion. Isn't that what compilers are for, after all? Hell, I've been writing code for over a decade and I still make mistakes like that on occassion.

My favourite interview question is "Tell me what your favourite development language is. Why? Now tell me something you hate about it." Any developer who can't give you something they hate about their favourite language doesn't know that language (and any developer who doesn't have a favourite language has either no passion or no experience).
Thanks, Chris!

I like your favourite interview question as well.
It's a cute question, but doesn't show in any way that the person would be able to do anything useful. There's so much useless esoterica in Java that it really only shows they're good at memorizing things. It would even be better if the interviewee didn't even know you could call static methods from instances than to have one that would possibly use it for evil.

My favorite thing to do is to ask them a design question not related to software to see if they can can generalize the software development process to anything. For instance, I like to ask QA interviewees how they would test a salt shaker. If they say, "First, I would find out what the salt shaker should do" and then talk about specification, then it's a good sign. If they just say, "well, I'd turn it over to see if salt came out", then it's a bad sign.

On the subject of development language, I think one of the good things that can come out is that the interviewee realizes that that there's a difference between the syntax and semantics of language. If they say, "I like Java because it's pretty", they totally miss the point. I like asking "how would you write an object-oriented program in C", since it leads to a good conversation about different programming languages vs. different programming paradigms.
A long time ago, during the local (Delft University of Technology) version of Object Oriented Programming 101, the exam consisted primarily of writing a bunch of code.


One of the classes given to us consisted of a bunch of static methods, and because I think writing code on paper is effing ridiculous (java, by the way, which doesn't exactly offer the gamut on brevity), I pulled a ClassName a; followed by a.staticMethod() just to save myself some typing.

I also made a bet that I could wrap the exam inside of 30 minutes (you have 3 hours) and get an 8 or up (out of 10).

I got a 7... and that particular stunt was marked off.

Assuming it was marked off due to bad style, I decided to take it up, and claim that I did it only to avoid writing so much. Turns out it was marked off because he thought (and this is a professor we're talking about) that wasn't legal.

Somewhere before it became a shouting match I convinced him to try it which led to an 8.

Anecdotal evidence, perhaps, that people just get this wrong and confuse proper style with what the compiler will technically process. I think default installs of eclipse warn you if you try it.
For what it's worth, if I was your interviewer, and if you had hijacked the interview over such an inconsequential topic, I would have no-hired you. I don't have any patience for coworkers who can't let trivial matters go.

You responded in exactly the right manner. What can I say? Sometimes your interviewer is an ass, and you can't do anything about it.
.. and, yeah, I'm with alyosha on this one. Frankly you don't know what this guy was expecting, but even money says you do what you did and get away from the topic stating it's totally irrelevant.

Personally if ever I have to interview someone I might just reconstruct the situation to see how people handle this kind of thing. I want them to talk about it casually or to let it go entirely, because unlike in this case, there's not always a 'right' answer.
Have you considered that they didn't hire you for reasons other than that specific question?

If I was a potential employer of yours and came across this post where you were still worrying over something that happened some time ago, a red flag might go off.
Reg, regarding your addition to the post:

I totally disagree. Now, if somehow you created the impression that the legality of that trick is legal, /maybe/. But you -specifically- mentioned that it's not important and that you'd never ever do it, legal or not.

The interviewer was being arrogant. And that doesn't work, because, while you nailed the idea that knowing these trivial details doesn't guarantee good programming skills, there's also no language that can reasonably be qualified as 'wart-free', either. Avoiding them like the plague is fine, and taking that to the extreme of not even knowing them is no problem...

but not knowing that there are warts at all - that's bad.

Especially when we're talking java which has plenty of warts.

I agree, it is unlikely that the entire decision rested on this question.

I'm not worried about potential employers, business partners, or employees reading my blog. In fact, it's part of the reason I write it in the first place.

Interviewing candidates is a major part of my job. Dissecting interviews I liked and disliked helps me improve my ability to identify star candidates and to employ interview techniques that they find interesting rather than annoying.

Feedback on interview questions from commenters like yourself helps me do a beter job as an interviewer.

Chris > I would never answer this kind of question, this would immediately lead to a flame discussion about the language war. IT people I met with is simply too immature to support a balanced discourse, even on the comments on this blog I got sarcastic answer.

I don't publicly express opinion on this kind of question anymore, this is simply useless.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /