I am a cofounder of a bootcamp (Hack Reactor) that teaches Big O. I believe our average grad knows more about it than I did when I graduated with a CS degree.
Some comments:
1. If you're a bootcamp grad, be aware that impostor syndrome / low confidence / "maybe I'll be ready to interview after I take one more class" is a FAR GREATER RISK than not knowing big o. When you read an essay like this, consider it as useful input. Big O is useful, and is a special point of interest to interviewers, but do NOT listen to any of the voices (especially those in your head) telling you "you're not a real engineer until you XYZ". So, by all means, internalize this essay if your takeaway is "nudge big o up on the study list". Reject this essay and everything it stands for if your takeaway is "I am not ready to be a software engineer yet".
2. A dissenting viewpoint from me: this is good advice for interviewees, but interviewer focus on Big O / data structures / etc is a part of the same culture that fetishizes CS degrees from tier-1 schools and mistakenly believes that the most difficult/valuable part of software engineering is computer science. In reality, the most difficult/valuable parts of software engineering are craftsmanship (measured in decades of real work, not built at schools except those named waterloo) and working effectively in teams. Big O is not uniquely useful to your work or uniquely difficult to learn on-the-job. You should study it anyway because many interviewers believe that it is.
Hi Shawn! I think I interviewed with you as a student when HackReactor was calling itself Catalyst. Anyway:
> not built at schools except those named waterloo
I was in Vancouver once and visiting a friend at his workplace. They mentioned that they hire a lot of University of Waterloo graduates and I asked, innocently, "is that a good engineering school?"
I got a blank stare from everyone before they flatly responded, "Yes."
I know Waterloo's prestigious reputation better now, but I'm curious what experiences do you have with Waterloo grads that makes them the exception to this rule?
Waterloo does one thing uniquely well: the co-op program [1]. Their grads have a ton of real-world experience before they graduate, which puts them head-and-shoulders above their peers. (This is connected to my broader worldview.)
100% agree. I would argue Big 0, or [insert abstract CS concept here] is drastically overrated in importance. We're much more interested in someones propensity to learn new skills and curiosity than we are in how closely they align with a traditional CS grad. To be honest, some of the best developers we've hired have had no formal schooling whatsoever.
I've been doing full stack web programming and server administration for the past 20 years, and I almost never encounter "Big O" notation and algorithm problem solving except in interviews.
99% of the things I have built in the past (and continue to build on a daily basis) consist of just gluing things like APIs together, or building user interfaces that essentially just allow users to display and modify data in various databases.
I've had to learn tools like Docker, Git, Travis, Ansible, and Kubernetes. I've had to be able to learn the basics of languages like Javascript and Python and Ruby in a matter of months or even weeks. I've had to pick up frameworks like Angular and React and whatever new shiny thing exists, at the drop of a hat.
I have built large web-based software projects that power multi-million dollar companies, and that handle millions of users on a daily basis.
I don't have a college degree, and my knowledge of advanced math ends at Algebra. But that didn't stop me from assembling and launching a machine learning platform for the company I work for.
But yeah. I don't know shit about algorithms or your "Big O" that you love so dearly and love to judge every "programmer" by.
The camp I went to was very small and went under after my class graduated. There were just 4 of us in the class. 2 of us now are devs. The other guy who became a dev had a good amount of IT experience coming in, but needed more hands on work with development. The other students just weren't picking up the stuff fast enough and quickly fell behind and didn't recover. I have met a decent amount of people from other camps that had similar experiences, sometimes coding isn't for everyone.
After graduation, I had to do a few more months of solo studying/project work before I reached hire-able level. I got lucky and got hired by a startup that needed a junior dev ASAP. I had a great boss at this startup and learned a lot while also getting the chance to work on features.
Now getting work is easy because I have worked before.
TLDR: You have to put in more work than just the bootcamp to go from no experience to hire-able. And some people just aren't made to be devs, and they may be able to get into a boot camp but they won't be able to contribute when hired. Hopefully I don't come off as conceited/cocky, but that's just my 2 cents.
Slightly off topic, but I'm working on putting together a newsletter aimed at career advice for junior software engineers and bootcamp graduates. It will focus more on the soft skills side of engineering. I've gained enough experience in my career where I feel I can offer advice for career advancement for people just starting out their careers. It's something I never had when I first started and I haven't been able to find a lot of solid advice more than a blog post here and there.
Without fail, every single "code bootcamp" that has applied for a job here has had a horrible resume. They didn't have anything on their resume that wasn't from the bootcamp, and even that was horrible.
And they generally failed our "use Flickr's API to get some images" test that we give out. Miserably.
I think we ended up interviewing 1 of them, out of dozens, and they just weren't worth trying out.
So now, when I see that on a resume, I groan. I still go look at whatever's on their Github, but I'm already primed to fail them. They would have been better off having nothing on the resume and anything in their portfolio.
- Why would you expect them to have more than the bootcamp on their resume? Most people don't have prior programming experience, and most bootcamps are demanding, such that they wouldn't have time for side projects.
- Is the test using a language they're familiar with? An editor they're familiar with? Is it pair programming, or are they just given a computer and a desk? Are they allowed to use Google/SO/etc?
- Why do you expect them to have a curated and up-to-date GitHub? Most of the code on there will only be stuff related to their bootcamp program.
Without knowing the specifics of your interview or the particular bootcamps you're hiring from, it sounds like your expectations are mismatched with what the bootcamps are teaching.
We expect them to be able to code at a junior level. They cannot. I wouldn't even consider most of them for an internship, and the rest only grudgingly.
Yes, I expect them to have more projects in their Github account than just what the bootcamp forced them to do. If they don't care enough about programming to do that, then they probably don't care enough about programming for us to hire them.
I've found it depends on the bootcamp. There are a select few that do a good job and produce solid junior developers, but the VAST majority are trash and produce developers similar to what you describe.
Can you expand on what you mean by "They didn't have anything on their resume that wasn't from the bootcamp, and even that was horrible."? Do you mean the projects they built, or the list of courses they've taken?
Like the top comment I have passed on many bootcamp graduates, and many of my colleagues have too. I can only think of one bootcamp graduate that was ever hired at any org I worked at.
When we look at an application/resume from a bootcamp grad, it tends to only contain: "this is what I was doing before", "this is the bootcamp I went to and the projects we did there" (sometimes, these are cleverly formatted to appear as projects done after the bootcamp. We can generally see right through this, and it feels a little dishonest, but it is fine.)
What would make a bootcamp grad resume infinitely more attractive is if they demonstrated their enthusiasm by doing more projects. What it comes down to for me is: this person wants to have a job that many people go to a 4 year program for. Additionally, lots of those people who went to the 4 year programs had an inherent interest in the subject even before starting schooling. Bootcamp grads are heavily outclassed in general by these candidates, and an org is taking a risk (burden) by hiring a bootcamp grad.
So, it goes a long way for a bootcamp grad to 1) demonstrate that they're going to come in fighting and have a raw enthusiasm, 2) possibly tie in their previous employment (biotech? stats? very relevant.) These two things are going to be their strongest assets coming into the job. Not whatever they learned at bootcamp.
Ah ok, that makes sense, thanks for the info. I can see how only having a bootcamp and an unrelated background gives just a single data point to work with, which even then isn't very illuminating.
This article treads lightly around calling bootcamp grads inferior on average, when actually, very little is standing between the company itself turning the bootcamp grads into the engineers that they want.
After all, you already have ample evidence someone can learn software development concepts on a compressed timeline compared to college, surely another week or so covering time/space complexity and data structures topics is worth the time if the candidate is otherwise a good fit.
But I don't know, maybe their idea of junior development tasks is "find and fix deadlock or race condition that occurs 0.00001% of the time"
Author here: I don't believe anyone is inherently inferior. Given the same amount of time invested, I think everyone has a shot at performing well.
But a computer science graduate typically has 4 years under his or her belt in an engineering heavy curriculum, and because of that time invested, they seem to be stronger in problem solving.
We use Big-O as a signal for problem solving ability. Whether or not that signal is problematic is another question - you could argue that it is.
So yes, I would say that someone who has invested 4 years into problem solving is going to have an advantage over someone who has only put in 6 months, even if those 6 months are dedicated.
But the bootcamp graduate could equal the C.S. graduate with a little more investment.
Hiring someone who doesn't work out is unbelievably expensive. It can be a disaster for your team.
When we hire someone, we have no way of knowing if they'll be the life-long learner type who will aggressively consume new knowledge and learn as much as they possibly can. In other words, we have no way of knowing if we can effectively train them, and it's crazy expensive if we can't.
We've tried to hire 1 or 2 of them as interns, but usually they're not interested in being interns.
But I don't think that trait would be discoverable in CS grads more often than boot camp grads. If it is, and you get a reliable source of candidates from CS grads, why not just filter on that and not bother with the time spent interviewing boot camp grads? And I'm not sure a couple of courses would change that in a person. That's distinctly out of the technical set of qualities.
Sounds like you guys should be hiring self-learners. If someone has taken multiples years of teaching themselves from scratch with no CS degree and no bootcamp attendence, they sound like the lifelong learner you guys are looking for.
How often do you guys hire someone who is _neither_ a CS graduate nor a bootcamp graduate?
>Because they can hire someone that has the skills they desire, and not have to worry about the investment time to get them up to speed.
Why are they taking interviews with bootcamp grads then?
None of this is adding up to me:
- The problem-solving gap between boot camp grads and CS grads in this company's opinion can reasonably be crossed via learning complexity analysis, and a couple of college courses in Algs/DS and Statistics
- Despite having the candidate's resume and knowing their own opinions, the company still decides to take interviews from boot camp grads when, presumably, they have a pool of CS grad candidates to compare the boot camp grads to
- The company wants boot camp grads to catch up while recognizing the gap is relatively small, despite having a pool of candidates they'd already prefer to hire from
- They have time to interview boot camp grads and reject them but are otherwise unwilling to spend the same time directing a new boot camp hire towards things that would bridge the gap? There's plenty of cram-tutorials out there that a few weeks would catch someone up with
"Junior developers" in hot markets make six figure salaries. If you could get away with paying $50k-70k to a software engineering trainee and then promoting them after they work out, maybe it would make sense to do that. But if you're going to invest software engineering salaries in a field that doesn't even have the kinds of formal credentialing of similarly-paying fields like medicine, you're not going to risk hiring someone who's a work in progress and might not even work out in terms of having the basic qualifications.
>you're not going to risk hiring someone who's a work in progress and might not even work out in terms of having the basic qualifications.
That's what the bloody technical tests are for!
If you're giving those out, on top of a technical verbal interview, and still saying "well, we still don't know if they can even build a CRUD app with our stack", you have a broken hiring process!
I can understand the difficulty in choosing the right questions for the limited time we all have to interview to extract the maximum useful amount of data about someone. And that there's a lot of debate about which questions are right ones to ask. But a technical test that represents the basic unit of usefulness to your company is bare bones stuff.
As long as they were otherwise able to contribute to the team, which is what should have been found out in the interview. That's what the boot camps are selling. The gaps in CS knowledge were what the article is saying was one of, if not the, deciding factor in choosing a CS grad over a boot camp grad.
Which is a different role. And if it were treated and paid as a different role, and there was an acknowledgement that a coding boot camp graduate without deep CS knowledge could develop into a real software engineer some day but they weren’t one yet, then I would agree with you. But if the role and salary is that of a full-fledged software engineer, understanding CS is a basic qualification.
After trying out different methods of teaching, here's what works for us:
1. We do peer to peer teaching. If a student learns arrays, he/she is in charge of teaching it to new students. This builds the ability to communicate technically.
2. Students are code reviewed from the first line of code they write. As challenges get harder, inefficiencies are caught through code reviews and explained to them by their mentors.
3. Rather than building their own ideas, students build products that everyone on the team use on a daily basis. We have our own internal hosting, our own email, stackoverflow, and student progress, all built by the team of students. By making students work together on one big project that runs exactly like an engineering team (with sprint planning, code reviews, project discussions), students not only get work experience but also get to learn with others through trial-by-fire. Its incredibly fun for everyone.
4. Since we are so young, we have only graduated 3 students, but each of them love their jobs and were able to jump right in to their issues and get stuff done. They were also able to have in-depth discussions with their teammates.
Having worked with so many engineers, I personally value technical soft skills. When I work with engineers who can communicate / collaborate well, I feel that I can teach them anything.
After going through a web dev bootcamp myself where we actually devoted a decent amount of time to algorithms and their time/space complexity -- this has been the thing I have used the least in my professional career.
Developers who learn about time/space complexity view code in a different way. They can reason about code in new ways and it also helps discuss code between devs.
When I work with large data sets, It's difficult to explain why something is taking a long time without thinking of it in terms of O complexity.
Not OP but I did a 3 month boot camp, where the final month was spent on a big group project (which was great) and then algorithm optimization, red-black trees, and a bunch of stuff that I didn't actually think I needed on the job for 2 years.
Sometime in my third year on the job I had to find the duplicates in an array. My beautiful solution "arr.select{|x| arr.count(x) > 1}.uniq" didn't work because I had 100,000 items in the array. My solution was O(n^2), and that finally made sense to me, and it actually mattered.
I would say this was when I didn't feel like a Bootcamp beginner anymore, and thought of myself as an intermediate professional programmer.
Yup. Understanding fundamental computer science is a good example of the Dunning-Kruger effect. If you don't understand it, you likely don't even realize that you're missing something important.
It's not meant as an insult. I meant professional as in
>characterized by or conforming to the technical or ethical standards of a profession.
In Germany we use the word to express sophistication and technical expertise.
If you don't know how to handle algorithmic complexity it's less likely you will take a job that demands knowing much about it, but that doesn't mean it's not professionally needed.
The author has the right idea. The company I work at hires junior engineers somewhat regularly, and the quality of bootcamp grads varies wildly. It'd be awesome to see additional CS courses on a resumé, as fundamentals like time/space complexity are usually the biggest weaknesses of the bootcamp grads we interview.
I'm a bootcamp grad and am about to finish my first year as a dev at a well-known, medium size start-up in San Francisco.
The advice the author gives is spot on. Taking the time after finishing the program, working through multiple algo textbooks, and taking an online course on data structures and algorithms definitely helped seal the deal.
To those deriding bootcamps, you are missing out on lots of great developers. The trick is to determine whether the individual worked hard during/after the bootcamp.
Lastly, if you're considering a bootcamp, do your homework, pick a good one, and work relentlessly (I was there generally 8am-11pm every day). It has turned out to be one of the best decisions I've ever made in my life.
I am a bootcamp grad with several years of experience now. I agree with the article that the two of the weakest areas for bootcamp grads are data structures and algorithms.
However, my advice would be to interview at places that have focus less on these areas instead of taking coursework. At the end of the day if you are bootcamp grad you are probably not in the financial situation to take extra coursework. It's better to lower your standards a bit to get your first job and then pick up these skills on the job.
You will still have to grind out algorithm prep by using sites like Leetcode and Cracking the Coding Interview, but it's probably a better idea to focus on companies that focus less on this area.
Have interviewed a bunch of bootcampers. Goal is to give everyone the benefit of the doubt. Without fail, they lack the fundamental knowledge needed to excel. Not because the classes or assignments are bad, but because there is so much hard-earned experience and "instinct" that only comes with time in front of a keyboard.
The advice to include online MOOC courses on your CV runs counter to every piece of advice I've ever received in regards to putting online courses on a CV. I've always been told that that is seen as a red flag and that you might get docked 'points' for having something like that on a resume.
I'm a coding boot camp dev with a few years of experience at startups and half of my resume consists of online MOOCS (Udacity's machine learning, Udacity's Linear Algebra, Fast.ai's deep learning, and Cloud Academy's Certified AWS Developer)
I'm curious as to what HR from Big Tech companies and small startups think about a resume filled with MOOCs like this.
I hire for a small startup, so maybe this isn't how it works at the big companies, but I certainly wouldn't dock points for this. I think it shows initiative, and at worst I wouldn't care one way or the other.
The only way I could imagine it being a red flag is that sometimes people put things on their resumes that aren't real accomplishments (like things they did in high school, or the fact that they know how to use MS Word) and it makes me wonder if there are so few worthwhile things for them to talk about that they use filler like that. But even then I pretty much just ignore it.
I don't hire engineers, but I am one. I've never heard this advice about not putting MOOCs on your resume, and if I were hiring, I would likely consider any MOOC (with a decent grade if applicable) to be better than nothing. Can the OP of the comment say more about the reasoning?
Am OP of comment, I believe the reasoning is that the quality of MOOCs varies wildly and there is often no way to confirm that a student actually completed the content or how well they did? Another reason could be that the sheer number of MOOCs that a student might take would just add noise to your resume?
I'm not sure that's accurate, but I've had many people tell me to avoid putting anything about MOOCs on a resume.
In over a dozen years as a professional web developer, I've never once needed to use Big O notation outside of an interview. Sounds like this guy doesn't know how to interview, knows that he doesn't know, but still doesn't want to admit it. No wonder he can't find anyone.
I think it's less about the notation, and more about thinking around computational complexity. You should know when to use a set vs a hash vs a list vs an array. You should know what different sorting algorithms do, and why you might use one over another. In some cases having exposure to more esoteric data structures like persistable tries, minimal spanning trees, red/black tries, bloom filters, etc can come in handy. Knowing why things like that are useful is worth knowing. But I agree with you, judging a bootcamp graduate on skills that can be taught with experience and continual study is probably not the best way to go about hiring people.
I think it's more about simply having an awareness of algorithmic complexity. I'm talking about writing a doubly nested 'for' loop and being able to realise that you've just written an O(N^2) algorithm if you're iterating over the original collection again. This sort of stuff is blindingly obvious to experienced programmers but for bootcamp grads who haven't built up that intuition, a short course on Big O notation exposes them to it.
Or, since you're hiring Junior devs, someone could like, take 10 minutes to explain why what they did is wrong and point them towards some resource to help them get on the right track.
This whole thing is part of the circular logic problem with hiring: you have people making these hiring decisions that aren't trained in hiring, so they just go with "what makes sense to them" or hiring a younger version of someone who looks exactly like them for a junior role. It's fine, it works for the company, but it's why people will miss long term talent.
Damn straight. 100% of stupid whiteboard coding questions could easily be solved with taking 10 minutes to google / explain the solution. So why are these stupidities even asked? In other words, the author is incompetent and shouldn't be in charge of hiring. He won't hire someone because he won't take 10 fucking minutes to explain to them something beyond simple (although if you explain it in big O terms, it's not simple). That's a manager who is in the wrong job.
I think your experience is largely true for professional web developers, but with the advent of things like Node that brought JS into back-end land, there are a lot of traditionally front-end people spilling over into back-end and "full stack" roles, which often do require some basic level of competence with complexity analysis.
When you make the switch from writing code to support UI elements to writing code to handle data processing, for example, you're going a bit beyond the standard coding bootcamp's toolkit. I think this is the author's point, and why he recommends that bootcamp grads (who may end up in situations like these) take extra steps to be prepared for whatever curveballs come their way in their careers.
I agree and I don't. For the record, I'm a (2014) bootcamp grad. I don't use Big O directly, and still struggle routinely to talk in those terms, but also consider considering performance one of the most important parts of my job.
I think it's important that bootcamps teach about complexity, and that they don't do a great job of it. I also think asking anyone to speak in terms of big o may or may not be the most comfortable way for the candidate to talk about it.
I do a lot of interviewing now, and prefer to check to make sure that they understand how to optimize their solutions in a coding context, rather than asking about the "description" of that optimization, personally.
Coders who don’t have enough statistical expertise is a problem why? I understand the importance of O notation, but didn’t know that stats/probability was important for things like web design and other coding jobs. Can someone help me understand this part?
I think the basics of it (i.e. recognizing n vs n^2 vs exponential) is important for back end developers. After a few years of doing back end I've definitely had to have awareness in how I design things like my loops to optimize.
It's not a biggie for most companies, but you should have a general awareness. Unlike the author of the article, though, I do believe you can learn this on the job. Also, you don't have to necessarily know the big 0 notation, it's a good idea to write a load test which will give you a more relevant stat anyways. But sometimes its good to recognize "Oh I don't need a 2nd inner loop that will change this to O(n^2)".
"if you take one of the 6 month programs, you’ll get a similar amount of experience as in an undergrad curriculum."
I am sorry, what?
Look, I know that people are all about "disrupting" the world. But, for the love of hard-work and whatever goodness left in your heart, can you please stop insulting people?
I once worked as TA for an introductory class in Computer Science. It takes about a semester for students to wrap their heads about what is "programming." It takes at minimum another semester of honest to goodness to absorb the fundamentals of computer science (incl. formal languages, basic complexity theories, and basic algorithm). It takes at least another semester to work through how the computer (you know, the silicon?) works.
Of course, I have only talked about the theory side the programming world. A good CS program also needs to introduce at least 2 (if not 3: one introductory, one system, one industrial) programming languages, plus at least 3 paradigms (corresponding the languages above: functional, system/procedural, and OOP), plus some discussion over the industry. And they should ensure that the students get stock overflow at least once, infinite loops at least a few times, and (on the verge of?) kicking their classmates/teammates at least once on some stupid bugs.
More challenges: a brain isn't a hard drive. Cramming is about the worst way possible to induce understanding. All of these above need time and space to work themselves through various layers of consciousness.
(BTW, all of the above are just the basics; if you notice, I have not brought up any "sexy" topics like networking or cloud computing or AI or what-have-you)
Imagine for a minute: what happens if a person walks up to newly minted chemical or mechanical or even electrical engineers and tells them that their 4 years of education can be done in 6 months. What would the new engineers think? Well, here is the nice version: such "disrupter" is laughed out of the room. The less nice version involves some honor-defense beating. The pragmatic version probably involves some lawsuits over how such claim is a fraud and may endanger the consumers (not to mention co-workers).
And yet, here we are. Software engineers, who spent years to acquire immensely complicated skills, are forced to sit through and agree with such insults, then to give comments like "oh yeah, maybe you should learn more about big-O notation." You know what I think about big-O notation? It's about as useful as calculus. Remember, doing something twice does NOT cost as much as doing it once (and this is before factor in goodies like cache miss and waiting for OS and whatnots). It's like push-ups: good mental exercise, but not actually used. So, telling someone "you need to learn big-O notation after 6-month bootcamp" is like saying "learn football for 6 months, add some push-ups, and you are ready for NFL." Am I the only one finding this ridiculous?
Some comments:
1. If you're a bootcamp grad, be aware that impostor syndrome / low confidence / "maybe I'll be ready to interview after I take one more class" is a FAR GREATER RISK than not knowing big o. When you read an essay like this, consider it as useful input. Big O is useful, and is a special point of interest to interviewers, but do NOT listen to any of the voices (especially those in your head) telling you "you're not a real engineer until you XYZ". So, by all means, internalize this essay if your takeaway is "nudge big o up on the study list". Reject this essay and everything it stands for if your takeaway is "I am not ready to be a software engineer yet".
2. A dissenting viewpoint from me: this is good advice for interviewees, but interviewer focus on Big O / data structures / etc is a part of the same culture that fetishizes CS degrees from tier-1 schools and mistakenly believes that the most difficult/valuable part of software engineering is computer science. In reality, the most difficult/valuable parts of software engineering are craftsmanship (measured in decades of real work, not built at schools except those named waterloo) and working effectively in teams. Big O is not uniquely useful to your work or uniquely difficult to learn on-the-job. You should study it anyway because many interviewers believe that it is.