[scishop]

On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article.

  function isPalindrome(str) {
    return (str.split("").reverse()).join("") == str;
  }

[verroq]

I'd expect to see this (assuming that this guy is a Javascript shop).

    function isPalindrome(str) {
        for (let i = 0; i < str.length / 2; i++) {
            if (str[i] !== str[str.length - i - 1]) {
                return false;
            }
        }

        return true;
    }

Quick check list:

1. Knows about es6

2. Knows about === and !==

3. O(n) efficiency with no memory bloat

4. Didn't write 30+ lines on a trivial function

I won't even add a comment about unicode since it should be your default assumption when working with javascript that multi-byte characters and surrogate pairs don't work properly.

[jameshart]

5. Didn't meet the specification.

You need to ignore white space and punctuation.

6. Didn't include any tests

7. Bonus! This function also returns true if you pass it a palindromic array! Er... Maybe it shouldn't do that.

[verroq]

I realise you are nitpicking. But when you ask a normal person who knows how to code to write a palindrome function, then this is what you will get.

This function is too simple to expect anyone to ask you any follow up question regarding the "spec" unless they are trying to game the interview.

Also note that the duct typing properties of JS are often used to allow such string/array ambiguities.

[jameshart]

So in an interview, I would probably try to guide the interviewee to explore some of these things. "Okay, that's a good first pass. Have you taken a look at all the example cases we started with, will your code handle all of those correctly? Can you think of any other input for this function that might return surprising results? Is there a way we can verify that we've covered all these edge cases? Oh, and what was that you said about unicode support? Can we just dig into that a little..."

Seems like we could find out plenty about how a candidate thinks and codes by pursuing this line of questioning. So long as the candidate doesn't respond to these questions by saying "Look, this is stupid, I'm not going to dig into requirements, that seems like I'd be trying to game the interview. This is my final answer - it tests palindromes. Next question.".

[mplewis]

As an interviewee, you need to be asking these kinds of questions.

• Will this function get only strings, or other stuff too?

• Do punctuation and capitalization count?

• Are there any special cases I should worry about?

[MustardTiger]

That is not nitpicking, it is the entire point of the exercise. Writing the wrong code is not helpful. The article is very clear how meeting the spec is the most important thing.

[paulddraper]

Or even more clearly

  def is_palindrome(str):
      return str == str[::-1]

[eru]

According to the authors spec, you have to filter out spaces, normalize capitalisation etc.

So your solutions works after a preprocessing step.

[paulddraper]

Correct, I wrote this based on the parent's desired answer.

[rhizome]

I'm a big fan of knowing the standard libs, so my thoughts on that are summed up by, "the people who wrote the language are much better programmers than I am." I'd probably get dinged for lack of confidence.

[gtycomb]

To start conversation in OCaml,

let is_palindrome str = str = String.rev str ;;

(function is_palindrome will return true or false for input str )