Interviewing for a JavaScript Job
raganwald.com
raganwald.com
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...
It's actually well designed.
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?”
http://blogs.msdn.com/b/ericlippert/archive/2011/02/14/what-...
No wonder he never heard back.
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.
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.
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? :)
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.
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.
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.
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."
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.
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.
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.
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.
^ +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.
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.
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.
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.
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.
"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.
Where is the flaw?
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.
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.
JM2C.
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.
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.
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.
Somehow, this does not come across as a fantasy being played out, more of a cautionary tale.
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.
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?"
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."
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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'
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.
That's the point.
What's the story with the repeated John Carpenter references?
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.
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.
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.
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?
He would need to return at least generator function but that would force him to invoke it before iterating.
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.
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 read first, executed second.
"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." [1]