> when I've had to hire people, a vast majority of dropouts who work on experience (though not all) have a weak understanding of fundamentals, and while that's not a problem for some domains, it is a problem for mine.
You are right. My statement was too simple. Experience is not enough. If someone spends 30 years doing the same thing without learning anything else they are not going to be a good hire for anything outside that box.
What matters is learning. That's what I look for. Does the person have a track record of constantly learning during the last ten years? What did they study? Did they try to get a handle on fundamentals? Did they stick to one thing, on domain, or did they learn and have experience in a range of domains? Did they enroll in any MOOC's? What were they? Can he or she speak about these topics with reasonable authority?
What I look for is an insight into who this person is as a professional. One of my typical questions is a short sequence: What are state machines? Give me an example of using a state machine? What's the difference between a Moore and Mealy state machine? Can you whiteboard examples of both?
I am not looking for the person to know the above with 100% accuracy and insight. I am trying to get to know the person and how they think. If, for example, they try to bullshit me, I learn something valuable. If, on the other hand, they say "look, I have never had to use state machines so I don't really know the subject but I understand they can be very powerful and useful and would love to have the opportunity to learn about them and apply the knowledge", well, that, to me, is far more valuable than them being able to parrot answers to my questions. Anyone can prep for an interview and ace it.
CS is an interesting field. When I started life as an EE designing and programming computers of my own design you used Assembler and maybe C and, if you were lucky, Forth. Virtually none of the things I do today existed when I went to school. And so comes the realization that, in my case, when it comes to CS, I am no different than a CS dropout. Virtually everything I do today I had to learn on my own. And that entailed a constant effort spanning thirty years that took me through CS theory, languages, frameworks, applications and new developments such as FPGA --which literally did not exist when I was in school.
Having navigated this journey I am forced to look at the person rather than the credentials. In fact, credentials very frequently lie about what the person is capable of. There are plenty of stories out there about major companies having trouble hiring recent grads because they don't know how to, well, do the work they need them to do.
Engineering in general is a domain that requires constant learning. Stagnate and you become irrelevant. CS can be particularly brutal in this domain.
So, no, it isn't about just experience but rather about what someone did during that time and what they chose to learn.
You are right. My statement was too simple. Experience is not enough. If someone spends 30 years doing the same thing without learning anything else they are not going to be a good hire for anything outside that box.
What matters is learning. That's what I look for. Does the person have a track record of constantly learning during the last ten years? What did they study? Did they try to get a handle on fundamentals? Did they stick to one thing, on domain, or did they learn and have experience in a range of domains? Did they enroll in any MOOC's? What were they? Can he or she speak about these topics with reasonable authority?
What I look for is an insight into who this person is as a professional. One of my typical questions is a short sequence: What are state machines? Give me an example of using a state machine? What's the difference between a Moore and Mealy state machine? Can you whiteboard examples of both?
I am not looking for the person to know the above with 100% accuracy and insight. I am trying to get to know the person and how they think. If, for example, they try to bullshit me, I learn something valuable. If, on the other hand, they say "look, I have never had to use state machines so I don't really know the subject but I understand they can be very powerful and useful and would love to have the opportunity to learn about them and apply the knowledge", well, that, to me, is far more valuable than them being able to parrot answers to my questions. Anyone can prep for an interview and ace it.
CS is an interesting field. When I started life as an EE designing and programming computers of my own design you used Assembler and maybe C and, if you were lucky, Forth. Virtually none of the things I do today existed when I went to school. And so comes the realization that, in my case, when it comes to CS, I am no different than a CS dropout. Virtually everything I do today I had to learn on my own. And that entailed a constant effort spanning thirty years that took me through CS theory, languages, frameworks, applications and new developments such as FPGA --which literally did not exist when I was in school.
Having navigated this journey I am forced to look at the person rather than the credentials. In fact, credentials very frequently lie about what the person is capable of. There are plenty of stories out there about major companies having trouble hiring recent grads because they don't know how to, well, do the work they need them to do.
Engineering in general is a domain that requires constant learning. Stagnate and you become irrelevant. CS can be particularly brutal in this domain.
So, no, it isn't about just experience but rather about what someone did during that time and what they chose to learn.