How to win the coding interview - <AUTHOR> https://blog.devmastery.com/how-to-win-the-coding-interview-71ae7102d685#.dy3irg8ei <comment><USER3> 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.

<comment><AUTHOR> 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](http://usejsdoc.org/about-getting-started.html)

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

<comment><USER4> Interesting learning streak. I took the same route, started on Vic 20 at the age of 10, but skipped on the amiga assembly, something I suffer from on a daily basis, so good choice.

<comment><USER3> Thanks! :) The Vic 20 at about the same age here too; assembly was great, but staying for _well_ over a decade on ColdFusion just because there was a lot of work in it (and, comfortable) was not.

I forgot to mention some PHP thrown in there, but I'm glad to have been making the transition to C# in the past year. Working with a strongly typed language is quite a revelation, and some fantastic things are happening with the language and framework these days too (dotNetCore).

</comment></comment></comment></comment></comment><comment><USER5> 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?

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

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

<comment><USER6> How so? HR needs to be in the loop unless I want to take on payroll, contracts, etc. IT needs to be in the loop unless I want to spend my time setting up equipment, which certainly isn't the best use of it. I am most valuable when I am leading my team and doing engineering. Not every company is some five man outfit, and successful five man outfits have to grow up at some point. There are many things to consider when bringing someone on, even a contractor.

</comment></comment></comment></comment><comment><USER8> "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.

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

</comment></comment><comment><USER10> 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.

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

<comment><USER12> It is pretty ironic that palindromes cannot be recognised by regular languages.

<comment><USER13> Hah, yes. That's probably the simplest application of the pumping lemma I can think of.

</comment></comment></comment></comment><comment><USER14> 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.

</comment><comment><USER15> [Disclaimer: I run [http://InterviewKickstart.com](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](https://www.youtube.com/watch?v=v1WiCGq-PcY)

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

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

</comment></comment></comment><comment><USER18> 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."

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

<comment><USER19> >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...](https://sites.google.com/site/steveyegge2/five-essential-phone-screen- questions)

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

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

<comment><USER16> You're totally right. I was confusing the stated problem with a common associated problem: whether a string is a permutation of a palindrome.

</comment></comment></comment></comment><comment><USER20> > 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.

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

<comment><USER20> 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?

</comment></comment></comment><comment><USER22> > 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.

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

</comment></comment><comment><USER24> 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.

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

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

<comment><USER26> The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it.

<comment><USER25>
       The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it.

PCRE isn't exactly simple to begin with. That languages may implement it, or a superset of it, is exactly the problem. I know regular expressions very well, or rather I know regular languages and can fairly easily identify if a problem is solvable as a regular expressions. But once you start to go beyond that, it's not simple anymore and the benefit of a regular expression is lost.

<comment><USER26> If you know what . does, various repetition markers (*,+,?,{}), and character classes, you're 90% there. Back-references are another big portion, although that's admittedly where things start getting a bit complex.

</comment></comment></comment></comment></comment></comment><comment><USER27> 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;
      }

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

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

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

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER29> 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.

<comment><USER30> 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."

</comment></comment><comment><USER31> "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

</comment><comment><USER32> 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

<comment><USER33> Nicely done. xD

</comment></comment><comment><USER34> 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.)

<comment><USER35> 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?"

</comment></comment><comment><USER36> > 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.

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

</comment></comment><comment><USER38> > 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.

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

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

</comment></comment></comment><comment><USER25> 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?

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

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

</comment></comment></comment><comment><USER40> 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

<comment><USER41> 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?

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

</comment></comment></comment><comment><USER43> 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.

<comment><USER44> 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?

</comment></comment><comment><USER45> 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.

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

</comment></comment><comment><USER47> 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.

</comment><comment><USER48> 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.

</comment><comment><USER49> 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.

</comment><comment><USER50> > The best developers know that, fundamentally, every bug is the result of an > invalid assumption.

I assumed that I could type without makig mistakes.

</comment><comment><USER41> > 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.

</comment><comment><USER51> 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.

</comment><comment><USER52> > 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.

</comment><comment><USER53> 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.

<comment><USER54> 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.)

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

</comment></comment></comment><comment><USER55> 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](https://news.ycombinator.com/item?id=11805296)

Straight link to code as well: [https://github.com/bluejekyll/palindrome- rs/blob/master/src/...](https://github.com/bluejekyll/palindrome- rs/blob/master/src/lib.rs)

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

</comment><comment><USER56> 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.

</comment><comment><USER57> Solving that code test in a more effective manner? :)

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

<comment><USER58> 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 ;)

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

<comment><USER59> One of the interviewee questions could be "Based on the profiler output, how many times would this code execute in a typical day, to the nearest power of 10? What code will it replace?"

string.reverse() and string.equals() is plenty good enough for smaller magnitudes or all-new functionality. Premature optimization just means you think you can outguess the profiler.

So first you code the simplest thing that works. Then you start optimizing in the most heavily used sections. If you have to go past the pointer-based solution in C to assembly that employs hardware-specific performance tweaks, it's time to just end the interview and go pet your taco cat.

<comment><USER37> OK, ask the people who get their annoying ads popping up on screen.

</comment></comment></comment></comment></comment><comment><USER60> 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.

</comment><comment><USER61> 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.

</comment><comment><USER62> 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.

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

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

<comment><USER16> I agree, and feel it's also irrelevant for what this could possibly tell me about a candidate as far as interview questions go. You're totally right, it just doesn't mean that someone doing these wrong things in the interview setting gives you really any bits of info at all about whether they would be good or bad in a real job setting. Absolutely none.

Great programmers who would never do such unnecessary things when programming in a real situation may nonetheless think of them and do them when in an interview situation, since the kinds of situations are so incompatibly different.

I guess if they did this in a take-home assignment, _then_ it might be evidence of something. In an in-person coding interview though, it's just not useful at all for forming opinions about the candidate.

I've even seen veteran programmers with greatly successful open source projects, lots of experience, good education, high level of intellectual independence and curiosity, excellent writing skill, etc. etc., give highly inefficient implementations of FizzBuzz during an in-person interview.

These interviews are just not at all related to the way human beings actually write code and work in real life, and so they just cannot tell you much.

</comment></comment></comment></comment><comment><USER63> "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?

</comment><comment><USER4> 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.

</comment><comment><USER64> The only winning move is not to play.

</comment><comment><USER65> 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.

</comment><comment><USER66> This is complementary:

[https://www.twilio.com/blog/2016/02/patrick-mckenzie-on- sala...](https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-salary- negotiation-job-hunting.html)

</comment><comment><USER67> 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 - <USER2>
            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'

</comment><comment><USER68> >> 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.

<comment><USER69> 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...](https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1a0fa67)

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

<comment><USER68> Yep, should have read all the way through before posting.

But the example solution is so bad anyway.

<comment><USER69> What's your preferred solution?

<comment><USER68> Nothing more complicated than this:

      is_a_palindrome(S) {
        assert is_a_string(S)

        if reverse(S) == S
          return true
        return false
      }

A string is a palindrome if it's equal to itself reversed. The example "solution" in the article is dreadfully overengineered to death and back. Noone interviewing should be happy to see such a solution and noone being interviewed should expect to be required to give such a solution, to such a trivial problem.

Unless of course the recruiter is trying to catch you pants-down, but then the parent article wouldn't post that overengineered "solution" as a gold- standard, like they did.

<comment><USER69> That solution would fail to catch several of the examples that were requested to be caught. Sometimes something that appears overengineered is built that way to meet the actual requirements a problem presents.

<comment><USER68> >> Sometimes something that appears overengineered is built that way to meet the actual requirements a problem presents.

That's poppycock. Here are the requirments:

>> Write the most efficient function you can that determines whether a given string is a palindrome.

A palindrome is a string that is equal to itself reversed. That's like, the mathematical definition of a palindrome (simplified, of course). What I gave you catches exactly that. If some of the test cases in the proposed solution don't agree with the commonly accepted definition that's a problem of the proposed solution, not mine.

Also, in terms of the "most efficient" solution, the guy's proposed solution is far from that- because he tries to be smart and reverse the string while he compares it, thinking that's faster than going the whole hog. But that's only going to save you some cycles a tiny amount of the time, because the vast majority of strings you can expect to encounter are unlikely to be palindromes. Reversing and comparing the string to itself is the neatest, quickest, most legible and prettiest thing you can do in this case, regardless of your use case or anything else.

And if you're a recruiter that expects anything else, that's because you have no idea what you're looking for, not because you are as smart as you think you are.

<comment><USER69> You omitted the bit just above your quote, which says:

>> A palindrome is a word, phrase, number, or other sequence of characters which reads the same backward or forward. Allowances may be made for adjustments to capital letters, punctuation, and word dividers. Examples in English include "A man, a plan, a canal, Panama!", "Amor, Roma", "race car", "stack cats", "step on no pets", "taco cat", "put it up", "Was it a car or a cat I saw?" and "No 'x' in Nixon".

Given the last sentence, doesn't that change the meaning of your sentence to directly refute your interpretation?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER70> 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.

</comment><comment><USER71>
      >"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.

</comment><comment><USER72> Came across this link on here a while ago, curious if anyone has experience with similar interview experiments: [http://goo.gl/fDGYhC](http://goo.gl/fDGYhC).

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

</comment></comment><comment><USER73> 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.

</comment><comment><USER74> "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/](https://blog.codinghorror.com/a-programmers-portfolio/)

</comment><comment><USER16> 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.

</comment><comment><USER75> > 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.

</comment><comment><USER76> > Your code should avoid breaking at all costs.

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

<comment><USER77> "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?

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

</comment></comment></comment><comment><USER78> 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.

</comment><comment><USER79> -1 point for not testing "Bolton".

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

</comment><comment><USER80> 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

</comment><comment><USER81> 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.

</comment><comment><USER82> 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](https://github.com/michaelmcmillan/palindrome)

</comment><comment><USER83> I'm not here to win, I'm here to contribute. Interviewing infuriates me.

</comment><comment><USER84> 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.

</comment><comment><USER85> 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?

</comment><comment><USER86> Very thoughtful post. This exactly what I look for while interviewing candidates.

</comment><comment><USER87> Would not get the job here.

</comment><comment><USER88> only makes sense if the recruiters are good and smart as you.

</comment><comment><USER68> 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.

<comment><USER59> 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?).

</comment></comment><comment><USER89> >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.

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

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

</comment></comment></comment><comment><USER92> 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.

</comment><comment><USER93> _The only winning move is not to play._

</comment><comment><USER94> > 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.

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

<comment><USER94> Flowcharts _are_ code. Pseudocode _is_ a code.

<comment><USER35> No they aren't. They are a diagram of a process. Code is the instructions used to implement that process. You shouldn't be so smug either.

<comment><USER94> Yes they are. A formal language is a code. Any formal language. What is the difference between code and pseudocode in your opinion?

And given that on a whiteboard interview you're writing a pseudocode, it is not any different from a typical day at work where you also write pseudocode on a whiteboard, blackboard, sheet of paper or whatever. And if this is not your typical day at work, you're doing it wrong.

<comment><USER35> Look up the prefix pseudo. "supposed or purporting to be but not really so; false; not genuine." Another definition, "not genuine; sham." Pseudocode is not computer code as to your assertion.

I think you are basing your argument that anything written down that can be turned into code is pseudocode. That is also not correct. Pseudocode has a very specific definition. Here is one:

"Pseudocode is an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a normal programming language, but is intended for human reading rather than machine reading."

Flow charts do not use the structural conventions of normal programming languages, they use shapes and text.

If you are writing pseudocode (the actual definition, not your made up one) every day, you are wasting everyone on your team's time. If you are drawing diagrams every day on a whiteboard, you are still probably wasting everyone's time.

<comment><USER94> I can only hope I will never have to work in a team with someone like you. That would definitely be a massive waste of time.

A typical workflow based on a pseudocode is very simple and efficient: you solve your problem in a _pseudocode_ \- an informal language that does not yet exist but captures the essense of the problem. Then, while still on a whiteboard, you refine your pseudocode into something still "pseudo" (i.e., a made up language that does not exist), but _formal_ this time. It may require a couple of iterations to reach perfection.

Then it is pretty much done, the only thing left is to implement this DSL, which is trivial in most of the cases.

This workflow is far more efficient than anything keyboard stomping kids can achieve in their fixed, always unsuitable, overbloated languages.

<comment><USER35> Ok, so I guess by your omission, you agree that pseudocode is not code and flow charts are also not pseudocode. I don't care about the rest, you can whiteboard all you want. We analyze the problem, then solve it in our heads, usually by the time we've finished talking about it. White boarding just seems way over the top, especially if it takes more than one person to solve a problem every day. Sounds like development by committee.

What's 2+2? Lets go to the whiteboard!

Out of curiosity, what industry are you in and stack do you use?

<comment><USER94> > you agree that pseudocode is not code and flow charts are also not > pseudocode

What?

I just demonstrated that pseudocode is an _ultimate_ form of a code, flowcharts included (they're just a graphical pseudocode). Maybe you do not understand what does the word "code" mean?

> What's 2+2?

Is it an average complexity of the problems you're solving?

> stack do you use?

Even your choice of words betrays you. You're a web coder, aren't you?

Just today I spent somewhere around 3 hours writing pseudocode on a piece of paper, and about 30 minutes typing it on a keyboard, testing and debugging. And it's about a typical proportion.

<comment><USER35> Pseudocode has a definition, you can't just make one up in an attempt to not look foolish.

No, automation with AI. DSS mostly. Stacks aren't just for web.

I guess if you are unwilling to share your stack or any information other than the fact that you write stuff on paper and don't know what pseudocode is, then we don't have much to discuss, and you haven't really made any convincing arguments to your "superior" coding methods. I've seen enough BS in my 20 years to recognize yours.

<comment><USER94> > Pseudocode has a definition, you can't just make one up

I'm using exactly the same definition: pseudocode is a made-up language which may or may not vaguely resemble some existing language features.

> Stacks aren't just for web.

Yet, only hipstors use this word in such a context.

I explained the methodology in detail. It is agnostic of a target language or even problem domain.

I'm using it even when I'm writing a pure C++ code, not just when I'm building DSLs directly.

<comment><USER35> You have a strange view of reality, my friend.

<comment><USER94> A mindless keyboard stomper is trying to say something about a "reality". Funny.

Go, solve your "2+2" problems. Hope you have a high enough character-per- second typing rate for this.

<comment><USER35> Let it go, you're wrong. It's obvious that you know you're wrong, otherwise you would argue your position rather than throwing personal insults and a hissy fit.

Pseudocode is not code. Flowcharts are not pseudocode.

You also didn't describe your stack. I just see some fresh meat who desperately wants people to take him seriously, but he has a hard time with it because he's kinda childish, very defensive, and can't argue his point.

Anyway, this discussion is counterproductive, so I'm going to stop reading after this one.

<comment><USER94> > Pseudocode is not code. Flowcharts are not pseudocode.

Pseudocode _is_ code, no matter what uneducated pitiful code monkeys would say about it. Take any textbook on algorithms, and they would be most likely written in _pseudocode_.

Also, in your shameful incompetence you apparently ignored (more than once) my reference to DSLs, which are very closely related to the notion of pseudocode. But, since you know nothing about programming even this was cryptic for you.

> You also didn't describe your stack.

I already told you that I'm not going to even answer a question worded in such a disgusting hipstor argot. I told you everything that is relevant. This idiotic "stack" of yours does not matter. I worked for some blue chips, used a very wide variety of technologies, for domains ranging from hardware design and verification to CADs, database engines and compilers, and everyone I worked with did more or less the same - used either a whiteboard or paper most of the time, with very little time on actual coding / designing / soldering / prototyping / whatever.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


ZeroVM: Virtualization based on Chrome's NaCl - <AUTHOR> http://www.zerovm.org/ <comment><USER2> I have been following ZeroVM since it's inception and often go to the website and stare longingly at my screen thinking of amazing things it could do (when coupled with OpenStack Swift to make "ZeroCloud"). If you look at my HN comment history you can see multiple articles about "serverless" where I tried to tell people about ZeroVM.

But they got bought by Rackspace (who originally open sourced Swift) in late 2013, and then their github account activity dropped to 0 by early 2015. Rackspace has probably one of the worlds largest Swift deployments, so maybe one day they will do some cool things with ZeroVM ala ZeroCloud but for now the forward movement of the project seems dead or at least proprietary :(

Other interesting implementations of the same concept include Joyents Manta, which is also open source and actually probably more flexible than ZeroCloud (you can SSH into your container).

<comment><USER3> Yeah the lack of further work on ZeroVM is unfortunate. You may be interested in [https://github.com/openstack/storlets](https://github.com/openstack/storlets) which is conceptually similar and is being actively developed.

</comment></comment><comment><USER4> "What does ZeroVM virtualize?" Also "Docker vs ZeroVM" at [http://serverfault.com/questions/574504/what-does-zerovm- vir...](http://serverfault.com/questions/574504/what-does-zerovm-virtualize)

<comment><USER5> Thanks for posting that. It was the exact question in my mind.

For anyone who's worked with it, does the fact that it's pure userspace have any negatives? Performance? What about access to system resources, opening sockets, etc.

<comment><USER6> I don't know anything about ZeroVM, but performance would only come into play when/if it crosses boundaries, and even then, only if the APIs at the boundary are slow. User space on Linux provides a lot of features to make crossing boundaries not slow. Zero copy write with sendfile(), efficient async I/O with epoll(), etc. are tools to allow user space applications to cross that boundary efficiently.

That said, user space file systems are slower than in-kernel file systems; at least, according to the data I've seen. But, I suspect ZeroVM will be used in ways that aren't quite the pathological case of a user-space filesystem under benchmark load.

As for access, Linux has a nice capabilities system to allow user space to access privileged resources as a non-privileged user and without being in ring 0 (if privileged access is even needed, which it likely won't be in the cases where this will be used, I would think). Again, this would still be through the public APIs, and not by acting like the kernel and hitting the hardware directly.

I don't think, or get the impression, that this would be used for full-system virtualization. It seems to be more targeted toward an AWS Lambda sort of usage pattern; a micro-VM that spins up to serve one API request, or to act as a long-running tiny daemon to do some housekeeping task. It looks like a fancy fork(), to me, rather than a competitor to Docker or LXC (and especially not KVM or Xen, which can run a whole Linux kernel in the VM).

<comment><USER2> > I don't think, or get the impression, that this would be used for full- > system virtualization. It seems to be more targeted toward an AWS Lambda > sort of usage pattern; a micro-VM that spins up to serve one API request, or > to act as a long-running tiny daemon to do some housekeeping task. It looks > like a fancy fork(), to me, rather than a competitor to Docker or LXC (and > especially not KVM or Xen, which can run a whole Linux kernel in the VM).

Almost. With ZeroCloud (OpenStack Swift + ZeroVM + appropriate middleware), you should imagine Lambda+S3 in the same service! Your "function" executes much, much closer to the location of the data, it doesn't require "shipping" from the storage service to the compute service and back again. You can take in an object, perform a transform (e.g. text search, encryption, transcode, etc) and store the result as a new object.

If you think about it, it's kind of the future of large scale computing, immutable dataset + immutable compute, that can horizontally scale to huge numbers of nodes.

<comment><USER6> > With ZeroCloud (OpenStack Swift + ZeroVM + appropriate middleware), you > should imagine Lambda+S3 in the same service!

Is that something that exists in a production form today? What's an example of the use case? I'm having trouble visualizing this "Your "function" executes much, much closer to the location of the data, it doesn't require "shipping" from the storage service to the compute service and back again." That sounds like going back to a monolithic model where data and functions are tightly coupled, but I assume I'm visualizing it wrong, since that would be moving backward.

<comment><USER7> Suppose you have a dataset big enough that it needs to be spread across a storage cluster. Now you'd like to run some kind of operation that's either completely parallel, or fits the map/reduce model. Maybe you have a petabyte worth of video files and you want to generate thumbnails, or extract metadata, or find all frames of video with text in them.

If compute is separated from storage, then all of that video data has to be streamed over the network from a storage node to a compute node before computation can even begin; the data is "shipped" to compute.

Presumably the function you want to execute is vastly smaller than the data. It would require much less time and bandwidth to run the function on the same node as the data it's accessing; no network overhead. Assuming you have an adequate balance between compute and storage, you get much lower latency access to the data.

Some downsides include \- running arbitrary code on your storage node means trusting your users or having very good sandboxing \- you now have to balance compute and storage on any given node

</comment></comment></comment></comment></comment></comment><comment><USER8> I have always been a fan of ZeroVM. I had decided to take the task of adding multi-threaded support so that we'd have NaCL-enforced security and performance constraints, rather than depending upon the Linux kernel for the same. This turned out to be more complex for my skill levels and I gave up mid-way.

I recommend that you try out ZeroVM for your Python apps. I've seen great demos where Rackspace devs applied on-the-fly transformations to content being served from swift. e.g. one demo added watermarks to files, another transcoded video streams.

At a ZeroVM workshop in Atlanta at the OpenStack summit some years ago, one of the participants started a discussion with the ZeroVM devs about running ZeroVM apps via the firmware of SSD drives.

Unfortunately, this nice technology didn't quite catch on.

</comment><comment><USER9> Isn't NaCl completely destaffed an no longer being developed?

[https://bugs.chromium.org/p/chromium/issues/detail?id=239656...](https://bugs.chromium.org/p/chromium/issues/detail?id=239656#c160)

</comment><comment><USER10> ZeroVM reduces the accepted X86 instructions and also restricts more syscalls than Google NaCl.

Per Google's NaCl devs, NaCl's restrictions result in an average of 10% drop in performance, though it's application specific. ZeroVM should result in slightly greater drop in performance given its restrictions.

</comment><comment><USER11> Maybe someone can mark this is 2015? This is from 2 years ago...

</comment><comment><USER12> To make this project viable they would have to re-build it around WebAssembly[1] instead. NaCl was conceived before WebAssembly emerged as the standard for binary executables for the web and is now in maintenance mode.

[1] [http://webassembly.org/](http://webassembly.org/)

<comment><USER13> Why would they rewrite this for the browser?

<comment><USER12> Not for the browser but NaCl is going to get less support from compiler toolchains now that WebAssembly it there.

</comment></comment></comment><comment><USER14> CloudABI anyone? [https://nuxi.nl/](https://nuxi.nl/)

</comment><comment><USER15> (2015)</comment>


From Hackathon to production: building a large scale recommendation engine - <AUTHOR> http://exchange.causes.com/2011/07/causes-tech-a-recommendation-engine-that-could/

<comment><USER2> Could you recommend some good resources for learning more about collaborative filtering? I'd love to help hack, but feel like I should learn more first.

<comment><AUTHOR> Most of what I learned was from Programming Collective Intelligence (<http://amzn.com/0596529325>). If you're in the Bay Area, Noisebridge has a self-taught machine learning class that I went to for a while (great group, I just couldn't make the time commitment).

<comment><USER3> for most of the fundamentals on Collaborative Filtering, You may check Chapters 8 and 9 from the following online book.

[https://docs.google.com/viewer?url=http%3A%2F%2Finfolab.stan...](https://docs.google.com/viewer?url=http%3A%2F%2Finfolab.stanford.edu%2F~ullman%2Fmmds%2Fbook.pdf)

</comment></comment></comment><comment><USER4> have you looked at Mahout? [https://cwiki.apache.org/confluence/display/MAHOUT/Itembased...](https://cwiki.apache.org/confluence/display/MAHOUT/Itembased+Collaborative+Filtering)

<comment><AUTHOR> Hm, I haven't. This suggests that Mahout might not work well for datasets on the scale we're dealing with (working toward 1 billion membership rows):

[http://lucene.472066.n3.nabble.com/Mahout-not-giving- recomme...](http://lucene.472066.n3.nabble.com/Mahout-not-giving- recommendations-with-large-data-sets-td641249.html)

But that's also an older article, and things might be better. Mahout might be worth checking out.

</comment></comment><comment><USER5> excited!</comment>


Rudy Huyn brings apps to the people - <AUTHOR> http://news.microsoft.com/stories/people/rudy-huyn.html

<comment><USER2> "It's like Disneyland," he said. "Every time I meet a Windows Phone developer, I want to take a picture and thank him."

Yeah everytime I meet one.. wait, no, Haven't met one yet. Have you ?

<comment><USER3> Yep, I've met a few actually.</comment></comment>


Efficient JavaScript - <AUTHOR> http://dev.opera.com/articles/view/efficient-javascript/ <comment><AUTHOR> Perhaps nothing new here but a good read if you haven't made it through some of the JS performance canon (High Performance JavaScript et alia) or want a refresher</comment>