First of all, being sometimes involved in teaching CS to people, I like your website. You have obviously spent a lot of time on the question of how to teach people programming (the latter in the sense of "How to write a program that solves a given problem?"). I have seen textbook authors with less dedication.
However (there is always a "however" or "but"), I am wondering whether you are using the right approach for the N Queens problem. You are following a bottom-up approach. For example, on the first page you let people write a helper function "validateQueenPlacement", followed by another helper function "nextRowColumns" on page 2. For somebody who doesn't know the complete solution, it's very hard to see why you would need those two functions. Of course, you know that you will need them but you have already seen the final solution!
You are probably familar with the top-down approach by Wirth (1971) called Stepwise Refinement. I think (but I cannot prove it) that most CS educators see Stepwise Refinement as the superior approach because it encourages people to think about the problem and not the code. Why don't you let the reader write first the high-level (pseudo-)code for the backtracking:
http://sunnyday.mit.edu/16.355/wirth-refinement.html#3
Once the reader has written the code for the highest layer, it becomes obvious what the helper functions should be, what their parameters are, and what data structures are needed. I know that Stepwise Refinement is unpopular nowadays because it forms a kind of psychological hurdle (bottom-up gives you directly small functions that you can unit-test) but I think it really helps people to guide themselves to the solution.That said, I don't think I want to have a step where "they write pseudocode", because a lot of people would just skip that step without thinking about it.
Codecademy pioneered a more interactive REPL style of learning for basic programming.
I felt that this interactive step-by-step approach could be used to learn other parts of Computer Science more efficiently.
Because of algorithms being highly represented in software engineering interviews, it seemed like a good place to start. But this step-by-step format could also be used to teach other parts of Computer Science.
I personally loathe these types of interviews and don't administer them myself. Nonetheless, it isn't going away anytime soon and I am willing to practice for it if needed.
Unfortunately, the fact that it is generally considered a flawed process by the community, doesn't mean the this kind of interviews are not required or common anymore.
That HNers hate them provides a nice circle-jerk, but doesn't help you get the job.
Its amazing how many people phone me "for a chat" after seeing my Linkedin profile then expect me to jump in to do their coding test. You have to convince me that I actually want to work for you first. If I haven't spoken with anyone technical about the job then its a definite no.
Essentially, it assumes a bit too much the shape of the resulting solution.
That's not to say I didn't get value from the hint, or that I think others will not - on the contrary, it is a valuable and clear hint.
The unfortunate part is just the feeling of being taken completely "out of it" in solving the solution with a slightly different approach and wondering momentarily if somehow one is wrong, even though one is passing all the tests.
The recap is also fairly lacking in content, but I imagine that is clear to you already.
Nice job on the site, generally. I only had a couple hiccups with submissions and some weird aliasing on the editor if I would edit a line before it redrew.
Edit: add some dropped words
I'll think about what can be done about the last-step hint for Spiral Matrix. I guess a reason why this tutorial format is not more widespread is that it's easy for the hints to be "off".
Maybe all it will take is another sentence that basically says "or maybe you are doing something else, and that's okay too"?