As Coding Boot Camps Close, the Field Faces a Reality Check
nytimes.com
nytimes.com
1) Most of the bootcamps teach the basic of front-end, and a lot of them, teach by doing without explaining a lot of basic concepts. They are basically money grabbers and throw these people out of the door as fast as possible to get their money back.
2) A lot of the students are in for the money, not for the love of the job. Sorry, but it's true. I don't mean to include everyone, but out of 30 students, only 2 kept working in my previous company, they weren't good developers, but they loved the job and kept learning and improving themselves. Nothing wrong with pursuing a good paycheck, but in developers world in order to keep being relevant in the next 2/3 years you need to keep sharping your skills.
3) The best developers I worked with are the self-taught guys/girls who learn on their own before they even hit the college. The most boring developers I work with, the the ones who only learn to code while in college and never developed any interested to learn before that. But the most horrible devs I work with came from boot camps. Not their fault, it's just how bad these bootcamps are.
I think this is the crux of the issues I had with bootcamp candidates. They were reasonably strong in the areas that they'd been taught, but there were gaping holes in their knowledge wherever they hadn't been taught. They could explain how to build a site with a Node backend and an Angular front end, but they couldn't explain why any of the decisions they'd been taught were good ones. And there were fairly basic concepts that were completely alien to them...of the 20 or so I interviewed, not one had even heard the term 'load balancer', let alone could tell me why I might need to use one. They had no notion of 'threading' or what it meant for a piece of code to be 'thread-safe' because they were only taught Node and its concurrency model. Even then, not one of them had heard of 'nextTick' or understood the event loop beyond the fact that it would call their callback function with the results. Their experience felt like a facade that was designed to seem impressive than it actually was. And all the areas where a developer with a traditional background would have thought, 'huh...I wonder how that works?' and then spent 2 hours figuring it out were completely unexplored.
This is why I think developers coming out of college are significantly more likely to be better at software development...not necessarily because the education they got in school was better, though I do believe an education starting with first principles and teaching you to figure out the solution from there is a better approach, but because the people that choose to study that in school are self-selecting for curiosity in the subject. They're the ones that hit something they don't know and go learn it rather being told what to learn. And they're the ones that spent at least 2 years following those tangents to get a more well-rounded education. Because any developer who only knows what they've been taught in courses, be they bootcamp or a traditional CS degree, is not going to have what it takes to learn on the job.
You underestimate the time a self-taught developer would spent figuring these things out. I'm self taught, and though I think nothing of it I easily spend 4 hours on trivial things -- it had never mattered until family obligations made it obvious that I needed to cut down since I was also teaching on top of my full time job.
I started teaching the bootcamp precisely because I disagree with the mentality that junior web developers need to understand load balancers or the event loop or any number of other things. These things WILL come to experience, and all you need to get started is grasp the basic syntax and be able to follow the execution path of anything you write.
It's a job, as much as people like to believe that it's a craft, and many other people are fully capable of doing this job even if their decisions look different from our own. Most of my students are at the same place I was when I landed my first Jr role, a handful (about 20% of the class) are far ahead of that point.
I'm not impugning bootcamps or claiming you should be teaching those concepts. I'm claiming that it takes years of independently exploring and learning concepts to be qualified for this kind of work. Most of the developers I hire and work with have been doing this kind of exploration since they were teenagers, if not before that. By the time Node, Angular or most of the technologies taught in these bootcamps came out, they would be comfortable reading docs and just figuring it out and wouldn't need a bootcamp to teach it to them.
It's an unrealistic expectation to think that people can go from zero to professional in such a short time. I honestly don't care if a junior developer knows those concepts. What I care about is that they know something other than what they were taught in the bootcamp. Show me some independent exploration that you did that wasn't required for the bootcamp which leads me to believe you can do more of it. I can pair a junior up with a more senior developer some of the time, but most of the time they're going to have to flail around and try to figure it out by themselves and I want to know that they can do it based on nothing other than documentation, trial and error rather than needing their hand held.
This was said over on /r/sysadmin when people were discussing where to start with Powershell scripting and the top answer was to get a basic grasp of OOP first as a foundation.
I guess my point is that the people going into these bootcamps, from the ones I interviewed, didn't seem to be people with that curiosity who had taken the time to learn a bunch of stuff on their own. They seemed to be people that wanted to quickly learn to be a developer. And it's perhaps possible to cover the part of a CS degree that's actually applicable in the workplace and a few technologies in the months that students participate in these bootcamps. But it isn't possible to cover the years of independent exploration that most CS graduates did both before, during and after their degrees. That's the bulk of what makes someone qualified to work in the industry. And there aren't really shortcuts around that learning process.
If you're happy with your current situation, forcing a change isn't going to suddenly make you interested in those changes. If you have legitimate interests, explore them. If you don't, see what catches your eye here on HN and other places and read up on them, seeing if anything naturally does.
Who cares? Can they do the job or not? Do they have the work ethic and professionalism to continue to do so?
The vast majority of people, including those who excel at their respective fields, don't love their jobs. This industry needs to stop using "passion" as a lazy signal for work ethic.
> The most boring developers I work with, the the ones who only learn to code while in college and never developed any interested to learn before that.
Again, who gives a shit if they are "boring"?
Me.
Computer programming as a self-motivated hobby is not unique in this. Many electrical engineers started playing with electronics as kids (e.g. disassembling radios, wiring up homemade amps, etc). Many mathematicians "play" with math as kids before they go to college and get a teaching/research position. (E.g. Andrew Wiles was 10 when he was captivated by Fermat's Last Theorem.) Many biologists and zoologists when they were kids had a keen interest in nature and animals (beyond the typical children's "dinosaurs are cool" stage). Same for astronomy.
> As a mechanical engineering major undergrad, I can assure you that I had no particular experience in the area prior to college.
I'd say this is true of most people entering college. Hence we have introductory courses to learn there.
It's a shame that so many people on here and elsewhere simply want to discourage people from following an interest simply because they discovered it later.
No one expects a chemical engineering 1st year student to have mastered organic chemistry already. Just as no one expects a 1st year mechanical engineering student to thoroughly understand rigid body dynamics at age 10.
Yea maybe they built an RC plane or did some home experiments, but if anyone is doing these things at a young age they are clearly far above their peers.
> Andrew Wiles
Example here-this man is extremely intelligent, it's like using Einstein as an example that anyone can be a genius physicist that changes the world. No, they can't.
We need to just call it what it is: arrogance and gating. "If you didn't do what I did, you must certainly not be any good." Which is an absolute shame
Then you are not aware of the toxic comments from your peers who agree with you.
To recap...
Group 1: programming-is-just-a-job -- the majority -- The programmers who want to compartmentalize their programming strictly to 40-hours work week so they can have a life outside of computers. Programming is just a means to an end. Programming is just the paycheck that feeds my family. Great! There's nothing wrong with you! You outnumber the programmers who view it as an artistic endeavor and self-actualization.
Group 2: programming-is-my-vocation -- the minority -- The programmers who got into as kids and find joy in side projects after hours & the weekends.
It's not enough for these 2 groups to peacefully coexist. It's also not enough that Group 1 outnumbers Group 2. It's also not enough that most cog-in-wheel corporate programming jobs don't even value Group 2's enthusiasm for programming.
No, Group 1 is not satisfied with the above advantages. Group 1 is very annoyed if Group 2 programmers prefer working with other Group 2 programmers. G1 derides G2 as psychologically defective or unbalanced. E.g see HN poster (gyardley)[1] describing them as an "obsessive wretch" and "not an asset". Toxic indeed.
Also This mindset eventually can backfire on even your group 2 people because life happens and just because you have the free time, energy and motivation today to work on projects outside of work doesn't mean you will later when you have a family or health issues or any of the myriad other things that can come up.
Well, G2 people have an affinity for other G2 people. That's human nature! That's not toxic. Look at the various reasons given by G2 posters in this thread: they enjoy a work environment with other G2 people. Just as one can prefer having a comfortable chair or closed office, a G2 can state honestly that they would be happier with other G2 colleagues. Just because that has an effect of G1 not getting hired does not mean it's toxic.
The analogy I like to use is a music band. If they're looking for a guitarist who's passionate about his instrument and music, the guitarist-just-a-job who has apathy about the music will not get invited to join the band. Maybe the apathetic guitarist can technically strum a C chord as well as the passionate guitarist. That's not enough. The band having a preference for the passionate guitarist is not being toxic.
Yes, for many G2 programmers who started as kids... programming/playing with the computer is a very similar intellectual high to a teenager exploring a guitar. Programming feels like fun artistic expression and not "work" or a "job". I think many G1 programmers really don't understand that. If they could view G2 programmers as band musicians, maybe they would have more empathy for the passionate programmers having a preference for like-minded people.
I'm not going to think of programmers as musicians because they're not. They are employees of whatever company. They are there to do a job. It's great that you want to work with like minded people but if that desire means that qualified G1 people can't get hired at your company that's a problem. If your desire means that g1 people can't get promoted that's a problem.
As a thought experiment replace like-minded people, with people of the same race. Or people of the same gender. Or people of the same religion. Do you see the problem now? A mindset that excludes some large percentage of people based on arbitrary standards that has nothing to do with their ability to do a job is always going to be problematic.
Side note if you lead with "looking for passionate" you're already misconstruing the issue, because what a company should be looking for is "able to do the job to whatever standard we've set"
Nobody in this thread has said this. Maybe your misunderstanding of the other side is part of your frustration on this topic?
Some have said that the self-taught programmers were better. Some have said passionate programmers were more driven to stay relevant in a changing field. Some have said they learn more from coworkers that developed interest in programming outside of college and work.
You may disagree with all 3 of those statements but none them are about dispassionate programmers not being able to succeed.
>It's an issue when you're desire pushes all the G1 people out of the work place.
This has never happened. In fact, the opposite has happened. G1 is the overwhelming norm at most businesses. To repeat -- most programmers do not view coding as a vocation. G1 programmers already fill most jobs slots.
The idea that the minority of G2 programmers want a work environment with other G2s and this is hurting G1?!? That is a complaint that's way out of proportion to reality. Literally.
Also, I'm not sure why hiring heuristics that negatively affect G1 somehow has a higher moral standing than heuristics that negatively affect G2 programmers. What about the opposite situation? E.g. G1 people say being well-balanced with non-programming activities helps them be a "better programmer". Great! Let that belief be a guide and don't hire G2 programmers since their excessive interests in computers actually makes you believe they perform worse. They are not assets. (See my previous cite to HN thread for example of this.) In those cases, G1 wins over G2 in getting the job.
>They are employees of whatever company. They are there to do a job.
The founders and many programmers would like the daily effort to be "more than a job" if possible. Sometimes, that's not possible (e.g. Walmart cashier). However, with programming, some do try to optimize for a better work environment.
>with people of the same race. Or people of the same gender. Or people of the same religion. Do you see the problem now?
Those race/gender examples weaken your argument. Having a preference for people with similar intellectual dispositions in programming is very aligned with Martin Luther King's "not being judged by the color of their skin, but by the content of their character."
>arbitrary standards that has nothing to do with their ability to do a job
Then this discussion has no resolution because in this thread, many have written about experiencing the opposite. Instead of it being an "arbitrary standard", it's been a positive correlation with performance on the job.
>what a company should be looking for is "able to do the job to whatever standard we've set"
Ok, many programmers in this thread said they prefer colleagues who enjoy computers+programming as outside interests. That's the standard that's been set. Many companies want to attract those programmers by hiring G2.
Neither ghaff nor I wrote anything about kids "mastering" the STEM topics before college or the first job. Therefore, that higher standard stated by you is a strawman.
I thought ghaff was talking about STEM side projects which is certainly something within the abilities of teenagers without mastery of programming. That's what my reply to him/her was about and how "playing with science" is not unique to programming.
No one would be expected to do meet those high standards, as you say. No one would be expected to be experts in basic chemistry by their first year of college.
Yet in this very post, there are countless examples of people saying the best programmers were the ones that knew it all before college, who didn't need college, who put in the time to learn before college, etc.
No other field is this expected. That's the point.
Playing with science and doing small little cute fun experiments is a lot different than me teaching myself productive front end development at age 16. I don't expect other 16 year olds overall to do as I did. Nor do I judge people if they didn't.
Nobody in this thread has said that programmers should "know it all" before college. You're injecting conditions and standards (like "mastery") that no poster actually wrote.
>No other field is this expected. That's the point.
This isn't true. You can see coaching advice for electrical engineers to update their resume with any DIY (do-it-yourself) electronics projects that would demonstrate self-motivation, passion, etc to potential employers. In that respect, it's not much different than computer programming. Do electrical engineers get jobs without any personal side projects?!? Yes, of course. Same as computer science -- many programmers get jobs without side projects.
In both scenarios, it isn't absolutely necessary but it's a way to stand out from the crowd.
I've hired good developers who had this type of passion, and good developers who lacked it. But I've yet to hire a truly great developer from the latter camp.
It seems to me this is true in just about every industry, those who have devoted the most time and energy to a skillset tend to be the best at it.
If they're content with where they are, there are numerous problems:
• as the business case becomes more complex, they won't adapt
• as you grow and progress, you'll be promoted and they won't. No one wants to work in an atmosphere of resentment.
• you want to learn from your coworkers while they learn from you. If it's one way, you're just slowing yourself down.
I don't want to work at a place filled with guys who want to do the same job for the next ten years. That workplace is going to be commoditised. They'll eventually find themselves on the Internet complaining about H1-Bs and outsourcing and how git is hard to use and technical interviews are evil because they have ten years of experience.
No thanks. This field is privileged in that there are lots of us who like our job a lot. Life's too short to settle for boring coworkers.
People usually call those types of qualities "passion," "love of job," or "interest."
You keep trying to work around definitions to suit your narrative when people are just trying to have an honest conversation. You are shoving intent into the OPs post that isn't there. Simply put, what they are saying is that those from bootcamps are there doing the what they think is the bare minimum in order to keep getting a paycheck at that moment.
You might think, "Hey, just raise the minimum and they'll raise with it, it's your fault for having low expectations!" However, when those expectations are raised, you rail against them. You can't have it both ways.
You can't argue for someone lacking drive, ambition, and work ethic, and at the same time bemoan people for demanding that.
Instead we should precise terms like drive, interest in technology, motivation to learn, etc. These make sense and don't bring any emotional baggage with them.
I want to learn from my coworkers. Making decisions that require evaluating new software or new techniques is difficult and risky, having more than one damn person who can contribute to that process makes a huge difference. Plus, I just like learning things from people.
Sure, it's very good for the business if they keep up with new developments in a rapidly changing field, but personally it's most important to me that my coworkers and I are helping each other sharpen our skills and make tech decisions responsibly (being fad driven is worse than being out of touch, I don't mean just knowing about what's "hot right now").
This isn't always true, of course. Some developers can have excellent skill and have no interest in programming outside of work. I have a coworker that does virtually nothing outside of work, doesn't keep up with current events outside of what our group discusses, but she is a great programmer and picks up on things very quickly. She shows genuine interest in the work she does at work. She's been with us for nearly nine years. Culturally, she's different than me and another one of our co-workers in a more fundamental sense, but as part of our _team_, she is a perfect fit.
I don't agree. Interest in doing a good job (i.e. work ethic) usually correlates with this, but I do not think work ethic corresponds very well with interest in the field.
> If you have a team of interested developers/hackers, then the lack of enthusiasm can drag the team down, both in knowledge and culturally.
I think part of my problem with the statements in this thread is that I would never put together a team of hackers to run a business. Your statement implies a team that is interested in tehcnology for technology's sake rather than as a tool to solve a business problem.
I wasn't expressing a 1:1 relationship. I also expressed an example where this wasn't the case: interest in the position and the work we do, but not a personal interest outside of work.
> Your statement implies a team that is interested in tehcnology for technology's sake rather than as a tool to solve a business problem.
I just happen to be a hacker that was hired by a business. That wasn't why I was hired---I was hired because of certain qualities that so happen to be a consequence of my being a hacker, and because of fundamental interest in certain topics (which also included side projects).
I'm certainly not interested in technology for technology's sake: I'm the author of a large system on which one of the core parts of my company (the company I work for, not a company I own) is based (raters for an insurance agency), and it was made using practical, business-conscious decisions. My coworker (he doesn't identify as a hacker) is Technical Director.
The discussion is whether someone who is just in it "for the paycheck" will be able to solve those business problems as effectively as someone who has a deeper interest in technology for technology's sake. By itself, that's obviously not enough signal to say one way or the other. There certainly are extremely valuable people who don't code outside of work, follow new language and tool discussions online, etc. I think it's equally obvious though that such an interest is a positive signal. If you told me nothing else about two potential hires except person A writes Java at work and has no interest in the field beyond that, and person B writes Java at work, but has a Github page full of utilities she wrote in Go, Lisp, Haskell, whatever, I'd bet a small amount that person B is probably better at solving technical problems. You can't say that for sure, and any of the myriad other factors that actually do matter could break the other way and make person A the better hire for an actual business, but outside interest is a positively correlated trait.
Many programmers who enjoy programming will have a preference for hiring other programmers who also enjoy it. That doesn't mean they can't hire dispassionate programmers but that still doesn't erase the preference for passionate programmers.
>This industry needs to stop using "passion" as a lazy signal for work ethic.
There's definitely a place for dispassionate programmers (as that's probably the majority of programmers who just think of it as a "job"). However, it's wrong to vilify programmers-that-love-their-craft having a preference for other programmers-that-love-their-craft.
Exactly, and it isn't just 'Work Ethic', I wanna work with these guys [1] in 'Silicon Valley' tv show who would go around doing a Jerk off calculation just because it is a fun calculation to do. Not just people with strong 'Work ethic'.
I'm not sure about "passionate" programmers, but programmers who enjoy programming are generally always on the lookout for new trends, new tech, new libraries, and even if you aren't using those things, being aware of them is massively useful. If you're relying on the business and your coworkers to drive your skill improvements, then you're going to stagnate, guaranteed, because the business doesn't care at all about new technology and has no desire to improve or change anything, and your coworkers will only care if (shock) they enjoy programming.
When you put together a team of 9 to 5 only in it for the paycheck programmers, what you get is a snapshot, their combined skills and technical knowledge will be the sum total of exactly what all of them know when you hire them and it will never improve. Putting together a team of programmers that enjoy programming and are doing it not just for the paycheck but because they enjoy the craft gets you a constantly improving team. Their skills stay fresh and they're motivated to improve and keep your tech relevant and modern, which ultimately saves you in the long run from having to face massive rewrites of old creaky systems, or ending up stuck trying to hire massively expensive developers to work on ancient deprecated technologies.
1. In for the money, no love for the job
2. In for the money, but also love the job, codes on spare time
3. Category 2, but no more free time (family, older parents)
I was in Category 2 but now on category 3. I show up to work early, work intensely, do not waste any time, and try to leave at a normal hour. On weekends, instead of open source projects, I'm spending the time with my mom who is getting much older and requires help and emotional support from the family. That does not mean I have poor ethic or lack of interest, it just means I have a lot of family commitments. I am very productive at work, I love it, but there are clear boundaries unless there is some major deadline or production issue. Speaking of Production issues, I write very very good code to ensure I dont have Prod issues and/or I can quickly do a root-cause-analysis of issues that pop up. My personal needs focus me like a laser on productive time at the office.
Embrace the time you have left with your mother. Work will always be there, and there is no job more important than your family. Do not give on your boundaries.
I spent the last 2.5 years of my mother's life (she passed away suddenly last month at the age of 59 from a brain hemorrhage) working for a startup, not making more time to spend with her because I thought I'd have at least another 5-10 years with her, and my heart hurts every day thinking about how I didn't spend more time with her. Do not make my mistake. It's just code, you're not saving the world.
It is a rare person who has enough work ethic to force themselves to use their own free time to improve in a field they don't have any passion for. If that weren't so, we'd see a lot more self-taught physicists, mathematicians, and other STEM people.
> The vast majority of people, including those who excel at their respective fields, don't love their jobs.
People who excel in their fields don't love their jobs? As kids nowadays say, "[citation needed]".
I fell into IT and struggled with feeling overwhelmed the first year or two but once I found the things within that field that fit my personality, that's when I felt more comfortable and could push myself more and ignore the BS that I didn't really like.
I completely agree about the "passion" thing. You can develop curiosity and interest about anything.
No algorithms, or data structures or complex problems to solve. Something that I would include if these were fresh college grads or senior developers with extensive background.
Again, I didn't mean to call anyone dumb, I don't think these people are dumb at all, they were just bad/fast trained.
Uhhh that's really difficult in js even for experienced devs. Way too much non deterministic behavior. I hope this exercise came with tests and a working debugger.
This "started coding in middle/high school or college" is a misleading metric since it assumes everyone has equal access and support to learn that way.
As some one from India who never had own computer until finishing college (the early 00's), along with no internet or cell phone, I find it hard to accept/respect those people who gloat about how early they started coding.
I always assume there are thousands of kids in the US who were/are not as lucky as the kids who started coding while they were in their diapers.
People/companies in US love to talk about their efforts to fix diversity, but without fixing this attitude of "earlier you learn, better you are" attitude, no amount of throwing money will fix it for the true diversity candidates.
"N years experience" loses value as a measuring stick when there are probably 2 orders of magnitude separating how much code the most passionate and least passionate developers wrote in that time frame.
This mindset seems to work rather well for more objective areas like athletics. I don't see any reason why an intellectual pursuit like programming would be any different.
See anyone you can think of from the 60s and 70s like Ken Thompson and Dennis Ritchie.
Ken Thompson had a MS in EE/CS and Dennis Ritchie had degrees in both physics and mathematics, all of which are far more difficult than programming. Most of the other great names of the '60s/'70s have similar backgrounds, invalidating your point.
Architects do their best work very late in life.
I personally wouldn't want a surgeon that started cutting into people at age 9.
But at least, in athletics, there's no charade of trying to fix the gender/race bias by throwing money at programs that make other's catch up so that they can claim "equality".
Most Marathoners and NBA players often are African or have African ancestry. And no one says the same team should have an equal number of <insert race/gender here>.
IMO, humans are adept at learning intellectually for a much longer time, compared to improving physically in 'objective areas' like athletics, which needs to begin very early in a human's life.
1. Athletic performance is easy to measure. Especially for individual sports (track and field, gymnastics, weightlifting) the numbers are the only way to compare athletes. Not so for programming. If someone invented a way to definitively judge programming ability today they'd become very rich, very soon.
2. If we assume that mastery of programming follows a sigmoid-curve (not an unreasonable assumption, IMO) it means that the ability difference in "coding for X years" and "coding for X + 5 years" becomes nearly indistinguishable for some value of X, for people of roughly similar innate ability and drive to improve. And if you believe in innate ability, then there will certainly be people who came to the field late and caught up with, or surpassed, less-innately-talented colleagues who have been programming longer.
3. One of the reasons that starting at an early age is important in athletics is because peak performance is harder and harder after you turn 30. The "growth" phase has to be therefore significantly accelerated. There's also evidence that for technical sports requiring motor coordination (eg. soccer), learning young is better. Whereas people can code at peak level until the day they die, assuming no other illnesses.
The issues with diversity, prejudice and bias would be much easier if there weren't cases where something was both unjust and true. Software development is one of those activities where experience is helpful, so those who start earlier are generally better.
And it's not hard to guess why. Just because you've been programming for a long time, doesn't mean you were doing it correctly, or even understood what you were doing.
For almost everyone else I've worked with it's just a job. No Github account, no personal projects, no dev environment setup on any home computer.
I studied CS and Philosophy. I could phone in a philosophy paper if I wanted. I could not phone in a linked list implementation. I know companies loathe the idea like no other, but software engineering is a skill that is difficult for most people to acquire and is likely to remain that way. Mostly it boils down to peoples understanding and value they place on logic. Anyone with a good grasp on, or even just a high value for logic, can learn to code. No one who sees logic as 'nitpicking' can learn to build systems that function predictably, reliably, and accomplish a defined goal.
The idea that code that doesn't compile is not worth partial credit is wrong in academics. In the real world the code needs to compile first, of course, then run. However if your professors cannot look at your code that doesn't compiler and decide how much partial it is worth there is a problem.
That said, getting code to compile is a trivial part of the problem.
75% of the grade was compiles and works, and the rest was style, readability, and performance.
If it didn't compile, you basically failed the assignment, if it didn't work you could get up to, but not more than a C, 75 out of 100.
Generally the task is not writing code, it is solving a specific problem and non-compiling code is a non-solution, not a partial one.
What about pseudo code that has the "right logic" but will never compile?
What if I submit python code that works as a c file, should that count?
This is not true in my experience as a professional. I write pseudocode all the time. Often the fastest way to evaluate architecture choices is to sketch out your architecture, sketch the consumers of your proposed API, and see what issues come up.
Making this kind of code compile is a waste of time. Reading code without the computer is a crucial skill.
Graders require compiling code because it's easier to grade.
Only difference is that then, the token technologies used for study were out of MS's desktop stack.
Source: worked with lots of outsourcing/offshore partners out of India during that time...
edit: I should also add that in the US the same could be observed: uptick in CS grads who only started out in it for the money, had no real interest in the actual building blocks they were given -- and were predictably uninspired in the workplace.
The percentage of 'good' programmers was higher, but that was only because there was a 4-year barrier to entry vs ~16weeks-1yr for the tech schools in India.
Are they game developers? Are they working on enterprise apps? Are they working on lead-gen landing pages for marketing companies? Data visualization? Accessibility-focused? etc...
Front-end is becoming increasingly specialized to a degree.
Hiring managers are under a deluge of underqualified code boot camp candidates, who are trying to effectively get past resume screens using all sorts of tricks. The blow back from that (I'm speculating here) is that code boot camp folks are probably often being screened out early at a lot of places since its just too difficult to assess them on paper based on the extensive grooming their resumes and github profiles get by their mentors at these bootcamps.
Instead, my advice would be to clearly label the work you've done at a code camp in your README files and include a link to your github. Explicitly call out on your resume projects you have done on your own, and talk about those in your cover letter. If you have literally any other projects or experience related to software engineering include those on your resume and emphasize them!
But highlighting your code camp and trying to tout it as "highly selective" and "accepts only top 1% of applicants" and all that stuff may be doing more harm than good at this point. The well has been poisoned by enough under-qualified people applying that ultimately need to be screened out via an on-site interview, which is time consuming and considered a failure of the hiring process, since they have been set up to pass the resume screen and the initial phone screens. So my advice is to just leave it off, consider the knowledge a secret asset, and don't risk inadvertently damaging your own application!
All it takes is for a company to be burned once or twice by misleading applications from a coding boot camp candidate to just auto-screen out all resumes from them in general. It sucks, but I found myself looking at resumes that seemed genuinely good, but as soon as the boot camp was listed there, I no longer had trust in what I was looking at. So be mindful, there may be folks out there who would have normally had you interview but didn't just because of past negative experiences with others from your code camp, or other boot camps altogether!
If there is a sufficient correlation between radically underqualified candidates passing the initial screens due to their applications being (retrospectively) designed by the coding boot camp to do so, then it's reasonable to assume applications from those boot camps contain basically no real signal, and so really don't say much one way or another about the candidate's technical skills. In general, interviewing people is costly, and so with minimal signal you'll just say "no."
On the other hand, if there is no coding boot camp on the resume, there's no reason to believe the person's resume, github profile, etc, has been hand crafted by domain experts around passing technical job screens. You can much more likely take it at face value. So, that is why my honest advice at this time is to leave it off, because you are probably doing more harm than good. (This doesn't mean remove the work from your github or wipe the knowledge you had from your brain, just don't put it there because it may be sending a negative signal, regardless of your own merit.)
Once the person is in the door for an interview or the job their application is, generally speaking, not very relevant at that point vs their actual abilities to get the job done and work well on the team.
And you don't need to tell them you went to a boot camp. So if you get hired without mentioning it you won't deal with that bias.
For a junior web developer position? Yes, absolutely.
And it turns out that junior web developers make a shit ton of money in the bay area.
A whole lot of companies do not need serious CS algorithms experts. A whole lot of companies merely need blue collar, CRUD web devs to build their CRUD angular react node web app.
Being a crud web devoper is still a pretty good gig.
Part of the problem is the high salary comes with the expectation of quick growth.
I think a lot of bootcamp graduates come up short.
11 hours a day for 12 weeks can't compare with two hours a day for a year.
I never learnt how to code though, but I know a lot of technical stuff.
So I legitimately thought that "hey, I can learn to code in a few months"
Nope. 12 weeks is hilariously less to truly understand coding.
You can, at most, mimic the actions of the teacher.
It took me quitting, then months of idle rumination to understand what a recursive loop could be used for.
In hindsight, I know what I did wrong and what I should have done instead.
I'd say it took me at least a year of failing before I could gather my bearings and understand what was going on.
But, that's not who these things are aimed at. New programmers need time to absorb the fundamentals of programming. Getting pushed through some fast-paced program is the worst way to absorb anything.
I do like the idea of hopping right into writing applications vs the more traditional route, but it needs to be over years, not weeks.
In reality all good coders are self taught - you can't really teach this stuff. You have to learn to play, to explore the solution space and figure out the different ways of composing your raw materials. And you need to do this over and over again throughout your career as new materials become available. Self-teaching never stops.
You can read about it all you want but unless you are doing it, you are not going to grow.
If you have a "great resume" then a bootstrap certification is not what makes it great. Self taught developers prove that a degree is not essential, and being self taught shows motivation and interest.
If someone disagrees with you and they have more experience and/or education, then your level of knowledge is the first thing they would attack, so again keeping it on your resume is no advantage in that case.
Without any commentary on whether you can be skilled/productive/knowledgeable after a bootcamp program, it CAN hurt your odds to list it on your resume. A former employer of mine was burned so bad by a string of bad hires they say they will never work with bootcampers again. Anecdotally I have observed that bootcamps tend to have their own tight-knit networks of alumni or companies willing to hire from a given camp, so I can't comment toward the net effect (whether it's better not to list the bootcamp on your resume at all), but I can guarantee you there are employers who want nothing to do with you if your primary education and experience are from a bootcamp, as misguided as that may be.
The person you are responding to makes a reasonable point that if an employer cares about productivity, then what you can accomplish on your own and what you actually know and understand should be emphasized. They may perceive that applicants whose primary self-advertised selling point is "I went to Einstein-Hawking Ruby Camp" may not have anything unique/valuable to offer for a given role because they seem identical to many other applicants from that same place, some/many of whom may have underperformed. I would recommend not developing a chip on your shoulder about it.
Wouldn't help. Would actually be counterproductive. Listing requirements higher than actual requirements is a game, and boot camps are good at figuring out and optimizing for games. Bootcampers will (and should) apply to literally every job description that involves writing code.
It is still pretty obvious, though: the resumes are all the same format, as are the application channels and techniques, and experience levels.
I'd recommend these individuals look toward internships, as I haven't found one qualified for a full-time job yet. Why aren't bootcamps lining up internship programs?
Unfortunately, I do not believe they are able to line up internships for all students anymore.
Are you unsure about their skills and need time to evaluate?
Agreed, however, that internships and apprenticeships are a great first step coming out of bootcamps, but I don't believe that's the expectation being set when they're admitted. The reason I usually have to pass on bootcamp grads is that, working in a client-focused environment on tight deadlines, time spent training someone up from a narrow view of the industry to what we need is at a very high premium; CS grads coming in as Juniors have anecdotally worked better to that end.
Apprenticing at a product-focused organization with high competency in managing expectations is where I see most bootcamp grads excelling.
Not sure "despite" is the right phrasing here. I'm a DBC grad from about three years ago, and I know DBC had various issues, but I do suspect that there was pressure from Kaplan to expand rapidly, crank prices, and decrease the quality of the education (because that's how Kaplan made their money everywhere else they've been profitable). Kaplan bought them right before my cohort started, and there was serious concern even then that it was a bad omen. I think a lot of startups in general would do well with less pressure for rapid growth, and I suspect that the bootcamp market is much the same.
It's not surprising that Kaplan, a company that relies on services that are supposed to improve performance but not actually teach, would suck at teaching skills. I think the debate should expand from just coding schools vs uni to comparing coding schools.
I'm including myself in the "good deal of prior experience" group, I did fine in the class and in my subsequent jobs. My class even had students that had been web devs on less desirable stacks using the class to ramp up on rails and they did even better.
I haven't done a bootcamp, but I've done quite a few MOOC courses so my opinion is based on equating the two. This might not be a valid assumption.
To me, MOOCs and I'd imagine Bootcamps are good to get an intro to something new, but they can't replace rigorous study of a defined base of fundamentals...i.e. a course of study.
What seems like a real opportunity are programs like OSU post-bacc in comp sci, and GA Tech comp sci masters. I've been toying with OSU for about 2 years now, and haven't commited to it yet because they don't have some of the courses online that I'd like to take (computer graphics). And I haven't done the masters program at Tech yet because I don't want to get into that without a more solid foundation. To me, more schools with post-bacc in comp sci and expanded course offerings (online) would find themselves flooded with demand. Recently I signed up at UCLA Extensions...It is almost the right thing, but still has a limited offering and isn't quite the right fit.
I left The Starter League after the first semester when I realized the buyer's remorse of paying more per day than tuition at MIT. The prices for bootcamps simply aren't worth it, especially given the numerous online and self-paced options out there... many of which are free. How my story ended: I left the bootcamp and took a few Udacity Nanodegree programs for $200/month and (full disclosure) loved them so much that I applied for and got a job at Udacity. I really flourished in the self-paced environment, and found that I was able to learn a lot more, faster. Now, I get to go to work every day and build systems that provide affordable education for students across the globe.
There are so many amazing and cheaper options out there, and I cringe when I hear about people dropping $15k+ for the same (or better) content that they can get for 100x to INF-x cheaper.
At the end of the day, if you're able to increase your salary from $30k to $80k, the extra $15k on a course seems well worth it.
I assume the same thing will happen with bootcampers, because I feel like many of them that I've met lack the passion for CS that the better programmers have. I know a few bootcampers, a couple from HackBright and a couple at my work. One of the HackBright graduates never found a job and went back to her old job which was kind of depressing considering how much she spent. But the others were decent, not great but decent. But I would prefer hiring a good fresh grad with a couple of internships under her belt over any bootcamper I've worked with, mainly because of the depth of knowledge they would bring to the table. Let's be real, how much can someone learn in 12-16 weeks, compared to someone with 4 years+?
I had MCSE back in the day (my org wanted n of them so it could become a gold partner of Microsoft or something, and the perks such as MSDN subs and 10 support calls were nice).
What killed it was "braindumps", people weirdly undermining their own certification by posting the questions they could remember online, until databases of all the questions were built up, at that point you could literally just memorise the exam, or blatantly cheat in some locations. That was why it was worthless; but someone who had actually learnt the material the old-fashioned way would be competent.
I'm not sure it's an improvement.
We've hired a few, but only one has actually worked out.
I came from a mix of technologies (approximate knowledge, but a master of none) before settling into the data sciences (Python ecosystem).
Galvenize has been precisely the challenge I was looking for and so much more. I barely got by the interview process, but picked up a Veteran Scholarship worth half my $16,000 tuition along the way.
Quit my job as a Salesforce case jockey and currently trying to stay afloat with the curriculum.
It's intense. As it should be. I want it that way. Otherwise everyone would be doing it. A counter argument might be that; "every one and their mother is taking a 'Data Science' title for the pay." From 2013 to now, that may have a lot of truth, but they are eventually found out I hope.
As for my cohort. There is a Physics PhD, undergrads in Mathematics and Physics, an acctuary Statistician from an insurance company, a Mom, and Biology grad, and a Veteran. An elclectic group I feel.
At this point, half way through, we just want to survive and not wash out.
Finally, once capstone projects get rolling in a couple weeks and whom is left of us should be feeling pretty good about their accomplishment and competent to take on entry and junior level Data Science roles.
How can this work? I mean, I can understand those with a math background being there to learn the tooling and programming, but how can a mom (presumably with no prior education?) and a vet (also presumably without any other qualifications) keep up? Or, if they're teaching at the level of 'this is the slope in a linear equation', what's in it for the math guys? I just don't understand how this sort of thing works in real life.
There's no reason to assume the mom isn't similar (many stay-at-home mothers in the US have college degrees).
Not just data science but "the data sciences" now! Where will it end?
Just show me what you've done. Send me repo links, production code, or even just the end result with some sort of proof that you actually built it. That's the best part about any craft - practicing or building something creates tangible results. If you don't already have a portfolio, get to work on that before you start applying.
Heck, even reasonably good software can produce a very negative impression. Utilitarian code can be seen as ugly or overly simplistic. Elegant conceptual stuff often runs the risk of grinding against biases and preconceptions of the particular reviewer.
For your second argument, I know what you mean, but that's also totally subjective, dictated by chance, and would apply equally across the board for all candidates. Even if that happens, it sort of naturally levels itself out competition-wise.
Also, remember that you're evaluating the employer too - do you want to work for someone who chooses employees that way? Would you want to work with someone who has a closed mind and an axe to grind about certain concepts? I wouldn't trust people like that to make good decisions that will make the company succeed, thereby keeping me employed - let alone providing opportunities to advance. Plus they sound like they'd be a pain in the ass to work with.
That would be difficult for people who work for companies that claim presumptive ownership over everything they produce.
I was commenting less on the article and more on the general disdain for bootcamp grads that seems to crop up in every article or thread about them. It always devolves into whether people with this education or that education are any good, and it's just completely irrelevant.
I get it, development is a craft, it's easy to judge the quality or experience level of a coworker after having to deal with their PRs for a month or two. However, it's not like any toy project I could throw on github is going to have real relation to the actual work I do, and trying to replicate e.g. some of the third party integrations I've written internally as public stand-alone packages is going to get me fired and sued by an overprotective employer.
This isn't a hypothetical fear either, multiple times I've gone through phone interviews to a "lets review some of your past work" stage, and my "I can't legally show you any of these things, but here's general descriptions of some of the major internal projects I've led or handled solo" has resulted in failing to make the next interview round.
Not that you need to know what the acronym stands for (hell, no one I know uses the technique to get xml anymore anyways!), but it is weird to see the details wrong in such a detail-oriented discipline, and wouldn't people wonder where the name came from?
Sure, our UX/UI guy does "AJAX" to create working prototypes of his designs before handing it off to be stuffed into React / Ionic / WhateverJS (which is quickly becoming the standard requirement for a UX person), so it's not obsolete tech by any standard. But let's not act like "boutique" web dev shops are actually still a thing... stay relevant people, especially if you're paying those sorts of fees to show up and learn how to build an Angular2 app on headless Rails in 2017.
> ["Ajacks"] Makes me wonder how fast and loose they were playing with instructors...
IMHO, there's too many jargon-jockeys in this field and not enough people who can truly explain things. Getting the acronyms strictly correct is the least of the problems.
IMO Bootcamps are great, people try and add up the cost and run the numbers, but the experience of growing and struggling through stuff with others, in an in-person environment, was enriching.
If there was a Kotlin Bootcamp in my area I'd be interested in learning more.
I work at a large company that absorbs tons of MIS/CIS grads. The non-CS grads that excel are the ones that are constantly hungry to teach themselves new things but for the most part they suck compared to the CS people. I can only imagine how much worse these bootcamp folks must be.
1) Define success before doing anything. Pick specific companies or a specialty you want to end up with first.
2a) Take the three months (or however long you can afford to invest) and work backwards. Figure out the most impressive and relevant project that can be reasonably be accomplished in that time. Make sure it's part of a hot trend because the time spent is probably the same regardless.
2b) In parallel, network and build the best quality contacts you can in your target area. Blog about any interesting observations made as the project progresses. Come right out and say in your posts that you are doing this in hopes of building skills, experience, and proof of your abilities, and say where you want to end up.
3) When its done, make it public online make sure it presents with visual appeal and with cogent explanations. Ask for feedback from your contacts, because that's your excuse to show off: "sure was challenging but I was able to go from zero to learning and building this in three months!". Ask for feedback because it's your chance to ask about openings and interviews. Ask for feedback because you really will need it.
How does somebody new make a good project choice, when taking into account everything that would actually be impressive and help land a job would require years of experience to know? You can't without feedback or validation, so don't make the mistake of choosing solo. Just ask people who are in the target area to help you decide. Lots of people would be willing to give input and it's more chances for networking and follow up conversations.
I think a big reason coding bootcamps exist is because the mental model is that "pay money -> software job" -- it's an appealing idea, and doesn't necessarily mean the person is not going to put in the effort, but it's broken.
I think it makes logical sense to someone that if they are going to pay lots of money for something, they think they are going to ultimately have an advantage over someone who took the path you mentioned, which is basically "free" other than opportunity cost. Surely, they must be getting something valuable for their money. Think of similar things like SAT test prep or other forms of job training that actually do legitimately teach trade skills that result in job placement that are hard to learn without experienced mentors, in person training, or expensive equipment.
Unfortunately, the reality is the opposite in software engineering due to the nature of what we do and what makes people really good. You don't need much other than a computer, an internet connection, and focused time to build something noteworthy enough to cause potential employers to notice.
The person above who built something from scratch on their own stands out head and shoulders above the sea of applicants from coding boot camps who have only done coursework.
There's nothing wrong with a "pay money -> software job" mentality, as long as the person is interested in the work, and puts in the effort. I know several people who came out of college with a humanities degrees only to become a poorly paid social media consultant or something similar. They didn't have the know-how to get started with software development on their own, but they enjoyed working with tech and were smart. They paid the $15k to the local bootcamp and within a few months got jobs increasing salaries from ~$30k to $80k (I know one who started well into six figures).
We shouldn't lock people out just because they didn't get into coding at ten years old. Bootcamps often lead to solidly paying entry level coding jobs, a great lifestyle, along with the gratification of actually building something. Bootcamps serve a real need between self-study and a heavy-handed multi-year BS or MS. The driven MS or self-study guy or gal may get the better job, but bootcamps will get the candidate in the door quickly, and they can prove themselves while on the job.
It's easy to assume resources are the key point - are people with less time/money well served by these bootcamps?
However, it makes sense that individual personality traits like motivation, ambition, and comfort level with uncertainty / cutting your own path could matter.
As aside I've always felt successful STEM people receive unbalanced praise, always credit for some ethereal genius, not enough credit for maniacal drive, near clinical obsession with goals, gall. Does the general public realize that everyone from Einstein to Musk would have been greatly diminished without these qualities?
I friends with an incredibly intelligent patent lawyer who quit her job to become an FBI agent. I know another really smart guy who took a huge pay cut from his big-tech job to be a reporter for the Wall Street Journal. They didn't quit their technical fields because it was too hard, they could easily handle the STEM jobs when they were thrown at them.
I look at them now and see an even greater level of professionalism than they had in their previous positions, and that comes with a greater respect. Many STEM jobs often get that self-respect, and probably also FBI agents ans WSJ reporters, wish the same could be said about many other positions.
If only there were some sort of...educational institution...that could put you into contact with people in the target area and get you that kind of input, even if your personal network doesn't already include people in that profession. And that could help you figure out the most impressive and relevant project that could be reasonably accomplished in a short time. And that could provide instructors from the industry who could provide immediate, rapid feedback on your projects. And then, maybe that institution could connect you to a network of quality contacts composed of previous graduates and contacts from the instructors' time in the industry.
Building a high quality sales contact list and network is extremely difficult, it can take decades. It's not uncommon for salespeople to be hired mostly on the basis of their rolodex.
Conversely approaching someone to ask for career feedback is much easier. In general, people don't want to be sold something, but they don't mind helping out an up and coming person in in the field. It can even make them feel good they were respected enough to be asked.
There was a sense among some that webdev had advanced to a point where the skill of labor needed had declined to cogs that could be squirted out by a crash course.
Ofc, there were always people willing to take the opposite perspective: that advances in the state of the art of development are continuously folded back into development processes. And there aren't roles that still require man-time after driving the skill barrier to zero because that becomes tooling given to the internal customer that specializes in a different part of the business.
But payroll and management salivate at the cog idea. So we got to see the idea be tested in the marketplace and prove out what was fantasy and what wasn't.
I remain a big believer that bootcamps will continue to supply a lot of the talent in the tech world, particularly in app development. I know too many success stories to think otherwise.
A couple of cherry-picked examples don't mean the coding bootcamp industry is going anywhere. IMO, there's no reason to panic until these bootcamps are being advertised alongside x-ray technician jobs during midday reruns of Judge Judy.
Now, the glut of junior devs entering the market - that's something to be a smidge concerned about.
The struggle to choose your domain: Web, Mobile, Embedded, Databases etc.
The struggle to choose the programming language(s) / technologies to learn.
The struggle to choose in which order and from where to learn them (for free).
The struggle to choose your Code Editor / IDE.
But guess what you'll be doing as a Software Engineer :)
I didn't go to one but I imagine those decisions are being made for you. But I know about the struggle, and I remember it with pleasure and satisfaction.
In a gold rush, sell shovels.
In the 2000s, tons of programming schools were created to exploit the lax student loan programs. They would bring in countless people and charge then $10K or $20K or even more to teach "programming" that you could realistically learn on your own. But it was so easy for people to get student loans and it was so easy for these schools to get people low-end programming jobs, that they made a killing off of it.
After the financial crisis and the crackdown on ineffective "programming/tech" schools ( especially their student loan programs ), these guys rebranded and remarketed themselves into "boot camps" which take a portion of your future wages.
When times are good, pretty much anyone who can type of a keyboard can get a job, but when a recession comes, these "boot camps" graduates are the first to be let go.
So my guess is that these boot camps expect a recession soon and are cashing out. Maybe they are the canary in the coal mine. Maybe the tech bubble is going to pop soon. Given how much they charge (10 to 15%) of the wages for the first few years of their graduates, I doubt they would leave so much money on the table unless they feel a shift in the economy or hiring is coming in the near future.
> Two specific coding bootcamps that 1) had been acquired by for-profit education conglomerates and 2) underwent relatively rapid expansion into second and third tier tech markets went out of business.
> As evidence of a larger trend, this article cites a single quote from the CEO of "a private lender and an alternative accreditor for the fast-growing boot camp sector." This is unpersuasive.
This article quotes Ryan Craig of University Ventures vs Rick O'Donnell of Skills Fund, to nearly the same effect.
So: big name closures of two bootcamps with similar pain points and acquisition contexts, vs. seemingly healthy expansion and unchanged placement rates for schools like Flatiron (mentioned in the article), Hack Reactor, App Academy, General Assembly, and so on. Further consolidation in the field wouldn't surprise me, but are we really observing a trend worth reporting on?
Once recruiters figured out that placing these under qualified people into jobs was not a good thing, the bootcamps started to train people how to fake their resumes. Just like how people figured out that if they want a specific job, they only need to update their resume to include all the keywords in the job description.
When I was hiring and screening hundreds of people, applications would show 'projects' completed on them as if they were real work. Hired.com was full of this for a while until they started blocking them there too. People would go so far as to make a domain name for a class project appear as if it was a real company. You'd go look at their github and realize they only made a few commits towards the 'project'. How is that a demonstration of skill?
I'm sure a few people have come out of these bootcamps with some real knowledge and skills. But this is the edge case, not the norm. You can't shortcut your way to a well paying software engineering career by spending a ton of money.
I believe strongly that software engineering is an art form that requires tons of practice to get good at. As such, you wouldn't expect a designer or artist to show up at an interview and not be able to show examples of their work. Just like a software engineer should be able to show something as well. Of course, the counter argument to that is maybe they didn't have time to work on something extra curricular. Except for the fact that the people who did the extra curricular work in high school, got into better colleges. Go figure.
Even worse is that I did try to interview some of these people and it became clear that the bootcamps were about training for the minimal viable education. Leaving a lot of basic fundamentals out. I'd ask what idempotency is and get blank stares. So sad.
Yes, you have to start somewhere, but that doesn't mean you are immediately prepared to get a job as soon as you graduate. That is part of the broken promise of these bootcamps.
What I'm saying is that you should have clearly identifiable portions that you can point at as something you did. I also think that it takes extra curricular activity to truly master a subject. You can't just rely on others to show you everything. You have to experiment and learn on your own too.
That's a little off the mark, as I've checked, but I'd think a full-time CS (as opposed to programming or computing or IT) student would be able to define it very readily ...?
You have to start somewhere, right? Those projects may not be "real" work but they may be enough to have given the candidate exposure to various problem domains and experience in solving problems using code, which should really be sufficient if you are hiring entry-level devs.
I mean what is the difference between the projects I do on my weekends and the projects a code school student completes as part of their curriculum? At the end of the day there is only one thing that matters, and that is whether the candidate you are interviewing has the necessary skills and insights or the potential to gain them.
Keep in mind that many computer science graduates can't even solve fizzbuzz.
An applicant with strong weekend projects implies:
- They have a passion for building software
- They are self directed learners
- They have the initiative and determination to build things and ship them
- They managed to navigate problems without having an instructor hold their hand
- They actually did the work, and aren't taking credit for a group effort they may have had minimal impact on
Code camp projects don't say much of anything either way to me on a resume. They don't rule out the above but they don't support it either. They basically say:
- I care enough about learning to code that I paid for a code camp
- I didn't get kicked out or completely fail out of the code camp
- I realize that employers value seeing projects on resumes
To me putting the code camp projects on a resume when they are not clearly marked as being part of that code camp is as dishonest as doing it for college projects when they are not listed under your education background. I've seen countless resumes come in where the projects from code camps are presented in a way so that the recruiter/hiring manager thinks they were self directed projects the person did on their own. The code camps know that this is a strong signal for top talent, and so they mentor the students to craft their resumes to mask the fact that the projects were assigned work.
The result of this, sadly, was that enrollment in code bootcamps became a first order screen for me. I'm sure there were some good people in there. But the work required to actually decipher what the resume was actually telling me required too much effort. (It would require opening the projects they did, trying to figure out if it was assigned or not, if it was a group project, and what contributions they made directly.) In the end, this combined with the fact that many code boot camp applicants are woefully underqualified made it not worth the time to sift through them to find the best ones.
I have encountered far more people who repeat this "fact" than I have encountered CS graduates who actually cannot solve fizzbuzz.
Closer to the truth is the statement that many computer science graduates can't solve a topcoder-elite problem, on a whiteboard, within 45 minutes, while talking out loud the entire time. Because that's closer to a real-world "fizzbuzz test" than anything I've seen on Joel Spolsky's blog. (sadly)
Education is broken on both ends. Spending 4 years teaching yourself will get you way farther than a CS degree will. Code boot camps need to focus on teaching people how to self learn because that's really the only thing separates average engineers from great ones.
For the extremely disciplined, maybe. For the rest, no.
Traditional schooling helps in two ways. First, they point the way to the important and useful stuff. If you're coming in knowing nothing, it's hard to figure out what to study. A good school will tell you. Second, they make demands. They set assignments and exams, grade what you did, and hold you accountable. They push you harder than you would push yourself, and that's really useful for anyone who is less than perfectly self-motivated, which is most of us.
Firstly, I work with a ton of people who came out of the Recurse Center (formerly Hacker School) and I've been consistently impressed by them. It seems to be a pretty self-paced thing, so maybe the people who do well there are the sorts of people who are excited about what they're learning, and I'm sure there's a layer of filtering at the hiring level. Just my personal experience.
Secondly, I think that while learning specific skills (app development, web development, etc) are really good things, they should totally be a layer on top of a core foundation of good computer science concepts. "Learning web development" ideally means "learning how to apply the concepts I know to the web environment", not "learning how to build a website The Right Way™". I totally blame inflexibility in these bootcamps not from their inability to adapt their course material fast enough, but on their lack of good conceptual foundations.
However, it fails to give any solid evidence that any of these exemplar schools are any more stable/less likely to close than DBC and IY. Are they profitable or propping themselves up with VC money while trying to find product/market fit? If they're profitable, how profitable (and for how long)? What did they do to get there (layoffs, campus closures, pivots to a new focus)?
The quality of their grads aside, I wouldn't be surprised at all if some of the schools mentioned in the article also end up closing their doors in the next year.
https://www.navy.com/careers/information-and-technology/info...
Coding bootcamps are just trying to sell a short path where it is not possible to have one.
You can study computer science and software engineering at universities. (Bachelor/Master of Science/Engineering)
You can study it at universities of applied science.
You can study it (without degree only state-certificate) at a school. (Staatlich geprüfter Informatiker)
And you can also do an apprenticeship in software development. (Fachinformatiker für Anwendungsentwicklung)
All are mostly free of charge OR you will even get paid doing them and you got an officially recognized paper that tells the world that you know stuff.
depends on what you work on. on my team everyone does need to (at least with guidance). that said, we only really hire those with significant experience OR college grads who have already proven themselves as interns on the team.
Buying a Jeep soon and will be working remotely while roaming North America in 2018. Hobbies include: photography, writing, painting, hiking, design, animal rescue.
- Talking about something else
- Being ironic
Turning away customers is bad for business,but essential to keep up standards.
If your goal is to get a good job and you don't have a strong background, then these bootcamps are a fantastic resource.
People who graduate from UNI actually know some things.
Once you consider the consolidation of the web into a few companies, and the news every week of another company outsourcing jobs to low cost locations, it's clear we are near or passed "peak tech" in the West.
People paying for training should look into things that can't be outsourced.
There is certainly a geographic shortage at least, right?
Perhaps those people in the UK need to move to a location where their skills are more in demand.
> Perhaps those people in the UK need to move to a location
It is very difficult and tedious process to go to work from EU to US. Also, most EU residents don't even want to live in US.
It's a lot easier than from most of non-EU world: at least you can hop on the plane for a job interview without fussing with visas.
If one can't be arsed to move there's always an option to remain unemployed.
I'm not so sure that those 13% unemployed are really good.
Remote interviewing is easy now. We have Skype, hangouts, etc.
Second, the relatively higher salaries we get out here are driven by two things: 1) the number of companies competing for talent and 2) the artificial scarcity induced by how they define the arena of competition (over-focus on "CS fundamentals" and under-focus on engineering fundamentals).
Supply being unable to fulfill a large amount of demand is the definition of a shortage.
It was not a three-month CS degree, nor did it pretend to be. Comparing a person who changed careers as an adult to someone who started studying the subject in college is disingenuous. Also, comparing a person who needs guidance, colleagues and to start making money soon to a person who has 6 months or a year to spend learning on their own is similarly suspect. The fact is that if you came to software development by traditional school or self-teaching, these programs weren't trying to help people like you. Understand that people with different backgrounds can still contribute even if they don't contribute in the way you do.
As for the ability of folks coming out of these programs, it's a bad idea to equate all bootcamps with each other or all people within a program. A few years ago, there was a gold rush to this industry, so there will be jokers in the deck. Still, there are many talented, hard-working people for whom these programs were the best option. You don't have to hire them, but take them seriously.
P.S. - Traditional education and self-teaching do not have bulletproof records, either. I've spoken to lawyers who are disappointed in the ability of most Ivy League grads they interview. I've also spoken with many folks who tried to teach themselves software development but never built a full skill set.