Fog Creek Software
Discussion Board




Tech Interview Rant

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 detals 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 JOS and look forward to interviewing elsewhere.

Thanks for listening, I feel better now.

Tyrannosaurus Rant
Monday, June 14, 2004

What's a good answer to your abstract vs. interface question?

Fred
Monday, June 14, 2004

Abstract class you can implement code, but can't instantiate.  You can instantiate objects of child classes.

Interface, can't instantiate or implement code.  But you can have more than one interface implemented for a class.

anon
Monday, June 14, 2004

>  someInstance.staticMethod();

is not allowed by the C# compiler but it is in Java and C++.  Maybe they wanted to see how sure you were of your knowledge/how you'd react to them telling you something completely wrong.

Billy Boy
Monday, June 14, 2004

It sounds like the interviewers were more interested in knowing what you already know (language-specific topics only) and not in how you think or how you learn or even whether you understand and apply general software engineering principles. There are better employers and jobs out there.

Nearly Nameless
Monday, June 14, 2004

In my experience, as goes the interview, so goes the job. In other words, if you found the interview frustrating, you'll find the job 10x as frustrating.

When I interviewed for Camel, I was asked exactly one technical question: "What is the difference between a dataset and a recordset?" That was it. All the rest was touchy-feely stuff about my experience.

I was also asked one question that should've had me running from the job before I started: "How do you feel about working for a woman?"

Not because I have a problem with working for a woman, but because that question indicates so much wrong-thinking (borne out by my experience) that it screams "we're a bunch of idiots."

Philo

Philo
Monday, June 14, 2004

">  someInstance.staticMethod();

is not allowed by the C# compiler but it is in Java and C++.  "

Ummm...  Someone correct me if I'm wrong, but Java does NOT allow this, right?

anon
Monday, June 14, 2004

Q: How many programmers does it take to change a light bulb?
A: The light works on the development system.

The following compiles and works on my machine (I apologise for not putting it on my FTP server, but I'm trying to stay stealthy):

public class HasToHaveTheLastWord {

private String name;

public void setName (final String name) {
    this.name = name;
}

public static void printStatic () {
    System.out.println(HasToHaveTheLastWord.class.getName());
}

public void printInstance () {
    System.out.println(name);
}

public static void main (String[] args) {
    HasToHaveTheLastWord instance = new HasToHaveTheLastWord();
    instance.setName("instance of HasToHaveTheLastWord");

    printStatic(); // implicitly call static method
    HasToHaveTheLastWord.printStatic(); // explicitly call static Method
    instance.printInstance(); // explicitly call instance method
    instance.printStatic(); // implicitly call static method
}

}

Tyrannosaurus Rant
Monday, June 14, 2004

Oh my God!  Java let's you do it, but IntelliJ stopped me.  I'm so disillusioned with Java!  Why would it let you do such a crazy thing?!? 

And I don't know whether to be thrilled or disillusioned with IntelliJ since it blocked me from doing something legal in Java.

anon
Monday, June 14, 2004

Eclipse will warn you about this, but let you do it.  Since I have 5 coworkers who do this all the time, I've turned this warning off. 

Joe Blandy
Monday, June 14, 2004

It's an obscure 'anti-pattern', and perhaps the IntelliJ people decided that you shouldn't have the right to choose whether to do that or not.

As for why Java allows it, two of the factors influencing high level language design are (a) encouraging best practices/design patterns and (b) discouraging worst practices/anti-patterns.

Maybe this anti-pattern just wasn't high enough on the priority list when they were writing version 1.0. And maybe it's one of those things that we only know is a bad idea because they allowed it and people screwed things up.

I personally don't do it, but I really doubt it's a mission critical problem. If someone showed me some code with that in it, I'd say "next time don't..." rather than "rewrite it so that..."

Tyrannosaurus Rant
Monday, June 14, 2004

Joe:

I think you've hit on the source of my grief. They use Eclipse, and the lead programmer probably feels that Eclipse is the authoritative source for what is and isn't legal.

So if at some point in the past Eclipse told him not to do that, he presumed that it was not allowed in Java.

I can't really blame him for that: why buy a dog if you plan to stay up all night barking at the moon?

Tyrannosaurus Rant
Monday, June 14, 2004

What is the point of a question like that?  Every single day I work with C++, VB6, VB script, Java script, ASP, SQL (both SQL Server and Oracle flavors), XML, XSLT, Java, HTML, C#, VB.NET, ...  And the list goes on.  Honestly, I can't keep things straight.  Why do they ask you about these "stupid compiler tricks" when you shouldn't be doing this stuff in the first place?!?

anon
Monday, June 14, 2004

You're absolutely correct, Tyrannosaurus.  I remember this point from the Java certification exam.  And if you read the Java spec, the handling of static method invocation with a target reference is described in gory detail.  Just look at the following example in the spec itself:

http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#45677

These guys should do their homework; and you should _politely_ point out that they're wrong.  Maybe they'll take it the wrong way; but if they do, you don't want to work for them.

indeed
Monday, June 14, 2004

^

OK, my URL was shredded.  Just look at 15.12.4.6 in that section.

indeed
Monday, June 14, 2004

It seems bad to call instance.staticMethod(), but why is it bad?

How would it be possible for instance.StaticMethod to return something that differs from Class.StaticMethod?

Fred
Monday, June 14, 2004

Re: abstract vs interface:  Another way to characterize the difference would be to compare the intended relationship between the abstract class and a derivced class, and between an interface and its implementer.

That is, an abstract class and a concrete class have an "IS A" relationship.  A Giraffe IS A Mammal.  An interface and its implementor have a CAN DO relationship.  A Document CAN DO ISerializable. 

Or, to put it another way, both describe commonalities.  In the first case, the commonality is the inside implementation, in the second, the commonality is the outside appearance.

Re: Interview badness: Remember, you're interviewing the company as much as they're interviewing you.  I wouldn't want to work for a company where not only did the interviewer get their own question wrong -- which is bad -- but where the interviewer had the unmitigated gall to tell you that you did badly on your way to the elevator.  That's a horrible thing to do to a candidate!

Eric Lippert
Monday, June 14, 2004

"It seems bad to call instance.staticMethod(), but why is it bad?"

It's considered bad because it violates the idea of a "static" member. The point being that you can create a class member not tied to a specific instance.

And one should not rely too much on a compiler "feature" just as a good rule of thumb.

In theory "instance.staticMethod()" should never work. I personaly can't ever seeing myself doing such a thing since it's assumed that it should cause a compilation error .

The java example scare me. I'm not surprised though since there might/should be only one copy of a function in memory. So all instances of an object execute the same code in memory. Can some one point out how wrong I am?

anon-182
Monday, June 14, 2004

Honestly, Tyrannosaurus' rant is a perfect example of dweeb "intellectual bully" programmer mentality. This workplace that "dino" applied to sounds like a masturbatorium for technical prima donnas.

I have written off programming for other people as a career option. If anything just screams "supply and demand is utterly out of whack" this anecdote is it. IE: there is NO pressing problem needing solved, no business issue to be addressed by technology implementation in the joint being described. Instead, there's probably 3-5 well qualified applicants for every open position and no real life based criteria that could be applied. So the interviewers have been given license to demoralize and beat the tar out of anyone dumb or persistent enough to try to stay in the game.

Bored Bystander
Monday, June 14, 2004

The interviewers were fucking morons. They will hire other morons and the place will be boring to work at. It was obviously a coorporate shop, not an ISV.


Monday, June 14, 2004


I think I'd have to email the interviewer the code that shows that you were correct as well as a reminder that just because his editor doesn't allow it doesn't necessarily mean it's part of the Java spec.

Chances are, you aren't going to land the job anyway, but more imporantly it sounds like you wouldn't want to take the job even if it was offered.

So not much is lost in sending an email that politely informs him that you were in fact correct.

Mark Hoffman
Monday, June 14, 2004

Not only that, but I think pointing out to the guy that he was wrong is the only satisfaction you're going to get out of this whole episode.

So far as why you can access static members from instances, I think there are times when it can make sense.

In .NET, if I'm dealing with a variable abc which is an Int32, I'd rather use abc.MaxValue than Int32.MaxValue; it makes more sense in context.  Plus, if later I decide abc should really be an Int64, abc.MaxValue doesn't have to be changed.

Kyralessa
Monday, June 14, 2004

It is frustrating when the interviewer is wrong.  And nobody likes to feel dumb or foolish.

Job interviews are not objective tests of your ability.

Frankly, I have suspected for a long time that most companies would hire the same ratio of good/mediocre/bad people if they choose completely randomly as they do when they hire now.

Your interviewers sound young.

Daniel Howard
Monday, June 14, 2004

Why calling a static method of an instance variable is a bad idea...

Consider two classes: Foo and Foo2.  Each has a static method called getFooName() which returns "Foo" and "Foo2", respectively.

The following code:
Foo f1 = new Foo();
Foo f2 = new Foo();
Foo f3 = new Foo2();
Foo2 f4 = new Foo2();
System.out.println(f1.getFooName());
System.out.println(f2.getFooName());
System.out.println(f3.getFooName());
System.out.println(f4.getFooName());

Produces:
Foo
Foo
Foo
Foo2

Since f3 is an instance of Foo2, some developers might have expected:
Foo
Foo
Foo2
Foo2

Ambiguity is bad.

Caffeinated
Monday, June 14, 2004

>
And one should not rely too much on a compiler "feature" just as a good rule of thumb.

In theory "instance.staticMethod()" should never work. I personaly can't ever seeing myself doing such a thing since it's assumed that it should cause a compilation error .
<

This is not a compiler feature, it's part of Java spec; just accept it :)

The most likely reason why it's in Java spec is because it was in C++ spec; why it's in C++ spec I don't remember.

Anyway, the reason it's preferable not to do this is because it looks like something that it's not. Static methods behave differently than dynamic methods, for example they are not virtual. But depending on the situation, it's not that terrible, and I've used it myself just for code formatting, just because the instance name was shorter then the class name...

But sometimes it gives "interesting" results... Try to guess what this does:

A a = null;
a.staticMethod();

If this doesn't rattle you, play with overriding some package-scope final methods :p

genius
Monday, June 14, 2004

"Consider two classes: Foo and Foo2.  Each has a static method called getFooName() which returns 'Foo' and 'Foo2', respectively."

Without knowing something about how Foo and Foo2 are related (if at all), it's not clear that...

Foo f3 = new Foo2();

...will work in the first place.

Kyralessa
Monday, June 14, 2004

I had an interview like this once and I was so annoyed I rang up the HR manager to complain about the interviewer.

Talk about fun. Once I had decided they were stupid, it was quite interesting to see the power relationships at work.

The HR interviewer and the recruiter both rang me expecting to upbraid me for my impertinence, but when I told them I was considering taking it higher, to the CEO, who I knew from conferences, we all realised they didn't have a leg to stand on.

tree
Monday, June 14, 2004

> Foo f3 = new Foo2();

There's no ambiguity. You said what you
wanted. How much clearer could it be?

son of parnas
Monday, June 14, 2004

>> "In .NET, if I'm dealing with a variable abc which is an Int32, I'd rather use abc.MaxValue than Int32.MaxValue; it makes more sense in context.  Plus, if later I decide abc should really be an Int64, abc.MaxValue doesn't have to be changed."

That's a pretty good argument for their use, although I'll still never do it because there are so many good arguments against.  In the case you mention, it might be more tedious to change each instance of 'Int32' to 'Int64', but:

(1) It's not like you can get away without changing each one - the compiler will enforce it, and

(2)I think it's much safer to have to manually change, or perhaps caste each occurrence of 'Int32' to 'Int64', because it forces the developer to examine the code.  What happens if some of the logic depends on using the max for Int32 rather than Int64?  Using your method, the developer would simply change the variable and never know that the logic depended on a particular variable until run-time.

Oh, well.  My two cents. 

anon
Tuesday, June 15, 2004

What is the compelling reason to use static members at all?

Mr Jack
Tuesday, June 15, 2004

"Anyway, the reason it's preferable not to do this is because it looks like something that it's not."

Well I think it's a little more than that.  With that calling syntax, it makes it very easy for someone unscrupulous to "globalize" methods by adding the static modifier.  eg, if I have:

class Foo
{
  void method( );
};

Foo a;
a.method( );

Then I can retroactively make method( ) static (essentially, global) just by tacking the static modifier onto the declaration of Foo::method.  That would then affect all such calls to method on Foo throughout the codebase.

If the language prevented this, then I'd be forced to think about and plan for static methods, by being required to use the correct, instanceless calling syntax.

I suppose you can't really keep unscrupulous people from doing dumb things 100% of the time, but having one more safeguard against breaking encapsulation/interface definitions is nice.

java_se
Tuesday, June 15, 2004

Question (this thread, IMO, is really about characterless young idiots giving interviews who should have their asses kicked):

In C++, the static keyword CAN be applied carelessly to any member function, but the ultimate safeguard against broken code resulting from this is the fact that a static function can't directly access member variables (because there is no 'this') nor can it access non static member functions.

IE, if you slap 'static' onto a member function that should not  be static because it accesses a member of object's own instance, which does not exist in the static case, the compiler will flag an error (basically, an unknown variable.)

So, what exactly is so different here and why is the erroneous static declaration in Java a problem?

This just seems like another instance of programmers vehemently discussing something that really doesn't matter, unless I am not seeing something fundamental.

Bored Bystander
Tuesday, June 15, 2004

"This just seems like another instance of programmers vehemently discussing something that really doesn't matter."

That's really why I'm ranting. It really isn't that big of a deal whether I'm right or he's right. And it isn't really a question of why the question was part of the interview, because he asked me to tell him how to call instance and static methods, which is a rather basic way to discover if I can spell the word "Java."

I was ranting over the fact that this nit semed to be important to him. I have no problem working for someone who doesn't read every last line of the language spec. I guess I would have preferred his response to be "I think one of the things you listed dosn't compile, but it's no problem because Eclipse would catch it when you typed it in, so no biggie."

post scriptum: I received an offer today from another organization, one that gave me a written C++ test with questions that seemed to be deliberately set up to trap Java programmers. Although my last C++ programming experience was three years ago, I was told I got every answer correct. Weird contrast to this interview: I'm programming in Java every day!

Tyrannosaurus Rant
Tuesday, June 15, 2004

So, "Ty": what is different between C++'s way of handling a static declarator and Java's? I am just curious. (All other considerations of interviewer social immaturity a given.)

Bored Bystander
Tuesday, June 15, 2004

In light of what you learned from the first interviewing experience you described, why would you ever consider working for another company which is deliberately trying to trip you up with nit-picking language-lawyer questions?  No red lights a'flashing? 

anon
Tuesday, June 15, 2004

"This just seems like another instance of programmers vehemently discussing something that really doesn't matter, unless I am not seeing something fundamental."

No one around here seems all that vehement.  But maybe you're talking about the interview guys, in which case I agree that it's stupid to screen people by asking them to have memorized things they could look up in the documentation in thirty seconds.

Kyralessa
Tuesday, June 15, 2004

"In light of what you learned from the first interviewing experience you described, why would you ever consider working for another company which is deliberately trying to trip you up with nit-picking language-lawyer questions?  No red lights a'flashing?"

Of course, it's difficult to obtain the interview questions before they ask them :-)

In the case in question, everything started with a luncheon hosted by the President and Director of Software Development. Then there were some phone calls discussing the company and where my career was headed. Then I was asked to come in and "meet the team." That afternoon turned out to be three or four interviews, one of which was over all-you-can-eat ribs.

Just before I was leaving the Director poked his head in the door and told me they have a standard written questionaire for all developers. It had ten questions, one per page. I think they normally start with that questionaire but since I had come in "from the top down" they missed the usual filtering.

So all-in-all, of the six to eight hours I spent in the process, perhaps twenty minutes was spent with the language lawyering.

As for the questions, I think these were not language nits. For example, one concerned the fact that passing an argument by value invokes a copy constructor, which has implications for side effects and virtual functions.

I think anyone who has used C++ professionally and/or has read "Effective C++" would get the questions right, unless they failed to notice something like the fact that an ampersand was mssing on an argument.

Tyrannosaurus Rant
Tuesday, June 15, 2004

*  Recent Topics

*  Fog Creek Home