4 ms·

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

by orless 10y ago

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?

patrickmay 10y ago
> 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?". 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.
- orless 10y ago
  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.
ashark 10y ago
> 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.
- orless 10y ago
  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()).
  - ashark 10y ago
    > 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).
projektir 10y ago
> 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.
- nissimk 10y ago
  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-founder-brian-acton-for-a-job-back-in-2009-2014-2 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-questions/ 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.
djhworld 10y ago
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()
- orless 10y ago
  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".

by orless 10y ago

patrickmay 10y ago

> 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?". 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.

orless 10y ago
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.

ashark 10y ago

> 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.

orless 10y ago
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()).
- ashark 10y ago
  > 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).

projektir 10y ago

> 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.

nissimk 10y ago
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-founder-brian-acton-for-a-job-back-in-2009-2014-2 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-questions/ 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.

djhworld 10y ago

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()

orless 10y ago
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".