1. People who can effectively teach others to program well enough to secure professional employment may have better options than teaching open-enrollment entry-level programming classes.
2. Because of that, and for any of a number of other reasons, we may generally be overestimating how effectively these kinds of schools are educating people.
3. It's an open secret that hiring in the technology industry isn't based on aptitude, but rather on credentials and hazing rituals. Something like 3 decades of cultural development have trained developers that the most important risk they face in hiring is accepting someone underqualified, rather than passing on someone who is in fact qualified.
Given all these problems, it's not surprising that a school with a model of charging a 4-5 figure tuition in exchange for attempting to increase the likelihood of graduates employment would fail.
Training junior developers is something I enjoy & think I'm good at.
I actually looked at working for a boot camp once. To do so would have required more than a half pay cut. If I'm going to do that it will be as an underserved public sector educator, not a for profit company.
If they paid 160k, they might get the type of teacher who could deliver the goods, and who would love their job. There would be competition for these jobs because people could afford to take them.
Regarding #1, an Iron Yard competitor offered a six-month contract for $45,000, 1099, here in Boston (with "an option" to re-up, at the same rate). It would not exactly be difficult to beat that number by doing almost anything else.
Another was talking about $80K/year...in freaking Ohio.
I would love to teach more than I do, and I'm starting to work on some web courses because I've learned from corporate training that I'm good at it, but the money doesn't make sense at all.
I don't get this sentence, is this good or bad? I grew up in Ohio and for the majority of people I know there, they would be absolutely thrilled at that salary. The cost of living is nowhere near SF levels.
The "freaking Ohio" part, yeah I can understand that for a lot of parts of Ohio, but it's highly dependent on where in the state you're talking about.
> Something like 3 decades of cultural development have trained developers that the most important risk they face in hiring is accepting someone underqualified, rather than passing on someone who is in fact qualified.
I blame the easy investment cash that is often given based on the surface impression your company can make than on its efficiency and GAAP numbers. This promotes overhiring and reduces the role of a single developer to a point where the professional duties take a vanishingly small amount of time, so the efficiency (and hence aptitude or experience) is no longer an asset, while the ability to entertain the earlier hires becomes one of the most important requirements.
I know the US is not the world but since we are discussing Iron Yard, it's worth pointing out that the private sector in the US is almost exclusively at-will employment.
Companies that size should have well-documented processes to follow to minimize liability around that. The much larger problem I've seen is that managers - since ground-level engineering managers tend to overwhelmingly be young and first-time-managers since the industry is dominated by youth overall - are green, don't know what they don't know about firing, and wait to bring in HR until they've already made up their mind, at which point they find out about the six month official process they should've started following six months ago. Or are just afraid of having the conversation, period.
New manager training is an even bigger hole in most orgs than on-the-job entry-level engineer training.
Small companies usually have a lot more leeway here, I've been the replacement employee for a guy who only lasted a month and a half at a startup before.
After getting past my initial uneasiness around dealing with poor performers (defining poor performer as "someone the rest of the team feels is a net negative and can't trust with important features"), I'm less afraid of a not-good-enough hire (effort and conscientiousness in looking for the right solution is the most important thing I look for there), and withhold my "definitely not" calls for people I think would be truly toxic to the team's rhythm.
This is probably true. It's just been my experience that it is extremely hard to get managers to evaluate performance and reliably go through the long drawn out process of letting people know they are under performing, and then removing them.
That's not the whole explanation, IMO. If you had the same distribution of accepted candidates with both the loose and strict policies, I'd still expect interviewers to use the strict one.
Why? If their hire doesn't work out, they've got a much better story - "Our hiring processes are really strict and everyone got on board with it, it must've been something else that went wrong". And when the hire does work, people at the company get to self-congratulate about how "elite" they are.
The costs of extraneous interviewing and leaving positions unfilled is borne more by the company, while the costs of making a bad hire is borne more by the hiring manager, so the hiring manager makes choices that offload costs more onto the company. Principle-Agent problem.
2. Because of that, and for any of a number of other reasons, we may generally be overestimating how effectively these kinds of schools are educating people.
3. It's an open secret that hiring in the technology industry isn't based on aptitude, but rather on credentials and hazing rituals. Something like 3 decades of cultural development have trained developers that the most important risk they face in hiring is accepting someone underqualified, rather than passing on someone who is in fact qualified.
Given all these problems, it's not surprising that a school with a model of charging a 4-5 figure tuition in exchange for attempting to increase the likelihood of graduates employment would fail.