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.
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 ¯\_(ツ)_/¯
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.
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.
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.