Hacker News Reader

Comment by CodeMage | Hacker News Reader

> But I've had candidates that try to make up language features, and that doesn't fly with me.

This piqued my curiosity. Can you give an example?

I'm still floored by how many candidates I've talked to that assert with great confidence that the local variables they declare will still be there with the same values when they call the function recursively.

And most recently, when iterating over a string's characters the underlying string methods KNOW that the string is being iterated and will pick up at the current iteration point. For example, you've got the string "5432112345". And via iteration, you're currently pointing at the first "2" at index 3. The candidate asserted that if you call "indexOf('2')", it would return 6 because "indexOf" knows that it is iterating and should start 1 beyond where it is pointing at.

And my favorite - once had a candidate that misspelled a function name while coding in Ruby. I didn't ding them for it. But I pointed it out because it just bugged me. And the candidate then swore to me that Ruby will automatically call the correct method if there was only 1 candidate based on the misspelling. You know when you do things like "git inti" and it says "did you mean init?". The candidate swore that Ruby would just call "init" for you because it knew what you wanted.

https://github.com/yuki24/did_you_mean#installation :

    Ruby 2.3 and later ships with this gem and it will automatically be required when a Ruby process starts up. No special setup is required.

It doesn't call the method for you, but it does do the did-you-mean automatically if you misspell and it's close enough.

Maybe this what they meant? I dunno. I can see this being helpful in irb/pry.

In the end, we did end up making an offer to this candidate. They did well on everything we asked them. This was the only "brain fart" they had.

I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten().

I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.

I thought you were allowed to assume functions you needed in the interest of a modular solution. Array.flatten is an obvious “assume I have this, I would write it anyways.”

I think most decent interviews will give you a pass on an enhanced standard library.

When doing an interview at Google in C, I asked if I could assume I had a hashtable implementation with so-and-so interface, and the interviewer said no ¯\_(ツ)_/¯

This depends on the question but I assume that in this case the interviewer wanted a different solution than one using a hash table.

Ouch. Well, most hashtables in C are custom, I guess.

If you can explain what it is supposed to do, I don't care a whit if you make up a method that probably exists in a standard library somewhere (Guava / Apache Commons, or wherever). If it's slightly more obscure, you might have to write pseudocode to show you know how it might be implemented.

This one candidate had been allowed to skip the phone screen, and phone screens would likely have filtered them out. Candidate used Java and claimed to be deeply familiar with it. Obviously this isn't exact, but the result looked something like this:

    public isTheFooBarred(class Node { int[][] positions, int size } node, int x, int y, Set visited = new HashSet(node.size)) {
      // ...
    }

The first parameter to the method had an inlined class definition, and the last parameter was optional. We discussed this and the candidate claimed that this was legal vanilla Java. In the case of the last parameter, the candidate claimed that the compiler generated every possible combination of methods including and excluding each of the optional parameters (so, 2^n methods).

I really tried to give the candidate the benefit of the doubt, and asked if there was some sort of annotation processor or code pre-processor that they were using, but they were adamant that it was plain old vanilla Java. I'm pretty sure that they were using some in-house built thing, but their solution had significant problems, so it wasn't the only reason I was against the hire.

I've had people interview for a Java job who didn't realise strings were immutable.

The question asked was a very short multiple choice; only two of the answers were possible under immutability.

That doesn't sound like a good question at. It sounds like you're looking for "Java programmers" instead of solid engineers.

When I interviewed for my current job using Java, I had been programming in Ruby and JS for the better part of a decade and had to refresh my Java syntax fairly quickly. I know I made some dumb syntax mistakes in my phone interview, like instantiating collections totally incorrectly. I distinctly remember one of my in-person interviewers saying "well, in Java it's boolean, not bool, but sure...". More semantically, I may very well have messed up mutability of collections and primitive conversions and boxing and such.

Enough of my interviewers saw through all of this that I got the job. Now people on my team come to me and say, "hey you're a java guy right?" and ask me questions about this stuff. I wasn't a java expert when I interviewed, but now I am, because that's what my job required, so I learned it. That's what my interviewers were looking for, to the company's benefit.

You're right that it is not disqualifying even if the Java expertise is essential for the job and the candidate describes themselves as a Java expert. This was a single short question among many though. And it's pretty fundamental to Java methinks.

BTW, they still got hired and proceeded to be a solid productivity reducer and all round waste of time.

Reply on news.ycombinator.com