Hacker News Reader

Comment by jacques_chester | Hacker News Reader

> I also am in favor of "open book" interviews.

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

View on HN

Companies that optimise for memorising obscure stdlib functions don't seem like great places to work.

Occasionally looking something up is normal, but if you don't know how to append to a list in Python or iterate over a vector in C++ then you probably are not currently writing much code in those languages. That's a signal by itself, and one that is too often a negative.

Why? Maybe you just use good programming languages instead.

I'm not saying you're wrong, but that reasoning is why I have to prepare for interviews. I'm _really_ bad at remembering that stuff, I think it really depends on how you think while programming.

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.

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

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.

I don't think companies intentionally optimise for that. It is just the fluid way of writing code that impresses whoever is watching you code.

But I do think most of what I use has grown into my muscle memory naturally, rather than memorizing anything.

Reply on news.ycombinator.com