As a manager, I'll tell you what is more important than almost any of these technical skills (although they are important):
1)
The ability to communicate what needs to be done, and how it is to be done, _before_ diving into the work. I work with tons of people who, sure, can get the work done, but I have little to no visibility about what they're going to do and when they think it will be done. I'm never going to be in the code as deep as you -- the purpose of my management is to help make sure the thing you do fits into the rest of the plan and doesn't waste time and resources. What good does it do our team if I don't find out how long it was going to take until you finished?
Inability to do this is generally an indication that they've not done the task before, can't tell you how they're going to solve it before they actually do, or are generally unable to plan their work at a higher level that is useful for a manager. And I don't even mean that the answer has to be a rock-solid time estimate -- if they can raise and communicate the uncertainties, that already is an important piece of information and next level thinking -- what do you know you don't know.
You can tell a more experienced person by whether they can give you plans and estimates for how long and what approach they will take, before they immediately start the work. The work isn't just a coding puzzle to be solved -- they understand it's a project to be managed properly and are working at your level to plan it. Versus you having to painfully extract that info from them.
2)
The ability to self-assess whether their approach is the right/best approach, or what compromises or missing elements their approach adopts. Rarely do I find that people who dive right in because they "know how it needs to be done" are doing it because that is really the right way among all possible solutions. More like, it's the first thing that popped into their mind.
You can tell an experienced person by whether they take some time at the beginning to debate / discuss with you what approach optimizes for what outcome (whether time, resources, maintainability, scalability, data integrity, etc).
The person who does even these 2 things (or similar indicators of self-reflection and considering the problem) is -- almost unfortunately -- the standout these days.
I think those two abilities which you cite are developed ONLY with experience in solving real-world work problems.
These are not skills which can be taught in a school. They have to be learned through work, through mentorship and through the experience of failures and successes. Internships certainly help, but it takes years.
It's OK if hires fresh out of school aren't able to do these things. These need to be cultivated by you, the manager.
All those things are true. Perhaps I write out of frustration that people I have seen working for 5 years still do not have these skills, or even realize they are the next step.
1)
The ability to communicate what needs to be done, and how it is to be done, _before_ diving into the work. I work with tons of people who, sure, can get the work done, but I have little to no visibility about what they're going to do and when they think it will be done. I'm never going to be in the code as deep as you -- the purpose of my management is to help make sure the thing you do fits into the rest of the plan and doesn't waste time and resources. What good does it do our team if I don't find out how long it was going to take until you finished?
Inability to do this is generally an indication that they've not done the task before, can't tell you how they're going to solve it before they actually do, or are generally unable to plan their work at a higher level that is useful for a manager. And I don't even mean that the answer has to be a rock-solid time estimate -- if they can raise and communicate the uncertainties, that already is an important piece of information and next level thinking -- what do you know you don't know.
You can tell a more experienced person by whether they can give you plans and estimates for how long and what approach they will take, before they immediately start the work. The work isn't just a coding puzzle to be solved -- they understand it's a project to be managed properly and are working at your level to plan it. Versus you having to painfully extract that info from them.
2)
The ability to self-assess whether their approach is the right/best approach, or what compromises or missing elements their approach adopts. Rarely do I find that people who dive right in because they "know how it needs to be done" are doing it because that is really the right way among all possible solutions. More like, it's the first thing that popped into their mind.
You can tell an experienced person by whether they take some time at the beginning to debate / discuss with you what approach optimizes for what outcome (whether time, resources, maintainability, scalability, data integrity, etc).
The person who does even these 2 things (or similar indicators of self-reflection and considering the problem) is -- almost unfortunately -- the standout these days.