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

~~~
billsparks
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)

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

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

~~~
sundvor
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).

------
kayman
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?

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
pmiller2
Hah, yes. That's probably the simplest application of the pumping lemma I can
think of.

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

------
soham
[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)

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

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

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

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

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

~~~
p4wnc6
You're totally right. I was confusing the stated problem with a common
associated problem: whether a string is a permutation of a palindrome.

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

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

~~~
NhanH
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?

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

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

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

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

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

~~~
thedufer
The most common dialect is PCRE. Most languages have an implementation of
either that or a superset of it.

~~~
hvidgaard

       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.

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

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

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

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

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

Quick check list:

1\. Knows about es6

2\. Knows about === and !==

3\. O(n) efficiency with no memory bloat

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

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

~~~
jameshart
5\. Didn't meet the specification.

You need to ignore white space and punctuation.

6\. Didn't include any tests

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

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

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

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

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

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

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

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

~~~
Retra
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."

------
FigmentEngine
"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

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

~~~
judahmeek
Nicely done. xD

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

~~~
Clubber
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?"

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

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

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

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

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

------
hvidgaard
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?

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

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

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

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

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

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

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

~~~
ci5er
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?

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

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

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

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

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

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

I assumed that I could type without makig mistakes.

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

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

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

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

~~~
vonmoltke
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.)

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

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

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

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

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

~~~
bithub
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 ;)

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

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

~~~
collyw
OK, ask the people who get their annoying ads popping up on screen.

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

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

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

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

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

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

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

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

------
christop
The only winning move is not to play.

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

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

------
prirun
To me, the first good questions would be:

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

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

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

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

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

    
    
        import sys
    
        # the straightforward way, char-by-char compare
    
        def pal1(s):
            slen = len(s)
            slenm1 = slen - 1
            for i in xrange(slen/2):
                if s[i] != s[slenm1-i]:
                    return False
            return True
    
        # s[:-5] === "the last 5 (or fewer) characters of s"
        # s[::] === s === s[start:end:incr], where start=0, end=len(s), and incr=1
        # s[::-1] === reverse(s) == s[end:start:incr], where start=0, end=len(s), and incr=-1
    
        def pal2(s):
            return s == s[::-1]
    
        # select which palindrome function to use
        pal = pal1
    
        # test with:
        # 1. null string
        # 2. single char (odd length)
        # 3. double char string (even length)
    
        if __name__ == '__main__':
            if len(sys.argv) != 2:
                print 'usage: pal <string>'
            else:
                s = sys.argv[1]
                if pal(s):
                    print 'yep'
                else:
                    print 'nope'

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

~~~
Programmatic
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, '');

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

But the example solution is so bad anyway.

~~~
Programmatic
What's your preferred solution?

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

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

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

~~~
Programmatic
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?

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

------
dominotw

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

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

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

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

------
amai
"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/)

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

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

------
snarfy
> Your code should avoid breaking at all costs.

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

~~~
pc86
"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?

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

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

------
WalterBright
-1 point for not testing "Bolton".

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

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

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

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

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

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

------
coldcode
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?

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

------
edoceo
Would not get the job here.

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

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

~~~
logfromblammo
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?).

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

>When I offer a challenge like this in an interview, the first thing I’m
looking for is wether or not you ask me any questions

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

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

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

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

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

------
hiou
_The only winning move is not to play._

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

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

~~~
sklogic
Flowcharts _are_ code. Pseudocode _is_ a code.

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

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

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

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

~~~
Clubber
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?

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

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

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

~~~
Clubber
You have a strange view of reality, my friend.

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

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

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

