Don't underestimate the knowledge gained from tangential brushes. Being able to Google and Stack-Overflow a question is dependent on knowing the vocabulary and keywords related to the problem. While tangential brushes don't give you full mastery of the domain, it gives you a bookmark on what is possible and how to find it again in the future. If you talk to newer programmers (new anything really), you will find they lack to knowledge to even properly express their problem, let alone search for answers. While more experience people may not know everything in detail, they have a better handle on various knowledge domains and where to look.

I agree with you on this. It's the difference between "I get a 500 error when I try to submit the blah form and here's the error in the log - it seems to crash in the foo method of the bar service when it receives a null value but it's not clear even from the debugger why it's getting null" vs "X doesn't work".

This exact situations happens to me far too often, especially when working with developers who refuse to learn the other side of the stack. Had lots of "this doesn't work" conversations with frontend devs who refuse to get their arms dirty with the database, and same from backend to frontend as well.

Very true. I don't disagree.

At a distance, though, reality can take on funny appearances.

I majored in math & physics, not CS, but was aware of the CS coursework at the time, 30+ years ago. Back in the day, the exams were more or less designed around the problems in the textbook. You could set yourself up pretty well for the exams by working the problems over and over. (Mostly derivations in physics, with or without numerical results, or proofs in math). Doing so would commit the factual content (e.g., formulas, definitions) to memory and get you quick enough in the mechanics to have some spare time during the exam for dealing with the unexpected.

What you learned in class was, among other things, the style of communicating results, i.e., what a well written derivation looks like. I imagine that a CS course could be structured in this way, if a program in CS is analogous to a proof in math. Whether it's actually a good way of teaching is anybody's guess, but it's how things typically worked.

The students who thought that they were expected to mimic the "tricks" and opinions of the professor, were suspected of simply not grasping the material. On the other hand, though I grasped the formula for getting good grades, nobody ever told us that formula, and a student who never guessed it, would be faced with nothing but frustration and sorrow.

When I taught college math and engineering for a brief period, many years later, I told my students the trick, on the first day of class.

Of course I have no idea if this was a good preparation for the workforce, but I'm pretty sure students were expected to combine their textbook learning with experiences gained outside of the classroom, e.g., from research projects, internships, etc.

> the majority of actual tasks are often googled and stack-overflowed

The more I've grown as a developer the less I've had to do this.

Ah damn; and I had been doing so well mushing down my imposter complex :P

I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean heavily on lookup resources for things that don't generalize. Just today I'm writing in py+full web stack+cpp+bash+powershell+sql(both PG and ms), and using full suites of associated libs. I at the very least am entirely unable to keep all of that in my head at once, I'd be curious if you find this same problem with bringing in a wide breadth of components.

(My honest fear is that I've pushed too far to become a generalist and am sacrificing strength in depth because of this, although I am somewhat proud of the end to end results it lets me accomplish)

I back you up on this. I'm about 10 years in my career, and I use SO more and more. Because, conceptually, I know what I want to do. Last night it was trying to use the asyncio library for Python 3 to use sockets. I know what I wanted to do: async, accept, listen, read and write to sockets. But how, _specifically_, do you do that with python 3 ? Don't know and dont care. Ask SO or find someone's blog howto and be done with it. For better or worse, I dont use books at all anymore. What I find is that they take the long way to go about things. The more I learn, the more I just want to see EXAMPLES. I dont even want to read a single word "about" topic X, I just want to see topic X in use.

I'm about ready to write my own manifesto about why man pages are worthless. When I do, I'm going to blog it and submit it here. I don't even know where to start about man pages. They are reference material, but totally useless at showing you how to use the tool. even though they tell you what EVERY dash-this and dash-that option means, you can STILL screw up by not ordering them properly, forgetting a required dash-this, or not formatting the arg properly (information that is either omitted completely or buried in thousands of words inside the man page, but could be explained concisely with one simple example). the corollary is also true: examples are so effective (in my opinion) that they could go ahead and omit the "dash-this and dash-that" from the man page, and I could likely infer what those options mean just by seeing the example, or an example with a one sentence comment saying "recursively scan directories" (and I see -r). the letters often don't correlate to an actionable-thing that the tool does, the man pages don't cover the most common, useful way that tool will be used, giving equal weight (or rather, equal ambiguity) to arcane, never-used options. They take 100 words to explain what a 10-word example could show. I honestly don't recall the last time I read a man page and actually found what I needed.

You may appreciate this: https://tldr-pages.github.io/

You're not alone. The more experience I get, the more I feel that specifics in a language are a commodity, but what you do with that language is what matters.

Those abstractions, identifying problems, talking with peers, deciding the next step, etc. The language is not the problem, you will learn it.

With time I got to know more core concepts but I don't know the syntax of whatever language the interviewer's company is using. It is nice to find people interviewing you who care more about what you're trying to say than the syntax.

Yeah I suppose YMMV. I work mainly with JS on a video player which uses no frameworks. I still lean on MDN a lot and use SO for learning new things, but I've learned to rely on myself and my teammates to solve problems and where that isn't enough, to look through Git issues and documentation. I've developed my own standards of "goodness" which helps me come up with solutions. It also helps that SO does not have answers to 99% of my problems (how do I make HLS videos upswitch faster?).

Working within a single language (Python), I've come to the point where I have sufficient knowledge to be able to answer many things about it without googling. However, my false positive rate is sky high because I know too many implementation details. It was unavoidable in working within a particular stack for ~5 consecutive years, but the false confidence it promotes can be counterproductive, as well as useful.

completely agreed, which is why it seems like years of experience has no correlation to technical interview performance, despite the likelihood that there would be some correlation between years of experience and actual job performance--because memetic technical interviews and what the job actually entails are generally miles and miles apart.

On top of that, I would assume that the bar is much higher for candidates with years of experience, either because the more experienced candidates self-select for more senior jobs or because it sets up some expectations from the the interviewer ("he's been a tech lead for 12 years and didn't know about quick sort!").

Yes, this is why we don't hire new grads. But typically when people work at a top-tier company they learn useful skills.

Is 3a "good interviewees..."?

Perhaps you are right. This is a usual argument against canned exams.

You are correct, sir. Updated accordingly.

EDIT: Wow, this is downvoted? Really?

Very accurate in my opinion.