The thing is that the job market is very competitive, and I can understand if people don't want to be self-deprecating and admit to not be very good at topic X since some employers might be picky and choose not to hire if someone doesn't know about topic X.
Some other employers would just consider that when deciding what role is best given an applicant strengths and weaknesses and address that deficiency as a team.
I think that if there's someone who meets the requirements for a position there should be no problem to hire, the thing is to establish what those requirements are...
To be more specific now: I think coding camps can help you getting started on web and mobile development, mostly covering scenarios when things do work as expected. But to go past the prototyping phase you will need to also understand how to deal with scenarios where things do not work as expected...
Having that said, that's where some more experience and knowledge starts adding value. You can accrue that experience and knowledge in different ways. But when you build a team you need to account for that by having at least one person who can make sure some advanced requirements are represented.
For instance, low level issues like race conditions, number precision problems, resource leaks, error handling... and non-functional requirements (https://en.wikipedia.org/wiki/Non-functional_requirement)... can be a bit counterintuitive if you don't come from a computer science/software engineering background, but it's not rocket science. Through mentoring, collaboration, etc... experience gets accrued and deficiencies eventually get mitigated. It just takes a bit of time, and some risk mitigation skills.
Personally my approach to mentoring is to avoid trial and error, and have people be vocal when they are unsure or they're blocked. I try to do this by asking newer people to write unit tests, to develop an intuition about how requirements get implemented and verified. Also, to create a culture in which asking good questions is perceived as a good trait, and guessing as a bad trait.
Some other employers would just consider that when deciding what role is best given an applicant strengths and weaknesses and address that deficiency as a team.
I think that if there's someone who meets the requirements for a position there should be no problem to hire, the thing is to establish what those requirements are...
To be more specific now: I think coding camps can help you getting started on web and mobile development, mostly covering scenarios when things do work as expected. But to go past the prototyping phase you will need to also understand how to deal with scenarios where things do not work as expected...
Having that said, that's where some more experience and knowledge starts adding value. You can accrue that experience and knowledge in different ways. But when you build a team you need to account for that by having at least one person who can make sure some advanced requirements are represented.
For instance, low level issues like race conditions, number precision problems, resource leaks, error handling... and non-functional requirements (https://en.wikipedia.org/wiki/Non-functional_requirement)... can be a bit counterintuitive if you don't come from a computer science/software engineering background, but it's not rocket science. Through mentoring, collaboration, etc... experience gets accrued and deficiencies eventually get mitigated. It just takes a bit of time, and some risk mitigation skills.
Personally my approach to mentoring is to avoid trial and error, and have people be vocal when they are unsure or they're blocked. I try to do this by asking newer people to write unit tests, to develop an intuition about how requirements get implemented and verified. Also, to create a culture in which asking good questions is perceived as a good trait, and guessing as a bad trait.