I recall reading an interviewing.io blog post[0] in which the dominant considerations interviewers weighed were (my interpretation):
(1) Did they solve the problem optimally? (2) How fluid was their coding?
With "communication" turning out to be basically worthless for predicting hire/no-hire decisions.
Perception of coding fluidity seems like it would be affected by how often the candidate stops and looks up things like library functions or obscure syntax.
For that reason I've been investing time in committing a lot of library functions to memory, so they instantly flow from my fingers rather than spending a minute looking it up.
It's dumb that I need to do this, but I don't make the rules. I'm just at the bottom of the information cascade that led to how things are done now.
[0] https://interviewing.io/blog/does-communication-matter-in-te...
I've got an abstraction that I think in that then needs to be translated to code. e.g. if I want to append to a list, I think "push to list", regardless of language/framework/whatever. Then somehow my hands will translate that automatically to code in the language I'm working in. If I'm not in my usual editing environment, that magic just sort of breaks, and I just look incompetent.
It's not a huge deal, but I have to actively sit and memorize that stuff before an interview. Usually by writing it out on paper or writing it in some foreign editor that I'm not used too.
It probably wouldn't be _too_ bad today, because I just sit and write Typescript everyday, but when I was switching between perl/ruby/python/tcl/kotlin/javascript/bash/csh/lisp my brain was basically mush. I couldn't tell you how to do any basic operation in any language.
Thank you for putting all of that into words that I can look at and go: that's exactly how my brain works!
I don't think everyone has that issue or can understand it. I think in more abstract terms (the problem and how to solve it) and more often than not the syntax is just an implementation detail that I prefer to increasingly outsource to my tooling.
But I do think most of what I use has grown into my muscle memory naturally, rather than memorizing anything.
I am not sure that is clear. It seems the expectation was not "closed book", but "never opened a book before, not even in the past":
"It's tough to determine if the candidate breezed through the question because they're actually good or if they've heard this question before."
Clearly the interviewers were looking not for knowledge, but for uncanny ability. How well was that communicated to the interviewees?
It is not cheating if the rules of the game are not defined.
The closed-book crap can stay closed in the universities and schools demanding a regurgitation of mostly-right knowledge.
Now... The skill of asking the right Qs also directly intersects with LLMs, and how to discern good/bad responses.
But hiding it? Yeah, probably not a good fit.
I work at a university and most of our exams are open book or project based. You probably want to update your image of universities.
I have a close friend who is a prof at a university and most exams remain closed book.
You probably want to update your image of universities.
Or, perhaps, we can agree that it depends on the university, the subject, etc. and blanket statements based on single anecdotes are silly?
I would argue that is the opposite: it's fair to say that the interview is a cheat.