How to win the coding interview

https://blog.devmastery.com/how-to-win-the-coding-interview-71ae7102d685#.dy3irg8ei

by billsparks • 10 years ago

312 296 10 years ago

blog.devmastery.com

kinkdr• 10 years ago

Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it.

I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.

desireco42• 10 years ago

Yep, spot on.

paulddraper3• 10 years ago

This should be obvious.

If my job is largely coding, I expect to demonstrate coding abilities.

If my job is largely bullshitting, I expect to demonstrate bullshitting abilities.

And so on.

sundvor3• 10 years ago

Very interesting article, thanks for writing! I have but one, eh, comment:

Your code should be commented

Sure.. but:

  > * @param {string} stringToTest - the string to test.

  >   // make sure we have a string.
  >    if (typeof stringToTest !== "string") {
  >

  > function isPalindrome(stringToTest) {
  >  ...
  >    // if we get here, it's a palindrome
  >    return true;

Do we really need to explain that stringToTest means string to test? I for one find such low level comments almost completely redundant. I prefer strong variable naming and other ways of creating clean code to littering the code with comments that the code expresses naturally.

Comments should IMHO be reserved for explaining special complexities, any particular gotchyas, etc.

danappelxx• 10 years ago

I agree. If a comment can be automatically generated by a computer (stringToTest -> 'the string to test' can be automatically generated), it should not be a comment at all.

billsparks2• 10 years ago

That particular comment (the @param) is for JSDOC. It's so that one can generate documentation for the code. http://usejsdoc.org/about-getting-started.html

sundvor3• 10 years ago

Ah, thanks for that.

I'm a Vic20 + Commodore 64 Basic -> Amiga Assembly -> ColdFusion -> C# dotNetCore person myself; mostly back end, but I'll check out JSDoc for when going down that path again next.

nulagrithom• 10 years ago

The comment is still optional. You don't have to give @param a description. @param stringToTest would suffice. http://usejsdoc.org/tags-param.html

deciplex• 10 years ago

I agree. Too many comments makes it hard to sort out which are the comments that actually provide insight to how the code works (or is supposed to) from the comments that are just bullshit the author put there so he could say he puts a lot of comments in his code.

fenomas• 10 years ago

Couldn't help but chuckle at this:

    'use strict'; // avoid ambiguity and sloppy errors

If the line that starts (or ought to start) virtually every JS file you ever write can't stand without explanation, one wonders what can!

twblalock2• 10 years ago

n++; // increment n

dclowd99012• 10 years ago

Right? I know developers who swear by comments and ones that swear by self describing code. You can't assume you're interviewing with one or the other.

EpicEng10• 10 years ago

And perhaps the interviewer should have been more explicit in their requirements. I have to admit I would never think to comment whiteboard code (and my production code would not contain comments like that).

meowface• 10 years ago

"// throw if we didn't get a string" before a throw statement two lines away from "make sure we have a string" would annoy the hell out of me in production code.

bobbles• 10 years ago

I can see a case for it if during the next 2 years of development more code is added between 'make sure' and 'throw...' because you do not want to want to worry about refactoring comments when code gets moved...

wp1• 10 years ago

In a whiteboard interview, comments can/should just be said out loud to the interviewer.

bhntr32• 10 years ago

I came here to make the same comment (pardon the pun.)

This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.

He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post.

Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion.

As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are.

Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen.

Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.

tamana2• 10 years ago

You might get have done better if you remembered the criterion correctly. Almost every data type used in computing is represented by non-fixed-length strings over a fixed alphabet (usually {0,1}).

Radix sort is O(n) in log(dictionary size) which is only a useful bound when the data set is larger than the dictionary (this is a severe but not fatal requirement. Some datasets have many duplicate values, and anyway in practice log(n) factors in real world systems are practically constant factors: an 1log(n) algorithm will be slower than a 100(1) algorithm.)

You can misstate a theorem, or forget the proof, OK, but doing both is poor form.

pc862• 10 years ago

Comments should explain the why of code, not the what or how.

From a technical standpoint you should read uncommented code and more often than not be able to tell exactly what it does (barring a lot of poorly named methods or similar architectural issues). Any comments should simply explain the business rules or decisions that led to that code. Maybe you are knowingly violating a best practice for your framework or language because following it would break business logic down the pipeline or something. This is the perfect time for a comment explaining that so a well-meaning junior developer doesn't refactor it six months from now.

alexandercrohde• 10 years ago

Perhaps better named "How to win my coding interview."

Author goes into the specifics he personally expects from an interview. Since he's not positing these as universal standards (and rightly not) I'm not sure if this is relevant to anybody other than the people who intend to interview at dev mastery.

bogomipz2• 10 years ago

Yeah and the whole thing is a loosely veiled attempt for him to generate subscribers to his email list. Not "winning."

parennoob• 10 years ago

Yes, I don't understand the suggestion for regexes as the correct and optimal way to detect palindromes. I hope this is not the expectation in general.

verroq3• 10 years ago

It is pretty ironic that palindromes cannot be recognised by regular languages.

iSnow5• 10 years ago

I don't understand the suggestion for regexes as the correct and optimal way to detect palindromes

That made me pause as well, but he actually doesn't say that. He says a "many will use RegEx as a part of the solution" - typically to strip whitespace and punctuation signs - something like /\W/.

dimino5• 10 years ago

I subscribed to this man's newsletter (literally) because while I realize the skills I can pick up from him aren't going to translate 1:1 to other interviews and jobs, this article resonated with me and what I already know about software strongly enough that I can probably at least get to like 1:.95 or something in that ballpark.

logfromblammo4• 10 years ago

If there is one thing that could possibly make tech recruiting even worse, it is this: "Did you review the study guide for our interviewing process?"

The problem is not that the job candidates are not sufficiently informed about the way specific employers conduct interviews. The problem is that employers have expectations regarding the tech jobs market that start at merely unrealistic and progress beyond a complete schizophrenic break with two extra hits of LSD.

We are not re-inventing the tech interview. We are, in the style of Thomas Edison searching for a better incandescent filament, discovering 10000 ways that are worse than the existing standard.

chrismorgan• 10 years ago

The best developers know that, fundamentally, every bug is the result of an invalid assumption.

I assumed that I could type without makig mistakes.

Swizec• 10 years ago

Is there even room on a whiteboard to write comments and tests? Often there's barely even room to write readable code ...

If you're writing in a shared text editor then sure.

And isn't all the talking you do already commemts enough?

Edit: I'm bad at reading comprehension on a mobile screen. The tests and comments bit is in a different section.

billsparks2• 10 years ago

I don't think the part about tests and comments is meant to apply to the whiteboard coding. It's in the section about coding on a computer.

ci5er• 10 years ago

Comments and tests? Are you serious?

I am told that the unit-test kool-aid has taken over the universe of common sense, and I respond: "surely not", and then this...

My position w/ something like Fizzbuzz to any level of developer wouldn't require much in the way of either comments or tests (or, if embedded in a larger system, bugs would be flushed out quickly)

Do you disagree?

cf• 10 years ago

That's why you need to bring some of those thin Japanese whiteboard markers.

http://www.jetpens.com/Zebra-Mackee-Wet-Erase-Double-Sided-M...

soham• 10 years ago

[Disclaimer: I run http://InterviewKickstart.com. It's a hyper-focused bootcamp on coding interview prep]

Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date.

The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't get into a long-term relationship (date) if you don't confirm to the (technical and social) beliefs (and biases) of your interviewer (date). The reverse is also true viz. no matter how mediocre you are, you'll get in, if you do.

So, do everything what the author says, but you'll progress faster if you keep your mindset grounded. See this: https://www.youtube.com/watch?v=v1WiCGq-PcY

p4wnc68• 10 years ago

Are you suggesting that interviewers should try harder to conform to social beliefs of a company -- as a valid interview strategy?

I'd instead suggest that it should never get to the point of an in-person interview unless both parties have already applied the necessary culture filters. Sure, you could get surprised at the on-site and then change your mind, but you're just wasting a ton of your own time if you either don't properly vet the important culture properties aheadof time, or else sublimate away your own culture standards because you believe you have to appear conformist in order to get the job.

A good example would be open-plan offices. I have many friends in tech who deeply loathe the cognitive damage done to them by their employers forcing them to work in open-plan seating conditions. Yet they also are too afraid to either speak up or to reject employers who use open-plan seating, thus perpetuating open-plan dogma.

My perspective is that if an employer feels I'm worth the investment to bring to the team, they must feel that trivial other things to accommodate what helps me work best are also worthwhile. If, instead, a company would reject me based on "culture fit" for these side issue accommodations, or would refuse to grant them and try to pressure me to work without them, then in either case I'm dodging a massive bullet by either rejecting them or letting them reject me.

But one thing I should absolutely never do is to compromise on those issues (e.g. "no matter how good you are, you won't get into a long-term relationship ... if you don't conform"). If my goodness isn't enticing enough for them to not just make the offer but also think hard about what it would take for me to be happy with them and make it happen, then I'm simply better off staying away from them.

As it happens, a lot of companies don't really care about the goodness of their employees. They just want warm bodies who will conform to the company line. I understand that represents most jobs.

I'd like the future to be a world where that doesn't represent most jobs, so I boycott all such jobs, even if it means my search space is drastically reduced as a result.

It's just too cognitively unhealthy to human minds otherwise.

dimino5• 10 years ago

The answer that employers are thinking is you shouldn't try to get any particular job, but try to find the job that fits you best.

At least in startups (The focus of this site), all the hiring advice is focused around finding folks who are passionate about your problem.

spyspy• 10 years ago

The hyper- prefix has become the new cyber-.

scishop• 10 years ago

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;
  }

paulddraper3• 10 years ago

Or even more clearly

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

eru• 10 years ago

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

So your solutions works after a preprocessing step.

rhizome• 10 years ago

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.

verroq3• 10 years ago

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.

jameshart2• 10 years ago

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.

gtycomb• 10 years ago

To start conversation in OCaml,

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

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

revetkn2• 10 years ago

1. "On this particular challenge, I am expecting many will use RegEx as a part of the solution"

Really?

2. "replace(/[^a-z0–9]/ig, '');"

If I were interviewing and a candidate did this I would ask if he/she knows what i18n is

swang2• 10 years ago

one of his questions is, "does this need to support utf-8" and i'm assuming in his hypothetical interview it is, "no it does not"

also are you seriously going to quiz someone about i18n for a interview? does that really tell whether they are a hire/no hire?

germanier• 10 years ago

Given how many sites fail as soon as I start entering an "ä" in the name field (even on websites marketed internationally) I'd prefer if people would. At least the very basics or else you get a bunch of people that won't think about those issues when developing.

arethuza2• 10 years ago

"also are you seriously going to quiz someone about i18n for a interview?"

Absolutely - in fact asking whether that regex was a good way of matching all characters in an input might be a good interview question.

revetkn2• 10 years ago

IMO in 2016 it is important to know the basics well enough to know if what you're doing is bad from an i18n perspective (at least for non-junior positions). Even a comment like "// TODO: localize" is OK

It is often a positive signal that a candidate has worked on software large enough to be used internationally or is thorough enough to worry about it. For most of us, day-to-day software work is about being thorough and careful with design and implementation, not heavy algorithmic lifting

p4wnc68• 10 years ago

The author says,

When you get the job you will never have to code on a whiteboard, but I guarantee you this, there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast.

and then proceeds to describe still giving you coding challenges on a whiteboard. I kept reading, but bookmarked this spot as the location at which the author lost credibility, and the rest of the article confirmed it.

If you want to test how well someone can collaborate with you (after all, that is what is described in the needless trumped up intro to the whiteboard sections -- just simple collaboration as happens everywhere in every job and is in no way unique to programming), then ask them problems that are suitable for a whiteboard discussion.

It's not the whiteboard itself that is the problem. It's the combination of a task that is intrinsically ill-suited to be done on a whiteboard and the requirement to do it on a whiteboard. It's like asking a football player to audition for you by playing football with hockey equipment on.

There are lots of good questions to talk about on a whiteboard. Sketching out graphs is a good activity. For example you might ask someone how life expectancy varies with age and ask them to draw some pictures. Now you can see what it's like to work with them, get the assumptions out in the open, etc. You can't actually do that if they are preoccupied with syntactical correctness -- and if you tell them to program in pseudo code then you'd better be happy with a psuedo answer that sweeps some parts of the solution under the rug or assumes that some minutiae details would be otherwise fleshed out later on and are not required to be literally correct in the whiteboard case.

Coding questions are just poor questions to ask for whiteboard sessions. That "we're all up against the deadline, cramming into the conference room trying to work shit out on the whiteboard at the last minute" situation is practically the last place on earth where minutiae syntactical correctness on the whiteboard matters.

The author is defending general whiteboard discussions but then saying that coding exercises, which are not at all like general whiteboard discussions, are appropriate for whiteboard interviews.

The section about coding at a computer is also frustrating. The author places a huge emphasis on asking questions, but it basically amounts to a sort of "guess the teacher's password" problem. The author has "good questions" in mind, that are secret and hidden from the candidate, and will secretly penalize you if you don't ask "good questions." Personally, I would see the server side / client side Javascript question as a waste of time and really immaterial to the given programming task (palindrome detection). Even asking "is the empty string valid?" is a waste of time. Honestly, in an interview I don't care which assumption you make about that as long as you tell me that you're making it.

But worst of all is the Cerberus red flag statement "write this code as if it was going into production." I can tell you that as a candidate, I would still be polite and try my hardest to work out the interview question, but I would have already rejected this company full stop. When you write code for production, it is a team effort and your interactions with the team, the business, the product all matter. A person who is injected into a foreign social situation, under lots of stress and pressure to put their best foot forward, etc., and also knows nothing about what you consider to be 'production' code is in no position to write 'production' code for you on some Mickey Mouse palindrome problem (literally a problem culled from the absolutely dystopia-level full of shit book 'Cracking the Coding Interview' -- meaning it is as not-productiony a problem as you can possibly select, akin to asking for a production-grade FizzBuzz solution).

This tells me that the interviewer has an extremely narrow and short-sighted view of 'production' code. They think it is something that can happen in a vacuum as long as you have a computer and a textbook problem to solve. They are not self-aware enough to understand that they come in with preconceived cultural notions of what 'production' means, and that realistically this is not at all a test of "coding to spec" or someone's coding talent, it's just yet another status game testing whether or not the person randomly conforms to whatever magic culture expectations they are being covertly judged against.

yanilkr• 10 years ago

Lot of people made tiny fortunes writing "How to interview" kind of self help books and blogs, just like this article they want people to believe that there is a formula to this madness and for a price you can know it. Smart people should realize that there are no shortcuts. You can't fill the void by pouring money and time into these products. The only way is to face the rejection and keep on focusing on the skill, solve real world problems, write code, learn to express ideas better, take internships.

One has to be good at programming, analytical skills, problem solving and communicating ideas. And after that a little research on how a company interviews should help. Even if someone reads all these books and cracks the interview, its very difficult to hold on to job with out the required skills.

Retra• 10 years ago

This article is useless to most people, most of the time. At the very best, the take-away is "know how to solve simple programming problems and have coding standards."

techman9• 10 years ago

I'd hardly call Gayle's fortune tiny ;)

swang2• 10 years ago

I'm not actually testing how well you write code on a whiteboard. I’m looking for something else.

unfortunately not true with interviewers at other companies. they are definitely looking for the correct answer. if you can't "get" a problem, you are not getting an offer.

FigmentEngine• 10 years ago

"Is this client side or server side JavaScript?"

kill me now. are you testing for insight or implementation correctness?

a whiteboard is a place to draw a diagram, not code. see how they visualize and reason about strings would be better

jtchang• 10 years ago

Am I the only one that is has been coding for years and don't expect people to know regex off the top of their head?

There are so many variants and keeping them straight between languages is a nightmare. Grep, egrep, POSIX, perl, python, php, javascript. They all have their idiosyncracies.

dimino5• 10 years ago

I feel that regex is kind of like SQL -- it's universal enough that knowing the major tropes is important for general software development.

hvidgaard11• 10 years ago

Problem is that every framework have their own dialect of it, and many of them are not even regular expression, but something beyond that.

rahulr• 10 years ago

True. And perhaps more importantly, for many cases regex is a very small part of job, if at all. I would rather test someone how they would refactor a method or a class. Something which is much more likely to happen in a real world situation (as compared to regex).

NhanH2• 10 years ago

I'm not actually testing how well you write code on a whiteboard. I’m looking for something else

Even if you believe so, it's more likely than not you're not actually doing that. You WILL judge how well someone write code on a whiteboard. I've done that too, and it's surprisingly easy not to notice. You can't stop yourself from judging, maybe you can realize that your snap judgement mean jackshit and don't make decision based on that.

While I don’t need a developer who can write code on a whiteboard, I do need a developer who can think on her feet, under pressure, in a room with others.

As someone who can't figure out if (9+1 === 10) is true or not under interview (true story, my mind just blanked out), I'd really love to have company who want "developer who think on her feet, under pressure" to put it on your job advertisement so we don't both waste our time.

iSnow5• 10 years ago

As someone who can't figure out if (9+1 === 10) is true or not under interview

As someone who has probably the same problem, any ideas how to land a better job? Those typically involve a lot of coding while someone breathes down your neck.

NhanH2• 10 years ago

I told my friends that they better get to VP or equivalent decision maker quick so I don't have to deal with stupid interview anymore.

Joke asides, unfortunately I don't have a solution here, I gave up on interview in general. Personally, if I was looking for a corporate job, I'd write "interview is stupid" in front of my workspace and play the number games until one day I might pass one. Otherwise I'd look for smaller orgs and tell the decision maker I have interview-phobia, can we do something else?

TillE2• 10 years ago

At the very least, you can always talk through your thought process. "I can't remember if the order of operations is..."

krisdol• 10 years ago

Last time I made interview rounds, about 50% of places gave whiteboard questions, 25% gave essentially the same questions but had me do them on a computer or screenshare rather than a whiteboard, and the rest had some kind of take home component that was usually larger than the whiteboard question but also more practical and relevant to my skill set. Obviously I prefer the last option, but even if you prefer to give whiteboard-style questions, why not at the very least allow them to complete it on their laptop in front of you if they so choose?

It seems incredibly arrogant to me that interviewers assume there is only one way to solve a problem, and that is by brainstorming on a whiteboard first. I don't feel comfortable standing up in front of the class to present a solution. I feel far, far, far less comfortable if it's a coding-related solution. I did significantly better, like pretty much 100% success rate on coding components when I could hit keys rather than display my chicken scratches on a whiteboard.| I move code around a lot as I prototype and it takes quite a bit of training for me to adjust to not having the option of restructuring as I code because the medium is a whiteboard or piece of paper. And every time I erase something my level of anxiety and nervousness just grows.

edocecrous• 10 years ago

Why regexes combined with the pre-processing?

First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer.

If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation.

And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.

I'm having trouble imagining the typical data set where this would be an efficient implementation and where there even exist non-ridiculous inefficient implementations.

Second, doesn't using regexes kind of defeat the whole point of the Palindrome exercise from an evaluation perspective? If someone asked if me if they could use regexes in a coding interview for this question my response would be "good instinct. If you have no other way then go for it. But I was really hoping to see you work through implementing/debugging/commenting/testing an implementation without regexes."

p4wnc68• 10 years ago

Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either storing the sorted string in new memory or else saving the inverse sort to unsort at the end (if the sort is in-place), I wouldn't care. In an interview setting, if they could identify those weaknesses, that's good enough. It's clever and shows attention to detail and good critical thinking for someone to come up with the sort-and-count solution. An interview is not the time nor place to be grilling someone about whether an nlogn solution is really optimal. That's just wasted time.

The fact that the post's author offered regexes as a solution is a bit frightening. In many languages, such as with Python's built-in re module, this is literally impossible, because the regular expression engine is literally confined to check for regular grammars, and you can show that no finite state automaton is adequate for expressing all palindromes (basically because they can't remember an arbitrary number of characters from the start of the string to use at the end).

Of course, lots of languages have regular expression engines that are more powerful than this, but it's a sham for an interview question to rely on that. It doesn't read to me like the post's author actually considered the theory of computation aspect of this, and instead just glibly and naively rattled off that regular expressions should work well.

This is the person judging the candidates on whether they are talented enough at computer science? Yikes.

jaredsohn• 10 years ago

If you use a bucket sort, your time complexity could be O(max(n,k)) and space O(k) where k is the size of the character set and n is the length of the string. Depending on the relationship between n and k, this could be faster than n log n. (But the pointers solution or even comparing against a reversed string seems better for both time and space.)

Also, your solution is poor since it only tells you that a string is _not_ a palindrome in certain cases but cannot tell with certainty that a string is a palindrome. For example, 'aabb' will pass your test but is not a palindrome.

garrettgrimsley• 10 years ago

I'd also be impressed if they came up with the idea of sorting the string and counting characters

While that method would identify if a string has the necessary attributes of a palindromic string it is not sufficient to prove that a string is a palindrome.

This is the person judging the candidates on whether they are talented enough at computer science? Yikes.

Right, anyone reading the OP would probably be better served by Steve Yegge's posts[0, 1] on the subject.

[0] https://sites.google.com/site/steveyegge2/five-essential-pho...

[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

Edit: Went back and actually read the code provided, they only use regex for a preprocessing step.

xenadu02• 10 years ago

It's because there is no standard way to determine the properties of a unicode grapheme cluster in JavaScript. Otherwise you could do things like isDigit(), isNumeric(), isPunctuation(), isWhitespace(), etc. Or just ask directly isLetter().

A Grapheme cluster basically corresponds to what a human would consider a "single letter", including any combining marks, etc.

gimpster2• 10 years ago

And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.

You're hired! :D

kayman2• 10 years ago

I'm tired of companies asking me to code at their interviews.

I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value.

Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value.

At the end of the week, you pay me wages and if you're not happy, you can not extend another week.

Isn't this a much better way to evaluate a good candidate?

jimbokun• 10 years ago

Sure, but some developers with a job already might prefer the interview.

krisgenre• 10 years ago

This is the perfect and ideal process but unfortunately hard to scale.

andersonmvd• 10 years ago

Regarding scaling: should we really hire developers as we scale servers? I don't think so.

EpicEng10• 10 years ago

Forget scale; I don't think it's practical for even one candidate.

amorphid2• 10 years ago

Some reasons against a 1 week working interview:

* It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access.

* Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment.

* You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week.

* Many places can't/won't put you to work without you passing a background check.

* Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.

dimino5• 10 years ago

You make a good point, but if I'm getting to pick my ideal work environment though, it's one where I can get ramped up and contributing meaningfully in a week.

jacalata• 10 years ago

Pivotal Labs definitely doesn't require a 3 week contract before hiring, and it never even came up as a theoretical option when I interviewed with them and got an offer last year.

redcap• 10 years ago

What I've seen suggested elsewhere is having publicly viewable code on github or the like - that would effectively be your coding resume and evidence of your ability.

andyjdavis• 10 years ago

True but it is not that hard for someone to fake that if they really want to. That said, faking history in github likely takes enough technical ability that the person could probably do a decent job programming if they use their powers for good.

richforrester2• 10 years ago

Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by seeing you do some work on a whiteboard, and make some cuts right then and there.

In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.

enraged_camel2• 10 years ago

You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maximize the chances of hiring really good people, right? The latter will pay for themselves tenfold.

nilkn• 10 years ago

Out of curiosity, am I supposed to take an entire week of PTO in order to undergo such an interview process while currently employed? Because I can't really think of a single company I'd be willing to do that for.

modeless• 10 years ago

That's great of you to offer as a candidate. However, from the interviewer's side, I can't ask candidates to do this. The people I want to hire are already busy. They don't have a whole week to devote to my interview process. Not even if I pay them for it.

EpicEng10• 10 years ago

Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value.

Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. Oh, and did I find you through a recruiter? Now I have to pay them a cut. Do I now get to run this little bureaucratic maze for all N candidates I'm looking at? You have become a very expensive interview across at least three departments and you're probably not worth it.

Sorry, but no. I do ask for some whiteboard coding, but it can be done in any language (or pseudo code) and I'm really only trying to tease out your thought process. For a junior or mid level position, yes; I am also trying to figure out if you can write a line of code. I'm also not sure how you're going to be able to get away from your current job for an entire week (I have literally never interviewed a candidate who wasn't fresh out of college who was unemployed at the time).

I agree that it can be a pain, but there aren't always better ways to measure your ability to take a problem and turn the solution into an algorithm.

chief1ic• 10 years ago

The fact that you need to involve three different departments just to hire someone for a week is a key part of why hiring is so broken these days.

ma2rten• 10 years ago

I think kayman talking about interviewing to work as an independent contractor because he said: "I have cultivated my own clients, ...".

BurningFrog2• 10 years ago

I did a 2 week stint like this for a small company once, and the setup took maybe 10 minutes.

In a bigger organization it's probably more involved, but if you set out to make it a standard way you interview some developers, I think it's perfectly doable.

I agree that improvising it when a developer asks for it, which is what I think you're describing, would be harder.

LnxPrgr32• 10 years ago

I for one actually appreciate coding interviews. Besides, I know my resume isn't a bunch of stuff I made up yesterday, but how are you supposed to know that? I do wish most were done differently though.

A few months ago, I interviewed with a company--the first rounds were remote, and we used an online tool so the interviewer could watch me work problems in an environment with a "compile and run" button, which was great!

Imagine my disappointment, then, when I got to the in-person interview, sat down in a nice conference room with a computer attached to a giant TV and a wireless keyboard, and was handed a pencil and a pad of paper on which to code.

That's clearly something I need more practice with--but why? It's yet another thing I have to be good at to get work, that doesn't make me better at doing the work I get.

voidr• 10 years ago

I'm a contractor with a decade's worth of experience, I automatically turn down places that ask me to do implement a linked list on a whiteboard, I do appreciate tests where I get an IDE and have to solve a simple problem, because after a certain level it's mainly about how you solve problems and how well you can explain what you are doing.

hiou2• 10 years ago

Just so you know, in the past I used to actually bother to jump through the hoops like a trained circus performer for the apparent gift of employment from some place that actually needed me a lot more than I needed them. Then I would get all the way to the end of the interview and then tell them I would never take the position because of it. I used to hope this might stop the silliness.

Then I just stopped taking interviews with that nonsense altogether and found places to work that I actually wanted to be and that, more importantly, had mutual respect for one another as opposed to being treated like someone who was supposed to be grateful for working at some run of the mill office job. One where we were all supposed to pretend we were given some great gift of fixing someones crappy log file code that broke production. Or adding some api endpoints for a new model.

These jobs aren't all that great and all this nonsense is I'm sure keeping a lot of capable people out of the industry making slightly less money while being treated like human beings and equals.

Clubber9• 10 years ago

Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you.

There are two major reveals in that sentence. One, HR rules your hiring practice and therefore you and your department, and you just advise them. Two, your company is so soul-suckingly bureaucratic, I couldn't imagine a good, creative, problem solving developer would ever want to work there. Both are red flags.

Bahamut• 10 years ago

Most good candidates wouldn't put up with that situation (1 week contracting) - also, years of experience can vary drastically. I recently interviewed a candidate with over 15 years of experience, predominantly in the backend, yet he didn't really have much experience scaling systems. He checked out in all ways until we drilled down into scaling issues.

ffn• 10 years ago

evaluate the candidate

But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees.

For example, your suggested hiring process of doing essentially an extended homework assignment might be great for a firm who doesn't care about "hiring the best", "building the elite team" or whatever, and instead wants to just assemble a ragtag team of misfits who trust and work well with each other to get things done.

Meanwhile, the Silicon Valley standard Googlesque hiring practice of using timed tree-inverting-list-o(log n)-optimized-talk-through-what-you-are-doing-(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) algorithm questions to pinpoint the most academically smart candidate is perfect for companies who want to hire the "smartest programmer" to create a culture of intelligence oneupmanship to drive "innovation".

And unless one happens to be in a situation where one absolute needs a job right away, a candidate could really glean a lot about a potential company's direction and culture through just how they conduct their interview, and decide if this is, indeed, a place where one could do one's best for the company and continue with the application or apply elsewhere.

dmoy• 10 years ago

90% of devs there don't use his software, and we have no idea why his application was denied :/

MustardTiger5• 10 years ago

(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off)

I use tons of open source software written by people I would never consider hiring. "You use something I wrote therefore I am good" is not a reasonable assumption.

grey-area• 10 years ago

From the perspective of a hiring company, say they have 5 final candidates. Suggesting a 1 week placement will not be practical either for most of the candidates (who still have their old job) or for the company (who has real work to do and not 5 weeks of on-boarding). Also to compare candidates they need them trying the same thing, not 5 different things.

I think a few hours discussing code is a small sacrifice for a fairer, more equitable interview process.

gregmac2• 10 years ago

I'm tired of companies asking me to code at their interviews. I have 10 years experience

I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc.

Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem.

10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions.

(Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)

cosmolev• 10 years ago

Disclaimer: I've never written any C# code, I write Java code.

"Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.

yoklov• 10 years ago

Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem).

I know none of the code I've ever wrote for a job interview was very good. Often it's total shit, hell, it often has a while (true) loop that I break out of later. (usually I ask if they'd like me to clean it up after I get it working properly).

If your interview is designed around trying to see stylistic choices such as these (yes, the distinction between writing a loop and using linq is style), you should refocus it to be about figuring out the candidate's thought process.

DigitalSea• 10 years ago

I have done what you have proposed and it worked for my latest job (2 years and counting). I flat out refused a coding interview. I openly said, in my experience as a developer, great candidates fall through the cracks because they fail under a controlled environment which does not reflect the real world. They actually agreed with me.

I came in and did a one week trial, I brought in my own computer, they gave me access to a repository and a task list, told me to do what I could in the week and ask questions. Arguably, the experience was great. I was able to not only see if I wanted to work for this company, but what the people are like and what kind of problems I would be solving. It was a great way for the company to see if I got along with their team and if they liked me as a person.

Being a developer is half knowing how to code and the rest is whether or not you are a match personality wise for the company. You might be smart, but can you get along with others and work in different situations? A palindrome function or FizzBuzz during a coding interview can't tell you everything about a developer.

You know what else is great? I came onboard as a senior developer, after a year, I was running my own team of 2 other developers. Then something greater happened, I managed to change the way the company hires developers. We do the initial screening which is just a chat to see if their skillset matches the role, then we reduce the list down and bring them in to pair program with someone.

It works so well. Also what is cool is that the two developers we have brought on since I started were hired after great work performances during their week trial/interview.

kriro4• 10 years ago

Let me add a somewhat unrelated side note since you have some say in the new hiring process which is awesome btw. and the company sounds like they "get it"...

Bring your own device should always be understood as a security tradeoff. Especially if it's someone who is auditioning for a job (I'm sure you're aware of that but can't hurt to point it out).

tigershark• 10 years ago

It's actually illegal in all the contracts that I ever had to work for someone else while you are employed for a company. And even if it was legal I would never lose a week salary for some fancy interview that takes a week, plus all the time that it takes to test the other n-people to have an answer.

ionforce• 10 years ago

How did you have the bandwidth to work there for a week?

kriro4• 10 years ago

This is a decent solution if you are a freelancer or between jobs or family free and able to relocate short term (you could do it remote but job interviews if you actually work on premise should also be on premise to some extend). If you're currently holding another job it's pretty tough as you'd essentially have to take a week of vacation time or do all the work remote.

gedrap2• 10 years ago

>> I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value.

I don't really agree with this statement.

The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results.

You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring.

But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)

BinaryIdiot5• 10 years ago

The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places.

Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work.

I doubt you have worked with folks with 10+ years of experience who wouldn't pass as junior developers who also had references and verifiable code running in a production environment (and if you did I would imagine that's a fluke negative hire).

But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)

Considering almost every technology company hires the same way and the employees typically have the "I went through it so you have to do" attitude you're not really going to find another company that has a "better" hiring procedure. Your response is more facetious than realistic. If you want to be a developer you don't have much choice than to go through the system that has been studied to death and known to be flawed.

BinaryIdiot5• 10 years ago

While I agree with your sentiment entirely I think you idea is faulty. Too much up-front cost for the employer and high risk for the employee if you need that job. I would like to see a short homework assignment which is then used to work with the interviewee. At least in some form (idea needs refinement).

ori_b3• 10 years ago

I have better things to do than spend a few months of PTO interviewing with multiple companies. This won't fly with me, and I doubt it will fly with many people that are currently employed.

agentultra2• 10 years ago

I'm tired of companies asking me to code at their interviews.

I get that. I am too.

I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon).

If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look.

Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews:

1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there.

2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed.

3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems.

4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for.

Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it.

The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something.

Happy hacking.

judahmeek3• 10 years ago

Some really solid advice.

allsystemsgo• 10 years ago

Couldn't agree more. It's getting ridiculous.

gimpster2• 10 years ago

This reminds me of "smart and gets things done". Your idea is to test whether people can get things done. An interview can test how smart they are. Both are important.

I've seen web developers with years of experience delivering successful projects who turned out to be terrible programmers. In this situation, it is nearly always because they're not smart enough or because they have an anti-intellectual outlook on life ("I found this on stack overflow, it works, I don't understand it in depth but it's good enough for me" or "why would I know that, I never needed it") or often both. They were ok churning out 4 month projects one after the other or maintaining some business web site for years, but when you have them working on difficult and complex problems, their abilities turn out to be lacking and the brilliant kid with much less experience turns out to be much more useful.

kylnew• 10 years ago

Overall quite subjective. You're not going to 'win' the interview every time. Sometimes the cards are practically stacked against you. You get asked a question no one had actually tested beforehand, you get an interviewer who's trying to prove how smart he is, you get someone who is too fixated on a particular skill you must have, you get someone having a bad day, etc... And when the process easily take 6 stages and unanimous thumbs up, one of these is likely to come up time to time no matter how prepared you were. Don't take it personally.

dclowd99012• 10 years ago

How to win the coding interview... For this one particular guy. Seriously, I've talked about this subject to about 400 different people, and absolutely every one put varying amounts of weight on not only the things mentioned in this article, but stuff that is completely out of the hands of candidates. I've heard people admit they've probably passed on candidates because they were simply in a bad mood that day.

christop• 10 years ago

The only winning move is not to play.

brooklyndavs• 10 years ago

"there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line."

Real response to this should be to ask how it got to the point where we are all stuck in a room with a deadline looming and our jobs are on the line if we don't come up with a whiteboard solution RIGHT NOW.

Sounds like this place has a management/expectations problem and I wouldn't want to work there in the first place.

joe_the_user• 10 years ago

The headline; dev(mastery) perhaps, means, "A gentle invitation to join our psychosis"

The idea that a coding interview is there to be "won" seems to me to be fundamentally delusional.

Artoemius• 10 years ago

Most programmers already know how to win the coding interview. You simply have to solve problems, at the same time trying to evaluate your next boss (or at least the kind of people who work there) by the level of insanity they generate during the interview. If the coding style in the company disagrees from yours too much, it's a good thing they won't hire you, so no problem there.

The tough thing is to pass the HR interview, with dozens of idiotic questions and no way to answer them correctly except having googled the answer to each particular question beforehand.

staticelf• 10 years ago

I've been at a really bad interview where the interviewer wanted me to sit at a computer, for a limited time, and answer a bunch of mathematical questions with the help of writing a program.

I was pretty nervous before my interview since it was one of my first ever. I had studied a lot before hand since the company used languages I didn't really know. I could not sleep the night before (mostly for other reasons as well) so I was pretty exhausted when I got there. There was no internet connections on the machine and each question built on the one before so if you failed one you pretty much failed the entire thing.

The whole test was a big hit for my imposter plexus and I'm never going to repeat that mistake. I feel like I have the experience and references that I do not need to prove it on a whiteboard. I don't want to and if you require me to, I'm probably not going to work for you.

The funny thing is, years later the same interviewer tried to add me on LinkedIn and it felt awesome to ignore that.

sekasi• 10 years ago

Solving that code test in a more effective manner? :)

replace non alpha/spaces, lowercase it, then compare value.reverse() == value

bithub• 10 years ago

Shorter yes, but reversing the whole string and comparing it with the input value is actually slower/less efficent than the algorithm shown in the article. Sorry for my nitpicking ;)

collyw4• 10 years ago

Clean, easy, maintainable. To me that is more valuable than an increase in performance. I would be very surprised to find a palindrome checker as the bottle nek in a system.

rafadc• 10 years ago

Looks like you are putting performance as a top priority for you. Do you think that a good candidate should at least measure cpu time somewhere?

Looks like all the performance related things I'm seeing there are assumptions based on experience.

smartan• 10 years ago

Came across this link on here a while ago, curious if anyone has experience with similar interview experiments: http://goo.gl/fDGYhC.

iSnow5• 10 years ago

Candidates are requested to supply source code, from one large project, a week before the interview date

Not everyone is the author of a big OSS library. Lots of people do most of their coding as an employee and cannot legally show you their code. Hell, I cannot even discuss some of the more interesting challenges I faced because that would violate my NDA.

kriro4• 10 years ago

Sometimes you can also solve whiteboard blackout issues with humor. I once was stuck because I couldn't quite figure out how to implement something (I think it was a peculiar sort). I proceeded to give up after reasoning through it for a bit and mumbled...well I can't quite get it now but let's move on since I'd probably never implement this and if I do I'd spend a lot more time on it and proceeded to add this line at the top of the whiteboard code.

import com.stackoverflow.* ;

One of the people in the room chuckled noticeably. I then went into a mini explanation of importing * vs. direct import (anticipating the obvious question) and was more or less free to use magic whenever I needed it :D

judahmeek3• 10 years ago

Nicely done. xD

marlag2• 10 years ago

I have ~20 years of experience in programming. The hardest part of my work is knowing if I have everything I need in order to classify a particular problem as one of a particular class so that I then can apply the tools that I know of would fit that problem-space and then use those tools to finish my task. For example, is the problem I'm facing a graph problem? If so, then I have a large set of tools (algorithms) to help me solve that problem. But is it a graph problem? It would suck for my employer or client, if I tried to solve a problem within a particular problem-space with tools suted for a different domain. It's kind of like that part of the Swedish standardized test where they test your math and logical abilities by presenting some information and then asking you, do you have what you need to solve this? If so, what is the answer?

Coding on a white board is useful I have come to find if there is a conversation going on and the interviewer use this opportunity to find out more about how this particular person thinks or works.

dcw3032• 10 years ago

Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation.
It’s not unreasonable to expect that you know the basics of RegEx

So that's a fairly arbitrary distinction. Regex has a famously terse syntax. Maybe in some jobs it's used frequently, and in those cases I could expect someone to recall the basics. But it's been my experience that regex comes up just infrequently enough that I never recall the exact expression, and then spend more time googling a regex tutorial (even more if it includes groups or look behind) to refresh myself than I would have if I just had a strings library that just had .StripWhitespace() .Contains() .Startswith() .IsItAValidPhoneNumber etc etc functions.

gedrap2• 10 years ago

Basics of RegEx, in my opinion, is a very subjective thing.

Personally, I'd interpret it as 'able to write a simple expression with a few minutes of googling', where simple expression is something like 'up to 5 lower case letters immediately followed by a digit'. It'd would be a reasonable indicator if someone has used them outside tutorials and class rooms in the past year or two.

However, you (or anyone else) might have a very different interpretation.

dcw3032• 10 years ago

I generally agree with your interpretation, but as the author wrote this later in the piece:

If I give you a challenge to take home, my expectations are even higher. If you get a week to code something with full access to Google, etc… There’s no excuse for giving me a solution that is anything less than top-notch.

I saw that as an implication that he expected a candidate to be able to recall regex basics from memory.

boredatnight12• 10 years ago

I'm not here to win, I'm here to contribute. Interviewing infuriates me.

hvidgaard11• 10 years ago

The author have a list of secret good questions, and that is not helping anyone. He expects the candidate to think loud and be explicit, but are himself very implicit in his requirements. What I consider production code is without a doubt different from what he things is production code.

Your code should be commented.

Then put this requirement, because judging from the example, the authors expectations, is what I fail students and junior devs for. Comments are complementary and explain things like "the why" ("pad to multiple of 256, otherwise libX will hang"). Don't expect people to automatically know your implicit requirements, it's a recipie for disaster.

You should have error handling or at least logging.

Again, put this in the requirements. Some environments need no error handling, because the error handling is external. And don't get me started on logging. Yes it's nice in a debug situation, but in many high volume production systems you have engineers with the sole responsibility of creating a logging system that impact performance as little as possible.

You should have a test harness.

If you say so, otherwise I'm not going to make one. Be explicit.

Runs fast. Doesn’t take up more memory than it needs to. Is stable and easy to maintain.

1. and 2. are secondary. 3. is king, unless you have empirical evidence that warrant 1. and 2. This is something many developers struggle with, including the auther by the sound of it.

RegEx

No, just no - the imfamous quote is "I have a problem, let's use a RegEx. Now you have two problems" and it's true 98% of the time, including testing if a string is a palindrome. Besides, regular expressions cannot identify palindromes - this is first year CS stuff. I'm well aware that some implementations allow back references, thus they are not really regular expressions but leaning on CFGs. For this particular problem, reversing the string and then compare is by far the most readable and understandable solution.

For senior devs, I want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points I want you to flag any of your assumptions in the comments.

What is optimal? With regard to execution time? Memory usage? Maintainability? Program size? What kind of error handling?

iSnow5• 10 years ago

But the author doesn't even advocate RegEx for testing if a string is a palindrome. He doesn't explain for which part he'd use it, but from the sound of it, removing whitespace and punctuation.

judahmeek3• 10 years ago

That's right. If you look at the code, the only use of regex is to remove all characters not matching [a-z0-9].

WalterBright• 10 years ago

-1 point for not testing "Bolton".

gavanwoolery• 10 years ago

I am currently looking for work and already kind of tired of the technical interview process. I have been programming for 15 years professionally. We could save a bunch of time and money if the recruiters and engineers just looked at my resume and looked at my work. The truth is 99 percent of the work I would do is nothing like a technical interview: I have time (with leeway to work overtime), and I have Google/Stack Overflow. Never encountered a problem I could not solve, but there are plenty of problems I have not memorized the solution to.

I don't mind a general interview - I can "talk the talk" - I just hate being asked questions with very specific answers that would require most people to study or memorize beforehand. If I can Google it in a few seconds, it should not be an interview question.

BinaryIdiot5• 10 years ago

Good points in the article but as usual much of it continues the trend of "do X, Y and Z to pass an interview" which rarely crosses into the other side of the venn diagram of useful skills / talents to have being a software developer day-to-day.

I would much rather see a take home assignment of "this is something we've had to do before", give them a few days to work on it, bring it in, make sure they can explain it, make sure their code isn't horrible or if it is there is a damn good reason then sit down with them and work together on adding a new feature. Together. Get an idea how they work with others, how they approach problems, architecting, etc; it seems so brain dead simple and yet almost no one does it.

Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation.

In one breath the author acknowledges that it's a waste of time but in the next he's saying you should understand them at least at a high level. There are a ton of useful algorithms and the ones you're going to memorize are not going to be useful in day-to-day work. They simply won't be. Merge sort, quick sort, binary search, etc are all useful but they're also some of the least complex algorithms that you'll never need to implement directly (and if you have to for whatever reason yes you can Google it) and algorithms that ratchet up the complexity are hard to memorize (at least for some people).

Common development patterns are far more useful than trying to memorize any algorithms, in my opinion.

Arguably, the most important thing in passing a coding interview is to be well prepared. The best way to do that is to practice common interview coding questions over and over and over again until you know them cold.

This part fills me with dread for any upcoming interviews. Practicing answering questions does one thing: it helps you memorize questions and answers. It doesn't help you be a real employee. It doesn't help you jump into wireshark to figure out what's wrong with the network because you hit a wall with debugging your ruby on rails app. It's just useless for anything but the interview.

For me I have an online portfolio, several open source projects, references; I'm not saying I'm "too good" to be tested but the fact that I have to waste time and energy memorizing typical questions and answers just so I can provide value to another organization just feels wrong to me. Everyone seems to claim there is a shortage of technology workers in SV so I would expect this ENTIRE process to work the opposite way than what it really does.

sklogic8• 10 years ago

Who on Earth writes code on a whiteboard? Like, seriously

You know, professionals do this. Anyone who value time and quality.

Hipsters may find it weird, but, well, they have decades to learn before they'll become professionals.

vonmoltke4• 10 years ago

I have been an engineer for 14 years and writing software full-time for 8 or them. I have never written code on a whiteboard outside of an interview. I have drawn circuits, flow diagrams, UI wireframes, ERDs, memory layouts, and so on. I don't have my own whiteboard now and it drives me crazy.

I have never had a need to write actual code on a whiteboard. Neither has anyone I have ever worked with.

sklogic8• 10 years ago

Flowcharts are code. Pseudocode is a code.

Kesty• 10 years ago

The problem with all this "advices" is that they boil down to "just study".

I agree that been prepared for an interview is a good thing, if you are ready and have studied you show that you are willing and that you put in the effort.

But what about people that are currently working ?

You are trying to get the best programmer, and chances are is that the best programmers out there are currently working (minus a small percentages of great programmer that are in between jobs, or that spent the last period on consulting or personal projects) so you automatically put people that are currently working and can't prepare for the interview as well as the other at a disadvantage and those are the people that you are probably most interested in.

To me it seems that in this world the only interview process is solely targeted at young people fresh out of college.

bogomipz2• 10 years ago

Advice is plural not "advices."

ubercode5• 10 years ago

It depends on your schedule, but prioritize time to study every day in your down time. You don't have to do a "night before the test cram session" all the time, just a little every day and within a few months you'll find yourself much more prepared.

chvid• 10 years ago

Honestly; the example answer is not good. If I was in a hiring position, I would at least talk to the person writing this and ask them to change their style.

The problem is that the answer is slightly over-engineered, over-commented, checks for input type, logs in a corner-case, looks-like-it-has-been-written-by-a-teacher-with-too-much-time-on-their-hands.

These are not problems in themselves but when you have a new person on the team and they write code like that, it may be inconsistent with what the rest of the team is doing / what the rest of code base looks like.

For comparison here is another way to test for a palindrome:

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

(Possibly add "normalization" in the beginning as they do in the article.)

Clubber9• 10 years ago

Hah. I was thinking that too. While I was reading the article, I was thinking about how I would do it. Then I read the wall of text that was the ideal solutions and thought, "wow, what the hell are coders doing these days?"

dudul• 10 years ago

The whole justification for whiteboard coding is total BS. Never have I ever written actual code on a whiteboard, not even "when we are banging our heads against a problem and there is a deadline looming and blablabla".

Yes we do go to the whiteboard. To design stuff. To organize components of the platform and figure out how the fuck to coordinate some f-ing distributed transaction, or how to send messages from A to B and not create a bottleneck. We don't try to write the pseudo-code for a palindrome detector.

I have nothing against coding interview, in front of a computer. Whiteboard coding? I just leave the room. If you give me a whiteboard coding exercise, you failed my interview.

logicallee• 10 years ago

the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked that when the write-up explicitly calls for "the most efficient code possible" nobody cares that the example program starts off making two extraneous copies of data that might never need to be read. (why lowercase the characters inside when you can fail early working outside in.)

Can you imagine if the task were "write the most efficient code possible to check if an array of strings of integers such as "3423", "34356", etc, is sorted (treating the strings as base-ten numbers, "3423" representing 3423 and so on), ignoring any strings that include non-numerical characters" started out by making two copies of the whole damn array. That's what's happening here, it's kind of shocking that this is what javascript developers accept as the "most efficient possible" without anyone having the slightest issue.)

I'm shocked. Even the definition of efficient offered for "Write the most efficient function you can" is

If you’re experienced, you should know that “efficient” in production code means three things:
Runs fast.
Doesn’t take up more memory than it needs to.
Is stable and easy to maintain.

This is an absolutely shocking definition, given the example code offered. It really does show that javascript programmers do not in any sense consider algorithms the way Go or C++ programmers would. (I conclude this after reading the comments here and also the article.) Especially given the above definitions.

I mean, on a two megabyte input file the "most efficient function that you can" would start by copying the whole two megabytes...twice. Rather than working from the outside in, so it can reject the input and ignore the inside characters as fast as possible. Shocking!

What I'm really shocked about isn't that that's what the solution was - fine, no problem. But rather, that nobody comes close to thinking about most-efficient the way other types of programmers would think about it - and this includes the comment in the story which takes exception to the offered solution. It doesn't do it either. This post and this thread was a real eye-opener for me.

p4wnc68• 10 years ago

The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather that interviewers of any kind, anywhere, actually care whether a candidate, who is writing code in a totally alien physical and mental situation (the interview), would write "efficient" code during an interview at all.

Yes, maybe some small allowance for some discussion about basic time complexity, but nothing more. If you very clearly articulate an O(n^2) algorithm during an interview, that's excellent -- even if there is an O(log n) solution that we'd all prefer. You can always learn on the job and improve through self-study, etc., but the basic task of clear articulation is much more important. Obviously, no one who comes up with the O(log n) answer is going to be marked off for it, but neither should the O(n^2) person be.

Instead, interviewers should just admit that focusing on efficient code in the setting of an interview is utter nonsense. You cannot learn from that whether or not the person is going to be effective at writing efficient code for you in the completely and totally different situation of coming to work every day in a regular work environment. No matter what you think, you simply cannot.

So the better thing would be to just admit that the results of timed interview trivia cannot tell you anything at all about how effectively someone will write efficient code in a real-life situation, and just get on with it.

logfromblammo4• 10 years ago

It is entirely unnecessary to copy the string, to stack or heap. Rather than stripping whitespace, you check for whitespace when incrementing/decrementing the index. Rather than setting everything to lowercase, use a culturally-appropriate character comparator that ignores case differences.

Just stick a Turkish dotless-i character in the unit tests somewhere, at the end of "I’m a lasagna hog; go hang a salamı." and see what happens.

Cozumel• 10 years ago

1, commenting for the sake of commenting 2, basic spelling mistakes in the article 3, god awful javascript code 4, condescending attitude Not a guy I'd want to work with, ever.

snarfy2• 10 years ago

Your code should avoid breaking at all costs.

This type of practice hides bugs. Whatever happened to 'fail fast, fail often'?

pc862• 10 years ago

"Fail fast, fail often" does not refer to the build status of your project, it refers to the business.

How does writing code that builds hide bugs?

snarfy2• 10 years ago

Fail fast, fail often isn't just about the business. It's about code too.

If the palindrome function does not support unicode correctly, it can:

1. Try to function anyway, return true/false even without a real match

2. Detect unicode and always return false

3. Throw an exception

It would be best to throw an exception. Why is a function that doesn't support unicode being called with unicode input? That's the real error.

coldcode• 10 years ago

How to win a coding interview where the company does nothing but write short snippets requiring cleverness. When's the last time you worked for one of those?

dominotw• 10 years ago

  >“Is this client side or server side JavaScript?”
  >“should an empty string be considered valid input?”
  >“Do I need to handle unicode characters?”

these questions seem a bit much for a palindrome test.

d--b• 10 years ago

Just a comment here, starting by a string.replace with a regex is not what I'd call efficient coding...

sickbeard• 10 years ago

Write the most efficient function you can that determines wether a given string is a palindrome.
When I offer a challenge like this in an interview, the first thing I’m looking for is wether or not you ask me any questions
/ * Tests wether or not a given string is a Palindrome * @param {string} stringToTest - the string to test. */

Don't take coding advice for someone who can't spell whether.

neotrinity• 10 years ago

Apparently wether is a castrated male sheep or a castrated male goat. Just saying.:D I have learnt something new today !

TillE2• 10 years ago

Similarly, "payed" is something you do on a ship. The hazards of relying on spellcheck.

agentultra2• 10 years ago

What if I we start by writing an unambiguous specification and I walk you through the proof?

The pomposity of this post is ridiculous. I can't stand the, "I don't have time for you," type of thinking. It suggests that the author assumes they are smarter than the person they are interviewing. It elides the underlying complexities of every persons' lived experience and inner world. Does the author not realize that people are not dumb actors in their narrative? People are generally intelligent, creative, and highly adaptable.

All this post does is show how trivial some people treat the interview process. The real lesson here is that if you can learn to ask how high to jump when ordered to you can get anywhere.

jcadam2• 10 years ago

My problem is not the technical stuff -- I just can't seem to pass the 'culture fit' part of the interview outside of my industry (defense/aerospace). I've been trying to get out of the govt sector for 10 years now (going on interview binges every so often). I often pass the technical screening (usually screen-sharing or "homework") and make it to the final "onsite" interview stage but something about meeting me in person puts people off. I hear "not a cultural fit" or words to that effect more often than anything else.

Hell, I was even told "We think you'd be bored here" when I interviewed at a startup several months ago. Didn't get an offer there either.

vonmoltke4• 10 years ago

Isn't it awesome to hear how hard it is to find people who actually know how to write code while being told all this shit?

(Fellow defense/aerospace internee here. I managed to get half-out four years ago but have failed multiple times to get full out on non-technical grounds.)

jcadam2• 10 years ago

Yea, I just roll my eyes whenever I hear "It's hard to find good developers" anymore. Current hiring processes only make sense if you're dealing with a surplus of talent.

victorhn• 10 years ago

We share the same struggle :). I have been in multiple processes where all goes right until the onsite interview where everything blows.

My gut feeling tells me is because i am a rather ugly guy and also somewhat of socially inept, so i should make a bad impression. Currently working in losing some weight and trying to improve my social skills.

collyw4• 10 years ago

Having interviewed a few people in the last year, my number one suggestion would be to show some enthusiasm for coding / tech / a particular language or framework that you have used. Tell the interviewer why you like it (or why you don't). Its really difficult to evaluate a candidate when they just give an answer to the question and no more.

jdc0589• 10 years ago

Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation

I couldn't agree more. I've had interviews (with big companies in the north-west), that had NOTHING ASIDE FROM ALGORITHM questions. At one of those, over the course of a 4 hour interview EVERY SINGLE QUESTION was whiteboard coding tree/graph traversal problems, aside from one "architect a system to handle this" type discussion (which was maybe 15 minutes).

Interviewers: if your candidate knows, without prompting, that the best solution to the problem is a depth first traversal of a tree and can explain why, implementing the actual solution is not the most important part of the interview. Not a lot of people need to write tree/graph traversal as part of their jobs frequently enough to warrant assuming everyone can implement everything from memory on a whiteboard in 10 minutes.

edoceo• 10 years ago

Would not get the job here.

bluejekyll• 10 years ago

After reading this last night, I got a little excited about doing something I've never done: a palindrome function in Rust only using Iterators, https://news.ycombinator.com/item?id=11805296

Straight link to code as well: https://github.com/bluejekyll/palindrome-rs/blob/master/src/...

It was fun because I realized I have a different option than stacks and arrays to solve this problem now.

hiou2• 10 years ago

The only winning move is not to play.

justinhj• 10 years ago

I find it amusing that the author asks for an optimal solution that avoids taking up extra space. Then in his example solution he makes two copies of the original string to convert it to lowercase and strip invalid characters.

Using a regex is overkill for the simple rejection of invalid characters. The job could be done in a single loop with worse case runtime n/2. Sure his solution is still linear time but he did ask for optimal.

It just goes to show that you can't win the interview game because everyone looks for different things. There is definitely good advice in this article though.

phat4life2• 10 years ago

I would much rather do a take home test, and as someone who has done hiring, I would much rather give a take home test.

The problem though I have with code challenges, is when you get rejected, and they offer ZERO reason why they rejected your code, despite the fact you may have spent a whole fucking week working on it, doing the best you could. I have outright asked why my code was rejected, and I have NEVER gotten a response. Pure bullshit.

The other problem, is that most of the time they tell you not to use external libraries, which I get why, if they want to access your algorithms or data structure skills, but this is stupid, because you likely shouldn't rewrite libraries that do a better job than what you can code in a short time, and in any real world scenario, i would use all the libraries I could to write less code. Its better to test those things via white board. In some cases, I would reject you based on you not knowing about standard libraries.

I had one take home test, that was basically, write a database like thing in ruby to process and query an input file with dates, names, etc, you can't use any gems. If I used external gems, I could finish the assignment in few lines of code, without external gems, i have to do all this bullshit i would never do in a real world scenario.

YeGoblynQueenne5• 10 years ago

> On this particular challenge, I am expecting many will use RegEx as a part of the solution. The regex needed for this is some of the most basic regex out there

Woohooa, cowboy. The language of palindromes is a classic example of a context free language that is not possible to describe with a regular grammar, such as accepted by a regular automaton... in other words a regex.

In Recruiter-Parseable English (RPE): you can't decide whether a string is a palindrome using a regex. It's impossible. Like, maths-impossible.

You can use regular expressions to compare strings while you decide whether a string is a palindrome but you can't do the whole thing in one regex.

Programmatic4• 10 years ago

He's not expecting the use of a regex to do the whole heavy lifting of checking for a palindrome, in the example he uses it for the replace functionality to remove non-alphanumeric characters.

https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1...

stringToTest = stringToTest.toLowerCase().replace(/[^a-z0–9]/ig, '');

YeGoblynQueenne5• 10 years ago

Yep, should have read all the way through before posting.

But the example solution is so bad anyway.

am8• 10 years ago

"is wether or not you ask me any questions"

wether.

Who cares there are plenty of places that will hire you without all this "super smart and get things done" cliché.

More trust should be given to younger employees just starting out. They might still provide lots of value but not need to tick off a certain % of clichés valued by a senior dev who think they know the correct way.

“I use this test on all levels of developers, but my criteria is stricter the more senior I expect you to be.”

Who would really want to work for someone who treats you in such a subordinate way.

A lot of the time the personality issues are with the super arrogant hiring developers at companies. I had this issue trying to get jobs out of uni, being able to code but not knowing the trends.

If you answer the correct questions (led by what is fashionable according to top developers/industry figures) and fit into their view of what a great developer is then you will get the job.

It’s almost like you could come up with a stock set of answers about subjects to pass (clean code, unit tests, maintainability, logging).

What about the project which provides your pay check, isn't getting to grips with that just as important?

mixmastamyk• 10 years ago

I guarantee you this, there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast.

False, that has never happened in decades of work in my experience. All "breakthroughs" I've had came to me in the shower or other solitary place. For most people, creativity does not spring from a gun to your head in a crowded room. The rest of the piece falls apart from there.

collyw4• 10 years ago

Exactly. High level architecture as well. I don't sit down and come up with one there and then. I get a rough idea of the problem early and think about it for a few days (while I am doing other things). Piece by piece I see what will work well and what won't.

YeGoblynQueenne5• 10 years ago

Oh my gods! This is what passes for an answer to "identify a palindrome"? All of that?? 59 lines to ensure a string is equal to itself reversed (hint-hint, nudge-nudge)? Why?

  'use strict'; // avoid ambiguity and sloppy errors

  /**
 * Tests whether or not a given string is a Palindrome
 * @param {string} stringToTest - the string to test.
 */

  function isPalindrome(stringToTest) {
    var start = 0,
        end;

    // make sure we have a string.
    if (typeof stringToTest !== "string") {
        // throw if we didn't get a string
        throw new TypeError("isPalindrome() expected a string, but got " +
            Object.prototype.toString.call(stringToTest) + " instead!");
    }

    // normalize string by lowercasing and removing non-word characters
    stringToTest = stringToTest
        .toLowerCase()
        .replace(/[^a-z0–9]/ig, '');

    if (stringToTest.length === 0) {
        // warn if we have no valid characters to test
        console.log("No valid characters to test, treated as empty string" +
            "\nStack: \n" + new Error().stack);
        return true; // an empty string is a palindrome.
    }

    end = stringToTest.length - 1;
    // Compare characters from outside in. Stop when we get to the middle.
    while (start < end) {
        if (stringToTest[start] !== stringToTest[end]) {
            return false;
        } else {
            start++;
            end--;
        }
    }

    // if we get here, it's a palindrome
    return true;

}

  // tests (should be in a separate file using a test framework)
  console.log(isPalindrome("something that is not a palindrome") + " = false");
  console.log(isPalindrome("something that is \n not a palindrome") + " = false");
  console.log(isPalindrome("race \n car") + " = true");
  console.log(isPalindrome("") + " = true + warn");
  console.log(isPalindrome("  ") + " = true + warn");
  console.log(isPalindrome("1221") + " = true");
  console.log(isPalindrome("0") + " = true");
  console.log(isPalindrome("racecar") + " = true");
  console.log(isPalindrome("No 'x' in Nixon!") + " = true");
  console.log(isPalindrome("~~!~!~") + " = true + warn");
  console.log(isPalindrome("Momsie") + " = false");
  console.log(isPalindrome(12)); // blow up
  console.log(isPalindrome(undefined)); // blow up
  console.log(isPalindrome(null)); // blow up

Godsdammit- I'm pretty sure I'm not missing the point here. That is a ridiculous amount of overengineering, it should not be accepted as an answer to such a simple question, under any circumstances.

logfromblammo4• 10 years ago

This is something you write only after the profiler says your previous palindrome checker function is a CPU/resource hog, a bug report says it isn't reporting all palindromes correctly, and your manager gives you the okay to spend as much time as you need to fix it forever (but really only spend like 30-40 minutes, mmkay?).

grimoald• 10 years ago

Before I start though, I have to say, if a company is going to hire a developer based solely and entirely on a piece of code the developer wrote in an interview, you probably don’t want to work there.

This is something I read many times when talking about interviews, and it makes no sense. Either there is a nonzero chance to be more successful in the interview if you perform good in coding exercises, or not. If the former, then there was at least one person in the history of mankind who was hired depending solely on the coding.

kevindeasis• 10 years ago

This is complementary:

https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-sala...

snambi• 10 years ago

Very thoughtful post. This exactly what I look for while interviewing candidates.

gmarx• 10 years ago

Says in the definition a palindrome can be a number then filters out number. Also, and most importantly, doesn't check to see if the items within the string are words.

The incredibly frustrating thing about interviews is that the interviewer is right, even if he is wrong.

thefastlane• 10 years ago

this shows me that there seems to be a cottage industry sprouting up around 'technical interview prepping' (this blog post is an advert for such a business). it's interesting that we've arrived at this point. curious to see the direction it takes

jupp0r• 10 years ago

Comments that don't document public interfaces are a code smell and should be avoided in all but the most exceptional circumstances. Reading Robert C. Martin's Clean Code really opened my eyes to this issue. Your emphasis on this in the code people write might exclude some people who avoid comments deliberately.

michaelmcmillan• 10 years ago

I had a go at this with Python. It has tests, a fast implementation (O(n/2)) and uses memoization to optimize.

https://github.com/michaelmcmillan/palindrome

prirun• 10 years ago

To me, the first good questions would be:

1. What language(s) does this function have to be callable from? 2. Can I write it in any language?

Rather than “Is this client side or server side JavaScript?”

Considering that I have no idea how to use a regex for this, it was very strange to read that the interviewer expected _many_ people would use a regex. Made me feel like I missed a year of school or something.

For efficiency, only half of the string needs to be tested, not the whole thing. (Edit: I realized later that the posted JS does this too. It was not obvious at first because "end" is also changing.)

Since I never actually do these things, I thought it might be fun to code one. First I wrote the simple function, pal1(). Then I wondered if Python had a built-in string reverse function, so looked that up with Google and found that it didn't. It has a klunky reversed() iterator, but there was the obtuse s[::-1] post on Stack Overflow that runs fast, so added that as an alternative. And I had to lookup the __name__ line, because I forgot the syntax of that, even though I've been writing Python (HashBackup backup program) for 7 years!

    import sys

    # the straightforward way, char-by-char compare

    def pal1(s):
        slen = len(s)
        slenm1 = slen - 1
        for i in xrange(slen/2):
            if s[i] != s[slenm1-i]:
                return False
        return True

    # s[:-5] === "the last 5 (or fewer) characters of s"
    # s[::] === s === s[start:end:incr], where start=0, end=len(s), and incr=1
    # s[::-1] === reverse(s) == s[end:start:incr], where start=0, end=len(s), and incr=-1

    def pal2(s):
        return s == s[::-1]

    # select which palindrome function to use
    pal = pal1

    # test with:
    # 1. null string
    # 2. single char (odd length)
    # 3. double char string (even length)

    if __name__ == '__main__':
        if len(sys.argv) != 2:
            print 'usage: pal <string>'
        else:
            s = sys.argv[1]
            if pal(s):
                print 'yep'
            else:
                print 'nope'

amai• 10 years ago

"Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it. But it’s not going to change any time soon."

In fact a much better way to evaluate a software developer in an interview is by asking her/him to present some examples of work they have done in the past. But don't take my word for it, read here:

https://blog.codinghorror.com/a-programmers-portfolio/

hajderr• 10 years ago

only makes sense if the recruiters are good and smart as you.

How to win the coding interview

Related Stories