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