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'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.
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)