Hacker News new | comments | ask | show | jobs | submit login
Interviewing for a JavaScript Job (raganwald.com)
163 points by wallflower on Feb 21, 2015 | hide | past | web | favorite | 113 comments

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

What is over engineered about his design ?

It's actually well designed.

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.

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

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? :)

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.

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.

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.

great point, didn't think of it like that before. I imagine there's no way to do online cycle detection in constant space?

In fact there is, check Alisey's excellent answer. I think this thread highlights perfectly the difference between pedantic overengineering and clear thinking.

It certainly is marvelously designed, not too amazing considering that Carpenter knew that it is one of the possible questions and he prepared his answer beforehand.

Anyway, judging by the provided code, Carpenter should have done only basic alteration to the original code in the marked spots (// ???) which should have been enough for the interviewer, so that they might have moved on to the next question if there was one:

> Christine looked at the solution on the board, frowned, and glanced at the clock on the wall. “Well, where has the time gone?”

If this happened in real life it would be frikkin awesome. The interviewer would be flabbergasted. There are a couple of other blog posts in this genre :



Another interpretation would be the candidate wasted all their time over engineering when a quicker solution would have done just fine.

No wonder he never heard back.

You'd be concerned that he tried to show off in a problem that was clearly highly contrived for the purposes of an interview?

Well, I'd be concerned too. But just ending the interview process immediately is incredibly naive.

If you see a candidate do something like this, your reaction is probably a mixture of (1) being impressed; (2) being wary that they're always going to be like this. So what do you do? You ask them about (2).

But of course, that's not going to happen in this example, because the company is implied to have an incredibly rigid interview process which cannot be modified or adapted at all on the spot.

The interviewer ran out of time - there was no choice but to end immediately, so you would have to either invite them back or call them later. eh. too much effort. Lets just hire the other guy.

Yeah, I imagine that would be quite weird.

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.

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.

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

Time and space complexity is obvious, and I agree I would want the interviewee to understand that. Like I said, the worst case is always the number of squares (just imagine the path of arrows walks through the entire board) so you can achieve O(1) space, O(n) time with just a move counter.

What I missed is the requirement that you ignore the known upper bound, even though it's right there in the code, and so you can't use the move counter technique to achieve O(1)/O(n), you have to use the cycle-finding algorithm, which is slower but at least still not quadratic.

  "Your code should not presume anything about the gameboard’s size
  or contents, only that it is given an arrow every time though the
  while loop."
It's not a bad question, but I think starting it off by asking them to write code inside the game function is a red herring. The function should be boxed off to return the sequence of arrows to start with, and then let the game begin. That way the requirements are clearly defined up-front.

However, in my experience 0% of interviewees I've ever sat with, given such a function, ES6Fiddle and nothing else, would actually be able to implement Floyd's cycle finding from memory. Unless of course the recruiter prompted them to study it the night before.

If you're adverse to providing full internet access during interviews (which I always do) then at least you would have to provide an excerpt from a relevant textbook or Wikipedia to set them on the right path.

I gave this question to a friend and she came up with what I think is a beautiful answer. Remember min and max X and Y coordinates seen so far, and count the number of steps. When this number gets larger than (maxX - minX)*(maxY - minY) we know we're in a cycle.

It's an extension of your idea of counting the total number of visited positions. What I like most about it is that it can work with streamed data.

That's a really cool solution. One potential problem is that it doesn't find the loop as soon as possible (e.g. if it's going around the perimeter of a square, the cycle is detectable after 4N steps, but the algorithm will take N^2 steps to realize that)

That's nice (and can be easily fixed to handle negative coordinates), but extremely slow (imagine a simple square cycle with side length N. Her solution takes N^2 steps.

Perfection! A beautiful hack around not knowing the size of the board, and even faster detecting cycles to boot.

I think it's the best answer so far!

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.

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.

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

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.

I'm not sure about you, but it took me until halfway into the reading to figure out that the interview was actually being honest. It may be just bad comprehension on my part, but the phrasing of the circumstances of the interview, as well as the way the interviewer spoke ("ECMAScript 2015"?), made me assume it was going to be some sort of satirical article.

That, as well as the ball of code that was the boilerplate, made me assume that this was some kind of parody of actual interviews. It wasn't until I was reading through the tortoise-and-hare bit that I realized the author was actually being serious.

Honestly, I'm kind of surprised that that kind of question even comes up in interviews--I think like easily 99% of a startup's tech problems are probably better reflected by "How do we handle rounded corners in legacy browsers" or "How do you provision a server because we can't afford AWS" or "What would you consider three essential libraries for Javascript on the backend, and why?".

These CS questions just seem like underhanded trivia, especially when you dress up straightforward problem with a bunch of extra noise. They'd be fun to work through with an interviewee, as a way of seeing how they think about a problem, but just dropping it on them as sink-or-swim in a hostile environment doesn't seem very nice.

I don't think this is an underhanded CS question. It just asks if you can make the conceptual leap from: "does the game terminate?" to "does the sequence get stuck in a loop?" They don't ask for the constant-time cycle finding algorithm, which someone may not necessarily know, but I think the interviewer's providing it reflects well on him.

So, I agree that the interviewee in the story did the correct thing, but the part where they are describing their reframing of the question ("So, I am to write an algorithm that takes a possibly infinite stream of…”) and then are just cut off (interrupted, as the story says) is kind of what I'm getting at. Like, if that happened in normal conversation, you kind of assume that either the person you're talking to is an asshole, or they are correcting your course because you are going down the wrong path.

That, plus the setup of the code with all the variables right there, meaning that you'd of course be tempted to break encapsulation and solve the problem by just adding a "visited" flag to each board[x][y] cell. That's the smarter engineering thing to do, because you a) have access to that state as the problem is setup and b) know that visiting any cell will only ever land you in the same successive cell.

Again, the question is bad because it takes a reasonable question ("Can you detect this loop?") and then foists on the interviewee boilerplate that literally begs to not follow the problem constraints.

Good point.

> The interviewer asked a simple question designed to screen the clinically incompetent

Have you actually interviewed developers? I have interviewed around 50-60. There's absolutely no way even 2% would answer that question correctly, unless we're talking Google/Apple/Facebook candidates.

I myself would probably fail to remember Floyd's algorithm, it's been too many years since my comp sci competition days (I used to do ACM, Topcoder, others). But I can certainly find it and implement it if I ever face a problem like that.

If you had recently graduated, it may not seem that way, but wait 20 years, and all the algos that you don't use regularly will be forgotten.

If you're going to ask tricky algo questions, you must allow people to use the internet.

Except that, unfortunately, Carpenter gave a wrong solution, showing that he's somebody who likes to write complex code for the purpose of showing off, but he's not particularly interested in understanding the requirements. It would have been enough for Christine to say:

"Ok, let's try your code. I'll read out a list of moves and you'll show me how it works"

and the fact that the code doesn't work would have become obvious.

Here is an ES6 fiddle with the completed solution.

Where is the flaw?


The flaw is in the design. You're passing to the tortoiseAndHare function an iterable, but the only data you have access to, as per requirements, should be represented by an iterator.

In other words, you're not free to iterate the moves of the game as many times as you please; the moves come in a single sequence. Adjust your code to keep track of those moves, and the solution becomes (almost) equivalent to the simple one.

I think a good interview process would involve suggesting that the solution as given does not meet that interpretation of requirements, and asking the candidate to discuss/adjust, as you suggest. A poor process would fail the candidate outright without discussion or explanation.

You’ll notice, for example, that Christine asking him to try out his code while she reads out the moves doesn’t match the template she provided, either.


Which says something unsettling, to me at least, about interviews.

I don't think I follow.

It suggests that succeeding in an interview requires you to be all three of competent, confident, and clever about demonstrating your skill. Only the first attribute is relevant to the job.

20 years from now, the idea of hiring programmers with interviews will be as weird as the idea of hiring an orchestra cellist with an interview.

Yes. The tech community has no trouble whatsoever understanding that getting good grades in school is overdriven by skill at taking tests, but somehow misses the fact that getting hired in tech is overdriven by skill at being an interviewee.

Just to be clear, Rayiner (upthread): my issue was, that candidate succeeded by being confident and clever enough to turn a straightforward question into an opportunity to put on a show for the interviewer. You're right, that's great. It sucks that the process required it, though.

I guess I'm thinking more from the other side of the table. I know several talented, hard-working people who had a hard time finding work because they couldn't "hack" interviews. It's a flawed system, but if you're a young person it's to your advantage to know how to game it.

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

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

Can you give some reasons why? Perhaps even show how you would have solved the problem?

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.

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.

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.

I dunno, the interviewer provides the template code as ECMAScript 2015 ?

Seems incredibly bleeding edge for an interview question.

And then the start of his reply is 'Using babeljs.io, I’ll write this in ECMASCript 2015 notation.', which is weird given the example code was already implied to be in this.

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.

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

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

So be less smart than the interviewer but more smart than the last person they interviewed?

There's interesting social psychology to back that up: status ambiguity as the fastest way to endear yourself to the new group. Representing higher status than the entire group marks you as a threat. Representing lower status than the entire group marks you as a waste of time. Projecting a fuzzy medium somewhere below the top people and above the worst endears you to everyone.

Very true, but there are also arguments about why you should always surround yourself with people that are smarter than you for both personal growth and bottom line results. Especially in the fast paced startup culture, you need the smartest and fastest people around.

It comes off as a parable about the fact that we write for our peers and our employers. We may aspire to be academics, but unless our peers and employers are academics, a highly technical, academic approach to problems will fail.

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.

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.

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.

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.

The opening of the piece pretty clearly implied that the candidate did not have trouble finding work. The candidate made a good-faith effort to solve the question given in the interview while also using it as a tool to discover if this was a place where he'd like to work.

Interviewers use filters like this question to weed out employees they don't want. What's wrong with interviewees using filters like code style and problem-solving priorities to weed out employers that wouldn't be a good fit?

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.

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

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.

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.

I've noticed that too, but I don't really know if that is a common practice.

It made me wonder what this Carpenter would do if he was not aware of possible questions or he was given something he was not prepared for.

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.

A nice set of slides explaining es6 syntax.


As the link in the article states you can use all of these with https://github.com/babel/babel today, here is a quick and recent overview of new features http://www.2ality.com/2015/02/using-es6-today-minsk.html

Those are new in ECMAScript 2015 (f.k.a. ES6). Check out Kangax's compat table[1] for support.

[1] http://kangax.github.io/compat-table/es6/

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.

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

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

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.

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.

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'

Where does the solution given use On space?

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.

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

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

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.

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.

> Symbol.iterator just seems like purposeless showing off.

That's the point.

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

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

I think that this is the correct reference http://ntraft.com/the-carpenter-and-the-engineer/

> 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 the thing - http://www.imdb.com/title/tt0084787/ escape from new york - http://www.imdb.com/title/tt0082340/ they live - http://www.imdb.com/title/tt0096256/

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

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

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.


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.

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.

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.

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?

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

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?

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.

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.


No you don't, you can Do `Array.from(myGeneratorFn())` or `[...myGeneratorFn()]` just fine - the difference is that you have to invoke it - you certainly _don't_ have to call .next to extract elements all the time manually.

Very true, You have to decide at some point whether you’re going to have everything be callable, or everything be an object, and thereafter be consistent. The functions `takeIterable` and `statefulMapIterableWith` are both written to take and return iterables, but you could write parallel versions operating directly on callables. You probably want them to return the same thing they consume. A more full-featured utility might pattern match on what it is given and return the same form.

Sure, but it's takeIterable and statefulMapIterableWith which I was wondering about. They are themselves callables which return iterables. Is there any reason not to write them as generator functions?

These would have been excellent questions for Christine to ask!

I made an es6 fiddle:


Is this what you mean?


  const takeIterable = (numberToTake, iterable) =>
      [Symbol.iterator]: function* () {
        let remainingElements = numberToTake;
        for (let element of iterable) {
          if (remainingElements-- <= 0) break;
          yield element;

  const x = takeIterable(3, [1, 2, 3, 4, 5]);

  console.log(...x); console.log(...x); console.log(...x);

  //=> [1, 2, 3] [1, 2, 3] [1, 2, 3]

  function* takeGenerator (numberToTake, iterable) {
    let remainingElements = numberToTake;

    for (let element of iterable) {
      if (remainingElements-- <= 0) break;
      yield element;

  const y = takeGenerator(3, ["a", "b", "c", "d", "e"]);

  console.log(...y); console.log(...y); console.log(...y);

  //=> [“a”, “b”, “c”] [] []

That's great; you've really made this clear. In python, one would just use itertools.tee() to get multiple bites at a particular iterator, rather than relying on sugary syntax to instantiate the iterator multiple times; perhaps ES6 should have something similar? I have to say, this "Symbol.iterator" magic string seems like an even less felicitous way to write this than python's dunderous __iter__() function. Maybe coffeescript or one of its forks can help ES explore a more reasonable way to write this.

Well, __iter__ was baked into Python decades(?) ago, so there’s no danger anybody might have their own __iter__ methods that mean something else. But now that JS is adding iteration methods to the language, there are lots of libraries and frameworks that have their own incompatible ways of greenspunning these features.

The [Symbol.iterator] expression resolves to a string that is guaranteed to be unique, so there is no possibility of breaking backwards-compatibility with someone who picked the exact same magic name.

(There’s a major headache involved when code crosses execution contexts, I don’t pretend to understand how that works yet.)

Ah, the penny drops. Thanks. I've actually been bitten by not paying attention to the same distinction in python, which I evidently haven't quite learned the lesson of yet.

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

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.

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

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

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

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

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

"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." [1]

[1] http://c2.com/cgi/wiki?CodeForTheMaintainer

That's why everyone changes binary files directly when they alter their code?

I have a different, yet equally unsupported view.

Code is meant to be read first, executed second.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact