Hacker News Reader

Comment by orless | Hacker News Reader

In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

To this day I'm very suspicious when I don't get a coding task on an interview. That's generally a pretty bad sign. Best option is when I get a notebook with "my" IDE, but I also coded on whiteboards, paper, Google Docs.

Frankly, I don't know what other options are there. There should be code in the developer interview. Take-home task? GitHub account? Probation day?

View on HN

> It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

This is the kind of bias that I think an interviewer should never have, and part of what makes interviews so stressful: that your ability is called into question off of something very simple. You don't know whether the candidate knows Java or not. You only know that the result of the interview is negative, which could say just as much about the interview as it does about the candidate. Assuming "you don't really know Java, do you?" with so little evidence strikes me as disrespectful at best. Why is this considered OK?

ashark makes a lot of very good points as to why someone may know Java but stumble with this question.

Exactly. So many of the proponents of the whiteboard algorithm question industry are thoroughly convinced that they are eliminating people who will fail on the job. Of course it's impossible to verify this. The only thing you can verify is the performance of candidates that do pass your test and you subsequently hire. I'm sure there are a lot of bad hires even at the companies where they use these interview techniques. The believers are clouded by survivorship bias and confirmation bias. They get no information from those that they reject and they refuse to acknowledge the bad people that they accept.

Didn't the guy who started WhatsApp fail his facebook interview? :-)

http://www.businessinsider.com/facebook-rejected-whatsapp-co...

Here is some debunking of other commonly held misconceptions about this interview strategy:

1) The questions are not tricks -- actually every coding algorithm question that has a "naive" solution and an optimized solution requires a trick. That's why you can study for these interviews. The studying involves memorizing the catalog of tricks and identifying which one to apply based on the question. Even the simplest and most commonly used tricks (using a hash table, multiple pointers into the same array / multiple accumulators, bit shifting) are still tricks.

2) The interviewers have a large catalog of these questions so you're not going to pass by memorizing stuff. As I mentioned in #1 above, this is false. The list of tricks that need to be employed to solve these puzzles is finite and definitely less than 100. Most common interviews will probably be solved by one of the top 10 tricks.

This page has 80 solutions: http://www.geeksforgeeks.org/top-10-algorithms-in-interview-...

3) This method may have too many false negatives (when they reject a candidate who would have been a good member of the team) but it eliminates false positives (when they hire a candidate who cannot code). With enough dedication and time, anybody can train to pass these. It's not really a skill that is super useful for getting things done in a programming job.

Some people are very good at riddles but have no common sense. They do not make good members of a software development team but they are very good at these interviews.

Tricks? Algorithms? Puzzles? Riddles?

Are we still talking about string reversal task?

You write "with so little evidence" without knowing what the evidence actually was.

> In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

I've written quite a bit of Java in the last year (though not in the last couple months), and a fair bit before that. I'd have a low probability of giving you a correct answer to that question without references—I have several possible approaches but I'm not 100% certain which would work without checking. Can I treat Java strings as arrays? Or is there some kind of toArray thing I need to do first? I think so but I'd have to check to be certain. Is there a string-reversing util method somewhere? Quite possibly. How do I read it one byte (glyph? Ugh, I can't remember how Java strings work and I have Go on the brain, I think) at a time if the treat-as-an-array thing doesn't work? God, I don't remember. What's string length again? size, length? Maybe even len? Assuming I figure that out, was that a property or a method, now? Hell if I know, it's not like I've written more than a dozen lines of Java outside an IDE, ever, unlike some other languages. I suppose I can use split if I have to (it's just called "split" in java, right? I can't remember for certain, of course!)

I'm sure some people memorize this stuff. Plenty of us, I'm sure, if it's not something we use ALL. THE. TIME. rely very heavily on tools, context (i.e. cheating for syntax by looking at surrounding lines) and documentation. I haven't been doing tons of specifically string manipulation in java lately, so I'd likely be screwed on this question.

I dunno, I guess by that standard I know zero of the 7-8 languages I've been paid to write over the last fifteen years or so.

I'm not saying it's a good task, I'm saying that people failed it despite we were thinking the task is trivial.

But still, I'd expect Java developer to know that Java strings are immutable and that you can't treat them as character arrays. It's totally OK to not know how toArray method is called (toCharArray). Assuming there's a kind of "reverse" method is a bad idea - even if there would have been one, it would clearly be not what we ask. Same for "I'd use StringUtils.reverse(...)" from whatever package. I won't mind if you write a.length() for array or a.length for String, this does not matter much. Knowing a difference between a byte and a char is, however, quite important in my book.

The "usual" solution is to str.toCharArray() and then iterate this array to the middle, swapping i-th and (length - i - 1)-th characters, then new String(array) with the result.

For this solution you only need to know fundamentals of the language and vaguely recall that there was some method to convert string to a character array.

Bonus points (figuratively speaking, there were no actual points) were for: writing test cases, checking the argument for not being null or showing how to swap two characters without using an additional variable.

Do you think IDE would help much? I don't think so. IDE would have helped you with the unimportant part (how was that toArray() method called exactly). But you'd need to know how to use a cycle to reverse an array. You need to know what the difference between a byte and a char is (in order not to choose the getBytes() method instead toCharArray()).

> Do you think IDE would help much? I don't think so.

It'd help quite a bit with the parts that make writing this in Java different from talking through a pseudocode implementation, yeah.

Or just let them write pseudocode instead, since you've written you don't care much about the details (aside from knowing you need to take care when manipulating strings that you're operating on the correct unit in order not to turn it into gibberish, which is a universal detail, not specific to Java). Bonus to that approach: you haven't just made your candidate incredibly self conscious over and distracted by things you apparently didn't care about to begin with, and there's also a lower chance they'll try to correctly use the language in ways you don't like and expected them to guess you don't like (e.g. using a single utility method that solves the problem immediately).

We've tried it with pseudocode. People wrote Java.

The IDE would make huge difference for me and this question. It would allow me to instantly know string api which I normally don't need. Also, it would add confidence that what I am doing is actually java.

I don't mind whiteboard in general, however expecting me to solve language specific question like this is weird - especially in language like java that is never written without IDE.

Well, yes, in an interview for a Java dev position I'd expect the candidate to be able to write code (whiteboard/paper) which at least remotely resembles Java syntax, is logically correct and does not break universal things like byte vs. char.

At the end of a day of interviews for a consulting gig a number of years ago I was asked to sit in front of a workstation and type while most of the developers were watching. I asked "Type what?" and got the answer "Anything." I started typing a paragraph from my resume and after one sentence the interviewer said "Stop, that's fine. The last guy who made it through the interview couldn't do that."

It turned out to be a fun project.

On one interview they asked me what my favorite pattern was. I said "visitor", was already about to start explaining but heard a deep breath-out and "thanks God he didn't say singleton". Appeared they had it pretty high in hiring criteria.

The string reverse question is a pretty poor one in my opinion, you'd be better off with FizzBuzz.

The smart arse answer to your question would be

new StringBuilder("my string").reverse().toString()

The question sticked as a tradition, everyone had it on the interview.

Noone ever gave the smart arse answer, by the way, but some people said "you're not looking for the library method, obviously".

Reply on news.ycombinator.com