[drakenot]

Most specialized fields have jargon. It is the common language between the practitioners of that field. At what point should a person be expected to know some basic ideas and the words associated with them for the field they work in?

[stegosaurus]

Well, if the knowledge of a particular thing is useful for that job, then yes, that's reasonable.

But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference.

If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't.

Problem solving tests are good. Memorization tests are terrible. We have search engines for that.

[drakenot]

I think memorization tests of the sort that ask what FunctionX you should use from LibraryY for a particular situation are terrible.

I don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important.

Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well.

These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.

[stegosaurus]

Sure. I know what a list, a hash table, a tree are because I looked it up whenever I saw someone mention it, and eventually internalized it.

But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.

Actually in usage I type {} in Python and it is what it is.

I'm not arguing that these things aren't useful at all.

I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal.

Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel.

Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer.

If that's what you want, just ask for it. Let's not waste each other's time and money.

The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.

[stuxnet79]

>> Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.

Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.

[stegosaurus]

>> Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far.

Please try to avoid this. We can discuss without resorting to attacks.

>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"

That's what most people are arguing for I think, so I agree with you there.

>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.

By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.

[drakenot]

You seem to be arguing that non-CS trained devs can learn these things when they come across them. I wouldn't disagree with that.

I think what I see as the real concern is a case of "not knowing what you don't know." If you aren't exposed to at least the fundamentals of this broad base of CS knowledge you aren't going to know that they are available to you when you need them. Learning about a tree when you first read about it is great. But that person will still have huge gaps in their CS knowledge compared to someone who systematically studied it.

I also don't think this is so much about having a CS degree, as it is simply having studied CS in some fashion. I've worked with plenty of talented self-taught developers who took the time to learn these things on their own.

[GFK_of_xmaspast]

> C++ calls it an (unordered) map.

Hey, whoa, stop right here. std::map and std::unordered_map are not at all the same thing, and if you're going to be using them in a manner beyond "trivial" it's important to know the difference between them.