Knowing the concepts but not the corresponding vocabulary.

For example:

- intuitively applying SOLID without knowing that there is a set of principles

- knowing how to play with closures without knowing the dictionary definitions of “closure”

This makes interviewing a bit harder and might lead people to (falsely) assume that the candidate isn’t any good.

I have a masters in CS and have been working for a decade at highly-regarded companies. I've never heard of SOLID and couldn't define closure precisely.

I do know closures but got rejected on not knowing SOLID. And when the interviewer explained it, the concepts were so easy to understand. I don't get it why he couldn't infer that I'd be able to apply the principles after a bit of practice.

Sounds like it's a bad place to work anyway. Hiring people who can recite definitions without evidence of being able to apply the concepts is a recipe for building a terrible team.

Seen it happen.

Very much like bike shedding: zealously insisting on <acronym> for every triviality, never doing so for more complex situations.

It makes for a an easy checkbox. No thought on the side of the interviewer required. Quite sad, really.

[x] closures

[ ] solid

Candidate had 1/2. Rejected. Now back to shitposting on HN.

If they demand you know SOLID then they must be “Uncle Bob” acolytes, which is a strong signal that you should run in the opposite direction as fast as possible

SOLID is one of my pet peeves, because the important thing is to know the basic principles and architect it ok, naming be damned.

(Not to mention they are, in essence, very subjective principles)

Also knowing the names of them doesn't mean anything as far as I can tell. I've seen SOLID done well and SOLID done awfully. What counts is can you actually produce clean code that's not wasteful? Apparently knowing the acronym and being able to answer at least one question on it is a proxy for that. IMHO it's a pretty darn poor one, but it seems to be the one everyone goes with.

Interesting!

Closure don’t seem to be widely discussed outside of certain areas, so be it.

SOLID is rather surprising though. It seems to be quoted and (supposedly) adhered to religiously. Though I suspect it’s akin to people preaching TDD in public while we all know that’s rarely the case.

I'd say closures are one of the fundamental concepts of computer science. They're described in the introduction to chapter 2 of SICP, "Building Abstractions with Data".

SOLID sounds nice but I don't think I've ever seen anyone adhere to it religiously. Easy exercise: take any Java program, and imagine the spec changed the width of integers it needs to support, from 32-bit to some other size. How many files would you need to touch to make this change? Clearly, no class in the program has the Single Responsibility of this. The first letter of SOLID is already violated.

From that chapter: "In general, a method for combining data values satisfies the closure property if the result of combination can itself be combined using the same method."

It sounds like they're just describing recursive data structures? When most people talk about closures, aren't they referring to this (from Wikipedia)?

"In programming languages, a closure, also lexical closure or function closure, is a technique for implementing lexically scoped name binding in a language with first-class functions. Operationally, a closure is a record storing a function[a] together with an environment."

EDIT: My SICP quote was actually from somebody's notes, not the book itself. But the point remains.

now imagine that is the case for almost every topic you know how to practice in

I see what you mean, a kind of IRL extension of the "problem of naming things".

I'm sure the opposite exists too, interviewees who can rattle off the names and principles at interview, but don't actually apply them in their code.

Now for the prize question:

Provided many candidates fall on one side or the other, what does one prefer?

When I talk with a person who studied cryptography in school, I can usually refer to a trapdoor function producing a digest of data. For a self taught programmer, they will know this as a hash.

When I talk to a person who studied algorithms in school they know phrases like amortized analysis and big O notation for time and space complexity. For self taught programmers they can often tell me an expected runtime and expected runspace.

For concurrency persons often use words like counting-semaphore, threads, and blocking operations may not be universal

Self taught programmers may know about unit and regression tests and code coverage, may not be thinking about execution paths as a graph problem.

The understanding is usually there. It is often even the case that a self taught programmer have no standard words for a particular pattern they use regularly. It becomes the interviewer responsibility to decide how much of the vocabulary is important for the job.

----

This is a different problem than not knowing how to use a domain. Things like SOLID, I have never been asked in an interview. I have never studied them in school. I would be subject to the same interview challenges as someone who was self taught in these topics despite my degrees