Live data from Hacker News

Advice for Coding Bootcamp Graduates

thinkfaster.co

41–50 of 69 posts

Re: Advice for Coding Bootcamp Graduates

#41
Bootcamp dev here:

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.

Re: Advice for Coding Bootcamp Graduates

#42
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.

Re: Advice for Coding Bootcamp Graduates

#43

Earlier quoted context omitted.

But 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? This just seems like such a small obstacle that the technical parts would end up taking a back seat to other hiring criteria.

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…

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.

Re: Advice for Coding Bootcamp Graduates

#44
post #22
post #15

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.

Does anyone have more opinions on this? 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.

Re: Advice for Coding Bootcamp Graduates

#45
> A coding bootcamp person could perform as well as a CS graduate if he or she took 2 more courses:

> 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?

Re: Advice for Coding Bootcamp Graduates

#46
post #10

Earlier quoted context omitted.

Maybe your not working on professional things? Also what is a decent ammount of time?

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 i…

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.

Re: Advice for Coding Bootcamp Graduates

#47
post #40

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.…

Which online course on data structures and algorithms did you take?

Re: Advice for Coding Bootcamp Graduates

#48

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…

"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.

Re: Advice for Coding Bootcamp Graduates

#49

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…

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?

Re: Advice for Coding Bootcamp Graduates

#50

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…

"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 hiri…

>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.

Post reply on HN