****** No Bootcamp Applicants ******
code.likeagirl.io
code.likeagirl.io
The genuine knowledge in a field like this cannot be conveyed to anybody over the course of a few months. Teaching someone with a stats or physics background to code is pretty doable on-the-job. Teaching someone years of math isn't. And it's not really possible in the workplace either.
I'm not saying that a bootcamp education is completely insufficient and there surely are jobs on the market where they make for a nice fit, but in jobs that tend more towards the theory side of things the general aptitude that someone has after years of rigorous education doesn't even compare to someone out of a bootcamp.
Not to mention that the comparison to race or gender issues in the beginning is in extremely bad taste. The question here is qualification for the job, not discrimination of a protected class.
Programming is required today to attain a post graduate and even graduate at physics since you’ll be programming a lot of math problems and more importantly simulations.
We have 8 CUDA programmers at my work place and only one of them has a degree in computer science/SE the rest got post grads in Physics Chemisty or Biology.
On a grad/undergrad level for the most par CompSci students would not have much advantage in programming today over Physics or other exact science/engineering students.
But some things can be trained while others realistically cannot, you can train people on the job rather quickly to develop using a given framework and toolset but giving them background in fields that require nearly decade of dedicated education is a different story.
The truth is that unless your bootcamper has had proper education they would not be able to catch up on the theory.
Forget algorithms maybe 1 out of 10 bootcamper I've interviewed understood basic mathematics like vectors and scalars, were talking about High School level Calculus here.
But again if you only build basic web applications and implement pre-defined UX/user stories there isn't much need for this.
Bootcamps aren't new I remember the Java/C++ 8-12 week night schools from the 90's which were later supplemented by .NET schools that was huge in the early to mid 2000's Microsoft was pushing Windows 2000/2003 MCSE and MCPD to highschool students in my country.
My older brother effectively use a bootcamp in the late 90's he had a masters in electrical engineering he had some programming experience mostly in FORTRAN but effectively in .com boom of late 90's he switched to programming after doing one of those JAVA and C++ evening courses. That said I don't think he would've gotten to IBM and now into Redhat without his previous education, that course was effectively just a seminar for him.
As far as bootcamp graduates go, I would be careful about assuming that's their only exposure. I'll take someone who has been obsessed with coding since they were a kid over a uni graduate who is just in it for the money, went to class, and only wrote code to pass the classes.
If you need them to work on more complex things say computer vision it might be more tricky unless they only consume existing libraries. It’s much easier to learn RoR than it is the lean the math needed to say understand what a Fourier Transform is.
It really depends on what the programmers actually do; implement a known solution or come up with one.
I always wonder, though, whether I'll eventually run into a math-critical issue and cannot just reason my way through it. It's a terrifying prospect, but luckily in my 5 years of dev experience I haven't faced that scenario.
I used to do and enjoy algorithm competitions as a student, but in "real life" I've found there is almost no correlation between the complexity of the algorithms and the amount of money to be made.
I see almost zero connection between the two:
* CS/programming: techniques (a mathematician might refer to these disparagingly as "tricks") used to make machines do things
* mathematics: foundational truths on the study of space, quantity, structure, change etc.
The most mathematics I've ever used on the job was basic (read: finite-dimensional) linear algebra, which is a part of every undergrad math student's basic toolkit.
If you're concerned about holes in your knowledge as a self-taught web dev, I'd study core CS courses like architecture, operating systems, networks. Know what you don't know that matters (hint: it's not "math").
EDIT: there may be a strong connection between computability theory and math https://en.wikipedia.org/wiki/Computability_theory, but I don't think this field is mainstream in either core CS (could be wrong here?) or math. I've certainly never encountered it on the job.
For me for example the turning point was having to learn a lot of trigonometry to apply to an AR app. No way I could have done without, but because I was still doing something I love I got the motivation to learn.
Then I go ahead and show them that just by doing the same thing in C++ you get a 10x speedup if you know what you're doing, sometimes more.
And then they say "but I'd never get an optimal algorithm done" (that C++ is typed actually makes this easier for me then python as soon as we get past the "trivial" complexity level, but to each his own I guess).
So I say "Ok. No worries ! Let's make it inefficient !". And add an inner for loop where a hash lookup would have done it (for example). And lo and behold ! The C++ code still beats the crap out of their "optimal" python code. (this is somewhat of a cheat because the odds of making a random thing somewhat inefficient is very unlikely to be the critical point of that code, even if it's in the middle of the deepest loop). Then we replace their 100mb csv with a new 10mb memory-mappable data and they can't even measure anymore how fast the program is. As soon as we enter main, it just immediately terminates.
Algorithms start to matter when your data, optimally stored, becomes >10x all the CPU cache combined, ignoring things like strings. That means 300-400 megabytes when stored fully binary. Ie. you DO NOT HAVE ANY SUCH DATA. Your company's yearly transaction log is less than this. Before that, forget about algorithm optimization, it will bring you nothing.
TLDR: If you're not working in C++, and actually doing most of your development on data layout in memory and on disk, you don't care about performance. Math does not matter at all. Once a year I encounter a situation where math matters, and frankly I just usually find a PhD in that specific field and ask them (despite having a master degree in Math myself).
You do not need math to program.
The big secret is that for programming, there is only one thing that matters beyond basic programming skill. And that thing is domain knowledge of the problem. Exactly, I might add, what almost all programmers don't have.
The big-O thing is not about C vs Python. A slow C program will lose to a Python program with a properly written algorithm any day of the week. Just because of how the math works out. The speedup of using C is linear (in practice, worse than linear). Suppose the O(n^2) C program executes each instruction 1000 times faster that the corresponding O(n) Python program. Then you only need n to start reaching thousands to blow the C program out of the water. Meanwhile, O(n^2) Python program would be a thousand times slower than that. And to me, that's unacceptable.
The thing about O(n) algorithms versus O(n^2) algorithms is that very often rewriting an O(n^2) algorithm into an O(n) algorithm involves splitting the loops, and using way more memory.
And that's assuming you do it correctly. Mostly people don't. Example, your basic optimization of a double for loop turns into:
# (1)
x = {}
for e in lst:
x[e.field] = e
for e in lst:
e2 = x[e.value]
# do something with it
# (2)
for e in lst:
for e2 in lst:
if e2.field == e.value:
# inner loop
n < 10000 or so: (2) (the actual number depends on the CPU, but it'll easily be 500 even on the most pathetic atom or even mobile processor)
n > 10000 and total size < system memory / 2.5 or so: (1)
Needless to say, this means that for anything you should do client-side the double loop will be the faster option, even on the slowest mobile cpu any of your customers might use.
At some point the Hash table will start winning. Until it causes virtual memory activity during the lookups. At which point, it's memory usage makes it useless. I'll see about actually running this test with an actual example program.
Hence, it's good to keep Rob Pike's rules of programming into account: http://users.ece.utexas.edu/~adnan/pike.html
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Coding "bootcamps" have been broadly embraced by people trying to get programming (about as gender-selected a profession as there is) opened up to people from broader backgrounds. Obviously there are white dudes that come out of these programs too, but... no, it's not too much a stretch to imagine someone talk about "bootcamp applicants" as shorthand for post-college women looking for a change of career.
Likewise, sure, it's possible that someone is just using "bootcamp" as shorthand for "unqualified" and trying to sincerely convey the deep background required of the position. But it's not in "bad taste" to imagine something a little less wholesome either. Which is to say (pause while people get out their SJW hatchets): check your privilege a bit. It's easy for people like us who followed the rules and have the right chromosomes to imagine that injustice doesn't exist. Those closer to the problem have a different perspective.
But don't mix those things up when it comes to the bootcamp issue. I would rather state it the other way around. Women can complete and do deserve to get a full education. We do not need to funnel them through rushed education systems, or be afraid to evaluate candidates candidly. It is not productive to keep bad and often expensive programs alive that market themselves to people looking for a career jump.
To paraphrase: "Women who didn't get a CS degree in their 20's can shove off, they're beyond hope and shouldn't try to break into a profession where they aren't qualified"
One man's (heh) objective and rational criterion is another's instrument of oppression.
All we hippies want you to do is just evaluate candidates on their own merits and not use shorthand like "no bootcamp applicants!" which can be easily construed as discriminatory. And it wouldn't hurt if you could try to see things from other people's perspective too, but that's optional.
Don't sacrifice the quality of education just to pursue an egalitarian end, it will backfire and get you the exact opposite result of what you want.
Whoosh, as it were. The point is that when you say that, it is what some other people hear. And that forcing disadvantaged demographics to read your mind to tell whether you're simply naive or a sexist jerk is hurting all of us. There are principles at work here beyond "sacrificing the quality of education".
The bottom line is that you aren't being nearly as welcoming as you think you are.
The interviewer will never know your entire backstory and needs to make a decision relatively quickly. If I would start to be overly empathetic or sensible, I would arguably start making biased and bad decisions based on personal gut feelings. That's what I need to avoid, not encourage.
Wow, 3 whole months? I wonder why they didn't want bootcamp applicants...
But, in general, I agree. They should be filtering by ability rather than putting a blanket ban on people who have done a bootcamp. But playing devil's advocate, I can totally see why they put a blanket ban on people who have done a bootcamp.
Also, this article was flagged, and I vouched it as I don't think it's totally unsubstantive. But I would prefer it if we lost the stars from the title.
12 weeks @ 10-12 hours/day on algorithms and data structures would be more time than one would have put into those subjects getting a CS degree from Caltech [1], so I wouldn't dismiss it based solely on it only being three months.
[1] well, it would have been if Caltech offered an undergraduate CS degree when I was there. At the time, they only had graduate degrees in CS. They had all the necessary classes available for undergraduates, but just didn't have the program. Those of us interested in CS would usually major in math or physics or EE, and simply take all the CS classes as electives.
My problem with bootcamps is that is not how the human brain works. No one can absorb 12 hours a day of information for 12 weeks. Things get lost.
We need experience and repetition. We need to shoot ourselves in the foot by accident a few times. You don't get that in a 12 weeks.
Which is fine. I've hired plenty of people with no college but years of real world experience. I've even hired someone straight out of high school before.
The difference is when you act like the 12 weeks has taught you everything you need to know.
"wisdom is knowing you know nothing"
I've been doing this 20 years and have a computer science degree and I still marvel at what I don't know.
With that said, the company that made that job post sounds like a terrible place to work. I'd probably rather work with the bootcamp grad than whoever wrote that job listing.
Although one point... and this is right up in there with things you didn't learn in bootcamp...
It's ok to write a O(n^2) loop if n is a small number. Only optimize your algorithms if it actually has performance impact. Don't optimize just for the sake of "exponential complexity is bad." Premature optimization is a terrible thing.
I've never met anyone out of a bootcamp who acted like that.
Perhaps "bootcamp" as the last thing on your resume just screams that you are a greenbean and can't rightly claim competence in much of anything. Get hooked up with a technology staffing group in your area, they'll help get you placed and the sweet, sweet lucre will begin to flow your way. (Search for "IT Staffing" or "Technology Staffing".)
I suppose there is a lot that is unfair/crummy about women's experience in the workplace these days, but I'd be shocked if landing an IT job is crummier than it is for men. I observe that sane women with any decent level of technical acumen in my division get promoted more rapidly than men. So, in some companies, it'd probably be advantageous to be female.
Let's not be complainers and wallow in our victimhood. That blog post will make you quite unattractive to some employers that care to google you by-name.
One of the questions that I was asked was "What's your go to tricky interview question"? Truth is, I don't have one. My advice for these graduates was to make sure when presented with a kobayashi maru that they do the best that they can to clarify the scope of the question before blindly falling into a trap.
I'm a bootcamp grad. I've hired bootcamp grads and will continue to hire them. If companies are that quick to eliminate potential new hires, then you likely wouldn't enjoy working for them anyway.
The author seems like a motivated person and while she speaks inclusively of all the bootcamp participants(a lot of "we"), I am willing to bet that many of them do not share her drive. It's also worth noting that just because someone taught you something and you studied, it doesn't necessarily mean that you can apply it to the real world. Which is why experience is probably still the best learning tool.
In the end, I do feel sort of the same even toward normal grads. I believe that it's not where your knowledge comes from but what do you do with that matters. The question then becomes, how do you weed out the bad ones? Well, we are back at square 0, with an interview.
To recap, I agree that you shouldn't have a job post like that but for different reasons than the author's.
The flip side to this: I'm self-taught and I've worked with plenty of CS graduates from good schools who didn't strike me as particularly driven or value-adding. On the theory side, I'm not sure they could talk through a basic DS&A problem if I gave them one as well (that they hadn't seen before).
To your point, it's not where your knowledge comes from, but what you do with it that counts (and I might add, that the foundational bits exist).
But think hard about whether or not you really want to work for a company that says things like this in their ads, because you probably don't.
"The post went on to detail a need for an understanding of BigO time complexity, which is completely fair. No one wants a double loop in production code. What a bulky monstrosity that would be (imagining a giant disgusting swamp monster made of 0’s and 1’s, eeek!)."
"I certainly don’t want to make a messy newb mistake like creating a method with a time complexity of O(n²) or worse (cringe)."
I'm not going to be critical and say that this is wrong and that the author doesn't know what she is doing. But it does seem that this quote demonstrates a tendency I see among female advocates of women in tech, and that is to slightly awkwardly use technical terms in order to try to prove that they are part of the "in group" of people who understand technical concepts.
In this case, it seems that she is trying to prove that she knows what BigO is. I feel like this is a kind of meta-sexism. What she is doing by explaining to us the gist of BigO is saying "I think that you think that I'm so stupid that I don't know what BigO is, so now I'm going to prove to you that I do."
I know I suffer from the assumption that women don't know how to code. It's a hard thing to get around, since %90 of female programmers whom I meet are women from PyLadies who come to the local python meetup, and really don't know how to program yet. And now our author is suffering from the assumption that I assume that she doesn't know how to code. And in trying to prove otherwise, she trips over herself in her eagerness to prove my assumption wrong.
This meta-sexist thinking and behavior is getting so complicated and convoluted that it is acting to distract us from thinking and communicating on technical topics. I believe that it has become harmful to the cause of encouraging women and minorities to join our communities. It is harder for me as a white man to talk to a woman or a minority because I am thinking about their gender or race. And it is harder for a woman to talk about tech if she is thinking about my thinking about the fact that she is a woman.
Somehow we need to escape meta-sexism and start talking to each-other as equals, without presumption or presumption of presumption.
That has nothing to do with being a female advocate of women in tech. That has everything to do with being 12 weeks into programming. That's the main reason I don't like this article.
I'm lucky enough to know a lot of incredible software engineers who happen to be women (and were also CS grads or PhDs), much smarter than me, and I don't like this attempt to associate all women engineers with people who clearly only have a superficial understanding of code.
I don't know that many experienced female programmers, but the ones whom I do know are not advocates and tend to avoid the subject of their gender. So my own experience leads to the conclusion that I made, not about all women programmers, but about those who advocate women in tech.
How the hell do you come to that assumption? I don't understand at all how you can make an assumption that a person knows or doesn't know something based on race or gender.
You need to check yourself because:
> It is harder for me as a white man to talk to a woman or a minority because I am thinking about their gender or race
is not normal.
> is not normal.
Perhaps you don't do so. But how do you know it is not normal? If you don't let me share my internal battles without attacking me, then how can you know the internal psychology of others?
When we meet someone, we begin with a default set of assumptions about them and what they know. You cannot even communicate with a person without assuming something about their level of knowledge, of language, culture, and technology. The question is, whether these in-avoidable default assumptions should differ based on a person's race or gender or nationality. I believe that they should. If I come up to you, knowing that you're from the UK, and start talking to you about the post communist privatization process in the Czech Republic, without first explaining to you what it is, you are bound to be confused. I assume that you do not know about the privatization process.
That doesn't mean that I believe that citizens of the UK are fundamentally incapable of understanding the privatization process. If I ask you if you know about this process and you say you are an expert on post communist economics than my assumptions about your knowledge on the subject will quickly change. But for now, since I know nothing about you, it is safe for me to assume that you know nothing about privatization and that in order to be polite, I should not spend the next 30 minutes talking about the current value of privatization coupons without ever asking if you know what the hell I'm talking about.
But when the basis for my assumption of shared knowledge is gender, this leaves an interesting question. If I know that most women who I meet in technical contexts are not computer programmers should I immediately assume that they are computer programmers and start talking about in depth concepts or should I ask first? Is it more rude to assume that my conversation partner understands what I am talking about or to assume that they do not understand? Especially when many newbies are so eager to show that they do understand, that they find themselves unwilling to say out-loud that they do not.