Programmers: technical interview questions

Those are pretty straightforward questions. I agree that any competent programmers can solve them in their sleep. Sadly, I also agree that many (or most?) people will have trouble with them.

For #1, some people probably forget to stop swapping once they have reached the halfway point. Instead, they just march through the entire array, swapping every element twice.

For #2, I’m guessing the “trick” is that you need to make two passes at every level. You need to print out everything first before making a second pass to recurse into the directories. The output is going to be a real mess otherwise.

Right for #1. For #2, I don’t care about the order (although that is a valid concern, for real-world applications, which mine is not). It’s actually that hasChildren is most likely unnecessary, as getChildren() will just return an empty array. Also, I never said you were allowed to use a print method. :wink:

Ignore this post… it’s been obsoleted

For that matter, isDirectory() is unnecessary – getChildren() will suffice. Unless you need to display directories differently than files.

You should have left it in; it was a good example solution.

I don’t know, but my guess is, after a while, the garbage collector isn’t able to pointer-chase to sufficient depth (stack overflow in its recursion?) and comes crashing down before the exception gets a chance to be thrown?

Alright, I’ll paste it back.

(Of course, the point is that it’s straightforward and pedestrian; I had only written it to ask what the “trick” was that I was missing, that apparently being “Who said there was a print function?”, a problem I admit I failed to take into account. :))

Anyway, the [pseudo]code I had posted was:



void printFile(String path)
{
  print("File: "); print(path); print("
");
}

void printDirectory(String path)
{
  print("Directory: "); print(path); print("
");
  print("With contents:
");
  for each s in getChildren(path)
  {
    if(isDirectory(s))
      printDirectory(s);
    else
      printFile(s);
  }
  print("Done listing contents of: "); print(path); print("
");
}


I suppose I should retract that question in the OP, as this is what I assumed the answer was and apparently it’s wrong after reading more. I assumed that the CLR implemented a different garbage collection algorithm and that’s why the same code in C# doesn’t cause the GC to crash, but they’re both using mark-and-sweep. However, it also seems that attempting to crash the JVM GC with linked lists and objects, instead of arrays, doesn’t seem to work (i.e. it correctly throws an OutOfMemory exception), and so it appears the problem is somewhere in the Java implementation of arrays.

So consider the question withdrawn.

As someone who does a fair bit of interviewing I feel compelled to ask - do people really bother with crap like this as interview questions? And why, what attributes are they looking for, syntax memorization?

I wouldn’t ask anyone my Oracle executable question from above—it’s the kind of thing that only one who has been bitten by it would know about.

I would, however, feel quite justified in asking a Java developer about the double-checked locking problem I linked to earlier because it would spur on an interesting discussion that would reveal some things about the candidate. (Does s/he even know why one would try the double-check? Is s/he aware that it is unsafe? What is the best solution? Does s/he have an inkling of why it doesn’t work? Does s/he know exactly why it doesn’t work?).

Back to my Oracle client problem…

I just did a few tests and found that this defect was fixed by Oracle long ago, so it’s probably no longer a valid question.

So, here is the gist of what was happening in earlier versions of Oracle:

The OCI layer that was connecting to Oracle via SQL*Net was providing connection information over the wire in a manner that looks similar to a TNS Names entry (very LISP-like in appearance)


IDENTIFIER =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP) (HOST = userid.myhosteddb.net)(PORT = 1521))
    )
    (CONNECT_DATA = (SID = odb))
  )

It turned out that Oracle passed information about the client machine and OS process over the wire, including the name of the executable file that was launched. That’s one way the Oracle DB has of knowing which client app you connected with.

Unfortunately, they did not escape parens when they put the filename in the string, so the embedded parens screwed up the server’s parsing of the connection info.

Ah, yeah, good test. I did think it would be pretty insane if the JVM would crash once sufficiently long linked lists existed… Still, it’s possible that it is some kind of stack overflow issue with the GC, just a fiddly one that’s highly sensitive to various details, which happen to magically change between the array code you tested and the linked list code you tested. And if not, I’m back to having no idea.

(For example (and this is just a shot in the dark; I’m not familiar with any of the relevant details), perhaps the linked list nodes take up more heap space per each round of adding “depth” than the array nodes, so that the OutOfMemory exception gets triggered sooner, before the GC stack can and otherwise would overflow)

For the most part, yeah, these are pretty bad interview questions, unless your goal is to find smug hackers who write tricksy unmaintainable code. QuercusMax’s seem OK for entry-level programmers, just to establish they can write some pseudo-code and, in the case of the first question, dodge some braindead blunders.

You’d be surprised at some of the candidates who aren’t entry-level programmers (according to their resume, at least) who can’t answer these questions. We had several interviewees this year with Master’s degrees from a state university here and several years of experience (in India) who completely and utterly bombed them. To the extent that at least one of them had no idea what recursion was.