[randomdata]

> Why would you need to _communicate about programming_? Because it's a core part of your job...

Honestly, I am not sure I have personally ever had to communicate low level details like that with anyone else. The people I have talked pogromming with in my life have all be capable technologists, which allow us to discuss in high level detail. If a list is the right data structure for whatever high level problem we are trying to solve, it is assumed we know that and understand how to use it.

> Every interview question can be characterized as trivia if you squint hard enough.

Well, I suppose. And there isn't anything wrong with trivia per se. But at the same time it should not be surprising when someone doesn't have an answer. A lot of this stuff just isn't worth having in immediate memory – unless you enjoy trivia, in which case, cool!

[alex_lav]

> Honestly, I am not sure I have personally ever had to communicate low level details like that with anyone else. The people I have talked pogromming with in my life have all be capable technologists, which allow us to discuss in high level detail. If a list is the right data structure for whatever high level problem we are trying to solve, it is assumed we know that and understand how to use it

This feels like either hyperbole or extremely rare/almost impossible, but regardless for myself and those I hire, I believe it to be a core competency.

[randomdata]

> This feels like either hyperbole or extremely rare/almost impossible

Why's that? Aren't these basic knowledge items almost always able to be left unspoken? "Here is what we are trying to accomplish, and you must use a map in your implementation" never seems pertinent. There is faith in the people I work with that they will understand how to best implement something.

Furthermore, if there were some reason to bring up, say, a list then I could fumble around with some other ideas to get the group there. "I'm blanking on the term, but you know, the thing you can build with square brackets.", "Oh, you mean a list?", "Yeah, that!" But that doesn't satisfy the question posed here which specifically asked for the structure by name. In normal situations you don't need that kind of thing at your beck and call like you do when you are playing with a trivia master.

> I believe it to be a core competency.

And, to be fair, if I were knowingly about to enter a developer interview I'd probably brush up on the language ahead of time knowing that it is likely that an interview very well might want to talk about the trivial basic building blocks to weed out those who have never programmed before. But I personally haven't interviewed for a job in 20-some-odd years, so again, not something in the forefront of my mind before this discussion happened.

However, of note, the interview in question was for a people-based job, not a technical role. Who is going to think to study the technical language ahead of time in that situation? It wasn't pertinent to the job. The interviewer just went there because it was noticed the person once was a developer in a past life.

[alex_lav]

> Why's that?

Communicating about work is a core part of work.

> Aren't these basic knowledge items almost always able to be left unspoken

Nope.

> "I'm blanking on the term, but you know, the thing you can build with square brackets."

Data structures are unrelated to brackets, so I assume this is hyperbole.

> In normal situations you don't need that kind of thing at your beck and call like you do when you are playing with a trivia master.

Are your friends names also trivia? The word "car", "tree", "sun"?

Hyperbole.

> But I personally haven't interviewed for a job in 20-some-odd years, so again, not something in the forefront of my mind before this discussion happened.

Respectfully, my assumption is that you also don't work in technology, or always work alone.

> the interview in question was for a people-based job, not a technical role

Technical leadership requires some amount of software knowledge as a core competency.

> Who is going to think to study the technical language ahead of time in that situation?

Someone claiming to have 10+ years of developer experience should know the word "list". Full stop.

> It wasn't pertinent to the job

It was pertinent to the job.

> The interviewer just went there because the person once was a developer in a past life.

Well, no not really. Because the person was expected to communicate intelligently about software, and knowing the basics of data structures is again a core competency.

[randomdata]

> Communicating about work is a core part of work.

Absolutely, and the work I do is solving problems to further business objectives. As such, we talk about business things. Lists, sets, and maps are not normally business-related terms. Indeed, programming is the tool we most often use to implement the solutions to the particular problems we face, but it is not the work any more than a hammer is the work.

> Respectfully, my assumption is that you also don't work in technology, or always work alone.

I do not work alone, but I use the tools alone, yes. I expect most do. I don't see much evidence that pair/mob programming has ever caught on in a significant way.

> Data structures are unrelated to brackets, so I assume this is hyperbole.

They are indeed related as some programming languages use [] syntax to denote use of the data structure mentioned. If the people involved in the conversation are familiar with those languages, they can infer what is meant through the process of communication.

> Someone claiming to have 10+ years of developer experience should know the word "list". Full stop.

You're going off the rails here. A developer of 10+ years will know the word "list". That is not in question. The topic of conversation is how they will not necessarily have it at the tip of their tongue, because why would they? Unless you are caught in the 10 years of experience doing the same thing over and over trap, leaving you forever a beginner, it is not something people normally talk about.

Again, what would seasoned developers need to talk about lists, sets, and maps for? They should know them inside and out, backwards and forwards. "Hey colleague, I need a list here, but I forgot how to do it. Can you help?" never comes up. "Good news everyone, I discovered this great new thing... It is called a list!" – not going to happen. If we were talking about esoteric data structures, that's a little more conceivable, but we are talking about the ones you use essentially every time you write some code.