Advice for Coding Bootcamp Graduates
thinkfaster.co
thinkfaster.co
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.
> 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.)
[1] https://cs.uwaterloo.ca/future-undergraduate-students/co-op-...
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.
If you're interested you can take a look at the first post and subscribe if you think it would he helpful. https://exponentialbackoff.substack.com/
Don't tell people you paid for a coding bootcamp.
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.
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.
- 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.
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.
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"
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.
This just seems like such a small obstacle that the technical parts would end up taking a back seat to other hiring criteria.
> why don't you hire them, make that little investment yourself, and have them fix things they're capable of fixing while they catch up?
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
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.
How often do you guys hire someone who is _neither_ a CS graduate nor a bootcamp graduate?
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.
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.
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.
What do you mean by, "not working on professional things"? Seems a bit insulting to me?
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.
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.
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.
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.
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'm not sure that's accurate, but I've had many people tell me to avoid putting anything about MOOCs on a resume.
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.
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.
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 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.
> 1. Data Structures and Algorithms
> 2. Probability and Statistics.
> You could take them at either a community college or online for minimal expense.
Are there any specific online courses for these subjects that you recommend?
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)".
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?