akbiggs

At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on the whiteboard without pressing against the time constraints.

It's also important to see how reliant people are on their tools.

This was accessible and interesting, thanks for the link.

A few questions:

1. Does the overhead of creating a new CLH every time a Haskell function is invoked from C introduce any performance concerns(speed didn't seem to be well-covered in section 6)?

2. How should Table 5 be interpreted? Is the main goal to show that B5 and B6 do not use the garbage collector if it's unnecessary for the task? Not sure I understand how the event-driven mutator fits into the situation.

The current title definitely caught my eye. Not sure there's a need for a change.

I think both this, the parent comment, and a fair amount of other comments on this post are unnecessarily harsh towards the designers. Pointing out design issues is always helpful for improvement and reiteration, but attacking their motivations just makes everyone hostile and gets nothing accomplished.

None of the people who put that question on hold were moderators, either. You can identify a user as a moderator by the diamond next to their name.

The person who answered that question is not a moderator.