I am currently working for a big corporate in the UK, who have been showing off their "pioneering" and "visionary" strategy to focus recruitment from code boot-camps.
All I can say is that as a senior developer, it has made my life misery. I've gone from writing code and producing features, to a full-time mentor and babysitter.
Half of the boot-camp graduates I believe have become coders for the wrong reasons like:
* developers have an easy life, getting into work whenever they choose
* they get to wear t-shirts and baggy jeans
* they get all the latest toys to play around with and shiny MacBooks
* I hated my last job, looking at developers on TV in these Silicon valley places looks like the dream life
* I am a single mother who was given the course for free
The others, have aptitude but are so inexperienced from their 3 month session that it will take them atleast two years before they can be fully independant engineers.
These codecamps are licenses to print money it seems, they charge the students a hefty fee for the course and companies then pay a recruitment fee at the end.
Needless to say, I will be leaving my company very soon to go to a place where there is a coding test and filtering to prevent most of these bootcampers from getting in.
Yes its snobby, but I didn't study and spend my student loan on my passion just so I can train up a bunch of people looking for the "easy life".
This has been my experience, and I'll add I have noticed there is a massive disconnect from the reality of just how complicated modern software is. I remember beginning my career what I think used to be a quite common experience of being quite a bit overwhelmed by how much I had to learn, very aware that I didn't even know what I didn't know and this definitely motivated me. This awareness is completely absent from 100% of the boot camp grads I've encountered, who have been sold and apparently internalized the idea that "everything is easy" and are quite resistant to the suggestion that they might not fully grasp the scope and difficulty of the situation. I'm sure there are exceptions, but I also suspect these people would have found their way into software development without going to a boot camp.
Completely agree, I would like to blame it on this dichotomy of "frontend and backend development".
Most of the bootcampers did three months of "frontend" work and are oblivious to what goes underneath in the murky world of business logic and services.
Until they have been able to demonstrate they are confident in:
* Presenting data to a user
* Validating inputs
* Making correct requests and understanding the interactions of an API (whether its REST, RPC, programmatic, internal)
* Processing requests
* Persistance and access of data
* Basic security
* Be able to document and explain all areas to a basic level.
* Debug and provide a root cause analysis.
Then they will remain a junior developer and I think that will be many of these bootcampers fate, as they are either unwilling or incapable of doing work outside their comfort zone.
> Then they will remain a junior developer and I think that will be many of these bootcampers fate
This is a fair assessment - not just of boot camp developers but of all developers. I don't think I agree that it is a problem that some people working as a junior developer today will never become a Technical Fellow, however.
I've personally found (especially in the "enterprise") that many senior developers do not actually have fifteen years of experience - but one year of experience fifteen times, and are functionally junior developers with the wrong title. Educational background does not tend to be an indicator of this.
I think it's worth bearing in mind that people who sign up for bootcamps generally expect to have a normal career trajectory. They do not expect to spend their careers as effectively junior developers. They genuinely believe they will become Technical Fellows, and expect that a bootcamp will get them started.
Few bootcamps seem to do a good job of teaching students what to expect in a career path or what they'll need to do to advance in it.
I think our industry is headed for a collective reckoning, though I would not begin to speculate on a timeline. We're going to have to square seniority as a measure of skill with seniority as a measure of time, and no matter how it happens a number of people are going to be unpleasantly surprised.
I'm reading job posts for "sr foo engineer" and requirements are typically "4 years of foo", and no other experience level mentioned.
Yes, we all know someone who's done something for 2 years and is amazing, a true genius/savant who redefines what's possible. They're the exceptions.
I've been in professional software around 25 years, and was recently talking with a colleague (roughly same years of experience). He's just started a new job, and is working with people coming out of a bootcamp, and is frustrated because they're both currently being put on the same tasks - some basic FE JS work - and the bootcampers are actually slightly more productive than him. It's because that's literally all they know - they happen to know the same versions of everything the company is using, because it's what the bootcamp used. They can't do anything else, but both parties are being judged by this one ability right now, and he's questioning his own value now. It's giving the junior folks sort of a weird view of what 'old people' are capable of (which, as an old person, bothers me some!)
Isn't the point that they _are_ junior developers after completing a bootcamp? Juniors can be some of the best people in your organization if your org is willing to take them on and teach them things.
I'm not disagreeing, but I think the implication is that the bootcamps tend to leave their students without the fundamental knowledge to progress further in their career.
Not saying you need a full 4 year program and a CS degree. I don't have a CS degree, but 2 degrees in electrical engineering and computer engineering. That gave me a very solid and low level concept of computing that most CS grads dont get. Programming languages are a dime a dozen. Some are better suited for certain tasks than others.
Someone going to a Ruby on Rails or Node/JS boot camp isn't going to get that exposure to multuple languages. They're not going to know that, say Python is a better language/ecosystem than JavaScript for scientific analysis. They're not going to be exposed to C, C++, C#, Java, Rust or Go. Personally, I wouldnt even interview someone that's taken a boot camp in C or C++. The languages are too nuanced and complex to even get a foothold in 3 months.
Sorry this ended up very rantish, and I didn't mean for it to be so. I'm trying to make the point that while, yes, boot camps serve a purpose and may be useful to some folks, they will not and are not designed to give you enough knowledge to truly excel in the industry with the knowledge gleaned from the boot camp alone. It will take an extremely passionate and aggressive self learner to be more than a junior after a boot camp.
You have an engineering degree, so.... The joke was, when I was an undergrad, that CS students were the last people you'd ever hire because they couldn't design a system at all (or program properly). The first you'd hire were the computer engineers, aka you and me (of course). Engineers are born, for the most part, not made.
Over the past 20 years, this general principle has been validated, at least in my experience - a good boss I had once said only the top 10-15% of people in IT know what they're doing. The next 20-30% have some idea, but they're sort of useless. The bottom half, you do not hire if you can help it...
I also don't have a CS degree, but I tend to agree with you that something quite serious in terms of scale and scope is missing in most bootcamps. For instance, it doesn't make sense to expose people who have never written a program before to RoR or Node if they haven't yet learned how to do basic tasks like command line functionality, learning the *NIX file system, text and data manipulation, etc, let alone if/then statements.
Juniors are great when their inexperience is correlated with youth, fresh outlook on the world, a burning passion for the subject, lack of fear with new ideas that seem controversial to the old guard, and frankly fewer family commitments such that succeeding at their job and learning and growing is their number one priority.
Very little of this applies to people on their second career doing bootcamps for a leg up.
I genuinely expected you to pivot to something interesting or novel halfway through your post and was very disappointed when I got to the end. This comment eloquently depicts everything that is wrong with corporate culture in general, occasionally magnified in IT.
It annoys me that front-end is sold as "easier". Getting started is "easy", building front-end applications at scale is a completely different ballgame.
> I have noticed there is a massive disconnect from the reality of just how complicated modern software is.
There's also a massive disconnect from the reality of just how complicated modern software needs (not) to be.
That said I agree that some 3-month bootcamp probably isn't enough time to really internalize the basics of programming (unless you're really smart or have prior exposure), let alone learn to design and write nontrivial programs.
Well, if the bootcamp is going to spend 3 months teaching you how to make a website using the industry-standard tools and frameworks, you're going to know absolutely shit at the end.
Consider a typical front-end developer setup - with IDE/smart editor, linters, transpilers, packers, package managers, project generators. These are all useful tools, but to be even a marginally competent developers, you have to know what they do and why. Otherwise, you'll be completely lost when some default changes. You'll be flabbergasted when you discover that the project structure you're used to isn't "how the web is made", but just an opinionated pattern that was sort-of fashionable at the time you were learning.
I've seen this problem happen with code camps teaching people RoR some years ago; I believe it now happens with Node/React.
I encountered a particularly egregious example of this recently.
I was running a group of recent(-ish) hires through a training course recently. Part of it is penetrating-testing a dockerized application on their machines. One of the things the application is vulnerable to is various forms of form tampering attacks.
One of my students just stared helplessly at this. They were absolutely stuck. I had no idea why. I came to find out that one of my students had managed to make it through a bootcamp, and an interview process, and be on the job for several months all without learning a Chrome or Firefox developer console could be used to edit a page's HTML. Or that a page could be saved and edited that way.
I hadn't even considered the possibility that a professional engineer in a web development role might be ignorant of how to edit an HTML form by hand. It implies a shocking ignorance of how the whole thing works.
I once observed a "become a web developer quick" RoR-based course, where they made people write their "hello worlds" as full-blown RoR apps with full MVC project scaffolding - meaning dozens of folders, and having to create 3 files (M, V, C) and write a lot of code to put something simple on the screen. I realized then that people finishing this course lack what I consider one of the most fundamental insights in writing client-server web software. I wonder if the person from your story lacked it too.
The insight is this: a browser is a program that reads text that it gets from files or servers, and that text tells it what to put on the screen, how it looks and what can be done with it. When you're learning the basics of a (backend) programming language, you first learn how to put text on screen. The same way, you can put text into a file, or (with some more tricks) into a network connection. So if you write a program that prints HTML to stdout and make browser read from it, you get a client-server web page. Boom, that's pretty much all. Everything else you'll ever learn is just managing complexity. Modules, MVC, database connections, etc. - it's all serving the goal of generating the right text that gets shipped to browser.
I was surprised by the ways people (sometimes junior programmers with little web experience) didn't get that. Some didn't know that browser simply reads text (happens when you're exposed to frameworks instead of raw HTML). Others thought MVC is something fundamental to web apps, instead of just being a way to keep your "print HTML to stdout" code from very quickly getting out of hand. So whenever I teach something the basics of web development, I always start with this - raw HTML as text, the connection to "your program can print text to stdout, so it can print HTML to stdout too", and we build up from there.
I can’t vouch for other programs, but I co-founded Dev Bootcamp (the first programming bootcamp) and the sequence you outlined is almost verbatim how we brought students into Rails.
We’d explain it the way you described. We’d have them start with Sinatra apps after 3 weeks of modeling problems in CLI apps.
After their 10th hand-written form with error handling, they’d see the value of Rails form helpers immediately once they hit the last few weeks.
Similarly, they’d write lots of SQL queries by hand in their CLI apps. We’d push them to separate it behind method boundaries then class boundaries then build a mini-ORM.
When ActiveRecord came along it was no problem because they had a model of the problems it was invented to solve.
It's also good to hear that there are bootcamps who seem to do this right (and, importantly, want to do this right)! So thank you for doing it like this, and thank you for taking time to share it in a reply.
I read the whole excerpt you linked, and holy cows if you did not just significantly improve my base opinion about boot camps. The way you introduced AR is exactly the way I would do it, with the same digressions to hammer down things like "AR is ultimately just writing SQL for you", and "AR is ORM, there are many ORMs with different approaches", and "where does a concept live?", and "map is not the territory".
BTW, the evolution of your feelings is pretty normal and it brings back memories. Haha. People would always be like, "Uh, yeah, ok, so you're churning out code monkeys, right?"
Then we'd bring them in, show them what we were teaching and how we were teaching it, and they'd go "Oh man, I wish I had been taught like this!"
Having been in the situation, all I can say is that sometimes you have to expect "shocking" gaps when working with inexperienced people at not let it throw you. It's part of being a teacher. You have to remain positive. If they're quick to learn it when you teach it to them, it's fine. This is learning on the job and it's expected.
That happened to me at Google for someone who didn't come in as a software engineer. I didn't handle it well and it's one of the things I most regret.
In this particular case, my student was hired directly into a software engineering role from outside the company within the past few months. This, to my mind, suggests a whole sequence of failures starting with the contents of the bootcamp.
That's an important thing, I agree. Seen a few shocking gaps in my co-workers at previous jobs, and whenever time and energy allowed, I always tried to carefully (to not bruise egos) and positively[0] patch it with a quick mental model update. I don't fault people for being inexperienced, or for not growing up as a computer nerd like I did. I only start having issues if someone wasn't given knowledge they're supposed to by organized learning (hence my scepticism about bootcamps, but see jfarmer's comment in parrallel), or when they claim knowledge and competence they visibly lack.
Programming is a profession. As you say, learning on the job is normal and expected.
It's not about understanding everything thoroughly. It's about understanding, for most things they use, what does the thing do in general, what's the scope of it, and why that job needs to be done in the first place.
I went to a coding camp. I sat in a group working with my classmates on our group project and I noted that what we were learning was "just enough so that we can learn reasonably well on our own.... so that maybe later we will be good at this".
They looked horrified...
Most boot camp students really do not know at all the level of complexity involved, how much you need to just go figure out yourself / learn about ... learning, and etc.
This. When I started my career all I had to learn to make enterprise grade apps was Visual Basic. True story, there were even big ERP companies built entirely on VB. Today? Modern HTML, CSS, and JS apps with backends in <pick your language and data store> is more off putting than Win32 or GTK+ was.
Yes I’m aware of the differences in capability and no I’m not complaining. I’m just saying it was easier back then.
Agreed. I'd go a step further and say that "easier" coupled with in-your-face accessibility/visibility (e.g. ubiquity of Macros in Microsoft Tools) made for a powerful combo and provided tangible illustrations to programmers and non-programmers alike of the power of software - especially with simple tactical solutions. This exposure can be inspirational to all involved. At least for me, it was enough to switch careers entirely [1]. My first practical creation of any code in a working context was in response to the inability (lack of skills) of my employer to fix a problematic software data input form - resulting in inefficiency and degradation in my co-workers quality of (work) life.
Many of the comments here have focused around the skills and personality traits of coders. I agree with most: problem solving, some level of aptitude and curiosity are all important parts of the basic mix for success. Most of the discussion around motivation either has circled around economic benefits or some self-driven desire to learn.
Again, while not invalid motivators - I think a BIG one that's not been discussed is the general allure to the raw transformational power enabled by software (automation). With only a few lines of code, disruption can be created to make things easier, make things faster, make things safer, make things better - with immediacy and impact. In my case, I used it to disrupt inefficiencies and accelerate solving problems. As a factory process engineer, that kinda power was way too intoxicating to look away from. But manufacturing wasn't quite ready to embrace software quite yet - so I made the career jump. For me, I wish coding camps or other channels would have been accessible in small remote towns in the Midwestern part of the U.S. back then, it would have accelerated my confidence and given me a channel to seek a career. Instead the luck of the dotcom boom opened doors in job fairs where I had plenty to offer in the technical realm but little to show in terms of code at the time. Nevertheless, 15+ years and going in software has been a great ride thus far and one that I couldn't have predicted.
Many of the things you said sound pretty representative of new CS graduates as well. It'll take them at least a year, and a lot of mentoring, to learn the best practices and get their hands dirty. I get the impression the problem at your company isn't with bootcamp-vs-CS-graduates. I suspect the problem is that your company is hiring too many inexperienced developers at once (to save money), and isn't doing a good job of hiring the best bootcamp graduates (probably also to save money).
I might be biased since I have an engineering degree, but no CS degree. Self-taught myself a bunch of stuff, made the switch to software, and have now worked for 2 of the FAANGs. My very first software employer certainly had to mentor me quite a bit for the first 4 months, but I certainly justified the investment over the following year.
I think part of the problem is people assuming CS degrees teaching software development and best practices. They don't. They teach theory and on the side as either a lab or project, you write some code. Best practices? Nope. SCM? Nope, unless you have an external influence.
Like you, I learned a lot of beat practices on the job. SCM? Was SourceSafe (Yeah. I know, cringe, but also 2000). But also practices about how to release, when, notification of releases, post mortem of incidents, none of that was mentioned in school. All on the job.
I landed in finance, and any single fuck up can land you on the wrong side of the door. But if you accept you screwed up, most people I've worked with will give you a second chance as long as you don't repeat your mistake.
A self motivated person can break into CS but that's not what he's talking about. A 16 week class isn't enough to prepare a dispassionate person looking for anything.
The problem with these camps is they help those who don't need it.
Self taught is the key skill. If you can learn on your own you have a good chance of facing a developers life.
Bootcamps are the opposite. Quick compressed learning certified by a brand. Good for experienced developers learning a new language but lacking for the type who haven't used a computer before.
Honestly, I agree with you. I don't mean to discourage anyone trying to learn software engineering but: IMO its something that takes years to learn the fundamentals. There are so many small details that aren't what you expect them to be that I see no way bootcamps could prepare you.
Things like how file systems work, what system calls do -- how write() works -- does it write data or not? How do blocking / non-blocking calls differ? What concurrency models are there in programming? How does parallel execution really work? How do you (properly) handle I/O, networking, and other events? How do you evaluate and compare the efficiency of algorithms? What kinds of security threats lie in different types of code? Practically, how do you prevent them? How do databases work? How do you design applications to avoid corruption? What are the different isolation levels in a database? What parts of the database are 'locked' for a given query, what 'order' are transactions executed in? How does the OS allows multiple programs to run?
Cryptography. Sessions, encryption, hashing, salting, peppers, verifiable delay functions, public keys, symmetric vs asymmetric crypto. Signatures. Mutual authentication. Message integrity. I guarantee you most developers have screwed up their handling of I/O, security, db use, or concurrent code at at least once in their career. These are deep concepts that can be "learned" in 10 minutes from a tutorial, but have tons of weird, undefined behavior that only shows up if you don't completely understand what you're doing.
IMO, what seems to have changed recently is there's now more ways to shoot yourself in the foot. I.e- more open source libraries that are usable right off the bat as black-box-plugabble, square-peg-in-circular-hole type deals. Kind of like how people trick themselves into feeling like experts from reading wikipedia -- a little knowledge can be just as dangerous as no knowledge at all.
Consider however that not all software jobs require all that knowledge. As software spreads, not all new software jobs are rockstar positions. A lab full of scientists, for example, might benefit a lot just from a couple people who know how to operate a database and do some basic data crunching. Or, consider the vast number of people who get their job done in Excel today, who don't need to call write() but could do their job better & faster if they switched to Python.
If the future is software, then there will be places for PhDs & bachelors, but also for associates and even bootcamps/certs. Even people who are not deeply passionate about software can make a useful contribution. Putting men on the moon took a lot more than just rocket scientists.
You should note that a bulk of your list is the knowledge that a senior engineer should require of his peers. To be productive writing a small feature in a React app it could be had under a week out from bootcamp with modest support sharing whatever tribal knowledge and documentation for onboarding.
>To be productive writing a small feature in a React app it could be had under a week out from bootcamp with modest support sharing whatever tribal knowledge and documentation for onboarding.
That's not my experience at all. I've on-boarded many bootcamp graduates and I've never seen one that was doing anything that I would call "productive" a week out of bootcamp.
I could see that maybe if they had a good bit of experience before bootcamp.
I've shared this experience of being a mentor and babysitter for people who seek all the things you listed, although in my case it's inexperienced coworkers who are "self taught" (no boot camp even). Their charisma and our shallow interviewing process usually lands them a job and leaves me cleaning up after the messes they perpetually make. You would think proper communication would prevent these things, but often they are so alack of experience it goes right over their head, and other times they're overconfident or just disinterested in improving themselves. If you try and give them too much constructive criticism, then you quickly become the office asshole.
Other engineering industries have to take rigorous exams to achieve any forward momentum in their job (civil engineering had the PE, for example). This is something I think I could get behind for our industry .
24 yo CE here with FE here, the question becomes do you think a test can be designed for something as large as software to accurately judge competency. Competency in code comes from getting stuff wrong and having to live with it and fix it, that stuff isn't super easy to test.
You're right, it would be pretty difficult to make a test that actually gauges competency. That shouldn't necessarily be a reason not to try though.
Honestly, it might be easier to adjust the hiring process. If the hiring process were able to easily select driven individuals who retain "software engineer" as part of their identity, and people that take pride in their work, seek constructive criticism and want to learn, then that would be good enough.
I should also clarify that being self taught isn't necessarily a bad thing (one of the best coworkers I had was self taught), lacking any of the above traits is.
>That shouldn't necessarily be a reason not to try though.
I'd argue that if a test could select good SEs then companies would be giving tests (or outsourcing such tests) as part of their interview process. It's not like a lot of thought, effort and experimentation hasn't gone into figuring out how to hire software engineers.
>Honestly, it might be easier to adjust the hiring process. If the hiring process were able to easily select driven individuals who retain "software engineer" as part of their identity, and people that take pride in their work, seek constructive criticism and want to learn, then that would be good enough.
I'd like to note that a test would not select for any of those things except the ability to study hard.
Self taught programmer here, criticism is something I think is harder for self taught people. I think it stems from never having an authority over you when you initially learned, and that sort of becomes enshrined as part of your identity. If your not reviewing someones code formally, just ask questions that could lead them to what your trying to suggest. Pretty commonly used method but just having them logically work it out sort of quails the knee jerk reaction to criticism.
Also maybe a lot of people are self conscious about no formal education as well? That wasn't an issue for me but I imagine it is for some.
TL;DR: The transition from learning the hard way always, to allowing someone to try to prevent it is tough.
You don't even need a test. Just drill down on one particular area and see how much they know.
For example, get them to explain a model they would use to represent user login. Then get them to explain how that would link to their use info. Then how they would display that on a login screen. Then how they would save that into the database. Anything to watch out for? Any security concerns?
Even to become a licensed land surveyor, which is a subset of civil engineering and not as highly paid as an engineer job, you have to pass the PLS exam. As an apprentice surveyor or surveyor technician, you can't sign off on your own work until you get licensed.
You're describing an unfortunate situation, but it feels like you may have mis-identified the issue.
> I am currently working for a big corporate in the UK, who have been showing off their "pioneering" and "visionary" strategy to focus recruitment from code boot-camps.
Your employer is trying out a new HR strategy to cut costs and boost productivity. Is that strategy working for them? It doesn't sound like it's working for them if they're hiring bad coders and driving away experienced staff. Do they think it's working? Is your management aware of your concerns?
Because honestly, this sounds a lot like "my management team is doing something dumb, and it's all the fault of the new junior devs we hired". That sounds unlikely.
Also:
> I didn't study and spend my student loan on my passion just so I can train up a bunch of people
Mentoring is a key part of the job. If your HR department is hiring poor candidates for that, that's an issue, but if you don't want to mentor people at all, is this really your passion?
I look at it the other way around. I get paid 115k$ in a very cheap area to do code reviews and go to a few meetings.
I make things at home now. I don't want to go back to the stress of rapid fire "three parallel orthogonal lines for Miss Business" development. The baby-devs are a cudgel of tender emotions with which to push back against the exploitative wiles of business.
I fondly imagine I'll actually have the time to strike out on my own any day now, but the reality is that my life is already better.
What is really disheartening is for those of us who went to camps.... we're painted with the same brush after people have experiences with our bad classmates.
About half my coding camp class was unemployable by my estimation. At one interview I'm fairly sure they had interviewed a classmate or two before me and the questions they asked were painfully simple to start.... if they felt they had to ask that, I can't imagine they'd ever want to hire someone at that level. Obviously I showed them otherwise and the interview went well, but I felt like their perception was so poor to start, there was no chance.
At least I'm working now so it's not just "coding camp" on my resume as far as coding goes (I had another technical career previous to this one). I"m hesitant to mention the coding camp when I meet other people who are in the same industry. I really enjoyed my coding camp experience (going back to school was a surprisingly wonderful experience as I was a poor student earlier in life) and yet I'm inclined to say "self taught" and that isn't exactly true although much of what I know now would fall into that category.
> I had another technical career previous to this one
This seems to be the huge differentiator.
I've had really good experiences with boot camp grads who had a previous technical career or came from a STEM phd. Camps are great for getting already well-educated people up to speed on how to hack together a website, which is an enormous value add to an existing skill set.
Absolutely, familiarity with troubleshooting, how layers of technology interact, dealing with new tech regularly, working with technical teams is a big leg up.
> Needless to say, I will be leaving my company very soon to go to a place where there is a coding test and filtering to prevent most of these bootcampers from getting in.
I went to a bootcamp, and the first hour of every day was spent learning to solve the types of coding tests that companies use in interviews. So, when companies look at the graduates of these bootcamps, it's really hard to differentiate between people who perform really well on the interview but will require significant investment before they're useful (this was me) and people who have been programming and working with computers for years and simply lacked a little bit of polish & training (like some other people in my program).
All that's to say -- traditional coding tests & filtering doesn't necessarily work that well when you have people training for the test (rather than training for the ability to do the work that the test is supposed to be a proxy for).
Coding tests -- I don't think so. Within three months of practice, folks were generally proficient at the "Cracking the Coding Interview" style of problems. When you have a curriculum that's partially designed for that purpose, any question you have that would stump bootcamp graduates is also going to flummox some amazing engineers with years of experience.
I'd instead try to pair with people on solving a problem that translates well to the problem domain that you're trying to hire for. Anybody who's new to the industry is going to need a decent amount of support & mentorship starting out before they're able to contribute meaningfully to a team and working with someone for a day is a good way to figure out how much support they're going to need and what it's going to be like to mentor them. Bootcamp graduates would likely be open to a day of paid pairing to figure out if a job would be a good fit.
If you did want to go with the more traditional coding test route, I'd try and do something relatively concrete:
- download a set of log files & group them based on a search
- hit an API route & use that to render and update a list of items
- connect to a database, figure out what schema migrations are necessary to support a new feature, and then talk through how to do the migration
- figure out why a test is occasionally failing on a CI server
- add metrics, logs, tests, and alerts to a service with two routes (/healthcheck and /doSomethingImportant)
Like all interviews, the closer the interview maps to the day-to-day of what your needs actually are, the better it will be. There's something beguiling about questions about dynamic programming or red-black trees, but being good at answering those questions has almost no relationship to day-to-day work. (Unless you're at a place where deeper knowledge of data-structures and computer science really matters... and in that case, you're not going to have much with recent bootcamp graduates anyways)
I have some luck with a question that needs you to use a standard “interview” data structure in a slightly nonstandard way. People who can bring up the data structure and tell me all about it, but not see how to actually solve the problem with it, are easy to reject. People who can derive it on the spot, or at least figure out how to use it after I give it to them, tend to be impressive hires.
The key to handling such environments is to not care about the result more than the others. So socialize with the newbies, maybe go have some beers, be a pleasant person and absolutely don't give a damn that they are utterly completely useless. It wasn't your decision to hire them and you shouldn't be wasting your passion and energy on rectifying it. If you care about what you're doing, it consider starting a side project and growing it into a fully-fledged business instead.
I don’t see how any of those things you listed are “wrong” reasons to go into software development. All of them are true or roughly true, so, if that’s important to someone, then great. Believe me, given a choice between software development and service work or factory work, I would always choose development for the “easy life,” too.
OTOH, you’re right about boot camp grads not being ready to operate independently, but that’s your employer’s fault for hiring too many of them. You’re totally free to leave and go somewhere that doesn’t hire boot camp grads if you don’t like it.
To a lesser extent, the same can be said for those who get an "IT" degree from a no name school from the college of business. I've spent a lot of my time training people who graduate from local small colleges instead of say, Georgia Tech or UGA (I'm in Atlanta) because management at my big corp is throwing cheap bodies at the solution.
Don't get me wrong, I've enjoyed mentoring but done kids graduate with no clue and the wrong expectations.
I've mentioned to management these kids don't graduate with the proper foundation... And I'm told it's my job to give it to them....sure, I'd love to if they give me their college tuition!
>local small colleges instead of say, Georgia Tech or UGA
This really only applies for CS, but I wouldn't hire people with "IT" degrees for programming jobs no matter where they went (not based on their degree anyway).
GSU is much larger than either GaTech or UGA, and it just received an award for being the 2nd best teaching institution in the US. Kennesaw is about the same size now that they merged with Southern Poly, and their CS program is also ABET accredited.
I've taken CS classes at both GSU and Tech, depending on the classes the person takes at GSU, there isn't a big teaching disparity. The type of person who makes it into Tech changes things, but if you look at their transcripts when hiring you can quickly see who took the easy classes and scraped by with Cs and who really took it seriously
I don't really have a good answer but I'll give it a shot.
I can only speak for my team. In big corp, your work experience is based on your team. We have 4 senior dev, 7 college hires who have been with us between 0-4 years. The experience/aptitude varies. i.e. there are some who have been with us for 2 years that is not as good as the one hired. We've had some come on our team and move onto other teams. I have one who's been with us for 4 years, and at 3 years I felt is like a competent senior dev. He's moved to another team and runs laps around his new teammates.
Because I have the most patience in the group...I end up being the person most of them come to for help. I'm technically the architect on the team (manager gave me the title recently, too modest to accept it...) and the senior devs even come to me with questions...but of course I don't truely mentor them. But to give continuing education to the team, I've implemented a "Tech talk Friday" where I book a 1.5 hour of our time on Friday and watch and discuss various conference talks on YouTube that I feel are applicable for us. It's a nice way to end a Friday, too :)
There's no defined ratio. A grad who has a good foundation, is a go-getter and can learn on their own only needs to be guided. While others need to be handheld. Mentors' should not be bogged down to the point they are not able to do their real work - otherwise they'd get burned out and would just dismiss mentees.
* The local management are non-technical and have a rudimentary equation that 1 developer = 1 productivity unit
* The bootcamp has some really great salespeople
* Hiring is generally difficult for great dev talent, so their logic is just to hire anyone for the numbers, otherwise their budget gets constrained by kafkaesque finance practice from the companies HQ.
* Local political and PR reasons, the company is "hiring local talent", "equal opportunities" etc.
Sounds like four political reasons. Better strap in for the long haul cause it doesn’t sound like things are gonna change quickly. Unless you happen to find that person who can understand and motivate developers while navigating the political power structure toward real solutions. Unfortunately, those people are even more rare than the 10x developer.
3 is not political. It’s hard to maintain hiring standards in this crazy market when you’re under business pressure to scale and it’s only natural management gets desperate after some time. I’ve seen this firsthand several times.
They could still administer a coding test to the bootcamp certificate holders. Just because you have a CS degree does not mean we hire you without a coding test. Some of the least productive coders I have worked with have had degrees. Most degrees only prove that you have some ability to memorize things, practical application is a very different skill.
>Most degrees only prove that you have some ability to memorize things, practical application is a very different skill.
My degree put very little focus on memorization. Individual and group projects certainly had nothing to do with memorization. My experience hiring and working people from other schools indicates that their degrees were similar. I'm not sure where this degree == memorization thing comes from.
I don’t really know either. Obviously a degree isn’t a necessary or sufficient condition for competence, but I don’t know why a lot of people seem to pretend it’s borderline useless, a scam, etc.
I know people with 4 year CS degrees from reputable schools who picked tech jobs for the same reason. I think wanting a job that allows you the means and time to enjoy other parts of life is perfectly valid. Being incompetent at said job is where the problems come from.
Nothing wrong with that, but if I ask you why did you become a developer and you list that as a main reason, then I will immediately dismiss you as not being serious.
Why? Nothing about that reason has any bearing on whether you will be any good at it. Passion provides motivation to gain skill but it's not the only thing that can provide motivation. It's not even the only reliable motivator. Having a better career or pay can also be pretty reliable motivator.
Dismissing someone as “not serious” because of their reasons for following a particular career path says a lot more about the person doing the dismissing than those being dismissed.
By the parent’s criteria, I am “not serious”. My record on OSS and early work at companies which were acquired or have outsized valuations suggests the parent is 100% wrong, however.
You can’t imagine that there are people who are smart enough to code, but wouldn’t otherwise be doing so if the salaries weren’t so good? The pay is really good right now. Lots of people I know who did boot camps were doing things like research in other STEM fields. They are definitely coding now because coding offers them a more comfortable life, not because writing enterprise software is more rewarding than say, researching climate change.
I definitely would be doing it if salaries were substantially lower. In fact, I’ve told people before that the main reason I’m a developer now is because it’s the only thing I know how to do that I know I can pay my student loans with.
Lots of people don’t have the opportunity to get into programming for fun or because they think it’s interesting. A person could reasonably go into programming when choosing a major in college never having written a line of code, and end up doing great.
Our perceptions of programmers are shaped by the PC revolution of the 1980s. A lot of people got exposed to programming because there was a PC in the house. Kids and teens so exposed tended to be the ones who went into programming as a career, just because they had a head start and because they were more familiar with it. The result is that many of the best programmers in the profession in the 90s and 00s were the ones who started as kids. But many of the mediocre and bad ones were too!
Passion and early starts are overrated. As long as a person is smart in the right way and reasonably enjoys the stuff, they can be a great programmer. (And I say this as someone who started programming at the age of 6 and did it for free for many years.)
No - I was 5 or so when I started programming - however when I chose a degree leading to a math-based degree vs studying music (which I would have done otherwise), job prospects for an easy life were very much top of mind.
There we go, it was curiosity then. I was a late bloomer and didn't program till I was 12 and that was modding Command and Conquer.
If you don't have intellectual curiosity, then I think your career prospects in software engineering will be limited.
Perhaps I should have articulated it better above.
What I meant is that many of these bootcampers don't have that curiosity or drive to have touched code before their course. Even after getting a job, I've asked them about coding outside of work etc. they're not interested.
> If you don't have intellectual curiosity, then I think your career prospects in software engineering will be limited.
This part I fully agree with.
Do not equate "boot camp" and "would rather sit at a computer than mine coal" for a lack of intellectual curiousity though. I have personally met grads _from the boot camp in question in this article_ who clearly do have it - while spending their work days writing Ruby for web apps, they were spending evenings learning C, assembler and the operating system fundamentals that their particular route into the industry meant they missed out on.
You think there aren't tons of people who do CS degrees that lack curiosity? I've helped students with their CS homework who, when I asked why they were majoring in CS when they obviously did not like it, literally said their parents picked their major. So, I'm sorry, when people on here say that getting a bachelors in CS is some indicator of "natural curiosity" aka "geekiness" I would say it is the complete opposite.
I should add I don't have a CS degree, yet I'm doing the homework for the "dedicated" "curious" "high aptitude" etc. CS grads you'll be hiring later. Ha.
Why are you asking people why they became a developer? That has nothing to do with their ability to do the job. You're in a professional environment, so ask the relevant question: do they have a learning mindset? That's really the only thing that matters.
It often comes with wanting to go to lunch whenever and leaving early to make up for it all. With the result that work never gets done.
Don't get me wrong, I'm the biggest fan of getting in at 10:00 or 11:00, but I also try very hard to get things done. If you come out of your boot camp without understanding that you still have a shit-ton to learn and you aren't willing to put in the effort to learn it and do the actual work (which isn't easy), and, yes, put in the time required, then you are a liability.
Well it's wrong if people have that expectation and it's not the reality.
It's also problematic in a world wherein people have to work together, which is why most jobs don't allow one to 'work when one chooses' although that is obviously the case in some scenarios.
I'm currently in a bootcamp in SF after several years in product/analytics type roles in tech. I decided to finally go for it after considering it for a few years because structured learning/accountability helps me learn a lot faster.
I just finished my first final project using React/Redux/PostgreSQL/Rails/S3 -> http://www.orangemusic.xyz
I don't think I could have learned what I've learned in that amount of time with self-study alone.
tech people have been automating jobs away and insisting the future is code for a long time now. Now all of a sudden we get "coding is hard" and the non-traditional bootcamp education they pitched only really works for highly motivated self-starters, often with preexisting engineering or science backgrounds.
So what do they do? What exactly are they going to train into?
We're commenting on an article about a coding camp founded by a professional TED talker who's now in law school.
The "they" pitching bootcamps and the "they" automating jobs away are two different "theys".
People who have been doing software for the last 20 years have always been saying "coding is hard" and "a few months in a coding bootcamp isn't sufficient preparation for a career in tech, especially when the winds of the market shift".
But no one wants to hear "high-paying jobs require spending years getting good at doing hard things".
> who have been showing off their "pioneering" and "visionary" strategy to focus recruitment from code boot-camps.
Seems like the kind of company which would be relying on interns and juniors (that need training too) instead of hiring seniors engineers, they just found a way to make it look good.
I always think the we should send CS graduates to a bootcamp to get some coding skills. Or send old-time devs so they get up to speed with newer tech. But starting from zero in 12 weeks seems almost impossible except for a few.
Being able to learn these things on your own is exactly what a CS degree is supposed to teach.
In my career, I've taught myself how to make complex CLIs. Then CGI-based web apps. Then Java desktop apps. Then MVC frameworks. Then JS frameworks. Etc. Ditto for changes in development and deployment processes. Ditto for changes in DB technology. etc.
My employer rightfully expected that, for a six figure salary, I should be a professional who is able to keep up with best practices. That's why they pay me well. They let me attend conferences and I negotiate for some "experimentation" time whenever there's a big shift in the tech landscape, but it's not like I'm disappearing for months at a time every 5 years. That'd be insane.
I'm not very old.
Hell, I don't even work in web development.
It's just one of those skills I need to keep fresh because it comes in handy every once in a while.
The changes in my actual domain of expertise have been even larger and much more difficult to keep up with.
Coding bootcamps are expensive -- they often cost on the order of a single year of college. If you're going to need to go through a few of them in your career just to keep up with a single skill set -- building UIs -- that's more of a baseline competence than a real specialty, why not front-load and just get a good-quality degree that prepares you to teach yourself the easy stuff? Double major while you're at it.
Maybe at some point you will notice that once you have more responsibility in one area it will use up all our time and energy and you simply don't have time to learn other stuff on the side. I am in that situation right now and I think an 8 week bootcamp to focus on Machine Learning would be a good starting point. I could learn it myself but I would need some dedicated time to focus on it and not have to worry about my regular job.
Do these bootcamps charge what a real uni charges? I recently went back to school (a well known one here in the UK) to get a MSc in Data Science (have gotten interested in research now) so I ended up doing a research dissertation. I already had a MSc (CS) and B.Sc (CpE) and 20 years experience, so it was not too difficult. It was a bit less math heavy than I expected, but ok.
But the MSc in CS course for this uni... it really is less than a proper B.S. in CS course - it was nothing but the very basics. Aka a fairly expensive bootcamp, albeit with a "dissertation" at the end. The uni is making serious ££££ churning out "MSc graduates" and now I know where the trope of people with MSc who can't program comes from. My MSc course was a real course, from a much better school, but that was 15 years ago...
Not all the MSc in CS students were bad, mind you - the ones who could have been engineers did well. But they still only got the very basics of what you need to know coming into industry now (or what a BSc student would get) and if I was in charge, I'd re-label the degree to something other than a MSc. But degree inflation is here to stay...
> I will be leaving my company very soon to go to a place where there is a coding test
Maybe that's your problem right there? I'm in SV and know someone who successfully did a bootcamp, but they certainly didn't get a special route through job interviews. They had to compete with graduates and pass regular technical interviews with algorithm questions (and they could do fairly hard ones that certainly many college graduates fail). BTW the bootcamp only charged on successful job placement, so it's hard to see how they could stay in business if it was just a scam.
> and filtering to prevent bootcampers from getting in
> its snobby, but I didn't study and spend my student loan on my passion just so I can train up a bunch of people
Why should the interview be for anything other than to determine technical competence and organizational fit? I'm sorry if you've had difficulty with your student loans but I don't see why it is relevant here.
There's plenty of mediocre programmers that managed to pass a CS program somewhere. Maybe their course material covered a broad range of topics but certainly not everyone retains it or can even answer basic questions. Assuming two people with no experience, I would strongly prefer to work with whoever performs better on coding challenges and computer architecture questions even if they went to a bootcamp. Probably especially if they went to a bootcamp. If someone has 4x as much time to study and still does worse, that's hardly encouraging is it?
To me it sounds like the hiring process at your company is what is at fault, and it would be better to fix that than to rely on expensive credentials (that can only set a low minimum bar anyway) as some sort of proxy. Maybe if you are overwhelmed with applicants you could filter by individual school, bootcamp, github portfolio, etc. But this seems to be painting with an overly broad brush.
This isn't a soul-crushing job babysitting (only outdone in horror by being in a chicken suit waving a sign for a fried chicken restaurant). This is an opportunity for you to study various psyches and all the gory "this is how sausage is made! details. Also exposure to abnormal psyches.
> very soon go to a place where there is a coding test
Sadly, I fear that will be like “going to a place that doesn’t require unpaid overtime” or “going to a place that doesn’t have a noisy airplane hangar ‘open office’” - once it catches on, it will spread everywhere.
That doesn't sound like a problem with the people you're hiring. It's perfectly normal to train new hires. The problem is that you were not hired for a training job, but they're making you do a training job.
Haha. There is a lot of this happening in data science as well for software engineers and with exactly similar kind of results. I hate mentoring tons of new people who just learned to throw tensorflow at pandas dataframes.
Bootcamps don’t provide an adequate training to become an engineer, yes, but believe it or not there are plenty of very good engineers who have things besides work at the top of their value list. Your post reflects narrow mindedness and a lack of empathy.
I've been in OP's boat, mentoring people (normal hires, not from boot camps) who couldn't be bothered to put in the effort. It was a colossal time and energy sink.
My attitude today is that you have to put in the initial effort to demonstrate that whatever I invest in training you will be paid off by your future work using that training over and over again. Otherwise it's a wasted investment.
And that attitude is basically that of the old kung fu master: First prove that you are a worthy student, then I will spend time to teach you. Yet in a modern software dev environment, it somehow becomes snobby and elitist?
Edit: I've gotten the same criticism from elsewhere, so the the parent comment (which has since been flagged) is not unique.
Part of life is getting to choose how we behave and what actions we model.
In a situation like this, we have a choice. We can be snobby towards junior developers. Or, we can be kind to juniors and push back at the management structures which brought in less than qualified talent.
When we follow the snobby path, we model that that type of toxicity is acceptable for senior developers. We also teach smart juniors that the best way to avoid our considerable wrath is to fly under the radar and avoid asking questions. How does that help anyone? I can point out several situations over my career where less experienced people have asked questions that exposed a gap in my thought processes. And I can point out more situations where relatively basic questions have turned into major teaching opportunities.
Or, we can follow a different path and ‘gripe up’. We can keep open minds about juniors and model kindness and approachability. And, we can tell management about our concerns and seek actual change.
* You have to help people, no longer get to play with your toys all day
* You hate your current job
* ----
I'm seeing a pattern of 3/5 but only because I'm assuming you aren't a mother. If I was wrong, Happy Mother's Day!
Have you ever been in a company where senior people were responsible for helping new people? Or, are you searching for that company where everyone comes in magically perfect and at exactly the same level of competence? I've never been at that company, when you find it, please share it here so we can all go work there.
I am currently working for a big corporate in the UK, who have been showing off their "pioneering" and "visionary" strategy to focus recruitment from code boot-camps.
All I can say is that as a senior developer, it has made my life misery. I've gone from writing code and producing features, to a full-time mentor and babysitter. Half of the boot-camp graduates I believe have become coders for the wrong reasons like:
* developers have an easy life, getting into work whenever they choose
* they get to wear t-shirts and baggy jeans
* they get all the latest toys to play around with and shiny MacBooks
* I hated my last job, looking at developers on TV in these Silicon valley places looks like the dream life
* I am a single mother who was given the course for free
The others, have aptitude but are so inexperienced from their 3 month session that it will take them atleast two years before they can be fully independant engineers.
These codecamps are licenses to print money it seems, they charge the students a hefty fee for the course and companies then pay a recruitment fee at the end.
Needless to say, I will be leaving my company very soon to go to a place where there is a coding test and filtering to prevent most of these bootcampers from getting in.
Yes its snobby, but I didn't study and spend my student loan on my passion just so I can train up a bunch of people looking for the "easy life".