
****** No Bootcamp Applicants ****** - CodeLikeAGirl
https://code.likeagirl.io/no-bootcamp-applicants-2374dea7d7ba
======
Barrin92
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.

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

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

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

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

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

Hence, it's good to keep Rob Pike's rules of programming into account:
[http://users.ece.utexas.edu/~adnan/pike.html](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.)

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

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

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

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

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

~~~
throwaway2016a
To be clear, I do not agree to filtering out bootcamp people.

~~~
tchaffee
You made that clear in your first post. I was just trying to add on to that.

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

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

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

~~~
monaghanboy
>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).

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

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

------
voltooid
Asking with honest curiosity, why is this post flagged? I mostly see civil
discussion.

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

~~~
JazCE
> 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

is not normal.

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

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

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

