I am not able to ssh into any production instance I’ve deployed. I know how I would but it’s just not organizationally allowed.
The “ecosystem” of development is very large. I’m sure there are parts of the ecosystem that others would know that you wouldn’t.
Maybe this person doesn't quite get how to properly not use a comma between dependent clauses. How could one trust this person to communicate well?
> networking, DNS, firewalls, shell scripting commands, or how to configure the services upon which the application's stack runs, like web servers, application servers, caching services, or even databases...
I have known plenty of gainfully employed, 25-year-old software engineers who didn't have experience with each item on this list. That's perfectly fine; it's easy to teach in one brown-bag lunch session. I'll still take the wizard because those innate abilities can't be taught.
You can teach "networking, DNS, firewalls, shell scripting commands, or how to configure the services upon which the application's stack runs" in a day? This is "Teach yourself C++ in 21 days"-type of stuff.
At any rate, I didn't read that it's not "fine" in TheRealDunkirk's comment. They were just saying that people can have wildly varying skill-sets.
You just described something which is trivial to learn in less than one minute. This lack of experience does not directly speak to their skills or abilities.
Extending your example to illustrate its irrelevance, were I to have spent 60 seconds with this engineer alone just before your little ssh test, he would instead still appear to be a 10x engineer to you.
Focus more on ability and less on what one has or hasn't seen just yet in their careers. I could easily find the limits in your knowledge in seconds and I'm quite sure you could return the favor. I'd gladly hire someone who demonstrates the ability to become a wizard in X and not care in the slightest if they've seen Y and Z yet. I can teach Y and Z to someone like that very easily.