If someone needs to continuously google how to use the basic data structures in a language they use every day, then I worry about their ability for knowledge retention as a whole.

“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”

― Robert A. Heinlein

(It's a matter of opinion)

I'm not sure I understand the point you're trying to make. Do you think a senior developer needs a basic understanding of the language they use or not?

I think you're approaching the quote the wrong way. It's more like "a C++ developer should be able to look at Javascript and ascertain the gist of what's happening, even if they can't finely dissect the exact issues on a language level."

Though the quote is more broad than that. It's really saying "a C++ developer should be able to write up a report, participate in an interview panel, plan a small party for Jane's birthday this Friday, and be able to make conversation with the external partner coming in today". Few of us are simply just writing code all day.

> Do you think a senior developer needs a basic understanding of the language they use

4 years ago, I'd have said "obviously".

At this point? Only for specialist languages the LLMs suck at. (Last I tried, "suck at" included going all the way from yacc etc. upwards when trying to make a custom language).

For most of us, what's now important is: Design patterns; architectures; knowing how to think of big-O consequences; and the ability to review what the AI farts out, which sounds like it should need an understanding of the programming language in question, but it's surprisingly straightforward to read code in languages you're not fmiliar with, and it gets even easier when your instruction to the AI includes making the code easy to review.

It’s not just the language but the domain within the language.

I see both the latest Claude and GPT models fall over on a lot of C++, Swift/ObjC and more complex Python code. They do better in codebases where there is maximal context with type hints in the local function. Rust does well, and it’s easier to know when it’s messed up since it won’t compile.

They also tend to clog up code bases with a cacophony of different coding paradigms.

A good developer would be able to see these right away, but someone who doesn’t understand the basics at the least will happily plug along not realizing the wake they’ve left.

Except I’m not hiring someone to do 20 things. I’m hiring them to do the one thing they say they can do.

Would I hire a taxi driver who can’t drive to drive me somewhere?

Why would I hire a software engineer who can’t demonstrate their abilities.

>I’m hiring them to do the one thing they say they can do.

If you hire an amazing programmer but then ask for a quick report on their implementation and it's gibberish. Is that satisfactory? Their job isn't to write reports.

If you ask them during lunch to grab your meal from the desk and they spill it everywhere, is that satisfactory? You didn't hire then for their ability to carry a plate.

EDIT: I should add here that I agree with your hiring approach. I just think you're critiquing this quote in the wrong way. The point of the quote is that humans have a capacity to learn and perform many tasks, even if they do some better than others. LLMs hinder this ability.

edit: wasting my time

Please re-read the original comment. All your suggestions are addressed there and I explain why this is inadequate.

I think it depends on what you consider "basic data structures"...

If it's the List and Dict (or whatever they are called in that language) then maybe. But I'd not expect someone to spell the correct API by heart to use Stack, Queue, Deque, etc, even they're text book examples of "basic" data structures.

For me, in a coding test, basic data structures are (using Python terms for brevity):

- lists

- dictionaries

- sets

- nested versions of the above

- strings (not exactly a data structure)

strings are tenuously in my data structures list because I let people treat them as ascii arrays to avoid most of the string footguns.

The question is: What are they better at? If you think the answer is "Nothing", I would be suspicious.

It’s never nothing, but it’s a matter of whether that something is enough of a differentiator.

More so, can they demonstrate that in interviews. We specifically structure our interviews so coding is only one part of them, and try and suss out other aspects of a candidate (problem solving, project leading, working with different disciplines) and then weight those against the needs of the role to avoid over indexing on any specific aspect. It also lets us see if there are other roles for them that might be better fits.

So a weak coder has opportunities to show other qualities. But generally someone interviewing for a coding heavy role who isn’t a strong coder tends to not sufficiently demonstrate those other qualities. Though of course there are exceptions.