I'd love to talk more about this. What kind of mentorship structure do you have? If you continually have to hire a seasoned person, are the jrs who level up not staying on?
For the painted into a corner scenario, I wasn't talking about my current work situation. Although I have previously tended to get hired as an experienced dev to plug into those scenarios. So I can't really answer your second question.
For mentorship structure, we are pretty small so it is mostly informal unfortunately. We have some resources and exercises that we tend to give the new hire. HTML and CSS first since we mainly do web. Then we teach them basic functional programming. It depends on the person, but it tends to be a few weeks of learning at their own pace before they get started working on a new UI app -- a real product that we are beginning. It starts as an empty app so they get to grow with it. The UI is convenient place to start because we use MVU, and it tends to reinforce the simple functional programming that we do. And it is easy to correct those inevitable early mistakes. It also has a quick and visual feedback loop, important for learners. When they decide they are ready, we introduce them to back-end stuff. Eventually they will implement features end-to-end. We've done this for a couple of products now, so we have also iterated on organization strategies for front and back that makes it easier to plug into.
Our initial reason for hiring devs with no experience is budgetary since we are a not-for-profit organization. However, even if that changes I intend to continue in this strategy because it has been quite rewarding. And because bringing in new people is a great way to test / improve the resilience of your development process / tools / paradigms.
Our company sees itself as an ever learning organization where people need to grow.
We give courses in high schools, then give scholarships in the University (we're not in the US so it's no so expensive), then we recruit university students and graduates and train them for several months (free).
After all that process we hire the best.
We've found that "growing" our own human resources has been very effective. We also hire people with experience elsewhere so that we get some cross-pollination, but incorporating training in your corporate mindset makes for an ever improving organization.
@aminmansuri This is taking what I advise my clients ("Don't waste your time chasing unicorns; invest in creating your own") to a whole other level. Great job.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd love to talk more about this. What kind of mentorship structure do you have? If you continually have to hire a seasoned person, are the jrs who level up not staying on?
For the painted into a corner scenario, I wasn't talking about my current work situation. Although I have previously tended to get hired as an experienced dev to plug into those scenarios. So I can't really answer your second question.
For mentorship structure, we are pretty small so it is mostly informal unfortunately. We have some resources and exercises that we tend to give the new hire. HTML and CSS first since we mainly do web. Then we teach them basic functional programming. It depends on the person, but it tends to be a few weeks of learning at their own pace before they get started working on a new UI app -- a real product that we are beginning. It starts as an empty app so they get to grow with it. The UI is convenient place to start because we use MVU, and it tends to reinforce the simple functional programming that we do. And it is easy to correct those inevitable early mistakes. It also has a quick and visual feedback loop, important for learners. When they decide they are ready, we introduce them to back-end stuff. Eventually they will implement features end-to-end. We've done this for a couple of products now, so we have also iterated on organization strategies for front and back that makes it easier to plug into.
Our initial reason for hiring devs with no experience is budgetary since we are a not-for-profit organization. However, even if that changes I intend to continue in this strategy because it has been quite rewarding. And because bringing in new people is a great way to test / improve the resilience of your development process / tools / paradigms.
Our company sees itself as an ever learning organization where people need to grow.
We give courses in high schools, then give scholarships in the University (we're not in the US so it's no so expensive), then we recruit university students and graduates and train them for several months (free).
After all that process we hire the best.
We've found that "growing" our own human resources has been very effective. We also hire people with experience elsewhere so that we get some cross-pollination, but incorporating training in your corporate mindset makes for an ever improving organization.
We also have very very low attrition.
@aminmansuri This is taking what I advise my clients ("Don't waste your time chasing unicorns; invest in creating your own") to a whole other level. Great job.