
Interviewing for a JavaScript Job - wallflower
http://raganwald.com/2015/02/21/interviewing-for-a-front-end-job.html
======
millstone
I loved this post and also the HN comments, which show a wide variety of
interpretations.

My interpretation is that the article satirizes modern JavaScript development
_and_ startup culture, both of which are heavy on sizzle but lean on steak. It
skewers the interviewer, who "intones" a highly refined question that's
totally disconnected from the actual content of the position. But it also
skewers the candidate, who happily provides an elaborately over-engineered
solution that shows off "modern" JS development practices.

The candidate and interviewer learn nothing from each other, but we are left
certain that, if hired, the candidate's chief legacy will be a GitHub repo of
a JavaScript MVC templating micro-framework that leverages JQuery and Backbone
and...

~~~
thewarrior
What is over engineered about his design ?

It's actually well designed.

~~~
batiste
I would just have used a position hash map and be done with the problem in 30
seconds. His solution is definitely heavily on the over-engineered side of
things.

If somebody would pull something like the author in a interview, I would
surely be impressed but it would be a read flag if it is really the way it
handle simple problems like this on a daily basis.

~~~
rtpg
there is the detail that if the interviewer wants it to be a constant-space
mechanism, that you'll want to use the linked-loop cycle detection algorithm

~~~
Udik
The interviewer requires for a solution in finite time and space, and
explicitly says that the size of the chequerboard is unknown but finite. The
constant space requirement is totally made up by the interviewee.

Also, the code is a bit muddy to me, but it seems (please tell me if I'm
wrong) that the proposed solution requires being able to move _two_ separate
pointers on the chequerboard. If this is true, note that the specification of
the problem is

"A chequerboard is _hidden from us_. A player (note: a _single_ player) moves
the chequer one square _and calls out the move_ ".

For how the problem is stated, there is no chance of moving two separate
pointers along the chequerboard. The list of moves could be streaming through
a web service, so in order for the tortoise to move at half the speed of the
hare, we'd need to remember in an array all the moves that separate the
tortoise from the hare, making it for a solution equivalent to the plain and
readable one.

So it sounds like the zealous overengineering somehow (in fact through the
usage of iterators) brought the interviewee to a solution that's plain wrong
with respect to the given requirements. Where did I see that before? :)

~~~
picks_at_nits
This is why a more interactive interview is useful. Christine could ask
politely, “How would this work if you were given a streaming web service,
instead of an iterator that you could restart? What would you change?”

It would be interesting to see if The Carpenter threw the whole thing out, or
simply wrote a memoizing cycle detector in place of the last step. That could
lead to a discussion about separation of concerns.

~~~
Udik
Apparently Christine failed to notice that the code doesn't respond to the
requirements as they're laid out. She would have at least had a better reason
for rejecting the Carpenter: she could have said "writes unreadable code that
doesn't even respond to requirements".

However, the fact that Christine couldn't even tell that the code was not
working reinforces the correctness of her hunch: hypnotized by the unreadable
code, neither her or the interviewee could see clearly that it wasn't fit for
the intended purpose. And this is clearly a serious issue.

I agree that an interview should be more interactive than that, but one could
easily blame the Carpenter for having transformed the answer to a simple
question into a long monologue that lead nowhere. I can't help but feeling he
got what he deserved, although I'm afraid that, in the real world, his
confidence and command of technicalities would have gained him the job on the
spot.

~~~
picks_at_nits
Let’s not fall into the common trap of assuming that blame is a zero-sum game.
I have no problem blaming all three of the participants for what happened
here.

------
zaroth
I'm obviously way behind the times here, but... what the heck have they done
to Javascript?!

Anyway... the worst case run-time of any algorithm I think is size-squared --
you have to look at every square. If you ever touch the same square twice,
since the state of each square is constant, you have a loop. Therefore, either
you use a bitmap to see if you've been there before, or just check if a move
counter is greater than size-squared.

If someone spent an hour discussing this problem in an interview, even if it
seemed intelligible, honestly I doubt I would want to pursue it further.

~~~
alisey
The question starts with: "Consider a finite checkerboard of unknown size",
which means you don't know the value of size-squared. Bitmap requires O(n)
space, while the Carpenter's solution requires only O(1) space. And both
require O(n) time. If an interviewee failed to see the difference, honestly I
doubt I would want to pursue it further.

~~~
Jare
"size" is perfectly known in the code. Before shooting off into functional
rearchitecture land, a simple common sense question like "by unknown you mean
arbitrary, right?" would have been more sensible. In addition, the candidate
thinks "being asked to whiteboard code was an excuse to have a technical
conversation with a future colleague" but spends the entire time having a
monologue rather than a conversation, and seems pleased about it.

------
Falkon1313
1) We will also need to hire a 'pretentious <-> English' translator just to
communicate with this guy. He's probably also very opinionated and difficult
to get along with.

2) His state-of-the-art code won't work on any of our deployed systems without
lengthy and expensive upgrading or backporting.

3) We'll have to get all of our clients to upgrade their systems, or spend a
ton of money and time adding compatibility layers.

4) None of our other developers will be able to maintain his code, and hiring
someone to replace him would not be easy or cheap.

5) If we need to hire a 3rd-party agency for something, they wouldn't be able
to work with him or his code either. It could cost us a fortune.

He may be brilliant, but basically, we'll have to treat everything that he
does as disposable, just as we would with a clueless newb who knows nothing
about programming. And we can't entrust him with anything important.

~~~
picks_at_nits
The story is really about what’s wrong with this process. You say the
candidate should have written production code. And yet, this isn’t a
production problem, it’s a made-up CS101 problem. How does it make sense to
ask a CS101 question, but not accept a CS101 answer? Likewise, how does it
make sense to give a CS101 answer without knowing what the interviewer is
looking for in an answer?

How do we know this is the code this person would write in production if we
don’t give him a real-world problem to solve and ask him to solve it in a
real-world way?

If it’s legit to assume that this person only knows how to write theoretical
code from one answer, it’s also legit to assume that the company only has
theoretical problems to solve from one question.

In reality, it’s insane to presume anything from one answer. If you want to
know what this person writes in production, you ask about that. This is an
experienced programmer being interviewed, how does it make sense to terminate
the interview after asking one poorly-given question?

Really, this is about a failure to communicate on both sides. For questions
like this, if you don’t make it clear what you are looking for, you aren’t
really testing their technical competence, you’re testing their ability to
guess the answer you’re looking for.

Likewise, if you aren’t given clear guidance about what kind of answer the
interviewer is seeking, your responsibility is to ask for guidance, not to
rush off and give the answer you think suits your agenda for showing off or
for sparking the conversation you want to have.

Failing either or both parties actually talking to each other, this isn’t a
technical question at all.

~~~
beaknit
"if you don’t make it clear what you are looking for, you aren’t really
testing their technical competence, you’re testing their ability to guess the
answer you’re looking for"

^ +1

Google stopped doing this for a reason. Give people real problems to solve,
then dive deep on their answer. Unless you're interviewing for an algorist,
this is a waste of everyone's time.

------
rayiner
I personally think the answer here is fantastic. It shows several important
things: the candidate keeps up to date with the tools, he thinks about
problems formally and systematically, and has a solid grasp of theory. Not
only did he decompose the original template into one that leverages existing
utility functions, but written the solution in a mostly functional way where
mutable state is localized in specific functions. You can easily extend his
solution with more analyses.

The interviewer asked a simple question designed to screen the clinically
incompetent, and this guy used it as an opportunity to show the extent of his
skills and knowledge, _which is the whole point of an interview._

~~~
badc0de
I hope I never get to work with someone like the carpenter.

~~~
morenoh149
you're missing out. I hope to be the carpenter's apprentice!

------
sirgawain33
Unless I'm being thick, I think the point of this parable is to question the
developer, not the interviewer.

Despite using a bunch of fancy new language feature, name-dropping Knuth, and
describing the solution for an hour, the result is code with no additional
benefit and significantly worse maintainability.

Sometimes being smart doesn't have to look so smart.

~~~
supercoder
Looking at the previous posts by this author it looks as though he's got a
very specific interest in playing with JavaScript language features.

So I'm guessing this wasn't ever a real situation, just a fantasy story about
how he'd love for an interview to play out.

~~~
picks_at_nits
And yet... At the end of the story, all three participants (recruiter,
company, and candidate) have failed to get what they want.

Somehow, this does not come across as a fantasy being played out, more of a
cautionary tale.

~~~
nostrademons
In the story, the very next day The Carpenter got a generous contract from
FOG, a stealth startup doing very interesting work, and promptly forgot all
about Thing. It sounds like he got exactly what he wanted.

~~~
picks_at_nits
That might be a red-herring. When times are good, people get positive
reinforcement for doing bad things. Thing might hire the next programmer, and
the Carpenter gets the next job, and everybody assumes that the right best way
to conduct an interview is for both people to “flip the bozo bit” on each
other as soon as possible.

Then when it becomes hard to find good people, Thing suffers because they are
too quick to reject people based on one answer. And if the Carpenter finds
there are few jobs that suit his criteria, he has trouble getting one with the
style of answer he tries to jam into every question.

That’s a bit of a metaphor for how many (but not all) companies become
internal shit-shows in tech. They get a lot of positive feedback (raising
money, adulation from HN) for their tech, but meanwhile are terrible managers.

It takes great discipline (and possible great mentoring) to say to yourself,
“things are going well, but what am I doing wrong that I just happen to be
getting away with?"

~~~
nostrademons
You bring up a good point, but it's not one supported by the text of the
story. Perhaps that's _why_ it's a good story: everybody reads into it their
personal experiences and assumes it means what they want it to mean.

FWIW, the meaning I took away from it is "Well, this is a cool way of looking
at things. Some people will run away screaming, some people will appreciate
it. If you want a happy life, find the people who appreciate it and don't
worry so much about the people who don't see things your way."

------
joncalhoun
This boiler plate code seems pretty bad to me. It is almost as if it was
designed to trick candidates by giving them access to data they aren't
supposed to use.

The problem clearly states "The game board is hidden from us" yet the boiler
plate code gives a developer access to the size of the board as well as the
current position. It is as if the interviewer asked carpenter to solve problem
A then gave him boiler plate code for problem B.

------
mesozoic
Perhaps not unreadable but definitely way overly complex. I'd be much more
happy with the 2-4 line solution that is obvious and move on to another
question or work on then optimizing that for performance time or memory size.

~~~
inglor
The candidate did not "optimize it for performance time or memory size".

I love how the candidate integrates a lot of ES6 features and even basic
algorithms into this. I would kill for candidates like this when I interview.
It doesn't only show that they keep updated in the field which is important on
its own - it shows that they understand the fundamentals.

When I'm interviewing I _am_ interested in seeing this in a candidate. At the
end of the day the candidate _did_ solve the problem.

~~~
figseed
The candidate may have solved the problem, but failed the task.

At the outset, the interviewer placed a premium on time which the candidate
ignored. The candidate made assumptions that the question was contrived
therefore the solution offered was simply a place to make speaking points as
well as test the interviewer's code literacy and as a result, spent the entire
interview rewriting the system rather than filling in the blanks and moving on
as asked.

Did the candidate prove adequate experience? Sure. But at the day of the day,
I feel the interviewer made a very reasonable decision to dismiss the
candidate based on the fact that the response ignored the implied time
constraint for the sake of adding superfluous nonsense.

If I ask someone to fix a simple bug in some of my code and come back to see
the code completely rewritten, 3 times the length with prince of darkness and
tortoise and hare stuff mixed in, that would likely be the last time I ask
them to touch my code.

~~~
nine_k
I don't see any mention of time constraints, except for "to save time, we have
written some boilerplate for you". I wish my prospective employer clearly
communicated key constraints like this.

If I were the candidate, though, I'd first explain the idea of the solution
(takes half a minute), then discussed ways to implement it (a minute or two),
then went with a particular solution (counter, bitmap, two chasing indices,
etc). I'd keep feedback from interviewers constantly flowing.

~~~
madeofpalk
Well, it's an interview. As both an interviewer and interviewee, you should be
respectful that time is finite.

------
badc0de
I'm surprised why no one has mentioned the fact that the recruiter hinted the
candidate and that the candidate could've prepared that convoluted answer
beforehand. I would've certainly not hired him. Also, it is stupid to measure
if a candidate knows some graph algorithm that you learn in CS 101 or some new
js features that no one in their sane mind would use in prod, you should
probably be more worried about thought process, concepts of modularity,
maintenability and experience.

~~~
monokrome
Third-party recruiters will often hint these types of things, because it gives
the candidate a better chance of success.

After you interview, they will ask what you talked about and what kinds of
questions you were asked. This allows them to keep track of how the company is
interviewing, and to give the next candidate more information about what to
expect.

This will mean that the recruiter doing so will have a potentially higher rate
of success than a recruiter not doing so, since the candidate has this
benefit.

Honestly, it's a pretty good thing. It's just good recruiters exploiting bad
interviewers. It's better to design your interview around each candidate
instead of recycling the same comp-sci questions that you heard in college
over and over again.

Companies are really just testing how often people interview in most cases,
but don't realize how bad the process is. They are using the same questions
that every other company uses instead of creating their own, and it usually
doesn't find good candidates as much as it finds people who memorize interview
questions.

------
patmcguire
I felt dumb not recognizing const, let, or the fat arrow as javascript
constructs...

Are they Firefox only? Or is Firefox the only one shipping the new standard?
All my Googling only gives me Mozilla results; I do JS full time and haven't
heard of these.

~~~
jekrb
A nice set of slides explaining es6 syntax.

[https://speakerdeck.com/rauschma/using-
ecmascript-6-today](https://speakerdeck.com/rauschma/using-ecmascript-6-today)

------
madsravn
This article is a little weird. First we have this guy, who despite his
experience "makes" the mistake of saying he can show something on the
whiteboard. Why is that a mistake?

And then we have this guy Bob - he coaches people what kind of questions they
are asked at a given interview. So he is letting people get jobs which they
might not even be suited for.

I hope it is satire, as mentioned somewhere else.

------
supercoder
I would just leave if this actually came up in a real interview.

~~~
geebee
This sort of thing deters me from interviewing in the first place.

------
scotty79
And all of that because he didn't notice that requirement was finite space not
constant space.

If someone asks you to buid a shed and you build space station then put it on
their backyard for them to keep tools in don't be suprised that the answer
you'll get is "We're not gonna pay for that".

Anyway nice short story. Pleasent read.

~~~
inglor
The protagonist didn't build them a space station - they have effectively
shown understanding of the problem by reducing it to the problem it really is
(cycle detection) showing them he understood the idea and not just how to
solve it while using modern tools and correct abstractions (sequences,
really).

It's especially "provoking" since the author mentioned it was a Python shop
and Python is _full_ of these - a lot of lazy sequences and generators all
around and a community that understands them well too.

~~~
scotty79
Except that it's not about cycles detection in a linked list. It's about thing
as simple as 'if I am where I have aleady been then I'm screwed'. You just
need to remember stuff and recall it as quickly as possible, so hashmap. It's
finite because size of the board is finite. End of story.

His solution is just worse. His solution is slower because he picked
inadequate data structures and he used algorithm for finding cycles that's
only interesting because it can operate in fixed space but it's use is totally
stupid because he constructs the linked list himself and that takes in worst
case amount of memory proportional to number of fields on the board.

It's a task you can figure out just by thinking few minutes about the problem
without any prior knowledge so a good test question for checking your ability
to think.

The only reason you might come up with the solution OP presented is if you
were told to 'do it as if js was haskell or something'

~~~
picks_at_nits
Where does the solution given use On space?

~~~
scotty79
Sorry. My mistake. It doesn't. It cheats its way out of it by running game
twice instead. That's why it needed to turn Game into iterable or at least
generator function not just a generator intance.

~~~
picks_at_nits
Not to worry. I have it on good authority that the author thinks all three
fictional parties are at fault.

------
scotty79
Is there a point there to returning object with generator in the
[Symbol.iterator] property instead of just the generator itself?

~~~
inglor
Generally? Yes, for example for an array like data structure it would make
sense to have methods on the data structure and make it iterable by providing
a `Symbol.iterator` - in this case it can be avoided a generator is just a
function that returns an iterable sequence (i.e. a sequence using the new ES
iteration protocol) so usage would be different - you'd invoke it in a
for...of instead of just iterating it.

~~~
scotty79
General usage I get. I just don't see the point of using it in this example.
Everything else can be explained by 'I wan't my data structures to be
immutable and lazy'.

Symbol.iterator just seems like purposeless showing off.

As for your last point, you wouldn't have to invoke in for...of if you
returned generator instance, not generator function from your code.

~~~
madeofpalk
> Symbol.iterator just seems like purposeless showing off.

That's the point.

------
ctaylor001
I feel like this is a roman à clef and I'm missing the clef.

What's the story with the repeated John Carpenter references?

~~~
inglor
I think that this is the correct reference [http://ntraft.com/the-carpenter-
and-the-engineer/](http://ntraft.com/the-carpenter-and-the-engineer/)

~~~
harlanlewis
> Some time later, The Carpenter ran into Bob Plissken at a local technology
> meet-up. “John! What happened at Thing?” Bob wanted to know, “I asked them
> what they thought of you, and all they would say was, Writes unreadable
> code. I thought it was a lock! I thought you’d finally make your escape from
> New York.” > The Carpenter smiled. “I forgot about them, it’s been a while.
> So, do They Live?”"

The character's name is "John, The Carpenter".

bob plissken -
[http://en.wikipedia.org/wiki/Snake_Plissken](http://en.wikipedia.org/wiki/Snake_Plissken)
the thing -
[http://www.imdb.com/title/tt0084787/](http://www.imdb.com/title/tt0084787/)
escape from new york -
[http://www.imdb.com/title/tt0082340/](http://www.imdb.com/title/tt0082340/)
they live -
[http://www.imdb.com/title/tt0096256/](http://www.imdb.com/title/tt0096256/)

FWIW, I don't get the connection to javascript interviews either.

~~~
tvmalsv
Let's not forget Assault on Precinct 13 (www.imdb.com/title/tt0074156/) and
Christine (www.imdb.com/title/tt0085333/) :)

~~~
TheOtherHobbes
They Live is a Carpenter movie in which aliens in invisible pizza masks - you
can see them if you have special magic shades - live among us and control us.

[https://www.youtube.com/watch?v=Wp_K8prLfso](https://www.youtube.com/watch?v=Wp_K8prLfso)

And of course there's The Thing, which does an excellent job of explaining why
you should you never allow important data to be mutable.

------
GhotiFish
You know what. Criticisms and thoughts of this article aside, I do love
thinking about problems, and solving problems.

I feel gratified to get the jump from looping -> halting problem, (though the
author obviously telegraphed it), and though I found the implementation he
provided to be a touch over engineered, I did enjoy walking through with him.

I agree with the majority of HN, but to be candid, I think I would of enjoyed
being in Christine spot.

------
aristidb
I read this as a parable about abstracting & decomposing problems, and how
lazy evaluation makes it easier. Also, about how you can write Haskell in
Javascript.

------
Kiro
So how would the expected answer look like?

1\. Create an array of visited squares

2\. Return false if square has been visited before, add current square to
visited

3\. Return true

Would this be correct?

~~~
thewarrior
Sort of. Store the squares in a hash map with the value used to indicate
whether you've already seen it.

------
voyou
The code here repeatedly defines functions which return an object with only
one property, with the name being Symbol.iterator and the value being a
generator function. Is there a reason to do this, rather than just writing a
generator function directly?

~~~
inglor
Well, you can't iterate a generator without invoking it. If you returned a
generator you can't `for(let x of myGeneratorFn)` because it's not an iterable
- rather a generator is just sugar for a function that returns an iterable.
You'd have to do `for(let x of myGeneratorFn())` although in this case I agree
it's silly to return it like this.

~~~
scotty79
He couldn't return generator instance because he needs two instances of game
running at the same time for the tortoise and hare algorithm to run in const
memory.

He would need to return at least generator function but that would force him
to invoke it before iterating.

------
jdauriemma
If you engineer a solution for a terrible game and no one actually plays the
game, does a problem really exist?

------
_RPM
Hey I think this should be called "Interviewing for a JavaScript game
developer job". Asking people to implement a game as a test to see if they
know JavaScript is in my honest opinion not the best way to probe a person.

~~~
myhf
They didn't ask him to implement a game. The game board was a metaphor for an
arbitrary network of states.

~~~
wavefunction
If you're trying to solve this problem in JavaScript and it's not a game then
I think you're doing something wrong(ly).

------
bootload
_" Writes unreadable code."_

Code is meant to be executed first, read second.

Programmer A's reply was a terse, when Programmer B commented on some piece of
code they couldn't understand. _' I can't read it, what does this do?'_

Code and its readability wasn't the problem.

~~~
jack9
> Code is meant to be executed first, read second.

Knuth would disagree, as would anyone who had to maintain code...ever. Nowhere
in the convoluted answer, did the carpenter explain the conceptual strategy of
the solution. At least, that would have gotten a discussion going by replacing
??? with a comment. Instead they just chose to pontificate random aspects they
considered important on a path that only they knew, assuming their approach
was optimal (which it is not). That's pretty useless at any company.

