I'm glad the "rigorous testing process" was mentioned. The facade of "we only hire superninja-kickass-hyperexperts and we will verify that you are such a programmer before we hire you" attracts a certain type of person, and intimidates another. And it may be that it intimidates more women than men.
But the article seems to glide past that and presents the idea that five years of experience might change someone's willingness to apply. And it probably will help, but that amount of experience is unlikely to change someone's basic perception of their ability to succeed in a high-stakes one-chance prove-yourself situation.
"And it may be that it intimidates more women than men."
I've been looking around for a developer recently, and in looking at the profiles of women vs. men at places like AngelList I noticed a few key differences in how they described themselves. We're talking about people with very similar academic backgrounds here with similar levels of experience.
Women would say things like "I worked on a team that did X," while men -- who obviously did the same kind of work -- would simply say "I did X." Women would highlight the cooperative nature of their work, while men would give the impression that they did it all themselves. In my experience the former is typically more honest, especially if you actually were working on a team or on a team-oriented college project.
Women also tend to highlight team-oriented and non-technical skills more than men in general, which to techie-minded hacker types gives the impression that they are not strong on the technical end.
I also noted my reaction to these differences. Introspecting, I noticed that I tended to assume that "being on a team" meant riding the coattails of the other team members. If I noted this bias in myself, it's probably pretty common.
I decided to try to de-program myself of this bias by thinking of all the counter-examples I've seen.
I do believe in the "10X programmer" -- for the simple reason that there are 10X everything elses. There are 10X athletes, 10X businesspeople/salespeople, 10X artists, 10X anythings. When we look for employees or contractors we are looking for that 10X standout, or at least someone who's going to grow into one. But being really good at something is not mutually exclusive with working on a team or highlighting non-technical skills, and the inverse is also not correlated. I've met plenty of monomaniacal "closet programmers" who really aren't any good. They sit alone stewing in their huge egos and churn out crap. (But then again I've met some who are. There does not seem to be a strong correlation.)
There's probably quite a few really talented female programmers out there who are being passed over because they don't conform to the "whip it out and let me measure it" customs of technical recruitment. I also suspect that this does drive women from the field.
I worked with a 10x developer once, he was awful and I couldn't stand to work with him. Although he could produce an insane amount of code and functionality his presence was like throwing a grenade into the middle of the dev team everyday. He left to take a job at google and the overall team productivity went up significantly. He basically did 10X individually,but took 11x away from the team. So team work is pretty darn important.
I've worked with 10x programmers, and while certainly a lot of their value is simply their ability to write code, they also have a lot of value because they help other people excel. The 10x programmers I've worked with are people who push for code reviews, better tools, proper testing, realistic timelines, good communication with clients, etc.
And in the long run, those programmers made the programmers around them better. A 10x programmer creates a lot of 2x-5x programmers. I'm maybe a 3x programmer and it's because a lot of 10x programmers have taken the time to help me get better.
> How to be a 10x engineer: Incur technical debt fast enough to appear 10x as productive as the ten engineers tasked with cleaning it up.
We have a guy in our onsite team that keeps making our user facing application suck with his changes one day and then fix those every other day. So lots of git commits but limited productivity in the team, and a very tough maintainence task for every developer in the team.
I think you're misunderstanding what "10x developer" is supposed to mean. The impression I've gotten is that they are considered to be 10 times as productive because of the work they don't do. They write code that has less bugs, is more scalable, requires less refactoring, is easier for other developers to understand, etc. You'd never see it in LOC or sprint points completed, but there'd be a noticeable difference of pace between a project of 10x devs and a project with 1x devs.
I wanted to reply to all the comments so I just decided to reply to my own comment. For those telling me I'm misinterpreting what a 10x dev is, I don't think a solid definition of the 10x developer actually exists it's mostly in the eye of the beholder.
I think it's mostly in what other people think of them especially that guy that hands out raises. So it's incredibly subjective.
I say a 10x developer is someone that can create features 10x faster than everyone else, regardless of their other skills.
To be clear my dream rockstart software engineer is not a 10x developer. They are 5x developer, a 5x Team player, 5x architect and 10x Mentor. So maybe we need a dictionary of terms around what people by various nicknames and concepts given to the various kinds of software developers.
I agree everyone has their own definition, but the one you are giving is a pointy-haired definition, where the only metric is LoC and a successful demo of some feature.
Even though it's hard to measure a lot of things like technical debt, architectural benefits, bugs, edge case handling, UX polish, teamwork, etc, it doesn't mean that you can reasonably get away with discounting those effects when you talk about 10x. The 10x is referring to productivity, which is implicitly a net measure (gross productivity is just activity, and no one willingly pays for that).
So yeah, you can be 10x in terms of cranking out working code a lot faster (rare), but if that is blowing other people up then it's not meaningful to say they are more productive, in fact it's extremely harmful to risk putting them on a pedestal like this in front of clueless management. For me, true 10x is more intangible than cranking out functionality, it's more about the ability to reconcile the details with the big picture, and zeroing in on solutions that solve the most problems and create the fewest. How this actually looks in practice varies from project to project, but I think it rarely correlates with sustaining a 200wpm typing speed for 8 hours a day.
impressmyself.co , It probably won't be up until next week sometime though. I have to figure how I want to write the blog post, and then actually do it.
Those exist too. It's possible to be really good at something but to be so awful at everything else that the net effect is zero to negative. But not all "10X developers" are assholes.
That may be a men/women thing, but I actually screen for that when I'm interviewing and significantly prefer to hire people that say "we did X" rather than "I did X". It's my job as an interviewer to figure out which person on that team you were, but if you describe your work as I I I I I and never We We We We, it is pretty telling.
It also goes for managing. If my team fucked something up, I say "I fucked up Y", even if it was a report of mine. If my team did something great, it's a "We did Z" even if I did it alone.
When you put it out that plainly, it sounds hokey and stupid. But trust me, over the long run those tiny things are the difference between a good company culture and a bad company culture.
It's interesting that you say your bias is toward perceiving someone self-reporting as working on a team as "everyone on the team did the work but me".
Does this result from primarily working alone, or have you just been granted license to be more autonomous than most coders I know? A lot of shops both employ pair programming and have a series of pairs working on one project, or have a t the very least a bunch of people working on different aspects of the project.
Of course this could be spun as "I did y for my project, x" but I'm curious as to why "As part of the team working on x project, I did y" sounds less like accomplishing something technical to you.
Say I had a project out of which I'm submitting 3-4 conference papers to various conferences for publication, working with my advisor and another student. Would it be better to say I did it all, or to be honest and say the other student did 1/3, I did 2/3, and my advisor helped shape our vision?
I felt the same as 'api' when he explained that and to me, it came from my bad experiences working on teams, in high school, where 1 or 2 people did all the work and the rest rode the coattails to an easy A.
Of course my experiences in high school shouldn't factor into my judgement of reading judging peoples capabilities (because chances are everyone worked on a team that did X). Something like that might just be a hidden cultural bias - I'm sure everyone has an experience where they forced to worked with others who didn't feel like pulling their weight - and its those negative experiences that shape our notions of what it means to work on a team, rather than the multitude of positive experiences we may have had.
I have often worked alone, but not always. I've never worked in a pair programming shop, and I would probably find it distracting for anything but debugging or syncing up. The trouble is that complex programming tasks usually have the nature where communicating the ideas takes longer than simply coding them. You'd spend all your time syncing state between you and the other person.
But I don't think this explains the bias. I'm not really sure where it comes from but I found it interesting.
I read a book about the development of writing in mesopotamia (http://www.amazon.com/gp/product/0674049683 , but I can't really recommend it as a general-interest book); it mentioned that a particular king had seen his city flourish under his rule and boasted accordingly, in the records we have, of how irrigation canals were dug and roads were built and generally a lot of great stuff happened on his watch.
In a parenthetical, it also noted that, as is typical for the records of the time, they actually attributed all these works to the king personally ("I dug canals in XX regions").
> Women would say things like "I worked on a team that did X," while men -- who obviously did the same kind of work -- would simply say "I did X.
I find this a very interesting fact, but I see a number of other possible explanations for "I do X":
- It is simply shorter. Men being used to more compact communication?
- It is also more boastful - perhaps men being used to market themselves more aggressively than women? Or, put in another words, having and/or presenting bigger egos in their CVs?
- Women being insecure about their personal contribution in X? Maybe the coattail-riding assumption is not always wrong.
In any case, I would withhold judgement before an interview.
There's lots of possibilities. It's really hard to tell whether any of these things are cultural or come from actual gender dimorphism (to use the technical biological term). Ultimately it doesn't matter if they are irrelevant to ability.
What I'm saying is that when we are evaluating peoples' abilities, we should take care to evaluate actual ability rather than unreliable proxies for ability. The latter are prejudices, basically, and they blind us to a lot of talent that might not fit those lazy filters.
I'm neither a "PC liberal" nor a conservative/reactionary on this issue. Liberals pretend differences in ability don't exist, while conservatives like to defend the accuracy of our "gut" prejudices and argue there's nothing wrong. IMHO equality of opportunity comes when people make an effort to look at actual ability as objectively as possible.
It's in your best interest as an employer to do this. Good people are very hard to find, and if you're running some kind of dumb ape-brain filter that excludes ~50% of the population from consideration you are handicapping your recruitment efforts pretty badly. Think like a human being.
I (male, for the record, but gender-specific behavior isn't my point here) used to write/say that I was "part of a team" that did X or "worked on a team" that did Y, but I stopped doing it for a couple reasons, the most prominent being that "worked on a team that..." is usually obvious given the context of the conversation and the scale of the work discussed. In those cases, explicitly mentioning it feels like you're going out of the way to distance yourself from the work and describe yourself as a bystander - someone who just happened to be on the team that did this great work.
Personally, I hate phrases like "I worked on a team that did X" because I can't tell what you did. Where you the lead, a junior, or did you get called in when everything exploded and saved the day?
I'd rather see "I did the Y on the team that did X" as it's more descriptive and leaves less to my imagination.
> " Women would highlight the cooperative nature of their work, while men would highlight that they did it all themselves. In my experience the latter is typically more honest, especially if you actually were working on a team or on a team-oriented college project.
Did you mean to say the former was more honest, i.e. that saying “we did X” is more honest than “I did X?"
It depends on the context of course. If it was your project alone, then you did it. If others contributed non-trivial amounts, it was a team effort. I noted that the males tended to bury that, while the females tended to highlight it.
I really want to hear what the individual contributed, though, and actually couldn't care less what their team did as a whole. I've heard way too many "we"s that were actually "they"s, while the subject was present, but not actually contributing that much. It's really easy for a bad developer to hide in a large team.
EDIT: and it's also easy for a good developer to get quagmired in a bad team! Just because the project as a whole didn't do much doesn't mean the individual is bad. So I still really only want to hear about the individual efforts.
This would be why I spend almost no effort on the interview process. I put people to work right away to force them to prove whether or not they can do the job.
Well, I suppose they could be subcontracting it out, but at that point, I don't care. The work is getting done and at a price I can manage.
Well I think the more honest part is I myself worked on part X and we the team created product Y made out these multiple parts. How big of a part you had does matter.
For example, I made the iOS UI part of this text chat app, and my team members created data models and networking code that I used to make the UI part. Another team member made the android part using the cross platform code and a bunch of others made the server part and so on. Together we made a text chat app pair.
> Women would say things like "I worked on a team that did X," while men -- who obviously did the same kind of work -- would simply say "I did X."
While this anecdote seems to match traditional gender narratives, I'm interested in how you knew the men "obviously did the same kind of work."
You observed that women were more likely than men to emphasize teamwork and not their individual contributions. It seems that there are two hypotheses which result from that:
1. Women are more likely to emphasize team aspects and de-emphasize their contribution (less narcissistic)
2. Women are less likely to individual contribute and more likely to rely on teams for projects (less independent)
"Women would say things like "I worked on a team that did X," while men -- who obviously did the same kind of work -- would simply say "I did X." Women would highlight the cooperative nature of their work, while men would give the impression that they did it all themselves."
Cannot emphasise this quote enough. It is the difference between, "We" and "I", the basis of any community where you put yourself second. It is also the essence of good leadership.
If you want a lone wolf programmer as a new-hire in a small startup, maybe this type isn't for you. As your company grows, the type of programmer described by @api above, the one who works in teams where your livelyhood and codebase is on the line, is the person I'd want to work with and for.
> Women would say things like "I worked on a team that did X," while men -- who obviously did the same kind of work -- would simply say "I did X."
Depending on what X is, and on context, it can be obvious that "worked on X" simply means that they worked on X, but that doesn't mean that others did not also work on it, with them. Especially if "X" is too big and complex for one person to do on ones own. In particular, researchers in CS (maybe coincidentally majority of men) tend to say that they "work on" or "are interested in" X, Y, Z - but that doesn't really mean that they don't collaborate or work with other people on those things. It's not exclusionary at all.
But this interpretation doesn't fit with the usual men-are-egotistical-narcissists-compared-to-women. So pay this comment no mind.
"But this interpretation doesn't fit with the usual men-are-egotistical-narcissists-compared-to-women. So pay this comment no mind."
I'm just reporting the patterns I saw. That's all.
I wouldn't say "egotistical narcissist," just that the culture probably holds out different behavioral expectations for men and women and that gives rise to differences in how people present themselves.
> I'm just reporting the patterns I saw. That's all.
Well let's not kid ourselves. :) If a pattern you happened to observe reflected poorly on women - like if you observed that many more of them were incompetent than men[1] - you wouldn't report on it here. Or else you would just get downvoted or ignored. Can you honestly object to that?
Casually reporting on something which shows women as a group (or subgroup, like in tech) is viewed at best as being in poor taste, or at worst as sexism or misogyny. And there are good arguments for calling it that. But do the same for men and it's just innocuous "observations".
[1] For the sake of the argument: totally hypothetical.
We (www.gapjumpers.me) are trying to solve the gender diversity issue in tech by using blind auditions as a first filter. Our data shows that blind auditions result in greater diversity numbers.
By using a technical challenge as the first step and fast forwarding people to an advanced interview stage, we're eliminating candidate reluctance and increasing transparency (the candidate interacts directly with the hiring manager through our platform).
In our experience, telling the candidate "Show us your skills, impress us, and you'll get an interview" is better than "Tune up your resume to pass every possible filter". Showing your skills early on also removes a lot of stress from the candidate and gives you something solid to talk about during the interview.
Uhm. I was hoping for something much more comprehensible and comprehensive than a series of blurbs and unlabeled pie charts. A statistical comparison of your cohort compared to the background population and relative performance is what interests me.
I want to know how your program does compared to a hypothetical ideal gender-bias-free hiring system. If what you present there is truly all that your data shows, I have some grave concerns about your company.
I wonder if you could also make the matching part of the process blind as well? That is, the article mentions that women might be less likely to apply to places like Fog Creek - but if you matched applicants to employers blindly both ways (blindly to them, of course, you the matcher would not be blind), so the applicants didn't know who they were interviewing for during the interview? Then developers with lower self-esteem but great skills might end up interviewing for high-end places, and not even be stressed during the interview, because they don't know who it's with.
I'd find this very interesting myself, although I'd have concerns about potential employers in some ways. As long as I was able to provide a list of employers I DON'T want to work for up front and have those auto-filtered from my blind interviews I'd be totally open to trying out this process through a recruitment firm. I personally tend to pick my employers broadly on three questions: 1) Are they doing something that's actually innovative? 2) Do they behave ethically in the marketplace towards their employers, vendors, and customers? 3) Is the position located somewhere that I'd be okay with living?
If the answer to any of those is "no", I won't even bother applying/interviewing and I automatically turn down recruiters from that company. #2 in particular is a big one, there are way too many businesses in the world from startups to big corps that behave unethically, and I refuse to be a part of it.
Being able to work with a recruiting platform where I can detail these qualifications up-front and trust that they'll be respected would give me the piece of mind to put myself in a situation where I'd be matched to an employer based on their needs and my qualifications without concern that I'd be getting screwed somehow.
This is an interesting approach. We will probably try it in the future but at the moment feedback says that candidates almost always want more information (more about the company, more about the people they'd be working with, more about the kind of work they'd be doing). But I definitely agree on how it might take the stress out of the process.
The only issue is that hiring and getting hired requires significant commitment on both ends and long term anonymity might not work really well under those conditions.
Our profile capture does not require applicants to include their demographic information, hence the only way we've been able to easily split by gender is by identifying their profile images and names.
Of course, outcomes have shown that racial diversity is also helped along. Our hypothesis is that if you work to remove bias through process there should be a measurable (even if it's small) change in diversity metrics.
It doesn't draw the connection directly, but part of the training program deals with technical interviews and getting the fellows more practice, and hopefully more comfort, with them. My guess is that once people have been through some mock interviews, the intimidation factor goes down quite a bit.
I'm glad the "rigorous testing process" was mentioned. The facade of "we only hire superninja-kickass-hyperexperts and we will verify that you are such a programmer before we hire you" attracts a certain type of person, and intimidates another.
Yup. And I've always suspect that this cant was ultimately something of a foil, and that the actual messages it's intended to send are of a rather different sort. To wit:
Internal: Hoo-ray for you! You made it through the gauntlet! Aren't you just swell and awesome!
External: You know you have to invest in us / buy our products because we only hire the top 0.001 percent! And we have a rigorously testing process (as verified by the magic of survivorship bias) to prove it!
>attracts a certain type of person, and intimidates another. And it may be that it intimidates more women than men.
This is classic horseshoe theory, where extremists on both ends of a spectrum actually wrap around and start to sound the same. In this case they both believe that women are delicate flowers who can't handle the pressure, stress, and competition of the working world like men can.
There's a difference between "lower self-confidence" and "can't handle pressure, stress, and competition". It's also possible that even women who have high self confidence in their abilities are less confident that they will be judged positively by others.
There's plenty of research to the effect that men will apply to a job if they meet 40% of the listed requirements, whereas women won't until they meet 90%. And when you don't meet someone's default expectations of what kind of person a "software developer" (or a "nurse" or a "CEO") is, you often have to work harder to prove that you are one.
But also, why does the working world have to be competitive rather than collaborative?
To me at least, what's intimidating about applying for a job described as Fog Creek's are isn't that they're competitive -- they don't say "you'll be in a knock-down drag-out competition to beat 100 other candidates". It's that the criteria for acceptance are high -- only those who have an extremely high opinion of their own abilities will consider themselves likely not only to meet those criteria but to be judged by others as meeting those criteria. And many people who are very capable are unlikely to judge themselves so favorably. Women in particular are socialized to underrate our own abilities and conditioned to expect our abilities to be underrated by others, especially in STEM fields.
Several people have already mentioned it here, but I'm also very pleased to read this line:
"Hall asked a simple question: Why didn't Chipps, a brilliant engineer, ever apply to work at Fog Creek? Chipps said she didn't think she would make it through their rigorous testing process."
I do think that the grueling and intimidating software interview process is a very serious problem in our field. This one sentence hints at the extent of the harm.
"I do think that the grueling and intimidating software interview process is a very serious problem in our field."
I'd have to agree. The interview process is irreducibly stressful, but that doesn't mean we have to go out of our way to make it worse. It isn't even good for hiring most men either, after all! It's just a bad idea.
I've personally had fairly good success hiring people who happen to be women, and I suspect a good part of that is that my interview attitude is that I'm there to find out what you can do, not to find out what you can't, which seems to be the unexamined default of a lot of interviewers. You don't start at "perfect" and get marks off for failure... you start at essentially zero and work your way up. "Starting at zero" may sound superficially harsh when I put it into English, but in practice this produces a much friendlier interview environment, I think, because we're discovering positive aspects instead of negative ones.
(Another reason to prefer this is that in practice this also helps avoid the problem of the senior candidate being thrown softballs, or the junior candidate being asked to design a cloud infrastructure. It really doesn't take that long for me to key in on where your most likely "knowledge frontier" is and probe for details there. As opposed to just going through a rote set of questions looking for demerits. It is a harder style of interviewing, though, precisely because you can't just go through a rote set of questions... even the standard question set I use has a lot of ways of approaching them and several "levels of detail" I can get into depending on experience and skill level.)
The end result is still, frankly, stressful. It's a big deal, and the interviewee would have to be outright irrational to forget that. But it helps if you as an interviewer remember that, too, and have some compassion.
> my interview attitude is that I'm there to find out what you can do, not to find out what you can't,
Have you ever considered trying to find out and confirm what the candidate has done in the past, instead of the almost impossible task of finding out what they "can do" in a few short hours? Barring some major new life issue, a developer's past performance is highly predictive of their future performance.
If I can, yes. But many interviewees are not prepared for that, and I've had to adapt to that.
If you are interviewing, please by all means bring samples of your work and be ready to discuss them, if you possibly can. But some people come from places where they can't talk about what they did (like, literally, Federal law in some cases), or for some other good reason can't really substantiate what they did.
You also have to account for the fact that a lot of the ways of finding out what they did in the past are somewhat unreliable. Many past employers have their own reasons for not being forthcoming or entirely truthful. The interviewee is incentivized to exaggerate their claims. In this context it's hard to get very much solid information of the type you're asking for.
My preference is to see past accomplishments, then use the interview to substantiate that they are indeed your accomplishments and you were not just generally in the area of accomplishments that happened to be occurring. But alas, that's not always an option.
That's what interviews for hardware engineers are like. I'm an embedded systems engineer, and as such about half my work is programming. I've only worked for companies that are primarily electronics manufacturers. I've hesitated to apply to companies that are more software focused largely because of my perception of their interview process.
Interviews for electronic engineers consist mostly of talking about projects the candidate has worked on (for young people these might be college and hobby projects). The interviewer's questions are things like "what did you consider the most difficult part of that project?" or "What tools did you use for that?" or "why did you do it that way and not this other way?" No one has ever asked me to design something on a whiteboard, nor would they dream of asking me to rattle off the pinout of some random microprocessor.
The software company interviews I hear about sound more like someone being tested to prove they aren't lying about their qualifications than like adults discussing a business deal.
What about developers with little experience, that come right out of school, or are applying for an internship position? Are you going to cut them out of the process? If so, are you okay with the fact that you'll often be missing out on getting an early lead on good junior developers? Good developers rarely kick around on the job market, and so it's often much more difficult to hire them when they've become more senior. Joel Spolsky's take:
I'm not suggesting to do this exclusively. By all means, hire promising devs out of college using the method the GP prefers.
I'm just suggesting that when an applicant like this exists before you, it makes more sense (assuming you're happy with their accomplishments) to confirm that these are indeed their accomplishments than to try to cram in some ad hoc heuristic for determining their range of skills in an hour or two.
And if my peers are any indication, the reason it's become so hard to hire senior devs is that no one wants to go through the headache of the interview process anymore once you've reached a moderately satisfactory job situation.
When I used to hire people, I focused more on their intelligence, their focus, and their motivation. Any idiot can google snippets of code or memorize answers to questions. What I wanted was someone that could handle learning what they don't know, motivate themselves to get the job done, and most of all, get the job done.
And you can't figure those things out just by looking at a resume or by quizzing them for hours until they break. You have to actually talk with them. Engage them in conversation. Learn who they are and how they fit into this field. Learn about their past experiences and their future goals. Then the question as to whether or not to hire them is easy.
Resumes are a starting point. Previous knowledge is a time-saver. Problem-solving and motivation is where its at.
*As a side note, most of my interviews were 30 minutes or less. I only regretted one hire, and I got rid of him pretty quickly.
Talk to them about school projects or classes. I recall one candidate was in a compiler class, and told me about the compiler s/he had working. I asked 'what's a recursive descent parser'. They didn't recognize the term. I asked what grammar the language had. They didn't know. Other's show excitement, talk about having had to study things on their own because it wasn't covered in class but they really wanted to learn it, and so on. You quickly get a sense of who has a fire burning and who is going through the motions.
It's tough though, because when you are a small company that expects developers to jump in and be productive, you do need some kind of process. That process can be referral based, in which case testing isn't as necessary because you can rely on past shared experience, but that obviously limits your talent pool.
When you are interacting with an unknown (or a less known) person, you have to have some kind of vetting process. And with a small company culture, typically false negatives are far less harmful than false positives.
You're making fair points. I think I understand the equation you're setting up here (harm of false positive vs harm of false negative, along with probabilities for each). I'm just starting to believe that the damage of so many false negatives to avoid the occasional false positive may be harming the industry more than we realize.
Let's not forget, we're an industry where employers very consistently claim a serious and economically harmful shortage of talented developers. At the same time, we're an industry that accepts an interview process they open acknowledge will result in the rejection of good candidates because they feel that the damage of a false positive is so high.
Is there a chance that there is a strong "negativity bias" at work here?
In other words, is it possible that the bad memories of a false positive is masking the thousand paper cuts that are inflicted on the high tech workforce though grueling interviews? What overall harm does it do to an industry when a programmer who would have been successful gets rejected from a promising job due to a poor performance on a one hour data structures problem at a white board? I think there's the harm you see, and then the harm you don't.
This one line suggests the harm may be serious and extensive. I'm not making any particular prescription here, I'm just saying that when developers experience repeated rejections due to repeated false negatives, this may be vastly more harmful in a global sense than people currently realize.
> I'm just starting to believe that the damage of so many false positives to avoid the occasional false negative may be harming the industry more than we realize.
I think you have "false positive" and "false negative" backwards, but I agree with your point. I have long thought that the industry systematically understates the damage of false negatives and overstates the damage of false positives.
If you are hiring, it fits one of two broad categories: catch as catch can, or specific need. In a catch as catch can situation, the "always hiring" mode, the company can afford to place more emphasis on minimizing the false positive rate at the expense of the false negative rate because the desire is to skim the cream off the top of the applicant pool as it comes to you. The company doesn't need new people per se; it finds slots for these highly-capable people somewhere in the company after the hire is made.
In the specific need situation, the company is hiring to fill a hole. Either work is not getting done, or other people are overburdened with the responsibilities this new hire will take on. In this case, every day that passes costs the company in some way. The cost of a false negative is related to the quality and size of the applicant pipeline. A false negative could add anywhere from a few days, if the company has a strong pipeline, to a few months, if the company has a weak pipeline, to the timeline for filling this position. The "false negatives are cheap" position comes from the former, but I would say that very few companies actually have an applicant pipeline that strong. Furthermore, if you can go months without filling a position and not suffer any ill effects, you need to ask yourself why you are looking for someone in the first place.
You're on to something here. There's the specific, need-based interview, and there's the "sure, we're always looking for talent" interview.
The latter can lead to an unintended problem. I once went on an interview where I was passed from room to room, on the hour, and taken through my technical paces each time. Each interview was intensely technical. If my interview had been my only exposure to the company (i.e., I hadn't gone to the site, read press releases and articles, and so forth), I would have no idea what the company does, other than that it seems to involve operations-research style math (optimization and stochastic processes), data structures and algorithms, and complex sql. I certainly would have no idea what they planned on having me do from a business point of view. I didn't get an offer (was busy, hadn't adequately refreshed my knowledge of tree traversal, markov chains, and linear optimization to immediate post-exam undergrad/grad levels), but I wasn't hot on the company anyway, because it left me with the impression that they wouldn't value my business input in any way.
So, why would they do this? Maybe they're just sort of looking generally for people. They figure, eh, if we find candidates who can rock an exam[1], sure, let's go ahead and make an offer, I'm sure we'll find something for them to do. Because their need isn't immediate, their standards (no false positives) will be set unusually high.
The unintended consequence is that yet another developer in this space is now reluctant to interview, because who wants to prepare for and re-take their undergraduate/graduate math and CS exams?
[1] At this point, I don't even think we should call this an interview, it was an exam that lasted longer than my MS graduate exams, with far less information about what would be tested.
I'm a big fan of looking at developers' github contributions. It's a good way to see that they can actually write code and it doesn't involve a high-pressure whiteboard test.
On the other hand, it can be a negative for somebody working for a company that discourages or forbids open sourcing their work. Or people who don't have free time to spend on FOSS projects.
Don't confuse activity for productivity. Most of the activities people engage in when searching for a new employee are complete wastes of time, at best.
I personally find it is net-better to stop wasting that time, just try people at essentially random, and get back to my own work.
Only if you have a policy of not having positions for Junior programmers.
Fog Creek has the same hypocrisy as any other company that demands X years of experience from applicants but consider it somebody else's problem how they get that.
As a business owner who is a developer and hires developers: getting my experience was my responsibility. It's now yours. And you won't do it on my dime.
I'm not in the business of using money to make developers. I'm in the business of using developers to make money. The jobs I offer are not because I want to give someone a job, they're because I want someone to come do a job for me.
Until very recently, the vast majority of Fog Creek's devs came through the internship program. Which is restricted to people who are going back to school afterwards (and, with a few exceptions, is only for undergrads).
Worse: they demand that you can code, and don't consider it their problem to teach you how to do that.
Anyway I thought it was well established that years of experience is a bullshit measurement anyway and you should just apply no matter what - worst thing happens, you end up getting hired.
Personally, I can handle all sorts of adversarial situations, but I've never done well with "rigorous" interviews. I think I was raised to be humble and that's built into my DNA, but the business world embraces overpromise/underdeliver.
At the same time, I've successfully managed large teams, budgets, interfaced with super-high level people and negotiated hard-nosed deals. I gotten myself into these roles by other means -- 90% of interviews that I have done have been formalities.
IMO, that's a symptom of a bigger problem, as what you do has more to do with where you are and who you know than any other factor.
Not all companies require them if you have decent experience. My friend interviewed with several companies and flat out told them "I don't do code tests anymore, my experience should speak for itself." Obviously your milage will vary but he ended up in a good position at a large well known company.
Edit: Also if you have a connection into the company that can vouch for you, that will work as well. The best coding test that can be administered is "yeah I've worked with this guy before and he's a good developer."
Actually I was more curious about the final year exam itself. Is this required in some schools? I have never heard of such a thing in colleges in the US.
I disagree. How many people actually do the bare minimum and work their way through Cracking the Code Interview, and make sure they know all of the material covered by those questions? I think having that would do a long way towards proving oneself in the tech interviews.
I applied for a job at Fog Creek Software in 2012 where I was accepted for an internship, and I would have to say the application process was difficult, but fair. I was told that there were hundreds of applicants, so being one of five interns selected seemed rather prestigious at the time, but it was still just an opportunity to work on my skills as a developer.
I don't think there is anything that would preclude women from getting technical jobs at a company like Fog Creek except maybe, as was said in the article, a self-selecting attitude. These companies are looking for well-rounded individuals and people who are competent with their skills. It's nothing beyond impossibility to get a job there, it just takes determination.
I have a very small consulting company. Both of my employees right now were non-traditional students when they finished their CS degrees. Actually, I'm not even sure the one guy has finished his degree yet. Regardless, neither of them had their degrees when they started working for me.
And honestly, I didn't really even know. I never asked them for a resume and they never provided one.
I don't really test the people I hire. I get to know them on a personal level. I meet them at parties, at meetups, conferences, etc. I then ask if they'd like to make a little side money with a freelance gig. We talk about the work, and if the person says they can do it, I give them a task. A real task, it goes right into the project I'm working on. It usually takes about a week or two.
And if they do a good job, I ask them to do more. If they don't, I pay them for the work they did, thank them, and don't mention they were ever interviewing for a more long-term relationship.
This has been so incredibly much better of an experience than the hiring processes I was involved with as a working stiff. Resumes that don't say shit. Stupidly simplistic coding tests. Interviewing anxiety. All of it, a nightmare.
And it didn't seem to make any difference. We would put more and more effort into hiring, to the point I was spending 10 to 15 hours interviewing and reviewing candidates a week, for weeks on end. It was having a detrimental impact on my performance, without any correlated impact on the performance of the people we hired.
So when I went independent, I decided that, if the results are really, actually random, then that means the inputs have no impact. So I threw away the interviewing process. I just ask people, "can you do this job"?
And really, I don't need to know anything else. That's what it all boils down to. They can lie on their resume just as much as they can lie to the question. They can cram on interview questions the night before. They can be really good at regurgitating academic theory but complete crap at thinking creatively. So I just ask, "can you do this job?"
I think this method doesn't work in all situations. For example in embedded programming. First there are not many of those who actually work in this field so unlikely to just meet up with them. Most are stabily employed. Secondly, there is lots of proprietary hardware and knowledge. Third, hard to work on a trial job when you are already working. Lastly there are a good number of people who are just not skilled enough and will waste your time during the trial period.
Actually, one of them does do some embedded programming for me.
Granted, my sample size is small, but traditional hiring practices are completely ineffective, so you shouldn't waste your time thinking you have any influence over the process.
There is a war for Women Dev's in silicon valley. Google's HR head mentioned in a podcast that they are simply poaching female devs' from smaller players to get their diversity numbers up. This puts smaller players at a major disadvantage as VC's have started tying their funding with diversity numbers. There is no way a startup can compete directly with Goog for the female dev's who are in major short supply.
This diversity madness is putting SV at a major disadvantage.
If VC do anything but focus on getting investment in the best companies they are not fulfilling their fiduciary duty to their investors - even if that anything is saving starving children in Africa.
I've worked for a company that claimed they did and it was always talked about internally in their "look how great our culture is" corporate-speak. Some developers even had the title of "mentor," but there wasn't any actual time allocated for it and no one ever took it seriously. In my entire time there I never met with my "mentor."
I'd be okay if it just said "usability testing". In my company that's just a part of the testing phase. But no way I'm just going to grab someone walking down the hall. I assume people are busy enough.
Is this meant to be taken literally? Fog Creek companies work remotely. How would you even physically grab someone in the hallway? As for how we do internal testing, we simply ask around on Slack and get a solid group of people to test for us before moving forward. Works out great.
I agree that lack of gender diversity in tech is an obvious problem, and I laud Fog Creek for trying to address this problem.
However, I'd like to strongly emphasis the fact that one of the main problems Fog Creek identified as hindering the most talented female developers from applying to Fog Creek, is also a huge problem that prevents many of the most talented male developers from applying to Fog Creek. Ironically, these companies, with their legendarily difficult and arduous application processes, are selecting for mediocre developers:
1) We all know that the Dunning-Kruger effect is real: there's an abundance of quantified and repeatable psychological research that demonstrates that the least skilled individuals are on average the most likely to estimate their skill to be above average. Likewise, the most skilled individuals are the most cautious in estimating their skill level.
So who applies for more of these types of jobs? Well, based on what I've heard, Google, Fog Creek, and many other top employers receive a huge number of grossly unqualified applicants. And while I'm sure they'd like to think they're getting the majority of their desired candidate pool to apply, research on Dunning-Kruger, as well as anecdotes like the one on the article, all suggest that's probably not the case.
This isn't the first time I've read about a top employer asking a highly-desired employee why they'd never applied in the past, and receiving as an answer, "oh, I didn't think I'd make it through your interview process". (btw, I love watching these kinds of interactions)
2) The most qualified developers can make a nice consultant salary without ever having to go through the headache of a demeaning 5-day interview process that often treats developers like disposable commodities. Why would you want to subject yourself to that kind of process if you're making $100,000-200,000 a year as a contract software dev (which is the range my colleagues working contract tend to make, depending on their hours and expertise)? So whenever I get an email from employers like Facebook, I say thanks but no thanks.
This is not to say that these employers never get highly-skilled employees. That's obviously not the case. But they get a very specific type of highly-skilled applicant: from top CS departments, coming right out of college. They're much less likely to get a highly-skilled dev to apply who has taken an alternate route to the top of his or her profession.
So what happens on average? "Top" employers like Google, Facebook, and smaller "desirable" employers like Fog Creek, effectively scare off a large number of the devs they want the most, both male and female. And they simultaneously attract a large number of unqualified applicants.
Yet again I ask: maybe the software developer interview process is completely broken? Are employers in enough pain yet that they're willing to revisit their hiring process? Or does it need to get worse?
> "oh, I didn't think I'd make it through your interview process".
I can attest to that. I was a contractor for Google for several years. I built all of their election results and voter information maps for the 2008-2012 US elections. I also did results maps for a number of international elections, both on my own and working with local teams, along with various special mapping and visualization projects.
The maps were very popular and people in multiple teams at Google really liked my work.
Of course it occurred to me several times that I ought to apply for a full-time job there, and every time I thought, "Naw, I'd never make it through a Google interview process."
This, after years of doing successful, highly visible work for them!
This isn't the first time I've read about a top employer asking a highly-desired employee why they'd never applied in the past, and receiving as an answer, "oh, I didn't think I'd make it through your interview process"
Exactly. And to someone who is already gainfully employed elsewhere, the opportunity cost of going through an interview gauntlet--which often consists of one or more full days of intense testing, and many more days of practice to prepare for that testing--is very real and daunting. So they will naturally tend to attract fresh college graduates who have nothing to lose and can afford to make such a huge time investment in the interview process for a particular prospective employer.
You are wrong about the Dunning-Kruger effect - there is not a negative correlation between perceived and actual ability, just a weaker positive correlation than you might expect. There's plenty of debate about the causes of the effect in the original Dunning-Kruger paper. Moreover, if you look at the actual paper (rather than exaggerated retellings of it), you will see that perceived ability is actually positively correlated with actual ability: most people tend to think that they're above-average - the bottom quartile tends to think that they're in to 50th to 60th percentiles, while more able people tend to think they're in the 70th to 80th percentiles.
Also, $100,000-200,000 a year is the range you'd make at those companies and have more job security and income consistency, so I'm not sure what your point is.
I regret my initial phrasing about Dunning-Kruger, which was incorrect as you have pointed out (and as I conceded below some 3 hours before you wrote your rebuttal).
Also, my point is that if I'm making $100-$200,000 and am happy with my situation, particularly when I live in a lower cost area than the Bay Area, then I am much less likely to put myself through the pain of one of these interview processes. Unlike lots of workers, software devs actually have a choice.
It's not a 5 day process. This is the standard bay area interview process:
1. 15 minute recruiter call
2. 1 hour remote screener interview
3. 4-6 45m-1hr onsite interviews. They can be done all on one day or possibly split up if your local.
4. Wait 1 day to a couple of weeks to get an offer or a rejection.
The real pain in the ass part is the onsite one. But that is 1 day, not a week. And because they go for high false negative rates, and you need multiple offers for higher salaries, you need to do onsites at multiple places.
It's a provocative thesis that Fog Creek hires mediocre developers. The evidence of their products suggests otherwise.
Of course as Atwood's friend Scott says, "We're all amateurs," so perhaps Fog Creek just hires the less mediocre on an absolute rather than relative scale.
This is exactly the thesis. And by the same thesis, if Fog Creek's ability to correctly identity high-quality applicants remains at a constant rate, and the share of qualified devs grows smaller, then Fog Creek will hire more and more mediocre devs.
Does it? I don't know a single person who uses any of their products. And I don't think it is plausible that the best devs in the world are flocking to work on a website for project managers.
Oh. Well, in my defense that was pretty unlikely. Hacker news search shows that it's been mentioned in the title of 475 stories, at least 25 of which hit the front page.
Well, we've still got Stack Exchange. Surely you've heard of that?
Having listened to nearly all the StackOverflow/StackExchange podcasts, there's as much Spolsky as Atwood in StackExchange. Spolsky was the grisled veteran when it came to building products and companies. Atwood more the tech hotshot.
I think the Dunning-Kruger thing is a nice idea but it's immediately ruined once you become aware of it, like a Heisenberg uncertainty sort of thing.
I used to think I was crap, but Dunning-Kruger, so I must be great.
I used to think I was great, but Dunning-Kruger, so I must be crap.
It just seems a bit trite to base any real world conclusions or behaviour off of.
I agree that the interview process is broken. The reason I wouldn't apply to Google/Facebook/Fog Creek is personal and nothing to do with their interview process.
> I think the Dunning-Kruger thing is a nice idea but it's immediately ruined once you become aware of it, like a Heisenberg uncertainty sort of thing.
Not at all! You're being too binary with it. Dunning-Kruger is about the relationship between discernment and capability. In particular, it's saying discernment drives capability. A great way of applying it is this Ira Glass quote:
Basically, the way I apply it is to say that if I can tell that my work isn't as good as I want it to be, that's ok: I have to use that as fuel to improve. And if I'm dealing with something where my work looks perfect to me, it's time to up my discernment.
In hiring, the way I apply it is to avoid listening much to self-assessment and related measures of competence (e.g., confidence). Instead, I go for demonstrations of competence, like short essay answers instead of cover letters, or pair programming interviews [1] over "tell me about a time when" discussions.
I like that Ira Glass quote, maybe some day I'll get there.
I think you are just positively improving your work, I don't think what you are saying is an application of Dunning-Kruger. Why in the first instance do you give your negative assessment credence, and have doubts about your positive assessment in the second?
Dunning-Kruger says both assessments are likely to be wrong, and in both cases you are striving to improve - so Dunning-Kruger has little to do with it.
In fact you could go further in a "worse is better" sense and say your striving to improve one thing is letting down something else you could be paying attention to.
Incompetent people think they're doing fine because they can't tell the difference between good and bad work. Highly competent people, readily seeing their own flaws, think they don't do as well as they are doing. (At least until you have them grade a bunch of other work, at which point they are better calibrated.) Competent people are competent because their metacognitive ability, their ability to tell good work from bad, drives them forward.
So basically, if I already can see the problems in my work, then my metacognitive ability is sufficient to drive improvement. When I improve enough that my work looks fine to me, further improvement is prevented because I literally can't tell whether changes I make are better or worse. There, the path to improvement is to improve metacognition.
As to the latter, my approach may be common sense, but it is not in fact common. Last I was interviewing developers, most people had never done a pair programming interview before. The default is talk-talk interviews. I'm sure some people did it the other way, of course: science frequently trails practice. But the Dunning-Kruger paper in specific is what convinced me that self-assessments were at best highly unreliable and at worst thoroughly misleading.
haven't read it thanks. are you saying the paper is about how one strives to improve? - because it's not titled that. the title is pretty clear. so is the abstract.
i think we agree that self assessments aren't worth much.
i think our disagreement stems from me applying it from a neutral ability perspective and you applying it to your own self assessment, where you don't question your basic competency.
> haven't read it thanks. are you saying the paper is about how one strives to improve? - because it's not titled that. the title is pretty clear. so is the abstract.
I am not. You didn't see how one could usefully apply their work. I'm explaining how I have applied it. You asked "Why in the first instance do you give your negative assessment credence, and have doubts about your positive assessment in the second?" When I say, "It's about how one strives to improve," I am answering your question.
> i think our disagreement stems from me applying it from a neutral ability perspective and you applying it to your own self assessment, where you don't question your basic competency.
Not at all. If for X I am a person of low ability, then I am likely to perceive myself as doing pretty well at X because I cannot see the flaws in my work. So if I'm at a state where my work looks good to me, the thing to do is, as I said, to improve my discernment until I can see flaws in my work. Then I can work to improve, increasing my competency.
This strategy works no matter what you relative competence is. And note that relative competence is distinct from absolute competence. Even people in the top quartile of a given sample can keep improving, and I believe Glass's quote helps explain why: their taste is still ahead of their skill, which if they keep practicing yields increased absolute competence.
I initially stated that you are just doing self improvement and dunning kruger isn't informing it.
you haven't said anything that disagrees with what i said, neither does the paper. at best you are applying half of it, the positive side. cherry picking?
if you're competent and you assess your work and it appears to be bad, then dunning-kruger says that it is not as bad as you think.
if you're incompetent and you assess your work and it appears to be good, then dunning-kruger says you don't have the competence to make that assessment and it's probably not good work.
if you had somebody competent in to assess your work instead of you, then that would probably be a more accurate application of it.
sure self improvement works, but self assessment doesn't really and that's the main take away.
I'll try one more time to get my point across. I agree with this:
> if you're incompetent and you assess your work and it appears to be good, then dunning-kruger says you don't have the competence to make that assessment and it's probably not good work.
Definitely. Ergo, if my work looks good to me, I should not assume that it is. Instead, I should look to improve my ability to evaluate the work. (What D+K call metacognition.) One way to do that, of course, is to have other people evaluate my work and tell me what they see. But there are plenty of others.
> if you're competent and you assess your work and it appears to be bad, then dunning-kruger says that it is not as bad as you think.
Exactly. Therefore, I should not be discouraged, but instead focus on upping my game to the level of my taste.
your overly positive outlook means you are either deliberately ignoring or unable to see the other side of it, and so there's no point in our continuing this conversation.
you've stated your position over and over, i've reworded mine, no progress will be made.
> Exactly. Therefore, I should not be discouraged, but instead focus on upping my game to the level of my taste.
it doesn't mean you should do anything. there's no need for this self improvement. the self improvement tactics are not informed by dunning kruger. they are not an application of dunning kruger.
in the absence of dunning kruger if you run with a self improvement mentality the input, action and outcome are the exact same. your behaviour is not informed by it. if you weren't self improving before dunning kruger, then you might be on to something - but i'm certain that wasn't the case.
in fact you are in danger of spending too much time on the improvement, whereas dunning kruger could be telling you, as you are competent "it's good enough".
I suggest going with either "there is no point in continuing" or "I will repeat again my possibly mistaken notion about why I think you're wrong." Because doing both makes you look like somebody who cares more about "winning" than having an actual discussion where people learn things. That's certainly the feeling I'm leaving with.
I believe your interpretation of the Dunning-Kruger effect is slightly wrong. The effect is not that the least skilled estimate their skill to be above average. The effect is that the least skilled tend to overestimate their skill level greater than those with higher skill levels. Also, those at the highest tend to overestimate the least (and indeed often times underestimate).
I don't know about D-K and mediocre developers, but I do know that those coming out on top of any test only proves one thing: that you are good at the test.
Let's say for argument's sake that the test is accurate (it flawlessly measures what its creators intended to measure.) This still doesn't mean that those who score highest are the "best." It only indicates congruence with the test designers.
The fact that Fog Creek has 0% gender diversity is evidence of this and indicates a underlying lack of diversity in many areas. So the question remains "Is a company that is an echo chamber full of mini-mes superior to one with a variety of opinions, habits, thinking styles, and working practices?"
I don't know the answer, but I think it's a good question.
If I understand what you are saying, we can look at the results of an interview test and say, “this test has few or no false-positives,” meaning that everyone who passes the test is competent.
But the way that the industry is set up, we have very little knowledge of whether the test produces false negatives, meaning we don’t know how many of the people who failed the test turn out to be successful or even spectacular somewhere else.
> The fact that Fog Creek has 0% gender diversity is evidence of this
No it's not. Do the math - at the rate of women in the application pool, and the total number of devs Fog Creek has ever hired, it would actually be fairly surprising if they'd ever hired a woman. The internship program, on the other hand (larger sample size) runs at more or less the expected rate, if memory serves.
This seems to make it pretty clear that the applicant pool is the problem, no?
When I applied at Fog Creek, I asked about diversity in the workplace and got what I considered to be a hasty, defensive, almost-canned response.
Prior to their jarring, incongruous answer, I was worried I was not good enough at software development to get the job. Afterward, I suspected it was just another "cultural fit" thing. They did use videoconferencing in the interview process, if I recall correctly. I thought at the time that maybe age discrimination could have been a factor, or regionalism.
Of course, Fog Creek, just like everyone else I have ever interviewed with, declined to give any sort of meaningful feedback afterward. "No, you were great, really; we just didn't pick you. No, we won't say why."
Not knowing any of the real reasons why I didn't make the cut, I am free to imagine any stupid, bogus reason that I can rationalize to myself. The only reason I would really accept with finality, in a way that wouldn't diminish my image of the company, is "we don't think your software skills are good enough to work here." But they very carefully implied that was not the reason. So my image of the company is diminished.
And a lengthy and arduous screening process only makes it more frustrating when the company won't provide any useful feedback.
I guess that sword swings both ways. They also don't know why they don't get more female applicants. I must admit feeling a little schadenfreude over that. It's mean and petty, of course, but I still feel it.
How about "Your software skills were great, but so-and-so's were better"? Of course, not knowing you and not working at Fog Creek, there's no way to know if that was the actual reason or not - but I would think it would be an acceptable reason.
Something I've realized since ending up on the hiring side of things is that there's a bit of a mismatch between how candidates and companies see the hiring process. As a candidate applying for jobs, I used to think I was applying to "the company" as an entity, and I was either good enough or I wasn't. The company, however, sees its candidates as applying for a specific position - like college admissions, there may be more qualified applicants than spots the budget allows for - especially at a place like Fog Creek.
(And, anecdotally, I am female and many years ago applied to Fog Creek for an internship. I didn't get it, but I enjoyed the interview process - it was one of the more interesting and challenging technical interviews I've done.)
I have heard that before, actually. It doesn't help if they won't tell you who they hired, and why they were better. The fact that they picked someone "better" is obvious if they picked someone at all, and it wasn't you.
Also, when I hear that particular line, I follow up with "I'm glad you were able to find someone you like. Will you keep me in mind the next time you're hiring?" If I get a response at all, it is something noncommittal, like "We keep all applications for a minimum of six months."
Perhaps companies should not focus so narrowly on the current position. I have applied multiple times to the same companies for different positions, provided my experience with them remains positive.
But if, for instance, a company like SAIC schedules an interview with me on a military base, sends an escort to the gate to bring me to the work site, and only then tells me that no one is available to interview me that day, because the supervisors are all halfway across the country, that company lands itself on my blacklist. Later experiences with employees of that company moved them to my permanent, public blacklist. Not only will I not apply for any of their positions, but if they appeared on my doorstep with an offer letter in hand, I'd order them off the property. And I would recommend that everyone else do the same, for both SAIC and for spinoff spawn Leidos. They are the sole reason why I ask "Who's the prime contractor?" whenever I interview with a contracting company.
When you create an energy potential by posting an opening, candidate-anticandidate pairs don't pop into existence to interview with you and then self-annihilate after you reject them. Actual, persistent people stick around, remember how you treated them, and talk to each other about their experiences. They stay in the industry, and may one day be customers or competitors.
As it happens, Fog Creek is not on my blacklist, either temporarily or permanently. But I do feel like their interview process would be a waste of my time if I had to endure it again from the beginning, and I don't expect them to ever pick me up again from where we left off. So I ignore their job postings now. It won't hurt them any, because they get plenty of candidates anyway.
But it doesn't surprise me at all that anyone who doesn't believe that they are good enough to top the 99 other people all applying for the same position wouldn't bother investing all that energy to compete, especially when that won't help them in their search if they fail. With no feedback, no referrals, and no helpful suggestions, it really is a lot of effort for a high probability of no reward whatsoever.
There may be something embedded in our tribal caveman brains that makes high-risk behaviors more attractive to men than to women. If so, Fog Creek might be able to attract more female applicants just by guaranteeing something of value at the end of the interview process, regardless of whether the candidate is selected for the next round.
You might be right on point 1, but it doesn't offer an alternative. If you state that you take mediocre developers, better developers won't want to work there either.
Point 2 is also sort of moot; if people can make it on their own in the contract world, then it doesn't really matter what hyperbolized interview process (5-days? What?) stands between them and employment. I'm in the same boat, I work contract now and don't want to go back. The interview process has nothing to do with it.
I think you're far from concluding that the process is broken, though. Some companies may want to hire top CS grads straight out of college. In fact, a small company could probably fill their ranks through that alone.
I've been a programmer for 20+ years. For the longest time I didn't see any discrimination in tech, probably because everybody I worked with was also a young white guy.
Except those over the hill freaks with their comb overs and sandals with socks. Fortunately their skill sets were rapidly obsolete, so we got rid of them.
On the other hand, my wife (a senior Oracle DBA with close to 20 years of experience) sees it on a regular basis. It's disheartening to hear her talk about it because I realize I'm guilty of many of the same behaviours.
I guess I could try to protect my ego and claim it's not sexism, but that's not who I want to be. I don't want to be the guy denying something I know to be true.
I went into an interview a couple of years ago and realized I was about 20 years older than everybody in the company. I don't have a comb over and I don't wear socks with sandals, but it was pretty obvious I was too old to work there. That's the day I realized my job opportunities are becoming limited. I should have seen it coming.
Hmm, maybe it's possible women don't want to be in tech because of the sexism they face.
"but it was pretty obvious I was too old to work there"
Who said that? Did they say that to you? If they did that was definitely wrong. However it sounds more like you imposed that criteria on yourself, and then attribute the blame to them.
If gender diversity in tech is a good thing, why not age diversity? Sounds like they needed you there.
I certainly didn't impose that criteria. I wanted the job. I certainly had the experience they were looking for.
And no, nobody came out and said I was too old. They just reacted like I used to react when old people told me they understood computers. Pleasant, but patronizing. How could an old guy possibly handle any modern technology when he's got COBOL and FORTRAN on his resume?
Discrimination is rarely blatant. I'd guess that most people are never aware they're doing it. That doesn't mean it's not happening.
Well for starters, COBOL and FORTRAN are effectively ancient technologies are far as much of modern business programming is concerned. I would omit them from your resume. State them for interest sake only.
Also they are not a charity organization, the business goal is to get value out of you. Perhaps you did not demonstrate sufficient value, or seemed out of touch with current technology. I have found that programmers are a fairly meritocratic group of people, but you do have to stay up to date with tech, and that is a battle that gets harder and harder as you age.
but you do have to stay up to date with tech, and that is a battle that gets harder and harder as you age.
Wait what? That right there is blatant age-ism.
You know what helps learn new technology? When it's the same shit we did 15 years ago repackaged. WSDL is coming back around right now, just in JSON or Protobuf form. Don't you think mobile apps that have to sync with the server are a lot like server/client apps from the 90s?
To think that it's hard to pickup a new language just because you are 50 is really missing the forest for the trees of what it means to be a software engineer.
I think his point is more related to the learning curve.
If you're in your fifties it doesn't mean that you are stupid but it does mean that you're going to have to learn a lot of technologies from the recruiting company's stack.
Now if they can find someone that already know's them, their return on investment will be faster and safer.
The older developer will also most likely not program on his free time for family reasons or because he has more interesting hobbies.
Now this is controversial but I still would say that this is career / life choice which means that not having a very sexy resume won't get you everywhere no matter what your experience is.
This of course sounds very "hipsterish" but if you loot at the kinds of companies that are talked about here (start-ups and ex-startups that grew), it does make financial sense.
I'm not a psychologist but I would also wager that age gap is lowering team performance due to a lesser bond / closeness between the members.
I tried to formulate a response to it as well, but it was impossible to even figure out where to begin. I'm thankful I'm at a company that proves all of his assumptions wrong.
Fortran, while it might be ancient in computing terms, is still an actively-developed language[1] with multiple open-source and commercial compilers. I started writing Fortran professionally when I was 26, nine years ago. In certain scientific realms it is still used heavily, and it generally still kicks everything else's ass at linear algebra.
Kind of a tangent, but I have a soft spot for that language.
[1] Most recent standards rev was 2008, current draft standard slated for release in 2016.
Fortran is not used at most businesses. I doubt Fortran is used much anywhere outside of possibly engineering. Even then Engineers probably use some type of AutoCad like software that does modelling, and therefore nobody needs to know FOrtran anyway.
Engineer here. I work at a large industrial plant Fortran is used quite a bit. We have numerical simulation code which runs and feeds back into our operating process written in Fortran (mostly Thermodynamics and Chemical kinetic's simulations). Plant Operators make descions based on the output of Fortran models all without knowing or caring that the things are written in Fortran.
You can trace the herritage of the code back to the 80's but it has been more or less constantly maintained since then there is a lot of company IP wrapped up in the code. You certainly don't need to know Fortran to use or understand the models (it's wrapped in a 'modernish' C++ GUI) but the engineers working on improvements to the backend definately need to know Fortran.
I suspect there is a lot of reasons for the prevalence of Fortran in Engineering code. Industrial plants tends to operate continously you can't exactly replace all the infrastructure without large downtime. A large part of our plant was built in 1996, so the technology is very much what you'd expect from that era (RS/6000 Unix boxes everywhere in the control system). The Libraies and compilers etc all have to link against that vintage. It's not slated to get upgraded until 2018 and we will probably try to push that as far back as we can. When the upgrade happens I suspect we will be on Wintel (and in another 20 years that will probably be just as outdated).
The other reason for Fortran is that Engineering processes tend to be stable. A chemical reaction does not change so once some code is written and it works very low incentive to replace it. At my plant our models were first written in the 80's (when personal computers began to become ubiquitous) by senior engineers in the company - these were guys who grew up in the 70's and were raised on Fortran. Eventually the code was handed to the junior engineers to maintain. The juniors passed up the ranks to become seniors and when it came time to write the next generation of models "I'll base it on this existing Fortran Model which I know inside out and works really well" became the mantra and so Fortran become self perpetuating and entrenched across the industry. If it had been a decade later would probably have been C
> Women can do whatever they want to do, if they aren't in tech, they probably don't want to be there.
This is so far from the lived reality of women in tech or any of the data on hiring that you should be embarrassed to open your mouth.
On HN most people get that before opining on the merits of functional programming, they should have tried it. Or at the very least spent a fair bit of time reading about what people who have tried it see as the pluses and minuses. But somehow we get to questions of discrimination in tech, an article can't be up for 10 minutes before somebody feels free to opine based on no knowledge whatsoever.
I find it maddening. Partly because so many of these people seem to think it's somebody else's job to argue them into an understanding. (Rather than, say, their responsibility to do a Google search and read for a whole hour.) And partly because it traps these discussions at a level of "let's explain Discrimination 101" over and over and over.
But to answer your direct point: your hypothesis that "people do what they want to do" is obviously worthless when you look at actual data on what people do. Consider this graph, for example:
By your interpretation, in 1965, women wanted to be lawyers at 1/10th the rate that men did. But 40 years later women suddenly wanted to be lawyers a lot more. Why? Well, who can know what people want? They just want things. Or they don't. But it definitely, positively, absolutely couldn't have anything to do with the millennia of structural oppression of women or the dramatic changes over the last century in the status and legal rights of women. Nope! Not a thing.
It's ridiculous. Which you would know if you had bothered to put forth any effort. Now ask yourself: why didn't you?
Are you aware that you have not only failed to educate people, but you have only taught them that voicing an opinion that you don't agree with will bring disproportionately furious rebuke?
A serious question: do you think you will change how people behave by acting in this way?
I think the implied ground for your comment is that everybody's opinion is valuable and should be heard. So let me sketch my quick hierarchy of opinions here.
First, there are informed opinions versus uninformed ones. I am happy to talk with people who have informed opinions even when we disagree.
Next, there are naively uninformed opinions versus lazily or willfully uninformed opinions. For example, suppose somebody says, "Hey, I'm a high school student thinking of going into tech, and don't understand all this recent discussion about diversity. Can somebody help me out?" I am also very happy to talk with that person; there's no shame in being honestly ignorant but eager to learn. (Most of the time I'm even glad to give the lazy or mildly willful people a chance, although my experience suggests it rarely helps, at least right away.)
Beneath that we have willfully uninformed opinions presented in a way that actively harms the discussion. When somebody doesn't know what's going on, doesn't want to, and perhaps doesn't even want people talking about the topic, then yes, I actually don't want them in this discussion right now.
For the record I believe my reply is proportionately angry. It's a serious problem that harms both the field and actual individuals. We have been discussing it for decades. (Note also that quibbling about tone itself has a long history in these discussions: http://geekfeminism.wikia.com/wiki/Tone_argument )
So, serious answer: Yes I hope that a) I will reduce the frequency with which the last category of opinion is deployed to halt or degrade useful discussion, b) more people will be able to recognize a particular dumb argument as a dumb argument, and c) some of the lazily or willfully ignorant will actually try to understand the context before opining.
So, serious response: you are perpetuating the notion that it's acceptable to attempt to silence an opinion that you disagree with sufficiently. Is this the norm you wish to encourage? That it's OK to exclude people who don't think sufficiently like you?
Please, do not attempt to answer. I would like you to contemplate this. It's not senseless navel-gazing and is quite significant.
Also, tone matters because we're dealing with real human beings who respond to tone as well as substance. To say "That's a tone argument!" as a form of dismissal is to miss that the whole point is supposed to be persuasion.
I like your presumption that I couldn't possibly have thought of this before. As well as your ridiculous assumed superiority in ordering me not to "attempt" to answer. Gosh golly, anon, please point out more of what's truly significant. Without you I would be lost.
I think any opinion is welcome in honest dialog between people who are pursuing sincere understanding and are acting with sufficient empathy toward all participants. I also think that is about 1% of public discussion, and that it takes an immense amount of effort to create the proper preconditions for that.
Outside of that, no, I think there are plenty of opinions that merit social opprobrium for their straightforward expression. And I'd bet you do, too. If you can't name 5 in the next 30 seconds, you aren't trying. Speech has consequences. And I think it has to. [1]
I also think that regardless of opinion, there are ways to engage in dialog that are so harmful that they should be called out. And you think that too, or you wouldn't be giving me your more-in-sorrow, think-about-what-you've-done routine. The only difference is that we have different standards for what merits objection.
I agree that tone matters, which is why I chose the tone I did. If your goal is to personally persuade every sexist goof to come to a considered realization that they have made a deep mistake, then godspeed. (If that is your goal, though then your recent comments history doesn't show you working very hard at that.)
But that's not my goal. My goal is to fix the goddamn problem. It's hurting my field, it's hurting people I know, and it's hurting a lot of people I don't know. I want the ongoing harm to end.
History suggests that a lot of people never get over the idiotic opinions they grew up around. This is true even for very smart people; Planck wrote, "A scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it."
So consider today's KKK. Do I want everybody to be not racist? Yes. Would I like every member of the KKK to realize that they have been assholes all their lives and start making up for lost time? Sure. If some rando starts talking to me about the inferiority of black people, am I going to patiently talk to him about what the research really shows? Fuck no. I am going to tell him that he's an asshole, and that I don't want to hear his racist bullshit around me. If he ever wonders why, he can hop on Wikipedia and read a little history. He won't, of course, because the problem here isn't primarily his ideas; it's his biases.
I was being charitable and attempting to offer food for thought. I now understand that both were in error.
I happen to entertain the fringe belief that call-out culture is unhealthy and serves to further the problems it purports to address. I can see that you do not share this belief.
Oh, please. We both believe in using words to discourage expression of certain beliefs and limit particular behaviors. Which is why you're talking to me in the first place. Saying that you don't believe in "call-out culture" while calling me out for calling somebody out just means that you object to it being done by people who you disagree with politically. "Call-out culture" is only novel to the extent to which previously marginalized people can collaborate and talk to people in dominant group as peers.
Also, your claim that you were being "charitable" is obviously disingenuous. How kind of you, so rich in thought, to donate your pearls of wisdom to the impoverished thinkers with regrettably different politics than yours. I only hope you have more time in the future to condescend to me while ignoring my actual points.
If you were all that serious about addressing the problems that you see "call-out culture" as attempting but failing to solve, I expect you'd be doing something about it besides tsk-tsking and making tone arguments. Otherwise, though, the simple explanation is that this is garden-variety concern trolling on your part. So yes, feel free to good-day yourself right on out of my replies.
I can come up with at least four reasons why people want to be lawyers in 2005 more than in 1965, without caring what is between their legs. These may or may not be their actual reasons, those are known only to the individual.
Honestly you don't deserve any reply though, after the way you treated OP. It is always the person who makes a claim who has to provide evidence for it - it is NOT the person who disagrees with the claim.
>Partly because so many of these people seem to think it's somebody else's job to argue them into an understanding. (Rather than, say, their responsibility to do a Google search and read for a whole hour.)
That is exactly what the rules for civilized debate proscribe. You have to argue your case, I don't have to.
1)Lawyers were (assumed) to be a safe career in 2005, in a world that did have that many safe jobs left. In 1965 there were a lot of other jobs that seemed safe, but didn't require you to work as hard to obtain them.
2)Lawyers have high earning potential - unlike most other jobs you can get with a college degree today. In 1965, this would have mattered less, because most jobs were relatively high paying (boom time does that).
3)In a world that changes rapidly, lawyering seems relatively safe, again the world changed less rapidly in 1965, with fewer obsolete jobs.
4)A safe, high paying job gives a high prestige. With fewer such types of jobs, more people will want to join those that exists.
So those would explain a higher amount of applicants to law schools, but not necessarily a higher amount of women, right? The thing is that law schools are limited in how many can be accepted and in how many new law schools can be created. You can't learn the law on your own in your bedroom and then get a job as a lawyer.
Is this what happened? Hell I don't know. I do know that it is at least possible it went this way and the explanation is as good as there were a large amount of sexism in law. After all if there were that much sexism in law in 1965, but not in 2005 why would there be so much sexism in computers today?
> It is always the person who makes a claim who has to provide evidence for it - it is NOT the person who disagrees with the claim.
You miss my point. Suppose I turn up and say, "The Earth is flat!" And maybe I even provide some evidence. Is it your job to argue and argue until I admit you are right? No. You are free to go about your business. If you don't take the time because you think I am a lunatic or a troll, does that prove me right? No. It is my job to know what's going on, not your job to convince me of it.
I make this obvious point only because many people like ManFromUranus seem to believe that anybody who says, "Hey, maybe several thousand years of blatant sexism didn't end on Jan 1" is obligated to argue with them until they are convinced. They aren't.
> It is always the person who makes a claim who has to provide evidence for it - it is NOT the person who disagrees with the claim.
Yes, and the claims being made in this case are that "women can do whatever they want," and "women are not in tech because women don't want to be in tech." When women were legally second class citizens in the US as recently as 100 years/4 generations ago (i.e., suffrage rights), I think that the burden of proof has to fall on the people making the aforementioned claims. Where is the evidence that there is absolutely no friction for women to choose whatever field they want? Where is the evidence that social norms have completely leveled the playing field for women in terms of salary, career advancement, workplace harassment, etc.?
This raises an interesting question: Do we think that discrimination in technology is worse (or more entrenched?) than discrimination in law, medicine, or finance? These other fields were almost entirely male within living memory (my mother was one of two women in her law school class) and are now approaching gender parity (at least at most levels, I'm sure that senior partners are still mostly men). Why has there been such a dramatic turnaround in medicine, but not engineering or technology?
> Why has there been such a dramatic turnaround in medicine, but not engineering or technology?
AFAIK, there's been a fairly dramatic turnaround in some areas of engineering and technology (biotechnology particularly), modest turnaround in others, and substantially less turnaround (even compared to other engineering and technology domains in general) in computing, both hardware and software, domains.
Biotechnology, like medicine, may benefit from the fact that the early preparation overlaps substantially with the early preparation for traditionally female-dominated fields (e.g., nursing) such that early interest isn't socially discouraged even in contexts where gender stereotypes about appropriate careers remain significant social influences.
Just a thought: Adolescents can start self-learning programming far earlier then you would start learning formal law or medicine. So if there is a gender divide among the adolescents self-learning programming/engineering skills, then I'd expect to see that trend exacerbated into adulthood. That dynamic doesn't happen with law or medicine.
Certainly with law (perhaps less so with medicine), early self-learning is quite possible. (As, for that matter, is early organized learning targeted to adolescents, such as middle/high school mock trial programs.)
I'm not certain how you can structure your argument such that it does not also imply that professions that are majority female discriminate against men.
Your introduction of that graph appears to be an attempt at making an improper inference based on conditional probabilities. You can't just flip-flop between probability of woman, given job, and probability of job, given woman. There's math involved, based on additional data not necessarily obvious from the visualization.
To make an inference about what women want, you have to remove the men from the data. It doesn't matter one little bit what the female numbers are in proportion to the male numbers. And what the female numbers show is that around 1985, women generally stopped wanting to earn CS degrees, preferring medicine, law, or physical sciences. The graph does not say why. It just suggests that women very abruptly reversed the previous trend and started choosing other careers. It also happened before the vast majority of people now working in the field had graduated from elementary school, which suggests that it is an institutional bias, and not a personal one.
It's easy to guess at the reason why, but those guesses would not be supported by anything short of surveying actual women with college educations, asking them "why not computer science?"
My hypothesis is that for those answers that cite the composition of the CS classes and faculty as a contributing factor, it wasn't because they were full of men, but because they were full of nerds. For a variety of reasons revolving around the capricious cruelty of adolescents, females are less likely to be in the nerd social caste, and possibly also strongly conditioned to avoid it.
That social dynamic fuels a lot of nastiness later in life. Sex balance in the workplace may be just another symptom of it.
But really, it's all useless speculation until someone actually goes out and asks some people about their reasons for doing things, in a manner that avoids known biases.
I think the only relevant argument I made here is that "women just don't want to tech" does not usefully explain the data.
If you're saying what careers people choose is a complex function with many inputs and interactions with the social context, I agree. I am arguing against the view that career mainly driven by a simple, stable, gender-based biological intrinsic, which is the usual thing meant by "women just X", as in "women just can't science" or "women just want want to stay at home with babies".
There's gender imbalances in lots of places now between executives, teachers, prison, the military, some of those are positive places to have a gender balance in.
I've seen lots of discrimination against females in the places I have worked, behind their back for the most part. I have also seen examples of positive discrimination in their favour, but not as much.
Personally, I think it's a manufacturing line of institutions that lead to a hireable tech worker - and if you go back each step along the assembly line, the female involvement is higher percentage wise.
So I think the lower representation is a product of women opting out of maths and science based subjects at an early stage, and later choosing the medical profession over engineering.
It would be interesting to get some statistics over the span of a career, do a higher percentage of women change career away from tech once they start?
Anyone that doesn't think there is a problem should try asking a female dev about her experiences in her career. Besides typical societal problems like calling 35 year old women "girls" and forcing them to choose between having a family or a successful career, they face all sorts of discrimination and sexism that men don't even realize they're doing. My SO on multiple occasions has been told things like "You're the best female dev I've ever seen", "It's so nice to have girls on the team!", and "Don't worry you'll find a job because companies always want female devs". Add on top of this any sort of general sexist behavior that is rampant in offices like unwanted advances, inappropriate touching, etc. It becomes really painfully obvious why there aren't more women in tech.
I am in complete and total agreement with what you are saying. I once heard an undergraduate female dev be fed the "companies always want female devs" and a female colleague my junior having self doubt over getting promoted. The whole thing stinks.
To be honest I'm sure I've transgressed a few times myself! Like many things you just have to be vigilant.
>and forcing them to choose between having a family or a successful career
This is not true. There are always trade-offs in life, even for men. Almost everything has an opportunity cost. You focus on your family the career suffers, focus on your career family suffers. The same is true of men except they don't have a biological clock.
>Add on top of this any sort of general sexist behavior that is rampant in offices like unwanted advances, inappropriate touching, etc.
I hear this, but have honestly only ever been present for a single awkward comment in my 10+ year career. I think "unwanted advances" is going to be a continual problem because most of the guys in tech are socially awkward, unnattractive nerds, so any advance they make is going to be by definition, unwanted. However these guys have no way of knowing that before-hand, unless they make "nobody wants me" their default assumption.
>they face all sorts of discrimination and sexism that men don't even realize they're doing
this is what bothers me the most, there is no concept of "mens rea" in issues of discrimination, you are guilty even if you try not to be. People choose to be offended or not, that's a voluntary choice. So if your SO is offended by people who have no intention to commit offence or cause harm, then what can I say? What can they do? Everybody will have to walk on eggshells around your SO so they don't offend her I guess. Doesn't sound like the problem is with "tech" to be honest.
The price of the privilege and prestige of being a member of the oppressive majority is eternal vigilance against overstepping the mark. Sure it's inconvenient, but politeness doesn't cost much effort. Eggshells is a good way of putting it.
If you or anyone you see steps over the line, get an apology out there and discuss it and move on. Over time what constitutes a transgression seems to get more minor and trivial in my eyes, but until we're at a star trek utopian standard of living, progressing towards it is worthwhile in my view.
Of course if somebody is taking the piss and claiming oppression when there isn't any, they deserve to be called out on that too. In the poster's comment to which you are replying I do think his SO's grievances are valid.
>The price of the privilege and prestige of being a member of the oppressive majority
I disagree with this assertion that I belong to an oppressive majority, or that the majority is oppressive.
>Sure it's inconvenient, but politeness doesn't cost much effort. Eggshells is a good way of putting it.
Tolerance goes both ways. Why should 100 people modify their behaviour so that 1 person doesn't get offended, when 1 person could modify simply raise their threshold for offence, and save a 100 people a lot of hassle.
>If you or anyone you see steps over the line
There is no way to know what or where the line is. The line is totally subjective and unique to each individual. So it would simply be easier and less risky (remaining employed wise) to avoid interacting with the person than spend the time to learn how to avoid triggering their offence reaction. I guarantee the path of least resistance is the one that will be followed.
100 people should modify their behaviour if they are being impolite and unprofessional.
The line is subjective I agree. Being polite and courteous rather than unprofessional works best for everyone. It's pretty easy too.
The path of least resistance is being followed and we are all the worse for it.
Also the opinions you are expressing are very much those belonging to a member of the oppressive majority, as far as I am concerned. 100 to 1? Oppressive majority? Fairly cut and dried.
>The price of the privilege and prestige of being a member of the oppressive majority
That sure sounds like most nerds I know - we are just so high on the social scale, even pop stars wish they were us.
And let me put it this way: I have no intention of walking on eggshells my entire career, never knowing when I hurt some delicate being. I don't for a second believe women are that delicate (there are far too many women in combat for that to be the case) but if they are as delicate as I read your comment to assume they are then they don't belong in computing - the compiler will not care how much it hurts your feelings.
And you are some sort of compiling automaton? Keep telling it like it is - you stick to your guns. You won't have to walk on eggshells when you're done trust me.
Oppressive majority: I meant white male, rather than programming nerd.
And I am pointing out that you can't simply include all white males and say that they are all oppressing majority (for one there are more people who are not white males on this planet) - not only would you have to include nerds, but you would also have to claim that homeless people are oppressing (since they tend to be men).
so you want to be an ass (not walk on eggshells as you put it, be unforgiving like a compiler) because there's homeless people and because nerds get a hard time?
yep i'm convinced those industry ladies should get thicker skins alright, especially when they are in your industry - they should play by your rules - right?
Why don't men want to be elementary school teachers? Well nobody really cares that much why, but they definitely don't. I think they don't because it's a low-pay, low-respect job and there's a risk of being called a pedophile.
Why don't women want to be in tech? Full of nerds, full of people they don't really want to be around. Hard work, the pay is getting lower every day, have to compete with low wage offshore workers. There are lots of men with no social skills in tech. Women can probably earn more money outside of tech, and have more networking and social outlets in non-tech jobs.
Elementary teachers -> a lot of people care because they think that without men, it runs the risk of becoming a marginalized, low paid female only job. Some of which is already true in your view.
I'm with you on why women don't want to be in tech, except disagree about the hard work or lower pay ever day and offshore workers. Not all women are social butterflies either, so it's just the negative stigma around it.
So that's why I asked, they don't want to be in tech cause of a bunch of needless, highly negative stuff. Stuff that could easily be rectified and thereafter everyone would be much better off.
As a younger male about to finish his software engineering degree and start applying I agree with these points. I am intimidated at the rigorous testing some companies use. I don't have the confidence that others might have in there ability.
I am ultimately looking for a mentoring workplace ( just to start) where I can build my confidence quickly and start producing for the company.
One place I worked at had a senior dev slash architect who really enjoyed mentoring green developers. This company did tend to hire people straight out of college, and this guy was really good at bringing them up to speed. It was really quiet nice to behold.
The problem was, the hires that were 'good' tended to leave after a year or two, leaving the less talented and motivated to muddle along. I think this is why you rarely see this nowadays.
I don't think that has anything to do with mentorship. I think it's just that most companies don't give most young programmers big enough raises to reflect their increased value on the open market.
Lots of companies don't want to hire new grads, so there's a significant price premium for hiring someone with a couple years of experience. The companies that are willing to hire new grads aren't always willing to give annual raises that reflect that price premium. So lots of programmers with a couple of years of experience see that they can get a 20% raise by switching jobs. So they switch jobs.
(This happens with programmers later in their career too, but the difference between 8 and 10 years of experience is much less dramatic than the difference between 0 and 2. If a company gives the same annual raise to all its programmers in the same performance band regardless of experience, that raise may be too small for the newest ones, even if it's just right for the middle ones.)
I'd say articles like this one are pretty significant benefits. I doubt they overlooked the PR benefits of this program. (Which of course doesn't mean it isn't still a great thing. Just that "no benefit" is a bit of a stretch.)
There are more women than men in employment in the US, where is the daily articles on that? And the effort to tackle that? And the constant shaming of companies that employ more women than men?
There are 1.4x the amount of women graduating college than men. Where are the daily articles on that massive issue? Where is the effort to do something about that? Where is the constant headlines on how many more women are graduating than men, put in a very negative light as the lack of quote underlined "diversity" in the tech industry is?
This absolute, unrelenting and incredibly transparent (tech = money, status currently) narrative being sharted at everyone in the tech industry on a daily basis is driving me toward getting out of it altogether.
But hey, lets ignore some massive issues on the table in favour of constantly debating why women who never showed an interest in the industry can't pick and choose the finest and most well paid positions in that industry and see where that gets society in 10 years' time.
There have been a vast slew of articles on the problem of male unemployment, and particularly the problem of the unemployment rate in minority males, who got hit particularly hard by the recession and have not seen those jobs come back. Around the recession this was all over the news.
Higher education has also been tackling the issue of getting men into college, and keeping them there until graduation. As has primary and secondary education, asking questions like what it takes to get boys to read more, and the effects of having mostly female teachers.
That you have to ask where they are suggests to me that you haven't looked very hard.
And the assumption that you cannot tackle multiple issues at the same time, worrying about both diversity in tech and unemployment in men, is simply false.
This absolute, unrelenting and incredibly transparent (tech = money, status currently) narrative being sharted at everyone in the tech industry on a daily basis is driving me toward getting out of it altogether.
It's not being thrown at the tech industry. It's people within the industry calling out the problem that we have. It's very telling that you think of the industry as a community under siege.
>It's not being thrown at the tech industry. It's people within the industry calling out the problem that we have. It's very telling that you think of the industry as a community under siege.
Actually, the vast majority of it is being carried out by people on the fringe of the industry in roles as "journalists" and similar who've never spent a day working within it.
And yes, I see the tech industry as being under siege.
But the article seems to glide past that and presents the idea that five years of experience might change someone's willingness to apply. And it probably will help, but that amount of experience is unlikely to change someone's basic perception of their ability to succeed in a high-stakes one-chance prove-yourself situation.