Translation: women are not interested in programming. This is the fault of everybody but women. (I'd love to see counter arguments to this instead of clicks on the "flag" button, but, alas...)
> I spent twelve weeks, ten to twelve hours per day, of my boot camp working primarily on algorithms and data structures, and was tested on that knowledge every three weeks. So that can’t be the skill I’m missing.
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.
I've worked with developers who have 20 years of development on their résumé who haven't spent 3 months thinking about data yet. I've also worked with interns who are weeks in to their first professional role who have taught me things about data I haven't seen before. Time served is a terrible way of measuring knowledge and passion for a subject.
Very true. There are devs that spent years of their careers changing magic numbers in code they never understood. I believe that a lot of comes down to attitude and eagerness to learn. Because some people maybe haven't even had the opportunity yet to think about data but would love to.
At the school I went to, Caltech, a typical computer science class was supposed to take 9 hours per week (3 hours in class, 6 hours outside of class for reading and homework).
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.
there's no way those boot camp programs spend 10-12 hours a day on data structures and algorithms. that's hyperbole. they need to give their students vocational education on how to build web or mobile apps...how could they spend 100% of the time on algorithms?
There are a lot of universities which taught the core CS worse, and also didn't teach any of the stuff taught in bootcamps, by Professors who were more focused on research than fixing the problem.
Not a great article. I can completely understand the rejection of bootcamp applicants. I've personally interviewed people for algorithm / math heavy positions (explicitly mentioned in the article) and bootcamp applicants just do not cut it.
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.
> the comparison to race or gender issues in the beginning is in extremely bad taste
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.
I do absolutely believe that injustice exists. I've seen women with extensive academic and job backgrounds be treated like amateurs by guys. That is absolutely real and needs to be combated.
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.
> Women can complete and do deserve to get a full education. We do not need to funnel them through rushed education systems
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.
that's not what I said at all. All I want to avoid is that women pick up bootcamp educations in the hope to get a job, fall short in interviews based on merit, and then end up stigmatized as second grade candidates. Which can easily happen if only certain demographics pick up a specific education path, that can't objectively compete with the expectations these people face in their jobs.
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.
sorry but my job when interviewing someone isn't to be welcoming. My job is to be fair, assess the person's qualification and experience because businesses work with restricted time and information.
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.
I've been curious about this issue, because I've been relatively successful in my so-far short career as a web developer. Yet I'm self-taught, and can't math my way out of a paper bag. I'm good at logic so that's gone a long way in helping me.
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.
The vast majority of actual profit-generating programming that is done in the world requires almost no mathematics beyond basic arithmetic. Unless you explicitly want to get into something more maths-heavy, I think you'll be fine.
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'm in a sort of same place. What I found out is that it's never too late to go back and open a math book. It can actually be pretty fun! Especially if math is the only way toward achieving something you want.
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.
I'm always surprised when people try to connect math and physics to CS/programming. I studied differential geometry in grad school, wrote proofs and read dense textbooks daily (very rarely missing a beat), then taught myself programming/CS. I'm now four years into my career, doing pretty well.
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.
Probably not. There are jobs that might require some decent may, so stay away from them. But you're average programmer won't run into a math critical issue.
If you don't use math, it's almost certain that you're writing inefficient code. There's no way to estimate big-O complexity of the procedures you're writing without at least some math. Unfortunately these days it's considered ok to write chat applications that consume several gigabytes of RAM, so maybe nobody cares about efficient code anymore.
I see tons of people online writing algorithms in python and ruby, that will run against a few megabytes of data, and worry about getting the "big-O" of their algorithms right.
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.
No, algorithms always matter. Especially in web-development. Yes, Javascript is slow. But there's no need to make it even slower by writing O(n^2) code where O(n) suffices. You don't even need to reach large n's to feel the lag. I personally had to rewrite such code, which was causing horribly slow website performance.
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.
Web development is about displaying ONE PAGE of data. 20 items. 40 items. 100 items. No more. A far cry from the thousands of items you say it requires (I'd argue that it's a lot more). And just so we're clear a supposed O(n^5) algorithm with n constant (like on paginated web pages), is really O(1).
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
Is that x[e.field] is an allocation and takes O(n) time. So this is an O(n^2) loop, and you have saved nothing over this, even in theory
# (2)
for e in lst:
for e2 in lst:
if e2.field == e.value:
# inner loop
So in this obvious case it takes infinite items in theory. Even that is a wrong prediction. (2) will also behave very differently depending on whether the VM is just starting up or has been running for a while. So in practice here's what's going to be faster:
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)
Why, in the beginning not doing the setup is just faster by itself. This lasts a long time because when the inner loop executes in cache and the hashtable copy does not fit in cache the loop is 100 times faster (on top of that ~100 times C acceleration). This means the loop stays fast for a long time.
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.
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.)
Teaching someone with a physics background to code while on the job is doable if you are willing to throw the code out. Programming is as much of a learned skill as any skill and expecting someone with no programming experience to quickly catch up to someone who has been studying and actually coding for a few years is not realistic.
I haven’t met anyone with a physics degree in the past 10 years that cannot program.
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.
Then they really aren't being trained on the job are they? Thanks for the info about the programming experience they get. I know a few graduate level physicists, but they never talk about programming.
They are, everyone is being trained on a job to some degree.
If you are hiring graduates you are going to be training them on the job for a while even if you hire SE/CS students only there is a big difference between knowing how to program and having experience in software development and delivery.
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.
The initial comparison was between someone with little training in a discipline and someone educated in a discipline. Of course every graduate needs plenty of mentorship at their first or first few jobs. That's not the same as training someone with no exposure to a discipline.
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.
Yes but it really depends on what you need.
If you only need coders for standard applications there likely won’t be much difference.
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.
Hiring is expensive, distracting and having an unfilled position can result in other staff leaving. No good company wants to leave a post unfilled. If you're capable and a good fit for the job nothing is going to stop a company hiring you. No matter what the advert says, if you can do the job and you want to work at the company just apply anyway.
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.
Last night I had the pleasure of meeting some of the students set to graduate from the Tech Elevator Cincinnati program. I emphasized that as someone hiring developers, I'm much more interested in how the applicant approaches solutions to problems presented in the interview than clever code. I'm more interested in the potential of a new hire that can work well with the existing team instead of a know it all.
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.
While I agree it's definitely something that should not go on a job posting, I can see what it stemmed from. And it's probably the fact that they did indeed give bootcamp grads a test.
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.
>I am willing to bet that many of them do not share her drive
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).
Is there a job shortage for devs? I am fairly certain many companies are hungry for devs, female especially. Businesses love claiming diversity, after all.
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.
Unrelated to bootcamps, but one thing really jumped out at me in the article. The author's discussion of BigO time:
"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.
> I know I suffer from the assumption that women don't know how to code.
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
>> 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.
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?
Because everyday millions and millions if not billions of transactions go on between humans of all genders and races, if your view was in the majority, then society would be different. You need to talk to someone about your world view and get help.
When you read my comments you have a set of assumptions that you have made about me. You cannot escape that. For one thing, you assume that I know English (which I do). Another thing you probably assume is that since I am on HN, I am a computer programmer. You assume that I know the word "transaction" since you use that word. You don't explain its meaning to me. Neither do you explain to me what a human is. You assume that I know what humans are. You assume that I am human, though you cannot see me. Assumptions are everywhere.
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.
> 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.
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'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.
It's too bad this got flagged. I think it could have good discussions.
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.
Agreed with most of what you said, especially that this would be a good discussion. My problem with filtering based on bootcamp training is that you occasionally find someone who has been programming their whole life (as a kid) an d finally decided to get a certificate. If there is one thing I've learned about interviewing, it's to not limit your options. Instead, talk to people for a few minutes on the phone and ask your own questions instead of looking at what someone put on a piece of paper about themselves. If you don't have time for that, outsource it to a recruiting firm who will also be good at finding diamonds in the rough.
54 comments
[ 2.8 ms ] story [ 129 ms ] threadWow, 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.
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.
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.
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.
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.
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.
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:
Is that x[e.field] is an allocation and takes O(n) time. So this is an O(n^2) loop, and you have saved nothing over this, even in theory So in this obvious case it takes infinite items in theory. Even that is a wrong prediction. (2) will also behave very differently depending on whether the VM is just starting up or has been running for a while. So in practice here's what's going to be faster: Why, in the beginning not doing the setup is just faster by itself. This lasts a long time because when the inner loop executes in cache and the hashtable copy does not fit in cache the loop is 100 times faster (on top of that ~100 times C acceleration). This means the loop stays fast for a long time.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.)
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.
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.
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).
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.
"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.
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.
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.
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.