The big result there is this: "Poor performances in technical interviewing happen to most people, even people who are generally very strong. However, when we looked at our data, we discovered that after a poor performance, women are 7 times more likely to stop practicing than men."
On the hiring side, "For the specific case of an online job posting, on average, 1,000 individuals will see a job post, 200 will begin the application process, 100 will complete the application, 75 of those 100 resumes will be screened out by either the ATS or a recruiter, 25 resumes will be seen by the hiring manager, 4 to 6 will be invited for an interview, 1 to 3 of them will be invited back for final interview, 1 will be offered that job and 80 percent of those receiving an offer will accept it (Talent Function Group LLC)." This implies that 80% of interviews lead to rejection.
Given that level of rejection, the key here is to get women to know the odds and keep trying.
At the start of our teens, we lose the intrinsic value that society places on us as children. For many boys, after this, their only worth is in what they can accomplish, for themselves or for others. For many girls, they learn that they are intrinsically valuable as women, as long as they're attractive.
It's not an issue of 'explaining' the odds. It's an issue of women knowing that they're worth something in and of themselves, competing against men who are motivated by a lifetime of experience telling that if they can't achieve, they are nothing.
Jumping directly to discrimination in society seems a bit hasted as an explanation for the data, since men entering the teaching profession also show the exact same data. When hitting a roadblock, men a several times more likely to quit the teaching profession than a woman hitting the same roadblock. Surely it not an issue of men knowing that they're worth something in and of themselves, competing against women in the teaching profession.
Theory should be testable. Failure rate after interview rejection should be fairly easy to gather over any number of profession, so why not do that. Rather than just studies on teaching and tech profession, lets have 20-30 different profession, about which 50% will be male dominated and 50% female dominated (should be easy since about 90% of all profession in Sweden have major gender imbalance, and >80% of both women and men are employed).
Rather than explaining the odds, and rather than talking about intrinsic value, maybe we should be talking about the psychological effect of diverging behavior. If 60% of people in a restaurant pick vanilla ice-cream as desert and 40% pick chocolate, the 40% is more likely to have buyers remorse than those in the 60%. Being in a minority, be that based on gender, race, language, or ice cream preference, will have an confidence impact. When it comes to carer choice, that impact has then a very noticeable effect.
Very interesting, I'd never heard that about male teachers quitting more often than females. I wonder if that holds true across different cultures? Here, at least, teaching is often seen as a bit of a fallback plan if you don't succeed at your chosen profession or you hit mid-20s and still don't know what you want to do.
I like the diverging behaviour angle too. That actually sounds like it could have a serious impact, and doesn't rely so heavily on stereotyping one particular teen experience across each gender.
If it culture has a major impact, it should be fairly testable. Any differences, after correlated to gender distribution in the work force, should hint to it.
Theories that can be tested to either be false or true is always valuable in this kind of discussions.
Yes I can. But first I would like to say that I could too just have requested citation from the parent comment and be done. Finding papers you read a month/year/years ago take times, and links goes sometimes dead, and in a online forum like this it is generally appreciated if the requester has done some initial attempts themselves to search online for sources.
Anyway, it was a polite request and I happened to save the pdf. Source: Rapport 2009:7 R, Swedish national agency of higher education, title: Man ska bli lärare!.
"I could too just have requested citation from the parent comment and be done"
Been done with what? Yes, I know, sometimes people say "citation please" as a way of refuting without reasoning, but other times, people are actually interested in reading the citation. This is one of those cases.
Furthermore, this is not one of those cases would something could be easily established through a quick google search, this sounds like a very specific study.
Thanks for showing that was the case, and Im glad that source was helpful. Chapter that begins at Page 27 is especially interesting since it directly address potential reasons, and the aspect of being in minority vs majority.
It's likely that it does make men more likely to give up after a failure than less - male labor force participation rates are at a historic low, and there are plenty of underemployed men who were shut out of a high-paying job. But these men drop out of the sample set, and so they aren't talked about when discussing industries with diversity problems.
Paul Graham once wrote [1] 'As a kid there's a magic button you can press by saying "I'm just a kid" that will get you out of most difficult situations. Whereas adults, by definition, are not allowed to flake. They still do, of course, but when they do they're ruthlessly pruned', which to my college mind seemed incredibly draconian, but that is largely the way the world works.
I think a better sense of intrinsic worth and the knowledge that our accomplishments are what we do and not who we are would benefit both sexes.
Subtle(ish) distinction: You aren't your past accomplishments, you are your capability to generate future accomplishments.
Who is more likely to persevere; someone who believes they have to keep achieving things or they are worthless, or someone to whom achievements are a nice bonus to the intrinsic value that they already have?
That makes absolutely no sense. By definition, giving up is failure. So the options are "100% chance of failure" vs "less than 100% chance of failure", and you think they are more likely to pick "100% chance of failure" because failure is scary?
Obviously it doesn't make sense rationally (you miss 100% of the shots you don't take and all that), but it's emotionally very powerful. It's much easier to emotionally justify giving up (I'm not really interested in switching jobs/getting in to tech/etc.) than it is to face the prospect of being rejected many times.
You are describing the wrong group of people. The "emotionally justify giving up" you describe is precisely what we observe with the group of people who are not considered failures for doing so: women. For men, that is failure. That is not easy to justify emotionally, it is the very thing they are trying to avoid in the first place. The emotional toll of giving up is the same as the emotional toll of trying and failing: you are a loser and not a real man, you have no worth or value. This is why they try again, because it gives them another chance to succeed, and demonstrate their value and worth.
Do you have any evidence to back up that opinion, or is it just your theories on what human nature?
If we want to trade opinions and anecdotes, I personally know plenty of "real men" who have justified giving up on different goals to avoid the pain of continued failure. Heck, I'll admit to having done it myself: many years ago I thought I might want to work in finance but after applying to a few banks and never hearing back I "decided" that it's not really for me when in reality I was just avoiding the pain of further rejection.
I realize this sounds confrontational, but I really do want to know where you're coming from that men don't give up on things due to fear of failure. In my personal and professional lives, I see it all the time.
The very article we're discussing? Remember, it shows 7 times as many women give up as men do.
A generalization is not contradicted by one example to the contrary, it would need a majority of examples to the contrary. Obviously some men do give up. But only 1/7th as many as with women. I am simply supporting the explanation someone else offered: that this is because women have inherent value and men's value is purely based on their current level of success. So men have an additional strong incentive to not give up. And when they do give up, it is often just to pursue another avenue where they feel success is more likely, rather than just giving up altogether.
All that is evidence of is that women give up more often than men. That doesn't provide any evidence that it's because men's value is tied to achievement.
I could just as readily argue that women give up more than men because they have stronger priors of tech not being for them (fewer peers and role models, less experience, etc.) so any evidence they get confirming that hypothesis is more likely to push them into giving up.
We could, in fact, have both things happening simultaneously: some men giving up to protect their ego, but even more women giving up because they think it's not for them.
>All that is evidence of is that women give up more often than men
Yes, that's the point.
>That doesn't provide any evidence that it's because men's value is tied to achievement.
Indeed, that's what we're offering a potential explanation for.
>I could just as readily argue that women give up more than men because they have stronger priors of tech not being for them
Then do so. Saying "I could make a bunch of other arguments but won't because I know they are contradicted by evidence" is not compelling. In fact, I find it inherently dishonest, in that you are trying to rely on the assumption that any other random explanation you could put forth is just as good, but you won't put them forth because then they would be demonstrated to not be just as good.
Sorry, I should have been clear: I do believe that my explanation (women quit more because they have a stronger prior of tech not being for them) is much stronger and more likely than yours. At the very least, its assumptions are backed by basic evidence (that there are fewer women in tech to look up to as role models).
Except they are more likely to give up in other fields too. Even fields with lots of women in them. So no, your assumption is not backed by basic evidence.
You miss an important aspect. You won't succeed in 100% cases you don't take
an action, but you also don't fail due to your lack of skills in 100% cases
you don't take an action. You can't be blamed for failing if you didn't even
try. You can only be blamed for not succeeding.
No, that's not how it works, which is the point. As they said, men's value is judged on their current success. Not trying makes you just as valueless as trying and failing, it is the exact same outcome.
That definitely plays into it. A certain amount of aggressiveness is crucial in career success (for example, men are much more willing to apply for jobs where they don't meet all the stated requirements).
this sounds like something you're making up right now. i can make something up that gives the opposite impression: it is implicit in our culture that the cost to women of failure is higher than to men.
or, i could say, anyone is more likely to give up something more quickly if they believe they "aren't the sort of person" who does that thing; if they don't fit the model that has been given to them by the surrounding culture of what that thing is. men are more likely to quit pursuing a career in early childhood education at the first rejection; women are more likely to abandon their ambitions of working in tech.
or, even just riffing off yours, i could say men are taught that their value comes from their accomplishments, and women are taught that their value doesn't come from their accomplishments. or even that ambitions and accomplishment carries a degree of cost. actually, i think we're seeing some of this playing out in the u.s. election.
That is a pretty huge statistic, - what also pops out to me is: "stop practicing ". This seems to imply that these technical interviews are skills that you don't really gain on the job. I know that personally would 9 times out of 10 spend time on a cool / beneficial project rather than making time to practice trivia problems.
> these technical interviews are skills that you don't really gain on the job
I believe that's definitely the case. That's why I shifted my interviews to be as much like the work as possible. First round was a pair programming interview plus a bit of technical discussion. Second round was kicking around a feature and its implementation with the team.
My goal was also to see people at their best, so I did as much as possible to make them comfortable. E.g., for the programming portion they were welcome to use their own device, their favorite editor, and their strongest language.
Wouldn't it be more detrimental to a team's performance to hire someone who isn't a cultural/productive fit? I think that would make the temporary performance hit when hiring worthwhile.
Exactly. A good hire will add thousands of hours of productivity. A bad hire can be negatively productive, either personally, by harming team performance, or by driving off productive people. Trying to minimize team-minutes spent per candidate on late-stage interviews is a false economy.
In practice, I don't try to get absolutely every team member involved, just a quorum. If everybody wants to have a say, that's fine by me, but often once you get past 3 participants somebody will say, "Oh, whatever you folks think is fine by me."
>This seems to imply that these technical interviews are skills that you don't really gain on the job.
the technical interviews skills are gained, at least in my experience, as result of the technical interviews - which normally implies, and did happen in my case, high rate of interview failures initially. Taking failures hard would naturally lead to Catch-22 here.
the biggest catch 22 for me is when you work with someone for years at a job. at this job you have a strong interview process. you reject the same 80%+ of candidates. then you move somewhere else. you refer your friend. they get rejected.
were they a bad employee?
did they sneak in the door at the last place?
Is there a problem with how we do interviews?
Speaking as someone who has taken on a lot of hiring responsibility: the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else.
The cost for accepting a bad applicant is several months of salary, reduced productivity for my team, risk of a discrimination suit if I don't put them on a PIP, etc.
So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad. The good applicants will get jobs somewhere else, it's OK.
The technical interview is part of that. The coding test is part of that. Sitting down with them and making sure they can talk through a problem with their future teammates is part of that. There's no one piece.
And finally, if your career is to write code and solve problems, and someone gives you a test where you have to write code and solve problems, you should be elated. Is there anyone that wants to answer the "Tell me about a time where you had a disagreement with a supervisor"-type questions that the rest of the world has to deal with?
> So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad.
How does this square with the oft-repeated "shortage of engineers" meme that Silicon Valley can't shake. You seem to be able to pick and choose, and pass on good candidates for nit-picky reasons, so is there really a shortage of talent?
3-6 months to get someone trained up, and a lot of their pay would be in /training/ them (you'd still pay at least a living wage for the area, but you might upfront plan and disclose to relocate them if hired).
The benefit would be both in seeing if they're a good fit, and also enriching that employee as an employee. Both sides would have a much better perspective of if it's a good fit, if they want to restart the process with a different team, or if the employee can find better value in society elsewhere.
When you think about it, college degrees in IT/CS are the wrong way to go about IT/CS learning. A 3 year apprenticeship like an electrician or plumber does would make a lot more sense. 60% of your time is spent at work, shadowing and helping an experienced professional who can show you the ropes and explain concepts in the real world. Remaining time spent in the classroom doing theory and learning new stuff.
My degree attempted something like this, with a lot of guest companies providing projects that amounted to coursework. For example, one coursework was to make a front and back end in asp.net with a predefined set of features for a company.
The problem with apprenticeships is that educators are handing over a large part of your training to a company with unknown factors, like mental people with random hangups. Still, I'm sure many of us when we got our first job felt hopelessly unprepared for working in a real company.
There's fear of poaching because the tech industry is so incredibly bad at giving raises. People are forced to change jobs to get what they're worth after just a few years.
Some companies are smarter than this, but most are not, from what I've seen. So yeah, they're going to worry about poaching because they know they aren't doing what's really needed to keep people.
>the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else
The cost seems much higher to me. I have to interview dozens of people to find a single good applicant. Rejecting one good applicant costs me dozens of interviews, not one.
Oh yes, and that applies to both sides of the table. Interviewing skills are learned as well - and they can be taught. (A friend is proud of the fact that he's had actual interviewing training.)
Interviewing is not that hard, but it sure as hell is a difficult thing to master. I'm reasonably good, but still nowhere near as good as I'd want to be. Nonetheless, it's still a skill that can be learned and improved.
The irony is that it'll be easier to improve one's interviewer skills than those of being interviewed. The reason is that if you're conducting technical interviews, you'll be doing it as part of your job, and any reasonably good interviewer will have his or her calendar full of learning opportunities.
Candidates will have less opportunities and due to the nature of the experience, are likely to be demoralising to boot.
I recently wrote a post about things I've picked up and learned when doing technical interviews: https://smarketshq.com/notes-on-interviewing-engineers-a4fa4... ; when judging the experience from HN posts, I cannot help the feeling that most engineers are subjected to pretty horrible, even recurring interviewing experiences.
I've had 4 technical interviews in my life and passed all of them. I didn't practice for them, I just have strong foundations in CS. The most criticism of interviews comes from people who can't get past them.
You don't "just have strong foundations in CS," you also have strong foundations in interviewing, whether you consciously developed those skills or not. The problem is that those interviewing skills aren't really relevant to the job, so they shouldn't be part of the interview.
I once had a candidate who completely bombed the interview, one of the worst interviews I've ever done, but he had a great portfolio. I took the risk and hired him on instinct and he turned out to be an amazing frontend developer who just doesn't do well when he's on the spot standing in front of someone. Years later I recommended him to someone else who was hiring, with the caveat that "he's going to bomb the interview," which he did. The guy called me back and said, "I can't hire someone who did that badly on the interview" and I told him, "do it, you won't regret it, I promise you." He did make the hire, and it predictably went great.
Interviews work well for salespeople because interview skills and sales skills overlap a lot. Interviews don't work as well for engineers because interview skills and engineering skills overlap very little. It's just a large injection of noise into the hiring process.
I've always thought that if I started my own company, I probably wouldn't even interview people. I'd search specifically for the people I'm interested in, bring them in for a meeting just to make sure they aren't crazy, and then hire immediately. If someone sent me an application wanting to be hired, I would give them a work sample to be completed in one week and hire on the basis of their performance on that.
What I'd actually prefer to do is actually pay someone to do real work for the company, like an actually useful task, but there are lot of complications with that. There are costs to "hiring" someone even for a small task (Tax ID number, 1099, etc.) and there are risks about exposing your codebase to interviewees who are not bound by proprietary information agreements and invention assignment agreements.
I have only failed one technical interview in my life, and to be honest I did not fail it, I took the confidence route which put off the 20 something lead I was interviewing with and mentioned that I was a keynotes speaker at IBM Impact on the coming transition to Javascript based applications. He took this as an affront and challenge (to be brighter than the IBM speaker guy to his team) and ensured that the interview was a miserable experience, but that is neither here nor there The only reason I toot my own horn is to relay the following observation.
The point I want to get to is: I have a buddy who I have dragged along with me (many times staking my reputation on his abilities), to every engagement I go on and this guy could not pass a how to use Microsoft Word interview. He has Aspergers and locks up and fails miserably in the interviewing process, but the honest, reality is, he is 10 times the developer I am, the guy sees patterns instantly and has a knack for code organization. He can master a new technology in a week and is hands down the best developer I have ever met.
That being said, over the years watching him has lead me to the conclusion that it is indeed the ones they hold faith in the technical interview are actually the ones that are the most stove piped and only see the world thru their limited experiences. It should be classified as a form of confirmation bias.
My advise don't be sorry be proactive, if you meet one, be their friend, be their network, look out for them. That is how the world changes, one person at a time.
Can confirm. My best friend is a sales guy at the place I landed my first real (W2) job. Been 5 years and going strong. I am even the "Sr. Engineer" now, working on first principals and loving it!
That's a pretty narrow view of the problem. Like you, I've never had a technical interview that didn't turn into an offer. However, I have some strong doubts about their sensitivity (as opposed to specificity, which is fairly good).
On the other side of things, I can say that most of the criticism of interviews I hear are from people who passed the interviews, possibly a long time ago, and are complaining that the technical interview process is inappropriate for hiring people onto their team, but they have to do it anyway. It's a common sentiment that the correlation between technical interview performance and job performance is weak.
Without sounding condescending, how old are you? I had my head more "fundamentals of CS" when I was just leaving school and also never failed a technical interview. After spending some time in industry, I don't think about those types of problems as much. If I were to do the same technical interviews I did back then today, I'm almost certain I wouldn't do as well.
You sound like a superstar. I don't mean that condescendingly, but I meant that genuinely - assuming you're telling the truth, you're the kind of candidate (based on tech skills alone) that most companies would love to interview and hire.
But there are way more jobs and positions than there are candidates like you. And you can't have every company be full of superstars.
The argument is for the rest of us, having a hiring process that optimizes for superstars doesn't select the best of the rest - it selects a random subset of the rest.
I wouldn't call 4 interviews a superstar. It's really doable, a bit of skill + a bit of luck for the first interviews + a hiring bar set at 'junior' cuz he's young :D
I suspect that they're not calling you a superstar because you've passed four tech interviews, but because your foundations of CS aren't decaying.
I work with a lot of teams as a contractor/consultant/whatever you want to call it. I often have to bite my tongue when team members that work for my clients forget what I believe are really simple things. For example, doing lookups in a hash vs an array. That was literally the entire solution to a performance problem I solved for a client: loop through an array once and make a hash, and then do lookups from the hash. Dropped the calculation from 4 minutes to 4 seconds.
The point is, this stuff comes naturally to me. When I think about going to town and shopping at 4 stores, I curse google maps for not implementing a heuristic TSP solver. When I started playing with hashicorp consul and vault, I went and read the Raft paper just to understand what was going on.
There's a lot of people in the industry that don't think about this stuff. I probably wouldn't if it didn't just come. I've got this deeply ingrained curiosity, and some kind of innate talent to remember it all and keep drinking from the fountain.
It's hard to remember that not everyone is like me. I'm not trying to say any of this as some form of humble brag or anything. It's just really important to remember that how I think and act isn't the same as most people. That, I suspect, is why the GP called you a superstar. You likely think about things in a much deeper and more frequent way than others.
Interesting, but your case may really get at what may go wrong with the algorithm exam approach to interviewing. I would expect a developer with a good understanding of fundamentals to see the difference in using a hash vs an array, and I would hope that developer at one point implemented a hash as an exercise.
I haven't needed to implement my own hashing table or methods on a real world project, as far as I can remember, but yes, I've absolutely written code that would have performed miserably if I hadn't known to use a hash rather than an array. I just didn't custom roll the hash, I used the hashing methods available to me in that language.
I'm aware of what a hash is, and what a hashing function is, and how collisions are resolved, and strategies to handle them. But I'm also almost certain I've been screened out of jobs because I couldn't implement a hash with a good hashing function in 45 minutes at the whiteboard. I just don't walk around ready to do this.
To address the last point, there's a tradeoff, as always. There's two competing forces with a hash function: speed and distribution. We want the hash to compute as quickly as possible, but want as close to equal probability of each bucket being chosen.
Assuming you're looking for a 32-bit hash value, my lazy whiteboard hash function would probably be something like:
- for strings, xor the bytes a word at a time.
- for ints, just use the 32-bit value
- for objects, let them provide their own, and if none is provided just use their memory address (this assumes that the objects don't have equality operators... that gets more complicated. If an object implements an equality operator, it also needs to implement a hash operator.)
These rules are by no means optimal, but they'd probably do as good enough for something that's not super high performance.
It also bears keeping in mind, I learned C twenty years ago, at the tender age of 12. Self-taught from the book that came with the compiler floppy[1]. We wouldn't have Internet at home for another 2 years, so I would occasionally persuade my parents to take me to a local Internet cafe for an hour to slurp up as much as I could at 28.8kbps and scribble it down. Bit manipulation operators are pretty deep in my soul at this point.
---
So going back to the original discussion... that came pretty natural to me. "How would I implement a hash function?" The brain whirrs a little bit and says "hey, here's some things to think about". I am 100% aware that this isn't typical, and do not expect others to have the same experience.
In fact, if I were hiring someone, I would be totally satisfied with an answer of "I'm not sure how to implement a hash function off the top of my head. It takes the object/value that we're going to insert into the hash table and turns it into a number that we can use to index into the appropriate bucket. Can we look one up?"
Hell, I'd probably be satisfied with "Here's when I'd use a hash table, and here's when I'd use an array. I've never implemented a hash table but I'd love to know how it works under the hood."
For me when hiring, the two biggest things I'm looking for are the ability to decompose problems into manageable parts, and a curiosity about how everything works. Those two things together tend to make any other knowledge gaps totally manageable; I'm not omniscient, but my desire to learn as much as I can about anything I don't understand can sometimes give off that illusion :P.
Well, here's the thing - I've been on a lot of interviews, and the majority of them wouldn't be satisfied with the answers you'd be satisfied with. If interviewers were the way you've described, I don't think the whole thing would be such an issue.
Overall, yeah, interviewers want to see that hash map largely written, often at a white board. Minor errors and bits of pseudocode are ok, but it should pretty much work.
"Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview."
Of course, Steve Yegge isn't the final word on prepping for google interviews, and I only had one experience there myself, but yeah, I'd say he's pretty spot on here (in fact, the google recruiter who arranged my interviews forwarded me the Yegge blog post, though I'd already read it earlier).
This, I think, is what is called "the Curse of Knowledge". I've taught 2nd year (Assembly) and 3rd year (Intro to Operating Systems Concepts) CS courses quite successfully, but I would have a helluva time teaching a 1st year course.
Like I mentioned in the sibling thread, I've been programming C for twenty years, and learned BASIC on a Vic-20 four yearsish earlier than that (at age 8). I learned all of that from library books.
Mostly, my algorithm for learning almost anything is "look at something that is somewhat magical, and figure out how it works inside". I've been doing that for years and years. Questions like "who programs BASIC? And how?" lead to learning about assembly. "How does BASIC store my program in memory?" "How does it translate what I type into output on the screen?" Etc.
Not to ramble on... unfortunately, I don't know of such a resource, and I don't really know what material it'd cover if I wrote it.
Right. Well, my story is that I'm selft taught (started programming when I was 6 or 7) and thus have been programming as a hobby for nearly twenty years. I decided not to go study CS because I suspected the amount of new and interesting material would be low compared to the time, money and effort it'd take to graduate. Instead, I went on to learn something completely new.
So one of my problems is that I don't actually know what I'm missing out on.
Are we talking onsite loops with 4-5 interviews each? In my experience the challenge with these is it only takes one interviewer to no-hire you for reasons that may have little to do with your technical abilities.
Meanwhile, I do terribly in technical interviews, and I've failed at pretty much all of them. Then in the jobs I've successfully gotten, I always get surprised feedback of how much stronger an employee I turn out to be than was expected based on my interview. Technical interviews that become a game pass on a lot of potentially strong employees.
This is me, too. People react with astonishment when I dive into a new technology, pick it up quickly, and become productive. Interviews are hell, though (and worse than they used to be). I can't sleep the night before a big one, and I tend to be nauseous and jittery during the interview. That doesn't come across well at all.
> I didn't practice for them, I just have strong foundations in CS.
Perhaps my take on things is different since my degrees are in math, so I don't have a bunch of 'canned' algorithms stored in my head, and so in a whiteboard would come up with my own technique, even for possibly basic things like trees / sorting.
I'm sure that even in math you need to know some basic things; for instance every math major knows basic theorems about groups, fields, rings, about real analysis, and so on.
It's the same for CS; basic knowledge of algorithms and data structures, and how these can be composed, is what a technical interview tests.
There's just three sorting algorithms anyone cares about, and they're not particularly complex. Someone with a math background should be able to pick them up in a few hours at most.
And outside of interviews, you will, with high probability, never, ever, have to code one yourself. You'll just call sort(), or OrderBy(), and rely on the battle-tested and bullet-proof standard library implementation.
Exactly, I used python heavily for a while, so don't think I've ever even coded my own for anything 'real' (e.g. outside of project euler or something) - I think the closest I've done on a real project is to code the comparison function and feed that to a sort.
Maybe, but I had to implement Hoare partition scheme which is used in Quicksort a few months ago. If I didn't know Quicksort I wouldn't probably have an idea that this algorithm existed.
I had to write my own tree traversal once. If I didn't know about trees, I wouldn't have had the basic context to do this.
But I did have to spend a few hours looking up and refreshing my knowledge of tree traversal. If I'd taken a technical interview exam on tree traversal prior to that four hours or refreshing my memory, I almost certainly would have failed. And yet I within the day I was able to write the code.
Agreed - my point is that I would be rejected from a job in the morning for an inability to write code that I'd be able to write by that afternoon.
They aren't testing whether you can look it up and do it, they're testing whether you have it all loaded into short term memory, on the spot.
Like a lot of people, I'm tired of having to reload it all and essentially retake my data structures exam. A lot of us just don't want to interview anymore. I know that if I need to, I can write a BFS or find all permutations of a set. If the opportunity is good enough, sure, I'll study up and get ready to do this at a whiteboard, but it's boring and unpleasant at this point, and I might not get or want the job, so at this point, I rarely bother.
Tech interviews are a big part of why tech companies are experiencing a "shortage" of applicants. They're hardly the only reason, but I'm pretty convinced they are a reason.
Even if you had to, the algorithms are so darn well documented there's no need to keep the details in your head. If you really need to implement one, you look up the details.
I agree that the fundamentals are important. In my opinion, half of the coding interview is having strong foundations in CS, and the other is being able to clearly convey that.
I'm still in university, but have managed to intern at a few a places so far and found the critical parts of each interview to be nearly identical. Microsoft and Google asked questions that boiled down to basic data structure problems, and Dropbox asked a simple backtracking problem. The problems weren't ones I had specifically prepared for, but were ones that I could break down because of my foundations in CS.
The only interview I've failed was my first one. The interviewer asked me to implement a Gaussian blur on a small whiteboard; between not knowing the algorithm and not having enough room, I flopped pretty hard. There wasn't a realistic way to prepare for this question, it was just one of those things you had to know at the time.
I too once had only had 4 technical interviews in my life and passed all of them. Then I had my 5th and failed. I've since passed many more for (even better) positions. I have no trouble finding jobs and have never had trouble (despite the occasional, random interview failure).
Given that there is a certain amount of randomness in interviews, of course it's possible to have a streak of successes. I don't look at a die that I just rolled 4 times and never got a 6 and determine it's loaded.
On my team there are two people with CS backgrounds (one PhD, the other MS). There are a couple of PhDs from the physical sciences and one from a more Software Engineering academic background. Without exception the guy with the SE background produces generally better quality code. The CS guys are not arrogant, they know their CS stuff, but their ability to develop software is... underwhelming.
Any possibility you should share some of the questions you would consider typical of your interviews? If you can't share the exact question, could you share what you would consider an equivalent question?
Getting a job and actually performing the job are two entirely different skillsets. There are a whole lot of people who bounce from one three month gig to the next as the people who hire them realize it was a mistake.
logically unexplainable multiple rejections just after very short interactions by seemingly picky capricious agents on the other side of the interactions - isn't it that the men have biologically wired in them as a normal thing to expect, doesn't matter be it dating or sales or tech interview...
Not sure about biology, but it's certainly ingrained culturally. As a man, I'm constantly trained by the society to overcome rejection, and a typical dating pattern of men approaching women is a major part of this.
However, I wouldn't use words like "patriarchy" here because I honestly think that this assymetry hurts both genders equally, just in different ways.
Men have the disadvantage (or advantage) of facing rejection much more often than women. Whether men overcome the rejection and become more capable is debatable, although it's clear men are more accustomed to being rejected.
Would this imply that women are also more likely to give up
if they get the job and they find that it's particularly challenging or competitive? If so, we'd expect higher churn out of the field, putting more downward pressure on diversity.
And this doesn't have to be just women, it could be anyone with a genetic or cultural predisposition (reducing diversity at least in personality types). Lot's of selection for monoculture here.
>Given that level of rejection, the key here is to get women to know the odds and keep trying.
Now that's an important fact that tends to get overlooked. Ninety-nine percent of the agitation about increasing "representation" tends to focus on accusing everyone of misogyny and attempting to destroy existing culture. But increasing the confidence level of female applicants, so they aren't put off by immediate rejection, could be a much less destructive way of achieving the goal.
Let's be clear here, you need to do that for potential candidates far before the interview.
Otherwise you'd be choosing less confident candidates simply because they are female, that's sexism and unfair to those who aren't being prejudged as low confidence. If you need confident people who can still work after facing "rejection" you'd also be hobbling your organisation.
If I'm a low confidence male then your system is going to stack heavily against me because of my sex.
That is some strange chain of reasoning. Do you really think men are more educated about these odds than women? Is there a secret male only class on this?
Maybe, just maybe, women don't want all of that, and we're collectively pushing them (in the name of equality of outcome) to something they don't care for? If you look at the stats, women in more egalitarian societies (Norway, Sweden, Denmark) are much less likely to choose IT over less egalitarian ones.
> women are 7 times more likely to stop practicing than men
For reference, what is this saying about how many of those that stop practicing are men?
7 times more likely than what? I haven't read the article yet. Any given individual is how likely to 'stop practicing' after a rejection? 10% if man, 70% if woman? 1% if man, 7% if woman?
teaching women to keep trying after failure should be done from an early age, i'm worried for women of the future that equality is causing men to learn the hard way along their whole career but for women they are going to be given easier routes to success but then fail in the real world because it's become hard all of a sudden.
> the key here is to get women to know the odds and keep trying
That's getting hold of the wrong end of the stick. The real key here is to fix the interviewing process, like the article said. Quit with the cargo-cult technical questions that don't mean anything, and just _talk_ to people.
Indians of Asian descent are a minority in the US, but well represented in Software Engineering. Further, there are plenty more Indian, Chinese, and Russian female engineers, than there are American (of european, aka White) female engineers.
I am less inclined to believe there is systemic bias against women, and minorities, and instead a culture difference between groups who are well represented in engineering, and groups which are not.
> I am less inclined to believe there is systemic bias against women, and minorities, and instead a culture difference between groups who are well represented in engineering, and groups which are not.
And that cultural difference is INDIVIDUAL CHOICE.
When people are free to choose whatever they like, because they aren't scared of starving, which is true in Western countries, they overwhelmingly choose gender stereotypical professions. This is most true in the most gender neutral countries, Scandanavia basically, where the gap is the widest in traditional roles such as nursing. As you go down the GDP per capita list, the gender gap shrinks.
Indian, Chinese, and Russians are from cultures where ANY job is hard to get, and good jobs are very few and far between. Because jobs are scarce and a safe, middle class life requires sacrifice, people in these developed countries are more likely to choose jobs based on pay and availability than what they will enjoy.
> they overwhelmingly choose gender stereotypical professions
Oh? Which ones are those? There used to be more women employed as computer programmers than men, for example. The shift happened because computer programming turned a corner and became prestigious, at which point it became "stereotypically male", and the pattern of "stereotypically male" = prestigious holds through a number of professions. Men are doctors while women are nurses. Men are professors while women are primary school teachers.
You can't just look at the present, you have to look at past shifts in employment demographics and "prestige" explains a lot more than "some genders just intrinsically desire certain kinds of work" (which, just to ensure my point is clear, is bullshit).
>There used to be more women employed as computer programmers than men //
Can you cite a good source for this.
I'm concerned it might be confusing the job called "programmer" with the role we now call programmer. AIUI in the early days of computers a "programmer" was a sort of typist that took a written program and punched the cards that allowed the program to be entered in to a computer, the technical tasks of algorithm design, program construction and such were generally not done by these same people.
That aside, I'm not sure it matters: why aren't there more female top chefs? It's certainly not because women don't like to cook. I posit that it's because in general they care less about being competitive and prefer to avoid high-stress situations.
Do you consider that testosterone is inert? It's mood and mind altering and men have lots of it. Denying the basic biological differences between the sexes is a dangerous axiom on which to attempt to create a stable and fair society.
Men, as an example, undergo hormonal changes when they become parents. These changes lead to greater tendencies towards nurturing behaviours, tendencies that female ordinarily possess by default and which make men and women naturally suitable for different societal and occupational roles. It makes a lot of sense for humans to be hormonally perturbed towards preference and ability at different roles -- why we are fighting against that rather than embracing it is well beyond my ken.
> Oh? Which ones are those? There used to be more women employed as computer programmers than men, for example. The shift happened because computer programming turned a corner and became prestigious, at which point it became "stereotypically male", and the pattern of "stereotypically male" = prestigious holds through a number of professions.
I think you meant 'computer'.
My grandmother was a computer. That is what they used to call the women who performed calculations in the old days.
It's interesting history but this could not honestly be described as computer programming. Looking around online it appears there are a lot of articles that have conflated the jobs. There certainly were women in computer science back in the early days, Lovelace, Hopper come to mind.
That's because Indian (particularly) men consider engineering to be a safe choice (source: am Indian). Anecdotally, speaking to women (esp American), they find engineering to be categorically unsafe from a career progress perspective. You may not 'see' the bias, but they definitely feel it. The effect is measurable.
I am no expert, maybe it has something to do with maternity leave regimes or the interviews (like OP mentions)?
My wife worked as a programmer for a while. There were two aspects that drove her out. First was the cliquey nature of the guys she worked with, she just felt like she didn't fit in. Second was the rate of change, just as she felt like she mastered something the new flavor of the month would take hold and she had to start over.
A man would feel unfit in exactly the same way when put into an environment
composed of mostly women (e.g. teacher in ground education). No surprise here.
Then, your wife must have worked with dynamic web pages (a.k.a. web
applications), probably frontend, to have that tool churn. Other areas don't
change that quickly and even then new tool allows to use most of the past
experience.
When our first child was born she decided to take a sideline sales business and make it full time, working from home. She does very well, in her peak year she made more than I did.
Google offers 18 weeks of maternity leave, and (according to the article at least) they still aren't doing any better than the industry as a whole. I also wonder how much of this perception is the result of a society that tells some groups that everyone is out to get them. Related: https://www.reddit.com/r/TiADiscussion/comments/5arevk/new_t...
Maybe they are inadvertently out to get them? Other than anecdotal stories telling otherwise the numbers show that there is something about the culture that women find openly hostile. We can either tell them to 'get over it' ('thats just the way it is') or change the culture. I don't think the former will work.
Could you qualify the particular geographic area you're referring to. Google are a multinational, only giving 18 weeks maternity leave would be illegal in the UK, for example (https://www.gov.uk/maternity-pay-leave/leave).
My wife is white, PhD in engineering. She choose the field because that is what she was excited about and wanted to study. Still works in Tech. Is a mother. Not so great maternity benefits though.
I have the same conclusion. The pipeline problem cited in the article is real problem, imho all the diversity efforts have to be directed at schools and parents. This is were the decision is made for college. After that you can't do much. My team is mostly male, we'd be happy to hire female developer, I think being a female would actually help to pass interview. But the resumes we see are all male, with very rare exceptions.
My analogy for the situation are as with seeds, if you only planted "potatos" in spring, there's not much you can do in autumn to get more "tomatos". (hope this is not offensive analogy in anyway, English is not my native language)
Situation with lack of female developers is not US-specific. I went to college in Ukraine, of ~100 sudents on computer science faculty, less than 10 were woman.
The fact that there're more Russian/Indian woman I think is because they are from immigrant families where husband is a developer. I'm developer and I met my wife at work back in Ukraine. But if you look % of woman developers in Ukraine, it's the same as in US.
A lot of my friends taught their wifes to become QA\developers after they moved to US and wife's profession didn't transfer to US well. Imho, entering IT is not that hard even without prevous experience, you do need to put hours to learn/practice, but unlike many other professions you can do that by just sitting at home and spending couple hundreds on books/video courses.
Are you saying that cultural differences can't be explained by systemic biases? Systemic bias may be the cultural difference, and in this context appears redundant.
As asked elsewhere--what systemic bias exists that targets certain women (white, black, mexican), but not women of other races (particularly Chinese, Indian and Russian)?
Perhaps instead, it's because schools (government?) in Russia, India, and China have emphasized Computer Science, and produce higher number of female grads.
Anecdotally, I attended a tiny engineering school in the midwest, and pretty much all the grad students were international students--women from India and China.
what systemic bias exists that targets certain women (white, black, mexican), but not women of other races (particularly Chinese, Indian and Russian)?
Well, from what GP said, it may be attributable to the culture itself:
"a culture difference between groups who are well represented in engineering, and groups which are not."
Which is to equate (or conflate) systemic bias and cultural difference. In other words, it sounds to me like, "it's not systemic bias, prejudice just comes from people doing the things." It's just a simple substitution, because "systemic" refers to a system, not an overarching one, so while we may not be able to ascribe these tendencies in The Technology Sector (or similar large group), systems have subsystems (a la culture vs. subculture), and it may be that those are where bias becomes encoded.
Newsflash: "race" is a bullshit concept that's a leaky abstraction on top of "ethnicities" at best (which is in turn a leaky abstraction on top of genetics and ancestry).
This addresses a straw man; nobody is saying that there is systemic bias against _all_ minorities, just some.
This in particular is the concept of a "model minority".
Culture difference cannot explain why women are not well represented in tech.
Culture difference can be a part of systemic bias, anyway. Let's say you have some programming job. The interviews focus on questions about frobbing linked lists (which is often the case). Now, it turns out that people from demographic A are more likely to focus on these questions when practicing for interviews, whereas demographic B focuses on honing the skill set they need for the actual job (algorithmy linked list stuff may not be necessary at all!).
You'd say that it's not possible for /culture/ to change how you study. There's hard evidence against that -- take India for example, CS students in India focus a lot on solving typical interview questions and less so on other skills. This stems from the general culture of finding and using a formulaic method of succeeding at academics. I don't like this culture (it ultimately leads to cases like kids who can solve whatever they need in quiz papers but don't actually understand the topic), and always have spoken out against it, but it's there.
But, you say, that's a different country, what about a minority demographic within the same country? Firstly, minorities more often than not are segregated into their own communities (socially, if not physically) due to various voluntary and involuntary reasons, and the effect can be the same as being in a different country (albeit milder).
Now realize that an interviewer will probably design questions around the kind that they are used to and that they (and their peers) would do well with. This is an unconscious bias -- interview questions are more often than not tests of how similar you are to the (often non-diverse) peer group of the interviewer, and not actually a test of how good you are as a candidate. This is an association fallacy, "all people like my peer group are good programmers, hence all good programmers are like my peer group". Of course, interviewing is often about avoiding bad programmers much more than it is about hiring good ones -- generally folks are okay with accidentally not hiring a good programmer, but want to avoid hiring a bad one at all costs. Thus tweaking your interview process to target a subset of the set of all good programmers isn't that bad, is it? Except that this targeting carries an unconscious bias inside it, and unfairly ends up disproportionately excluding minorities. If you're going to use a process prone to false negatives on purpose, be damn sure that the likelihood of someone being a false negative is in no way correlated with the demographic they are from. You may not have designed the process with this correlation in mind (hence, "unconscious bias"), but this bias is still there.
-----
And it doesn't have to be culture differences. You have a lot of other behavioral differences due to economic status or demographic which are unconsciously excluded in interviews. E.g. women are less likely to apply for jobs where they do not have all the listed qualifications, but men are very likely to apply, and get hired, because not all the qualifications were necessary anyway. The fix here is to be clear on what you absolutely need in a candidate, and what would be "nice to have".
And it doesn't have to be behavioral differences either. Sometimes it has to do with defining your inputs. Many companies focus on hiring from a set of people which itself is biased. It can be by hiring only from certain colleges (and then inexplicably whining about the "pipeline" -- you chose the pipeline!). It can be from having unconscious or conscious discrimination against autodidacts. Or code bootcamp folks. If you restrict your inputs to an already biased source, you will get biased results.
There are tons and tons of articles and papers out there about this. These aren't unknown effects. They're well established.
None of this is on purpose, of course (at least, I hope it isn't!). But it's still a bias, even if it's unconscious. And the onus is on the creators of the bias to fix it.
There are a million reasons out there why various demographics aren't well-represented in tech. It's just lazy to blame it on the demographics and say "it's cultural differences" without realizing the mistakes made by tech cos in making culture a factor in the first place.
> This addresses a straw man; nobody is saying that there is systemic bias against _all_ minorities, just some.
What bias occurs against my [Filipino,Vietnamese,Thai,Malaysian,Pakistani...] brothers, that doesn't also apply towards me, an Indian?
> There's hard evidence against that -- take India for example, CS students in India focus a lot on solving typical interview questions and less so on other skills...it ultimately leads to cases like kids who can solve whatever they need in quiz papers but don't actually understand the topic.
What about American CS Students, who presumably don't have a "teach to the test" based education system? They are well represented in tech.
I'm going with Google here. It's a pipeline issue. Fewer folks that pursue degrees in tech, fewer applicants in the pool.
> What bias occurs against my [Filipino,Vietnamese,Thai,Malaysian,Pakistani...] brothers, that doesn't also apply towards me, an Indian?
> What about American CS Students, who presumably don't have a "teach to the test" based education system? They are well represented in tech.
I gave the "teach to the test" example as an example of how culture affects tech interviews and why that's a problem on the interviewer's side, not as a specific example of why Indians do well in the U.S.. Nor was it a litmus test for "people who will do well in interviews", because many other factors contribute.
Though "teach to the test" is probably a part of why Indians do well. In my comment above I explained the mechanism by which the majority white-male-american tech industry unconsciously ends up crafting interviews where white-male-americans will do better. It wasn't about giving an exhaustive set of reasons as to why each demographic does the way it does. But if you want examples, just google "pipeline problem tech" and you'll get more than enough examples in the hundreds of articles out there about why the "pipeline" is a red herring, often with examples as to why various interview practices (or other practices) end up excluding demographics. I gave one example about women, and below I talk a bit more about "choosing the pipeline", but I'm not going to start a discussion where I give an example of systemic bias for/against one group and you ask why it doesn't apply to another group ad infinitum. These biases are complex, intertwined, and not always tangible. There is a simple mechanism as to how they appear, and lots of evidence that they exist (interviewing.io itself has done some of research on this by running voice modulation etc on their platform, but there's plenty more research otherwise too), independently of the pipeline.
Edit: I guess an example that folks might find easier to understand is in https://news.ycombinator.com/item?id=12860397 , it's an unconscious bias against self taught people. Most self taught people are pretty picky in what they actually do, because they're often doing it for fun. On the other hand, if you are a CS student, you will learn whatever is taught in colleges, and follow what your peers do (e.g. practice coding puzzles for interviews). So a self taught person may not be great at coding puzzles because that's not an actual skill that they've ever needed when coding for fun, whereas CS students tend to be competent with these. I know many autodidacts who have had issues with this but are otherwise great programmers. I myself am self taught, and while I did practice coding puzzles, I have felt such biases too.
> Fewer folks that pursue degrees in tech, fewer applicants in the pool.
...
> degrees in tech
and here it is again, you're choosing your pipeline. I just talked about that. There are plenty of autodidacts out there. Plenty of folks (often from a lower income background who cannot afford college, or be able to juggle college and work) who go to coding bootcamps. Plenty of folks who do go to college, but go to less prestigious ones because they can't afford it or they have to go to college near their holes (and they have less mobility because of job/family to support/whatever).
Again, there are articles all over the internet about this. I recall reading about companies which target historically black colleges in their interview process. They don't quota it or otherwise disallow people from interviewing with them; they just go to the colleges for campus interviews. No different from other companies who go to Stanford for campus interviews.
It's a pipeline issue but there are ways to cater to certain groups (see affirmative action). The question is, why is there a need to cater to certain groups? Incongruity is present in every field, every job, every company, everywhere.
As long as opportunity is sufficiently available for everyone (which it is, one can learn to program, get input on their code and collaborate with other people on the internet without disclosing their gender/age/race), that's good enough.
> The question is, why is there a need to cater to certain groups?
Have you ever used software or website that was written entirely by an offshore team and felt that it was a bit "off"? The translations were a bit wonky and the interactions felt somewhat unintuitive?
Most people have and we're more than willing to attribute it to a lower skill level, but it's also the case that clear and intuitive aren't universal concepts. White men make software that's intuitive for white men and less so for other groups. The more than you can blend different perspectives into the product development process, the more the finished product will appeal to those represented perspectives.
There's a reason all the big tech companies are trying to address their lack of minority representation, and it's only partly PR. It's also the case that these companies have largely saturated the tech-savvy market where the demographics look similar to the demographics of their employees. And in a world where high valuations require growth, reaching those under-represented groups of consumers is critical to achieving that growth.
> Have you ever used software or website that was written entirely by an offshore team and felt that it was a bit "off"? The translations were a bit wonky and the interactions felt somewhat unintuitive?
Translations off? Sure. Unintuitive? I don't know, but let's say I'll give you that. The offshore team lives in their own cultural bubble, where English is used in a particular way(incongruent with what I/you are used to), and maybe they like to place their menu on the left instead of on the right. I can see, intuitively, the link between "local differences" like language proficiency and cultural preference, and producing a different product.
You then cite "white men" making software that's intuitive for "themselves". I don't see any intuitive characteristics that would encompass "white men" in any meaningful way. There's white men in the US, there's white men in Russia. The white men in Russia don't build applications the same way the white men in the US do.
I can instinctively tell the difference between a german developer and a US developer(visible language differences). What are the common factors attributable to "white males" that lead them to create software that is intuitive for them?
I agree with 98% percent but I just can't see everyone designing all of their systems on top of unfounded biases against "just some" minorities and that demographics are blameless. They do have nasty effects on each other though; demographics shortcomings confirm bias and bias prevents demographics from alleviating shortcomings.
Remember, it's not intentional. And the biases aren't overt. A lot of it boils down to "I want to hire people like me", where "like me" refers to academic and professional past, but the kind of academic/professional past you have might actually be a characteristic of your demographic without you knowing it.
why? why should you be more inclined to think the explanation is found in a pertinent cultural difference between two large groups of people, (asian women, non-asian women) rather than that the explanation is to be found in the culture of one, small group, (tech)? maybe you're right, but i don't understand the inclination.
> I am less inclined to believe there is systemic bias against women, and minorities, and instead a culture difference between groups who are well represented in engineering, and groups which are not.
This reveals a complete misunderstanding of how "systemic bias" occurs and persists.
[Edited with further thoughts]
"Cultural differences" don't just appear out of nowhere. Culture itself is an amalgamation of different human experiences that have combined and recombined over tens of thousands of years. It's not static. The things you deem "cultural differences" have many causes, and "differences" can and do change all the time.
When we throw up our hands and say "cultural differences", it implies that we don't need to ask why such differences might exist and whether we should actively seek to change them. That's an important conversation.
"Systemic bias" may or may not exist in this case, but if you think cultural differences themselves can't lead to systemic bias then you are mistaken.
What bias exists that targets women, and minorities, but doesn't also target Indian, Chinese, and Russian woman, and Indian and Chinese men[1]?
> When we throw up our hands and say "cultural differences", it implies that we don't need to ask why such differences might exist and whether we should actively seek to change them. That's an important conversation.
Except the article (and conversation) isn't about cultural differences, but instead about "diversity problem[s in tech]" and in this case, how the technical interview unfairly penalizes underrepresented groups.
1: I believe that in general, Caucasian Russian males can be safely lumped into the "white male" category that dominates the tech industry.
> ... in this case, how the technical interview unfairly penalizes underrepresented groups.
If this was your big takeaway I think you should read the article again. It's not about unfair penalization.
People fail at technical interviews all the time, men and women alike. The article doesn't assert that there's the kind of simple bias that would cause women to unfairly receive lower marks in an interview compared to an equally-qualified man.
The article reveals that women react differently to negative signals from the technical puzzle-based interview process.
You've tried to assert that this is due to "cultural differences" (your words, not mine or the article's). And I'm saying that's too naive an explanation, and we should look further.
The reason this comment is getting downvoted is not because it's (necessarily) incorrect, but because saying only "You just don't get it" in fancier words contributes neither to understanding nor to the discussion.
"We believe that technical interviewing is a broken process for everyone but that the flaws within the system hit underrepresented groups the hardest… because they haven’t had the chance to internalize just how much of technical interviewing is a numbers game.”
I understand that people here hate technical interviews, but are we going to skip over the fact that the whole premise of this article is that the technical interview is awful for everybody, but minorities are more affected, because their poor little brains can’t figure that out? It’s ridiculous that you’d ever even propose that some "VP of Diversity and Inclusion” has anything to do with hiring of engineers. Why is this garbage being given any thought on HN is baffling to me.
Someone gets it. Funny how people who are so "moral", actually end up being incredibly immoral and biased.
Here's a question: if there's such a demand for solutions that solve a problem that the "majority" can't see, why don't women and minorities just start their own companies to solve those problems and make piles of $$$?
Reality check: building a good team is a struggle for every race, culture, gender, and individual in every industry on the planet. I get it though, it's a lot easier to mooch off of actual engineers who build solutions and then act like they had some significant impact as the "Director of Diversity".
Keep riding those coat-tails, maybe one day you will invent something on your own that isn't pseudo-scientific bullshit and actually improves people's lives. Go on, I DARE you to run your own startup and actually try to hire good help. You'll quickly find you have no time for such nonsense and only care about getting $*!@& done.
This is because the technical interview has completely degenerated into an arms race. It started with good intentions. It used to be just, here's a problem, try to solve it and let's discuss. And at first it was fine. But then knowing Big-O, algorithm, data structure, etc. became a way to "show off" and impress the interviewer. So everyone started to focus on those to impress the interviewer. Then the interviewers noticed and started to state they would only be impressed by more and more obscure algorithms and data structures.
And then the real downward spiral began with the publication of Cracking the Coding Interview. More books were published, a whole industry to support this. Then came the sites like leetcode and HackerRank. Now there's a lot of money supporting and pushing for continuing this stupid process. And the arms race just keeps getting worse and worse. The interviewers expect more and more obscure algorithms and data structures and justify it with "must avoid false positives". This just increases the study time for candidates and they're willing to spend time and money to do it. And the tech interview industry (all the books and sites) are happy to push this arms race since it's more money for them. Now they have enough money to go openly defend the tech interview as the "best practice".
It's not even enough to get the right answer now. You have to do it fast enough or you fail. And now they care about syntax on a whiteboard. None of this used to be true. It all started as a way to see how you approach a problem and discussing it. No expectations that you would correctly get Algorithm ABC and Data Structure XYZ. No expectation that the syntax is correct, pseudo code was ok. No expectation even on a complete working solution, the point was just to see if you can reason about the problem.
All that is gone, replaced by the tech interview arms race. Now it's just a massive speed pattern matching contest to see if you've studied enough to hopefully cover the obscure problem the interviewer will pick and if you can correctly pattern match in time based on the hundreds of questions you did on leetcode. Completely useless and against the original intent of tech interviews.
I postulate that false negatives are far more expensive, in a constricted talent pool. We keep seeing the adage that false positives are expensive but honestly if one cannot spot a false positive within 30 days of engagement with that person, then the hiring person should really contemplate their expertise in the field.
I saw a really good write up (I think on here) where they basically did a initial "are you an idiot?" round of interviews and then contracted every person that they thought might be a viable (not good just viable) candidate with a small piece of software for 2 weeks. This amounted to 3 candidates IIRC the TL;DR was that the person they thought was least likely to perform knocked their socks off. The one that crushed the interview asked for more time and then just fell of the radar. The technical code test and trick question interview is a tired fingerprint of the industry. Honestly if one cannot spot technical talent by having a 30 minute conversation with a person, they may want to reassess where they think they are in their own technical and managerial skills, because they may want to reflect the possibility that they are engaging in a weiner waving contest as opposed to an interview, to stroke their own ego.
Imagine that you passed your dream job interview, you pack you things and move to another state! 30 days into the new job you get the news, you are fired for being a low performer! You go online and post about your experiences, how horrible this company is for not looking out for their employees. You get a lot of responses saying that they have experiences the same, a large part of new hires are fired within the first month at this company!
Now tell me, do you think that said company will get many quality applicants in the future? At least I prefer harsh interviews and then being relatively safe compared to the reverse.
I did not go into deep detail about the article because I did not want to misquote it but my understanding was that they sent the prospects a VM with the entire dev environment running. Gave them a simple but real task that they needed accomplished and remote contracted them to complete that task (with compensation). They (the prospective developer) were given a full software spec, and access to the development team. They did track the time the team spent with the developer and did review the returned code. At worst it was a side gig with some income for the two week. IIRC 9K to each candidate whether completed or not. The way the process was structured was so that there was little risk to the applicant. The whole experiment was to expose their companies bias in the hiring process and the summation was they found it eye opening.
People keep talking about doing these "trial" periods but the people I want to hire are the type of people who have enough options that they wouldn't agree to do some two week trial period when they have four other companies offering them a full time job with no strings attached.
I wish I could do paid trial periods for everyone, I just think this will filter out far more people than having a restrictive interview process that works specifically to filter out false positives.
So with a paid trial you will generally filter out the best people who have other options while a more restrictive interview process would generally filter out the worst people who couldn't make it past a difficult Skype interview and a difficult onsite two hour pair coding session.
The problem is as the company in the article articulated, they thought they where filtering for the best but found out that they where not. The guy that they all agreed would be the best selection submitted a ball of code that was not cohesive and incomplete. The one who actually made it thru was the lowest on their list. IIRC their intent was to all three if they submitted good work.
The whole intent of their experiment was to show them exactly what we are talking about, you are selecting people based on their sales skills not based on their technical skills. 99% of the time people don't develop while someone is watching them over Skype or pair coding where they know they are being graded. They develop at their machine and if they get stuck they know they can turn to a close confident and ask them a question without being graded on it. The point is how well I perform under a microscope is a huge factor in your decision making process and it is not normal. Therefore it acts a a huge bias filter and one that does not amount to a hill of beans in every day development.
I am not saying that what the company in the article did is a workable or salable solution to hiring, but I am saying that it exposes what many of us, with multiple decades in the industry have been saying and that is hiring is broken and people in the industry are very bad at hiring because they let all kinds of bias in. One is salesmanship as highlighted in the article, the best salesman usually gets the job. Another big one is developer ego and sadly it is a very real thing in our industry. I will see if I can dig up the article.
From my perspective there aren't any other methods that are less arbitrary than several interview coding sessions.
Doing no coding sessions are more arbitrary because it is far easier to BS a non coding interview than it is to BS a coding interview. Doing paid trials are more arbitrary because you are excluding anyone who can't devote two weeks of their life to a trial that may not amount to anything.
So from my perspective intensive coding sessions, although far from perfect, are the best system we have, so our effort should be placed on recognizing the weaknesses they present and working to construct your interview in a way to minimize them.
For us we very proactively (and without judgment) give advice throughout the coding process - if it is clear someone is stuck on something small or easily Google-able we will simply tell them so they can move on to actually solving the problem. If they are stuck on something bigger, we will talk through the problem with them in a way that would make certain approaches apparent to someone who is a halfway decent programmer.
I am not saying that any of the above is perfect, but I think trying to construct a programming interview that tries as hard as possible to mitigate unimportant factors that could lower interview performance (such as nervousness or getting stuck on something simple and panicking) is a better approach than any other form of vetting I've ever seen.
> But then knowing Big-O, algorithm, data structure, etc. became a way to "show off" and impress the interviewer
How is knowing the very basics of CS a way to show-off? It should be requisite shouldn't it?
That said, I agree with the degeneration to arms race. I'm awaiting an interview question on Shor's algorithm. "We like to be ready for whatever the future may bring here at LolCorp."
How often, in your day job, is it a necessary job-related task for you to be pop-quizzed on the Big-O characteristics of half a dozen data structures and then have to draw out manipulations of a binary tree on a whiteboard?
Somehow we decided to never test for the things we actually do at work, and instead to invent an entirely new discipline (whiteboard interviewing) and test for competence at that, in hopes it would translate to doing well on the job.
Thus far the empirical evidence is not particularly great that testing for the skill of whiteboard interviewing translates to success on the job, and there's a growing body of evidence that it excludes the most desirable people (since experienced high-quality candidates are likely to have been out of school, or whatever they used to learn "fundamentals", for long enough that the things tested in a whiteboard interview are not close enough to the top of their minds to consistently pass).
I mean, I think the whiteboard thing is pretty lame, and would prefer to give and get coding tests on my own machine and environment.
But yeah, I expect someone to be able to tell me what the complexity of various algorithms when shown them is and how to manipulate common data structures. At the very least one ought to be able to walk a tree don't you think? My front end engineer has to walk a tree of JSON on a project right now. I'm glad she can do it.
And yet... this attitude is how we get stuff like the Homebrew guy tweeting that Google is happy to be internally dependent on his software while also saying he's not qualified to write software for Google, because their tech interview excludes him.
(Google's interview process, in my experience, can be gamed heavily by just memorizing a dynamic-programming solution to the longest-common-subsequence problem; they love popping that one out in interviews, even for job descriptions which have no reasonable need to ever be able to regurgitate it onto a whiteboard on command)
As far as I remember, the guy comes from the team that didn't understand what
the heck are digital signatures for in package management. They refused to
acknowledge the problem that they hosted everything through raw HTTP with no
signatures whatsoever. This may be a hint that he indeed was not qualified.
Not to mention that people constantly complain about how Homebrew works with
its dependency resolution, compared to how people rarely complain about
Yum/DNF or APT.
Stating for the 1e100th time in discussions of this topic: whiteboard interviews do not test coding ability and do not usefully distinguish people who are able to code from people who are not. So any argument proceeding from the assumption that doing away with them equates to no longer testing for ability to code is invalid and contains a known-false assumption.
Yes I agree with this. I even stated as such, that I give and prefer to get coding tests using an actual computer. I'm not talking about those.
f I ask someone the complexity of searching a binary tree, or show them a double for loop with that iterates over the same collection in each loop, and ask them the complexity of that, I expect them to say logn and n^2. Bonus points for addressing best, average, and worst case performances and what kind of data drives those.
If I ask someone to write a small program at their own laptop to parse an integer, I expect them to be able to do that. This shows the absolute bare minimum in competency at the job you'll be asked to perform.
Other industries have higher costs for employment and pay less.
For example, teachers often have to spend thousands of dollars out of pocket to take tests to get various levels of certification just to start teaching.
I'm afraid our industry is moving in the same direction.
It will start becoming more and more expensive just to get the damn job. It's already hard enough.
Soon all costs of training an employee will be pushed off onto the employee themselves. "You must be able to jump this high (and spent $$$) to work here."
Technical interviews are moving in the direction of more concreteness
Herein lies the scam. (Disclaimer: It's not on purpose, they're lying to themselves too)
Just because you have a process to produce a "concrete" result, that doesn't mean it doesn't stand on a house of cards.
I'd have to sit and have a think to make a clearer explanation than by analogy, so here's an analogy. This reminds me of the way people with an insufficient anti-authoritarian streak are more willing to question a person's on the spot decision than a decision from systematic, bureaucracy or law.
Just because more time and process has gone into establishing them, doesn't necessitate that the decisions are any better founded than what some rando pulls out of their ass.
Because, at the end of the day, taking the technical portion of the interview itself too seriously is the real fraud. There is exactly one way to tell how well someone will be able to contribute to our team, with our technologies, in our environment after a few weeks of getting up to speed. And that's to hire them.
The technical portion of the interview isn't useful beyond a low-bar rule-out criteria. After that, the technical portion turns back towards the softer skills of how the interviewee handles hitting a wall at problem solving in a field where nobody knows everything.
The current environment in tech is as follow: Someone goes through an interview process. Depending on the result, they get brought in or not. If they are brought in, they accept an offer. Usually it will contain some kind of language about blah blah trial period 3 months blah blah, sometimes in precise terminology, sometimes vaguely.
If someone is absolutely useless right off the bat, immediately everyone's like "but but we need to coach them, they just started, they'll get better". If after 3 months they're still useless, then it's "Blah blah it's the company's responsibility to keep them around and coach them because we hired them and we failed at interview".
That can only happen so many times (and can ruin teams or entire companies) before you start getting downright paranoid when interviewing. Maybe you have a lot of false positive and false negative, but if your interview process is Google-like enough, on average you'll turn out okay-ish (source: Google/Facebook/Netflix/whatever other company with such an interview process. They have some pretty strong teams in there). But since it's so hard to get rid of a bad apple, you can't take risks (Im being told Netflix is good at getting rid of people).
Change the game a bit: make it easy to get rid of bad apples early on. You know the interview process is bad anyway. Give people a chance. If they're actually competent, they have nothing to worry about. They'll get hired, prove their worth, and stick around. If they're bad, well, bye bye. Then we no longer have to rely on excruciatingly stupid interview processes.
A lot of people think this is inhumane/heartless. That big evil corporations MUST provide people with jobs and must keep them no matter how bad they are because they have bills to pay. I say its heartless to not give people a chance to prove themselves (or to fail while at least trying).
Do you have to give people a permanent contract right away in the US? In Netherland, people usually get a temporary contract at first, and then a permanent one. Too much uncertainty isn't good of course, but half a year to prove yourself is not unreasonable, I think.
(Though there are Dutch companies that abuse it by extending temporary contracts without ever giving a permanent contract, and sometimes even let good employees go because they don't want to give them a permanent contract.)
It already happens, it's called contracting. And the results are terrible because no one gives a fuck about quality at a job the might not have in 3 months.
Small caveat - I'd say contract-to-hire is what many places are implementing if they actually want the headcount instead of just a budget expenditure. The problem is that you end up with worse candidates because most people who are really good don't want the uncertainty and stigma of a contract position if they can get a full-time one elsewhere.
In the UK, specifically in London, you'll be a lot better off contracting and as a consequence when you look for senior engineers you'll have a tough time finding someone perm as most senior people who know their worth will be contracting/consulting.
Fair point, but in my experience the extra money is basically a wash when you factor in healthcare costs (I'm in the US), self-employment taxes, lack of employer-matched 401k, unpaid vacation, and the realistic utilization rate you can expect averaged out over several years. If you can keep your rate and utilization up you can definitely do better contracting, but a lot of people prefer the perm setup.
The pension contributions and paid vacation is nice but it doesn't make up for the difference in income. Also contracting means that you can essentially decide the holiday/income ratio yourself.
One of the main benefits for me is that I usually get bored/sick of working at particular companies after an extended duration (the work can get repetitive). Contracting means you can job hop, gain a wider variety of experience and take extended holidays without stigma.
I've found the extra money to be an illusion when you consider public holidays, sick days, holidays etc.
I've found it to be a net negative when you consider time between contracts. Contracting really needs to be about double your salary to make it worth it.
nah, that sucks. What I'm talking about is how Netflix does it (or at least, how Ive been told they do it).
You start working there for a premium salary and you're expected to deliver accordingly. If you don't, you get a generous severance package and politely ask to leave. And you know about that when you get hired.
the counter-argument is that when you fire someone, their co-workers, generally speaking, become at least a little uneasy (usually the level of unease is directly proportional to the level of agreement that the person getting fired wasn't good enough or otherwise had it coming, but there is still some unease even when it's obvious that it's the only way forward.)
Now, you can try to get around this by a real trial period (either contract-to-hire, or being super clear that the trial period is actually a trial period) - if you fire an employee of a obviously lower class, employees of the higher classes won't be as disturbed as if you fired one of their peers, but then you have the contract-to-hire problem, which is that people will usually choose a job perceived to be long-term with a low risk of being fired over any sort of 'trial period' - a large portion of your top applicants will turn the job down if they have to spend time as a lower-tier of employee first.
you're right, people get uneasy about it, but they get really uneasy when you keep bad people.
I've seen entire companies evaporate because a bad apple stuck around, people who had to work with them quit, then more quit, and eventually the whole company was just mediocre or bad people and they couldn't run with that anymore.
Kind of the broken window problem applied to people.
Sure, but my point is that there is a high cost to firing people. I agree that there is also a high cost to not firing someone when it needs to be done, but the two of those things combined explains why employers want so badly to get it right the first time.
Notice that according to the very figures cited by the article and released by Google and Facebook, as well as other uncited figures released by Yahoo, Amazon, and LinkedIn, whites are actually underrepresented with respect to the general population of white Americans, not overrepresented, and minorities collectively are therefore actually overrepresented, not underrepresented. This is primarily due to Asians being so overrepresented with respect to the general population of Asian Americans, by as much as a factor of ten.
Yet amazingly, the charges that tech "lacks diversity," is "too white," or even "overwhelmingly white"[1][2][3] haven't let up even as the hard data refuting them has become available, and may even have intensified. In fact, many of these critics, like the author of the linked article, actually attempt to use the very data that refutes their point to somehow support it--an indication, perhaps, of the "post-fact" era leftists so often complain we're now living in.
Little wonder is it then that Trump's white supporters despise journalists so much, considering how deeply so many journalists seem to despise white Americans.
I agree that tech interviews are terrible, and you cannot do any sort of self-reflection on them (especially if they are these q/a and or puzzle types where they don't give you answers or feedback of what you are looking for, despite being reasonably confident you answered correctly -- even after having requested the feedback -- I had this experience at GitLab)
> We believe that technical interviewing is a broken process for everyone but that the flaws within the system hit underrepresented groups the hardest… because they haven’t had the chance to internalize just how much of technical interviewing is a numbers game
I just don't understand this reasoning. Can someone explain differently?
I also agree with a later point -- no firm should have a "VP of Diversity and Inclusivity" but for different reasons.
I think the next couple sentences explain it well:
> It takes a lot of interviews to get used to the process and the format and to understand that the stuff you do in technical interviews isn’t actually the stuff you do at work every day. And it takes people in your social circle all going through the same experience, screwing up interviews here and there, and getting back on the horse to realize that poor performance in one interview isn’t predictive of whether you’ll be a good engineer.
If you don't have friends in the industry and you don't have the time and money to go interview at 10 different places, 1 or 2 failed algorithms interviews can be very discouraging and might convince you that you're not cut out for this industry. In fact the "Poor performances hit marginalized groups the hardest" section has actual data showing that women are much more likely to stop trying after 1 or 2 failed interviews.
But this can be literally true for anyone. I tried re-reading it again and again and I am not seeing the distinction. Different people have different reactions to things. In other fields, it's not uncommon for people to submit resumes to 10, 15, even 20 firms and go through 5 to 10 interviews before landing their first "real" job. I think we forget how good we have it in tech relative to the rest of the economy. It's either that, or work for shit wages and awful benefits. But we don't hear about the diversity problem for a position like, an "analyst" for example. This lends me to believe it really is a pipeline issue.
It can be, but marginalized people are much more often given signals that they don't belong, that they're not as good. They also tend to have less to fall back on when breaks don't go their way because of historical and current marginalization.
I'm trying to find a previous discussion on this that had some numbers, but the same "early quitting" pattern is seen at the university level. Women go into STEM, do badly in a class, then change majors. So yes, there's definitely a pipeline issue, but that issue is the same root cause. Sounds like we need a root-cause analysis to find and fix the underlying issue.
EDIT: Can't find the previous discussion I'm looking for, but Wikipedia has a pretty good section with hard numbers:
People in other fields do not go through this while simultaneously being told how their is a critical shortage of people with their skills. The disconnect is probably very off-putting to people of certain persknalities. Personalities which happen to be over-represented in certain minority groups.
See my edit, I said I think I agree with the premise the author was trying to rebute -- maybe it actually is a pipeline issue. (Side note, I don't think this article is specifically about women, but underrepresented groups in general: women, african americans, hispanics)
I think this was one of the biggest take-aways I got from attending a coding bootcamp, honestly. Basically everybody failed their first on-site interview, even the strongest candidates from the cohort who went on to get the best overall results.
For PhD science in industry, I remember my father sending out about 1000 resumes on paper. He took a 2-month drive around the USA for interviews, dropping in wherever he could convince somebody to meet him.
There's a reason why coding bootcamps now tend to have a section at the end, entirely separate from teaching coding, on how to pass technical interviews, because technical interviews are increasingly completely divorced from the skill of knowing how to code (despite the claim that failing a technical interview is unimpeachable proof that a candidate was an impostor who was "lying" and "couldn't really code").
I consider myself a competent developer, but I have no academic background as I am self-taught. While I have had a steady supply of work, because of this, I will most likely never get to work for a big company like Microsoft, Google or Facebook because I wouldn't pass their technical interview. I lack the understanding of core computer science principles and I am okay with admitting that, I don't think it makes me a bad developer or inferior to my peers who have computer science degrees. Most developers I know envy the fact I have no student debt and said if they could do it over again, they would go the self-taught route.
Technical interviews are broken because they favour developers fresh out of college or with academic backgrounds. Not every development task is a coding problem or puzzle, rarely do you ever need to write your own algorithm implementation in real world situations. The times you do, most developers (even the intelligent ones) will Google. My problem solving ability is decent enough I am at a senior level and always complete what is asked of me, but give me a code golf/coding puzzle and unrealistic constraints like only being able to solve it on a whiteboard? I will fail. Ask me to solve problems on sheets of paper as quick as possible? I will fail.
Give me a laptop, an IDE and ask me to build something. Better yet, sit me down with one of the developers in your team, give me a simple Jira task and ask me to help solve it pair-programming style. I would rather hire a developer who can get things done opposed to being able to solve a non-real world programming puzzle I found on Google. Interviews seem to forgo the highly acknowledged fact that developers rely on Google/StackOverflow than companies care to admit.
Problem solving is one percentage of the hiring equation, being a great developer also requires patience, cooperation, understanding and communication. I think above anything else, a developer who is a good communicator is a dream combination. I would take communication skills over coding puzzle solving skills any day of the week.
Even the much beloved FizzBuzz test is a scam. Any developer can memorize a FizzBuzz implementation 10 minutes prior to the interview. I never understood how this was a valid metric for determining suitability of a candidate, when candidates have come to expect a FizzBuzz test coming up. Maybe it worked in 1999, but not in 2016.
I'm one of the people who ask those algorithm/white board questions. I've read a lot criticism on this topic, here're my reasons to stil keep asking these questions:
1) Working on algorithm problem requires very little in common between interviewer and interviewee. I'm C++/C#, I won't be able to give Ruby dev a real world task and evaluate it properly. Algo/data structure problems are universal and looks similar in any language.
In my practice I completely failed to make any conclusions by talking about previous experience. It was not clear to me what person actually did vs what was already on the project, may as well just fixed couple UI bugs on the complex project. This part might be might personal failure as interviewer, but it was it is, and I've seen enough developers with years of experience who barely code. So unfortunately having great resume doesn't prove anything.
2) Everyone knows that big tech companies ask these questions. Knowing that you didn't take to prepare, says one of two things to me: you don't find it interesting topic/usefull or you don't have enough grit to go thru that.
When I prepared for the interview I went thru two algo books, it took some time but it was easy for me, I did enjoy the learning part, yes it's not something I use every day. But learning things is a trait of good developer, knowing fundamentals if part of that. Some folks found it useless, but since it's known fact that's being asked on interiewes, motivated developer would spend time and learn it. Over the years at work, we have to learn things that are not interesting and that I'd rather choose not to know at all, same as algorithms to some people. If you can't make yourself learn algorithms to pass interview, likely you wont learn things for the work too.
Your first point suggests these questions have some value for you in identifying people's skills. Fair enough.
Your second argument admits that this is basically a hazing ritual. Of course you will have to learn some things you don't intrinsically care about in the course of your work. The difference is, that isn't part of a process that we intentionally designed to be that way. Admitting that your hiring process requires useless knowledge that people just have to learn to get through the process means you admit your process doesn't measure what matters and is just a hazing ritual. You're putting up hoops just to see who will jump through them.
You can't make conclusion just from second argument alone. It's not hazing ritual because my first point. But I also think knowing them is useful, but I see a lot of people arguing it not needed at all. So what I tried to say in second, that regardless of what one thinks on usefulness of Algo knowledge,there's no excuse to ignore algorithm and expect to pass interviews.
If you think it's not necessary for the job but it's necessary for the interview, then at least we can agree the interview process isn't so great.
Of course, knowing how to play the system is part of getting a job, but we can still point out that the system is broken. After all, these are systems we set up ourselves.
As a fellow engineer who also performs technical interviews, I cannot accept your first point.
Solving trivial problems does not give you any useful information about how a person solves nontrivial problems. This is especially true if you are not specifying the language the candidate needs to use.
What if I solved fizzbuzz in Haskell? It certainly would not look like a c# implementation, and you wouldn't be able to judge anything about it other than maybe it might produce a correct answer- is it idiomatic? Is it performant? Will it even compile? Technical interviews (especially when you consider candidates outside of your current language / stack) are about assessing capability and trajectory - willingness to learn and adapt. Rote memorization of objective problems that can be found online tell you nothing about how they will solve problems on the job.
As for point two, memorizing solutions to problems with objective answers isn't a terribly valuable skill; presuming that it should be a requirement without announcing it in the job requirements is certainly analogous to hazing. Unless you want a team with little to no creativity, you are selecting for candidates that do not demonstrate what you actually need- and the success of your team is in spite of your hiring process, not enabled by it.
I am sorry if this came across as either personal or exceptionally harsh, but I am pained by the amount of incredibly intelligent people who are willing to accept that suboptimal things ought to be, simply because they are.
One of the biggest contributing factors for a team's - and company's- culture is its hiring practice, and it deserves far more attention than what our industry gives it.
Yeah I'm not arguing it's suboptimal, but I don't see better suggestion. What are you doing instead?
"Assessing the capabiliyt and trajectory, willing to learn and adapt" - that's the intent of the algo/data sturcture related questions. The questions are not about knowledge of specific algo, but assess way of thinking and write some code. Typically solution include recursion, nested loops, pointers/references, some not-trivial composition, etc. I'm never expecting candidate to know the specfici algorithm righ away.
I'll address your second paragraph before returning to your first question- I think my answer will be a little more cohesive that way.
The fundamental problem with whiteboard / live coding technical interviews is that you're selecting for candidates whose strengths aren't necessarily useful on the job.
They:
- have memorized answers to solved problems
- work well under immediate pressure
- demonstrate knowledge of basic programming techniques
They do not:
- demonstrate collaboration
- demonstrate researching and gathering requirements (i.e. no access to the internet)
- demonstrate planning or reasoning about business requirements
In short, yes, they're solving problems, but they're not solving the same kinds of problems that you'll need them to solve on the job, nor are they solving them in the same way they'll be solving them on the job.
These interviews select based on superficial qualities, and practically ignore the qualities of top candidates (teamwork skills, interpreting technical requirements from business requirements etc.)
I had typed out a lengthy explanation of the process I'm currently using, but I realized I don't want to go too deeply into the weeds. In short, design a small challenge application for candidates to build, with the expectation that it'd take no more than a handful of hours, and let them turn it in on their own time (say, within a week). If they "pass", bring them in for a second, technical interview, which is a conversation based on what they submitted (i.e. how could they do X better, how would they add new feature Y, etc.)
The benefit of that kind of process are numerous:
1- The time commitment of candidates is the same as a long whiteboard interview (or set of them), and they don't need to commit to all of the time at once (takes less time away from their current engagements)
2- The time commitment of employees is reduced to ~2-3 hours (one to evaluate, one to interview)
3- candidates are building a small application, meaning there's not an objective answer to be found on stack overflow to memorize
4- candidates have time to ask questions and demonstrate skills they are passionate about, but might not have been specifically requested- say, testing, user experience, flexible architecture to support future features, that sort of thing
5- The second interview becomes a relaxed conversation, where a broader selection of engineers perform well, as opposed to the more biased high-pressure scenarios that aren't typical of our day-to-day
To do this well, of course, you ought to review the challenge and process each year, and have (preferably junior) employees test it to ensure that it will be respectful of candidate's time commitments and the value of the information the challenge will provide an evaluator. Given that you want to keep it limited to a few hours, you'll need to balance features that you think will be interesting with features that actually yield interesting information about the candidate for a second interview- anything that can be learned by simply asking a question doesn't actually need to be included.
Finally, to return to the original topic of this thread, you potentially eliminate certain cultural biases that are irrelevant; not only is the candidate demonstrating capabilities more reflective of the job itself, but they are doing so before ever meeting in person.
1) If you're trying to hire a Ruby developer to write Ruby applications and that's not what you're screening in interviews, you're not proving anything relevant to the candidate's ability to do the real world job. Between not having anyone to interview and an algorithm interview, I get where you're coming from. But if there is any other choice, you shouldn't be giving the technical interview to someone whose practical skills you can't assess.
2) There are a billion things to learn as a technology professional. The time you spend practicing specifically to be able to whiteboard algorithms for interviews is time you're not spending doing something else. Something that will be more beneficial to you and to your business on a day to day basis than learning how to interview well. So choosing to do those other things instead doesn't show that you're not engaged.
Yes if you need specificly Ruby dev, you ask Ruby (though only if you need it now right away, may as well hire contractor for a few months in this case). Imho smart developer can pick up Ruby fast (or other stack fast) and that's the benefit of algorithm related question - you don't have to pass on candidate that don't have experience in your stack.
Yeah... FizzBuzz still works. A large percentage of phone screens fails it. It's not meant to be a signal you're a good developer if you pass, it's meant as a signal you're an atrociously bad one if you fail. Most people don't bother to even memorize it, and those who memorize are thrown by slight variations.
Sure, but the important bit is that if you completely blank and forget about % (I have done so) you can still solve it easily if you're a half-decent programmer.
Not to mention that if I see a candidate is stumped on the modulus part I'll offer them % myself.
> While I have had a steady supply of work, because of this, I will most likely never get to work for a big company like Microsoft, Google or Facebook because I wouldn't pass their technical interview.
The stuff people complain about (big O, data structures, algorithms in theory) are stuff even us with degrees have to study and relearn before job interviews. I think you might be underselling yourself. Those big companies use questions like this (often instead of hard checks for degrees) specifically to allow self-taught coders who are good an opportunity to get in.
To some extent, as other have posted, it is kind of silly, but you might be able to look at it as a leveling of the playing field.
> I never understood how this was a valid metric for determining suitability of a candidate, when candidates have come to expect a FizzBuzz test coming up.
It's not--it's a metric for determining unsuitability.
Honestly, the more I read about all those "diversity initiatives", "outreach campaigns" and "pushes to increase H1B" caps - the more I wonder about the intent and motivation of the people pulling the strings and funding the groups fighting so hard to further those causes. My comment is only tangentially related to hiring practices.
Maybe age has turned me into a cynic, you can never know for sure, but this seriously starts to look like an organized campaign to 1/ increase the supply of engineers in the valley 2/ increase competition for access to a limited supply of jobs 3/ maintain engineers as a inexpensive, replaceable and unorganized workforce (in the face of increasing demand).
To address the diversity numbers of Facebook, I wonder what are they exactly suggesting when they mean that it is not "diverse"? At the risk of sounding like a white supremacist (I am Vietnamese) that very much sounds like a code word for "too many white people" or "too many asians". To clear that out and maybe find out that I am mistaken, I want to know with what kind of demographic breakdown would proponents of diversity be pleased. Should it follow the US racial distribution? Or have equal proportions of people from each race?
Finally, I think that a breakdown according to class would be much more interesting than this document. Since race is only skin deep, I do believe that having people from all walks of life would be a better optima than having people of different colors (that are all upper middle class).
Expanding the hiring pool is valuable to these companies. Many companies also feel like they'll perform better with a more diverse group of employees. I sure felt like that about my company.
They probably _also_ feel like it's right. This is one of those social problems where both the business need and moral need match up.
My guess is that people who want racial diversity want class diversity, diversity of thought, cultural diversity, etc. These are not exclusive problems. In fact, if we got to a world state where race played no part in someone's job opportunities, I expect it would be easier to tackle the others.
This is mostly empirically provable [1]. Diverse teams come up with better ideas that apply to a larger swath of markets (an immediate payoff for companies).
And the applicability of studies of the value of diversity in an executive team attempting to strategically position themselves in a market to a team building a compiler is questionable to say the least.
Even making your product appeal to a wide market often isn't recommended for small companies. We often see posts here about focusing on a specific winnable market and going from there.
In a vacuum, I'd imagine that having likeness between the customer and the developers to be far more effective than general cultural diversity. A team making a compiler is programmers making a tool for programmers, so it's an excellent fit. I could see cultural diversity becoming more effective once you're trying to reach the general public or niche markets.
Your statement to "hire the absolute most productive" implies that no woman or black or hispanic person can be "the absolute most productive", because there is no reading of your comment which makes sense without the assumption that you believe this.
Congratulations, you've exposed yourself as possessing irrational biases and allowing them to influence how you'd hire, while showing no desire to eliminate, overcome or compensate for those biases. As a result you are unqualified to ever make a hiring decision.
So provide me with an interpretation of "just hire the best" -- as a response to critiques of the lack of diversity in tech -- which does not imply or require an assumption that currently-underrepresented groups are, by the nature of the people in those groups, less qualified and thus less likely to be "the best".
Because you can't provide that. "Just hire the best" is an excuse for biased interviewing and hiring processes which self-reinforce; you claim to "hire the best" and then actually hire based on your biases and claim those are "the best".
The point is to question why that is -- other fields have stubbornly insisted they were purely merit-based, that women and various other minorities simply were predisposed not to like or be good at what the field was about, etc. etc.
And pretty much every time that's been shown wrong.
In the context of "diversity", which is taken to imply increasing the population of currently-underrepresented groups in the industry, responding with "just hire the best" only makes sense if one believes those groups do not by definition contain "the best", since otherwise everyone who already claims to "hire the best" would have hired from those groups.
Money in Silicon Valley knows no prejudice. One of the companies that I consulted for offered 10K placement bonuses if you could recommend an engineer that stayed for just three months.
This idea that there's a group of hidden engineers just waiting to discovered and included, that they just haven't been shown a company that cares, that somehow if we just went to the right unrepresented areas or schools or groups they would be there they'd be waiting to add millions to the bottom line... Just isn't true.
If you're not showing off your skills, putting yourself out there with code, meetups, conferences, then no, you're not one of the best. Engineers can self-delude themselves all day in their cubicle with how clever their code is, but if you're not sharing it with the world then you're not doing enough to be included in the best.
I feel the same way. I want teams that are diverse and inclusive, because I think that's how you get both the best business results and the best society.
One good historical example is labor force inclusion of women. For centuries, women were excluded from most professions. Circa 1970, women got only 10% of law and medicine degrees. They hit parity in the mid-aughts. Are doctors or lawyers making less? No. The expanded pool of applicants means as a society we're getting either more or better doctors and lawyers, so as a society we're wealthier. And things are undeniably fairer. Economic and social incentives coincide.
Very few human practices in software engineering have been proven to any level of rigor. But still, you have to make choices. There is usually no neutral position. You have to pick a particular language, a particular platform, a particular process, a particular team.
For me, the theory's pretty clear. The hard part about software is not the typing; it's the thinking. It's my experience that thought monocultures are less effective, so I always hire for diversity along many axes. I like having somebody with ops experience. Somebody else who loves the details of front-end work. Somebody else who has wrestled with deep optimizations. Young and old, functional and OO, careful and bold, etc, etc. I take as much variety as I can get, because the more diversity you have, the more problems you can spot and solve quickly.
An especially hard part about software is thinking about users. Good developers are always imagining the effect their choices have on the people they serve. But our imagination is limited by our experiences. Our empathy comes most easily for people like the ones we know. The more diverse your team, the more likely you are to spot and solve human problems.
So sure, it's not scientifically proven to be optimum. But the default isn't either. If we only question the things that seem novel, that's just a fancy way of arguing for a sort of generic orthodoxy.
I agree that diversity in software perspectives/technologies/experiences is important. However I don't see how racial or gender diversity plays a role in that.
I don't believe I asked you, but sure, jump on in. Is there a contrary assertion you would like to make and present evidence for? I'm all ears.
I should point out I can't stop asserting it's true, because I never started doing that. I said "I feel [...] I want [...] I think [...] For me, the theory [is ...]". Did you really not understand I was expressing my educated opinion?
Historically, most things done well have been by a group of like-minded people banding together to do something in a way that minimizes individuality and differences between them. They focus on a single vision and unite around it to become successful.
You won't find a lot of studies on this because it's not a politically correct topic. Nobody wants to do the study that confirms you're better off just hiring whoever's the most qualified unless your customer base is dramatically different from your development team.
I also feel like it's a false equivalency to suggest racial / gender diversity is in any way comparable to this:
> I like having somebody with ops experience. Somebody else who loves the details of front-end work. Somebody else who has wrestled with deep optimizations.
Those things actually relate to the work being done.
Historically, most things have been terrible. There is no historical era I would like to live in more than the one we have now.
Taking recent history, America has been enormously successful and prominent, especially in technology. And America, as a nation of immigrants, has unusually high levels of diversity and inclusion. What in modern America qualifies as non-diverse would still historically be very diverse.
> Nobody wants to do the study that [...]
It must be nice to be able to read the minds of thousands of academics around the world. I'd probably use my powers differently, but I guess you have to start somewhere.
> hiring whoever's the most qualified
Yes, I'm hiring the most qualified team for the problems we're tackling.
> I also feel like it's a false equivalency
It's nice when people share their feelings. Do you feel better? If so, good.
That aside, I'm not sure why you think the feelings of J Random Commenter would be relevant to me as compared with my years of experience building and running teams. Given the throwaway account, even you don't appear to take your opinions very seriously.
> Historically, most things have been terrible. There is no historical era I would like to live in more than the one we have now.
Not even long history. I'm talking even our modern tech companies, where many were started out of a garage by a few very non-diverse people.
> Taking recent history, America has been enormously successful and prominent, especially in technology. And America, as a nation of immigrants, has unusually high levels of diversity and inclusion. What in modern America qualifies as non-diverse would still historically be very diverse.
I think you're right, although this doesn't make a strong case for diversifying our almost completely white/asian/male technology industry or any company.
> It's nice when people share their feelings. Do you feel better? If so, good.
"I also feel like it's a false equivalency" is the phrase I went with after softening down "your argument is dishonest and misleading," which is itself softened down from the original response of anyone rational watching you compare hiring both front end and back end developers to hiring "diverse" team members.
> That aside, I'm not sure why you think the feelings of J Random Commenter would be relevant to me as compared with my years of experience building and running teams.
Your comment I responded to asked for a contrary assertion. My apologies if I offended you, but I really think it's helpful for people in your position to be exposed to an alternative view. Few are going to honestly respond to things like this in person out of fear of being labeled racist / sexist, but these aren't racist or sexist views and they aren't uncommon.
> Given the throwaway account, even you don't appear to take your opinions very seriously.
I do take them seriously, but it's not prudent to say politically incorrect things on an account linked to your real identity. I apologize if the comment bothered you.
> Your comment I responded to asked for a contrary assertion.
No. No it did not. I asked oldmanjay if, having falsely criticized me for asserting things with evidence, he wanted to make a contrary assertion with evidence. This was a rhetorical device to draw an interlocutor out.
I neither asked for nor wanted an Internet random to offer half-baked, unevidenced pro-racist, pro-sexist waffle, thanks.
> I really think it's helpful for people in your position to be exposed to an alternative view.
Yes, because I never before would have encountered people justifying the status quo by suggesting that racism and sexism don't exist or, if they do, are in fact optimum. Surely, there is nowhere else on the internet I might have been exposed to an "alternate" view. I'm sure nobody on HN has ever taken that position, let alone in response to me. Gosh, thank you for bringing something new into the world.
> but it's not prudent to say politically incorrect things on an account linked to your real identity
My, aren't you the brave one. As we see in the US elections your opinions are indeed politically correct for a notable portion of the American electorate. They have been politically correct for most of American history.
What you're unwilling to do is to have a lot of people, the people you'd rather hang out with, think you an asshole. You lack the courage of your convictions. So instead of being openly pro-racism and pro-sexism, you'll do it quietly. Hoping, I presume, for the moment that the gang in white sheets get enough power that you can finally be "honest".
If you want me to take you seriously, own your words. The internet and HN have a custom of offering a free hood dispenser to anybody wanting to comment. But that you only feel comfortable opining from under a white hood should tell you something. It certainly tells me something.
> I neither asked for nor wanted an Internet random to offer half-baked, unevidenced pro-racist, pro-sexist waffle, thanks.
There's nothing pro-racist or pro-sexist about what I said, but that's the world we live in. Making an argument for hiring the best person for the job is called racist and sexist. This is the cause for anonymity--people like you demonize those you disagree with.
> Yes, because I never before would have encountered people justifying the status quo by suggesting that racism and sexism don't exist or, if they do, are in fact optimum. Surely, there is nowhere else on the internet I might have been exposed to an "alternate" view. I'm sure nobody on HN has ever taken that position, let alone in response to me. Gosh, thank you for bringing something new into the world.
Your frustrated response at someone who would have the audacity to challenge your view reinforce the claim that it doesn't happen enough. It's much easier to sit in an echo chamber where everyone pats themselves on the backs about how progressive they are and how racist and backward everyone else is, but it's hard to step back and examine things rationally when called out on it.
But it's OK! You're under no obligation to respond to my (or anyone else's) comments. You can return to your safe space whenever you'd like.
> My, aren't you the brave one. As we see in the US elections your opinions are indeed politically correct for a notable portion of the American electorate. They have been politically correct for most of American history.
It's irrelevant. I don't want to limit my hiring options to people who agree with me politically.
> What you're unwilling to do is to have a lot of people, the people you'd rather hang out with, think you an asshole. You lack the courage of your convictions. So instead of being openly pro-racism and pro-sexism, you'll do it quietly. Hoping, I presume, for the moment that the gang in white sheets get enough power that you can finally be "honest".
No. I just don't want to be fired or miss out on a job opportunity because of political disagreements with the hiring team. I wouldn't endorse a political candidate on an account linked to my real identity, either. It's not prudent.
> If you want me to take you seriously, own your words. The internet and HN have a custom of offering a free hood dispenser to anybody wanting to comment. But that you only feel comfortable opining from under a white hood should tell you something. It certainly tells me something.
It should tell you that you and the people like you have been successful in demonizing anyone who disagrees with you. That's all.
> Your [sic] frustrated response at someone who would have the audacity to challenge your view reinforce the claim that it doesn't happen enough.
The problem here is that you're not challenging my views. You're just repeating a generic pro status quo argument, which comes up every time anybody suggests that there might be some better approach than the (historically racist, sexist) status quo. I have seen it a million times.
I'm not frustrated by the argument. I'm frustrated by the zillion buttinskis who aren't willing to take an actual stand, who try to claim they are being apolitical, but somehow only choose to be "apolitical" when jumping in to object to antiracist or antisexist changes to the status quo.
I'm frustrated by the cowardice. It's not clear that you believe in anything but yourself. You'll argue to protect a status quo that benefits you. But you won't dare do it under your own name, because that might not benefit you. You don't want to limit your "hiring options", while you work to retain the limit on hiring options for women and black people.
> the people like you have been successful in demonizing anyone who disagrees with you
I am not interested in demonizing people. But I will happily repudiate the notion that those who aren't white dudes aren't really people, aren't deserving of the same respect, consideration, and privileges that accrue to white men.
There's no cowardice involved, and the sooner you realize that, the sooner you'll be on a path to a rational discussion. The argument's validity isn't based on who says it, and continuing to harp on this point really shows the hoops you're willing to jump through to avoid making a rational point.
> You don't want to limit your "hiring options", while you work to retain the limit on hiring options for women and black people.
I'd hire women and black people for every single position if they're the best for the job. It's amazing how somehow Asian males have a significant presence and we're all the better for it! Somehow they pulled it off without your help, and I'm sure they're proud they didn't need to play the race card or invoke white guilt to get where they are. They're there because they were determined to be the best for their position, and they earned every bit of it.
But yeah, maybe I'm just racist because I don't doubt women or black people's ability to do the same.
If you want to talk about making it easier to account for white privilege, I'm all ears. But equating hiring people based on skillset to doing so based on genitalia or skin color is dishonest. It's condescending to even think we'd buy it. Make an honest argument for hiring someone based on gender / race and we'll take it seriously.
> But I will happily repudiate the notion that those who aren't white dudes aren't really people, aren't deserving of the same respect, consideration, and privileges that accrue to white men.
Nobody said this, and the gap between "people who think we should hire the best person for the job" and "people who think those who aren't white males aren't really people" is colossal.
If there's no cowardice involved, start posting this stuff under your real name. Until then, adieu. I have enough honest interlocutors to talk with; you and your hood will just have to keep each other company.
Or enforce preconceived views about who belonged in the field and discourage others — you don't have to go back very far to find those groups setting quotas on the number of Jewish doctors, for example:
Nah man. Even a half-honest business person will tell you the business incentive for making and funding diversity goals is about expanding the hiring pool.
The fact it overlaps with a popular social goal is just an added bonus for marketing and internal feel-good. Maybe the businesses are true believers in diversity, or maybe they're cold, calculating, and just hiring the true believers to diversify their business.
It's like when Google lobbies the government and their goals happen to overlap with ends an everyday engineer clued into the topic also likes. They're not doing it out of the goodness of their heart. But they'll make the strong principled argument for it.
> The fact it overlaps with a popular social goal is just an added bonus for marketing and internal feel-good.
This gets to the core of the issue: in a late stage capitalistic society, meaningful social change ONLY happens when it is aligned with business incentives.
everyone has access to products the consumption of which threaten the ecological underpinnings of the society in which they live, but generally consume more of these products anyway
The company's mission is to fulfil its purpose that may or may not related to immediate shareholder value. I recommend to read the Flow's author's other book called Good Business: https://www.amazon.co.uk/Good-Business-Leadership-Making-Mea... . He describes quite well what bugged me with the concept of “a business entity is to maximise the profit”.
Should it follow the local area's racial distribution, especially if that is divergent from the national averages?
In any case, one pro-diversity argument is that across cultures and genders lie different ways of looking at the world and looking at problems. This adds more potential good solutions to the discovery space your workers are exploring.
However, I think underlying these movements is that companies desperately do not want to be viewed as socially offensive, to avoid being in the crosshairs of devastating angry mob backlashes.
I think what they mean by "not diverse enough" is in comparison to the pool of candidates. Under the hypothesis that race/gender/ethnicity/sexual orientation/nationality/age are uncorrelated to performance/ability of the candidates, it implies bias in the selection process. Which isn't only an ethical concern, but also a business one: it means they're not hiring the overall best candidates.
Of course, there's also something to be said about the lack of diversity in the pool of software engineer candidates, which signals a problem for the industry in general for the same reasons. That's e.g. why tech companies are funding programs so that girls aren't turned off a software career if that's what they fancy.
Those details aside, in general my impression is that the industry isn't currently in any sort of stagnation of opportunities, with employees' salaries racing to the bottom to cling on those opportunities. On the opposite, there seems to be plenty of things still to be done, and not enough hands. If you dump a lot of new good candidates in the pool, they're going to be absorbed right away, even if they're all white American males.
That would make sense if they weren't also complaining about the fact that there are fewer [group X] applicants in the first place (and then using that to justify accusations of systemic discrimination).
>Under the hypothesis that race/gender/ethnicity/sexual orientation/nationality/age are uncorrelated to performance/ability of the candidates, it implies bias in the selection process.
We are infinitely certain of this, which explains many things.
Ideally, the demographic breakdown should perfectly match the candidate pool. And again, ideally, the candidate pool should perfectly match the general population. Lacking the actual candidate pool numbers, there's actually two assumptions in play:
1. That the candidate pool matches the general population.
2. That the company is discriminating against this candidate pool, leading to skewed demographics.
For some reason, assumption (1) seems to be implicitly trusted, and all blame fall to assumption (2) -- that is, that any deviation from the general population is somehow the fault of the company. I would posit that assumption (1) is typically not true. For instance, we know from studies that the STEM candidate pool for women is smaller than the general population, due to university dropout. It is impossible for every STEM company to have a population distribution of women that matches the general population. Reverse applies to, say, nursing or teaching, which have larger-than-expected numbers of women. (I'll leave it to the reader to make their own conclusions about why we aren't reading about diversity problems in such fields.)
Aren't you forgetting that different people, even different groups of people, have different motivations? E.g. in general, men like cars, gym and climbing; women like jewellery, yoga and dancing. These are all voluntary activities (well, you could argue that things like gym and jewellery are socially motivated), yet different sexes in average choose differently. Why wouldn't it be the same with careers?
Are you assuming that there is some genetic or evolutionary reason for men to like cars? That somehow it is hard-coded into the Y chromosome to like cars?
Or have you considered the possibility that social conditioning can make a large difference in what hobbies and preferences someone ends up having?
There definitely could be an evolutionary reason why men biologically prefer adrenaline, technical subjects and showing off their muscles, whereas women prefer talking, being led and showing off their youth/beauty. After all, despite all the feminist/anti-sexist posturing in our society, no-one bats an eye when someone says that men are more aggressive.
But even if there are first-order biological reasons ("encoded into the Y chromosome"), there could be second-order biological reasons. E.g. women choose when it comes to sex (the underlying biological reason being, men have more time and more chances (more sperm) to make kids, so they can afford to be less picky), so men will put more energy in displaying/becoming a good partner (e.g. by earning more money). I guess it's a similar logic to why murder is immoral - there's no immediate biological reason for it, but the groups where killing in-group members was condoned simply didn't survive.
Historically, most people have been killing each other for resources.
Ultimately, food and water are the most important ones, so there had been historic precedents of cannibalism among groups of people in harsh conditions where resources were very scarce.
> Are you assuming that there is some genetic or evolutionary reason for men to like cars? That somehow it is hard-coded into the Y chromosome to like cars?
There does seem to be some supporting evidence for this theory over social conditioning.
Sex differences in rhesus monkey toy preferences parallel those of children[1]
I hope that's not the case here. My reluctance to give my own conclusions about paper is that I don't have the background to interpret the observations properly.
I didn't want my posting of it to be taken as a statement of a poorly informed opinion one way or another, rather than me feeling pressured by society not to discuss it.
I personally don't have anything objective to contribute to discussion that wouldn't be distracting.
The problem as always is that, every time a field or industry has tried to argue "well, (insert underrepresented group here) just aren't interested in/aren't as good at what we do", no matter how many attempts they make to justify it with weird evolutionary arguments, they usually end up being proven wrong when someone finds a way to remove bias from the entry process of that field or industry.
Seriously, go read about stuff like the blind auditions for orchestras (and applications of the same technique to other fields) and how they blew up any notion of meritocratic processes and gender/racial imbalance being purely due to lack of interest or ability from the groups being excluded.
This is an interesting analogy and there is evidence that it works, as long as you somehow negate the gatekeeper: Biases from interviewers.
Does it still hold when there is no gatekeeper?
I'm not seeing that many minority or women as entrepreneurs. Can you hypothesize why is that?
For example if the oft cited gender pay gap is really as wide as 23%, where are the all female companies with female CEOs exploiting the market inefficiencies?
Except we've heard this exact excuse -- "women just aren't interested in X, men are" -- before, and it's turned out to be wrong. Plenty of other fields people just said "oh, women don't like that/aren't interested"... until concerted effort to break down biases and barriers, and then suddenly "oh, guess they do like and are interested, we'd just been keeping them out all this time".
So any "in a highly convenient coincidence, human sexual dimorphism just happens to prevent women being interested in/good at my field of endeavor" argument should at this point probably carry a presumption of incorrectness (and of same for anyone advancing said argument, if not presumption of outright bias/discrimination) until overwhelming evidence is provided in support.
I think that 'non diversity' (or at least how I interpret is) is an indicator of possible unfairness, and not necessarily bad per se. If a company has too few people of a given group in comparison to the hiring pool availability, it may be something that the company is doing, maybe unconsciously, to keep them out. If the difference is with respect to the country's distribution of that group (which I suspect is the case in tech), there might be something either with the companies and/or the education-motivation given to access that knowledge.
In any case, I think it's worth to look at it and try to solve it, because maybe you end up improving the actual/future employees' life and the company itself.
And possibly race is not the only division to look at, as you say. Class is probably more interesting, but also age, family responsibilities or sexual orientation can reveal practices/attitudes that can be improved.
I agree with you in the cynical thinking and in the motivations of some of the groups pushing for it, but I think that in the long run thinking about the diversity problem and trying to fix it can lead to better outcomes for everybody.
> At the risk of sounding like a white supremacist (I am Vietnamese) that very much sounds like a code word for "too many white people" or "too many asians".
Too many underrepresented groups would be a nicer way of putting it.
> Should it follow the US racial distribution?
Would that not be fairest?
> Since race is only skin deep
It's about institutionalized racism, so race is what we should be looking at.
Besides, your idea wouldn't be that interesting considering how underrepresented women are regardless of race.
Not that any interview process is perfect, but another reason why the current process is not going away, is sheer convenience, especially for the fast growing core tech companies that don't have a pipeline problem. When you have hundreds of people applying for any open role, and you're under pressure to deliver products quarter after quarter, your incentive is to stick to a process that gives reasonable results, fast enough.
e.g. Google has estimated 40K engineers. With a 10 year average time on job (it's probably less), G is hiring 40K engineers every 10 years just to sustain itself. That's a massive operation and the incentive of any company at that scale, is to design a multi-layer, fast process. They are looking for 40K engineers that pass that process, not necessarily 40k best engineers from their pipeline.
Considering diversity with that little attention span is possible, but very hard to do. And like you said, technology is possibly the only way diversity hiring can be encouraged/enforced.
Actually, I remember reading that Google and Amazon engineers have an average time on the job of about 1 year. It seems most people just want to work there so they can put it on their resume, or maybe once they pass the interview process, they are confronted with the reality that not all jobs there are so glamorous--e.g. people probably imagine they'd be working side by side with Jeff Dean and his likes, but then they actually end up maintaining some internal system that keeps track of the stock in the Google cafeterias. I wonder if after ten years or so, a short stint at Google or one of the other big five would become a requirement to be taken seriously in the field...
I have an entirely unsupported hypothesis that much of Google's software/documentation inconsistent quality and seemingly strange product strategy can be explained by their preference for hiring "A" players or better, but only having enough truly interesting work for the smaller number of "A+" players they've got, so that at some point "A" folks get assigned something really boring but necessary and before long they're applying other places with Google on their work history so they can take on much more interesting work at some (possibly smaller) place that gives the boring stuff to "B" or "C" developers--or else they manage to get on or agitate to create some greenfield project, and that keeps them busy at least until the boring stuff on that project begins to overwhelm the interesting work. Result is there's too much churn among any personnel assigned to boring stuff for them to be very good at that kind of thing, as a company.
Without a doubt that stat is because these companies have grown so fast. It's not that people leave after a year, it's that they have added tons of engineers in the last year (and have done so repeatedly for the last few years).
I worked at Google. Turnover was really low. 10 year average stay doesn't sound unreasonable for me if you select only the employees that have left.
Maybe I misunderstand the metric, but isn't turnout calculated as the average tenure of people who leave? If the companies just add
more engineers, this shouldn't affect the metric (unless you also count the tenure of people who are actually still working there, but that doesn't sound like a good way to estimate churn rate...)
Yup. When you have a revolving door of people who want to work for you (often, despite your interview process), you're probably gonna be fine no matter what.
That said, folks at Google are putting a ton of effort and resources into diversity initiatives. But not at the expense of revamping the current process.
I can't think of a single reputable company that I would be interested in working at in a SDE role where they do not conduct data structure and algorithm intensive interviews. If you want to work at a brand name company as a developer today, you must be able to solve these interview questions.
My main problem with this is the fact that, at certain point, your previous experience gets somehow irrelevant.
Have you been able to solve difficult technical problem in the last 5 years, which you can explain in detail? It doesn't matter unless you can code me from scratch a binary tree.
Do you have domain experience about something the company work? Cool story, but tell me the proper API call to do this obscure operation.
I understand what's the point of that, I made technical interviews myself and I know is the game to play, but at some point it feel a little weird that you cannot leverage your previous experience and go talk the interesting, actually relevant parts, not the big O of quick sort algorithm...
After playing the game N times (and I don't think I'm particularly bad at it), it gets a little tiresome, I have to say...
I tend to agree with this sentiment. As my colleague aptly put, algorithms/data structure questions aren't really about whether a potential candidate can perform the job.
It's more about whether or not they are "one of us". I mean, if you couldn't be bothered to brush up on CS fundamentals, how can I trust you with the responsibilities that the job entails? That looks like a red flag to me.
FWIW, when I interview people, I ask actual problems I've run into, i.e. design and implement a sane concurrency system that's easy to reason about on an embedded platform with limited resources.
I think the conversation about diversity in tech often overlooks a key metric, which is the percentage of tech companies that are founded by and/or employ a majority of minorities.
For example, if its accurate to say that over 88% of US tech companies are founded by white people and employ mostly white people, then a diversity issue exists in the number of tech companies founded by black people and employing mostly black people.
As a black american, it's interesting that the approach to tech diversity so often revolves around the concept of hiring minorities to help fulfil the goals of existing (mostly white) companies.
An approach that feels more altruistic to me would be to empower minorities to build their own tech companies to solve their own types of problems, and hire people who are a good 'culture fit.'
Instead of diversifying employees, diversify the companies and let them naturally attract diverse employees.
Yeh, I'm not sure that's a great idea. Companies fail a LOT - startups especially. We look at the successes and think "this is the way to do it", but I wonder if the failures would be felt most starkly by the poor. If Zuckerberg failed at FaceBook, he was still Ivy league educated from a middle class family. That safety net really helps take that risk.
I'm not saying stop people doing it, but I'm not sure encouraging more high risk taking amongst the most vulnerable is wise.
But I agree with your central idea - diversity of options, beacuse diversity, to me, is not forcing every environment to be as diverse as possible, it is about a diversity in the cultural landscape. As a reductio ad absurdum analogy, diversity isn't forcing mosques to server beer and bacon and forcing pubs to have alcohol and pig free sections, it is having a world where there are both Mosques and pubs, and we can all choose what we prefer.
> For example, if its accurate to say that over 88% of US tech companies are founded by white people and employ mostly white people, then a diversity issue exists in the number of tech companies founded by black people and employing mostly black people.
Well america is 12.6% black, so perhaps that is perfectly representative.
The people who can work towards diversified hiring aren't the same people who can work towards diversified founding teams. They're both necessary, I think.
>Unstructured interviews reliably degrade the decisions of gatekeepers (e.g. hiring and admissions officers, parole boards, etc.). Gatekeepers (and SPRs) make better decisions on the basis of dossiers alone than on the basis of dossiers and unstructured interviews. (Bloom and Brundage 1947, DeVaul et. al. 1957, Oskamp 1965, Milstein et. al. 1981; Hunter & Hunter 1984; Wiesner & Cronshaw 1988). If you're hiring, you're probably better off not doing interviews.
The "make candidate solve puzzles" technical interview sounds like a very poorly designed IQ test. Just replacing it with more objective standardized IQ tests would help a lot.
The link you cited is talking specifically about "unstructured interviews", the sort where you're judged based on handshake firmness and questions like "What is your greatest weakness?" It shouldn't be too surprising that these are poor predictors of job performance.
Programming technical interviews are not supposed to be like that. They're supposed to be some mixture of a relevant-ish skills test and a plausibly-deniable IQ test. (One constraint here is that anything which is overtly an IQ test will make the company's lawyers get twitchy and start nervously trying to remember the details of the Supreme Court decision in Griggs v. Duke Power Co.)
Why diversity is needed to be fixed in the first place? Pizza business is dominated by italians and kebap by turkish, and nobody tries to fix diversity issues in those industries. Somehow every industry finds its own best people and the balance, I don't understand the need of fixing it. Nursery is dominated by women and men are underpresented there, should we also fix it?
Tech is hip, trendy and a desirable sector now - unlike, say, logging or mining. Some people feel like they are not only owed a seat at the table, but that there was a grand conspiracy in keeping them out of a field that not long ago only a certain group of people was interested in.
I've seen a number of tech interviews where the interviewer has played down candidates that were better than them (consciously or not). I've also been a interviewee many times and sensed a one-upmanship from the interviewer(s), and subsequently avoid those companies. I could easily see this also being another factor if someone isn't in tune with the norms of the industry to call BS and walk.
It's more than fixing the technical interview process. Bottom line is western culture does not raise daughters to succeed in tech. From my own experiences 80% of the chemists I've worked with (including leadership) are female - so it's not a total failure in STEM education.
The culture around software development is unfortunately very misogynistic and/or off-putting and exclusionary toward women, so they find themselves pushed away from the dev education/career track from an early age and onward. It wasn't always this way, it used to be that women made up a larger percentage of software engineers, but the culture changed over time. Not that dudes in tech are willing to accept this, for them everything about the culture is part of its charm, and the industry is a perfect meritocracy.
> We believe that technical interviewing is a broken process for everyone but that the flaws within the system hit underrepresented groups the hardest…
Turns out, people who are bad at technical interviews, are underrepresented at companies who use technical interviews to hire employees.
"Being good at technical interviews" is not the same thing as "being a good programmer". You can be bad at interviews but good at programming. You can be good at interviews but bad at programming. Turns out that there's a correlation between the former set and certain demographics, because of unconscious biases in the interview process.
I'd like to know their definition of technical interview because it seems to cover everything from fizzbuzz to arcane problems. I very much doubt there are good programmers that can't solve fizzbuzz.
Of course it doesn't. I talk about this in my other comment (https://news.ycombinator.com/item?id=12859833), many companies are okay with false negatives. And false negatives are okay. Sad, but okay.
However, if your metric for hiring is also correlated with favoring a particular demographic, you shouldn't be using it. False negatives are not okay when you disproportionately target one group.
I've been in software tech for nearly 30 years. Never had a "technical" interview, puzzle solving, or anything like that. I would not take a job that screened candidates that way.
If references and credentials and track record aren't enough, I would look elsewhere.
Flip side -- I view it as a strong negative if a company has what I consider a weak interview or vetting process.
The interview doesn't have to be all whiteboard coding but I want to at least feel like the person got some grasp of my technical ability. If the entire thing is basically a "personality interview" I start to think that it is very possible technically weak people may have been able to schmooze their way into a place in the company and I'd prefer to not work with a high ratio of bozos.
Current company I work had me write FizzBuzz on paper, and that was mostly it for the technical interview. They asked about my history and I talked about projects and such, but it was probably the easiest interview I've ever had. And this is my favorite job I've ever had as well.
Wouldn't simply taking an IQ test, or submitting your SAT score along with your resume serve the same purpose then? If the goal is to reveal "technical ability" this would save a lot of time.
I'm not being sarcastic at all, but I can see how my comment could be interpreted that way.
I don't have evidence (though I'm sure I could find it) but I think IQ and SAT scores are probably very highly correlated with coding abilities. Coding is just analytical problem solving after all.
So I honestly do think IQ and SAT score have almost as much predictive power of your ability as a software engineer as a simple coding exercise.
Honestly, I'd bet the only extra predictive power comes from the fact that correctly solving fizzbuzz reveals an underlying motivation and interest in software engineering.
"Coding abilities" aren't innate. Writing a for loop in Java isn't something you're born knowing how to do. Everybody learns it at some point.
Think about it this way. Take two people with the same IQ test result. One of them can solve fizzbuzz, and one of them can't. How much would you be willing to bet that the other one won't be able to solve fizzbuzz if you or I teach them about Java for two weeks?
I don't know. I went to an Ivy league college, and though I ended up pivoting and only getting a minor in CS, I was in and around the CS department for a long time. There were a lot of absolutely brilliant people there, in the CS department, that couldn't code their way out of a wet paper bag, even after ostensibly studying computer science and programming for years.
I don't know what it is, but there appears to be something intrinsically different in people that really grok computers and those that can't. Flying spaghetti monster knows, there were people that could run intellectual circles around me, but their brains just locked up and started stuttering trying to understand pointers.
> It is amazingly easy for BS artists to look good on references, credentials, and their presented track record. And yet fail fizzbuzz.
So what? Just fire them quickly. Or put people who aren't so naive in charge of the hiring process.
Most of the time the actual problem is that "hiring managers" aren't practicing their trade anymore, and even in a simple conversation aren't sufficiently able to sniff out extremely obvious underqualified candidates who wouldn't be able to solve fizzbuzz.
Here's perhaps a good test for hiring managers. Have them interview 10 people who would normally apply, and just have a conversation. Make sure at least one person can't solve fizzbuzz. Ask the hiring manager to predict whether each candidate can or can't solve fizzbuzz based on their conversation. Anything less than 100% predictive accuracy and you can't be a hiring manager.
I would hope so I guess, but apparently according to OP a lot of hiring managers are duped by people who give off the appearance of software engineering aptitude but who can't solve fizzbuzz.
Good for you that the market is so good, you can be insulted and walk away from an interview and still find a different job that doesn't do an extremely standard thing: basic technical screening.
Your credentials might speak for themselves. After all, you've been working for 30 years. 80% of the people I've hired have between 0 and 5 years work experience and without a technical screening I might as well just give them the job based on dice roll.
Usually I don't check credentials, and only use a resume to make a selection but don't use it _at all_ to determine if you're a good candidate after you've come in for an interview.
I think most experienced people would agree that a technical interview could be appropriate for someone with 0-5 years of work experience.
For somebody with 10+ years of experience, who you can find that talks the talk during a real interview, CS101-level quizzes are insulting and inappropriate.
I have worked with people who have 10+ years of experience and can talk the talk, but are still pretty bad at the day-to-day work of writing software. I also have worked with some great developers who aren't so good at interview-style conversations.
I agree CS quizzes are a bad interview technique, which is why I favor pair programming. But I've never had a good candidate feel insulted by asking to sit down and code together for a while. Indeed, the #1 thing good programmers have in common is they like programming.
IME it's not about asking easy questions, it's about asking questions about "programming in the small" that are relevant to day-to-day work. I conduct lots of technical interviews and I've found that it's just as important to ask the 10+ year veterans about the fundamentals as it is to ask the new grads. It's just way too easy to talk about programming while actually being incompetent at it. Only by having a candidate write real code can an interviewer detect the difference.
People claim all kinds of things as part of their resume and track record that aren't true. It's simply routine. People who were on a team that worked with a technology list their technology as something they know. People who were on a team that delivered a product claim the product delivery as their own. Drill into what exactly their role was during conversation and you'll get a much different story. Ask them details about the technology listed on their resume, and you'll quite often find that they know little about it. Resume inflation is so standard that filtering it out is not even a question.
You know what's honest and true? Put someone in a room and talk to them, and see how they react to a situation and perform. See what they can figure out from first principles. Strong performance in these situations (problem solving, i.e. reasoning from first principles) correlates very well in my experience with strong performance on the job as a software engineer.
2. Do you think you might have sold yourself short? In other words, if you had practiced one of these do you think you might have ended up in a place which you enjoyed more?
The premise of question 2 is that the interview process does not represent the job or company. In many cases, I think this premise is valid.
Huh. I agree that puzzle interviews are useless, which is why I do interview that involve work-ish activities like coding and technical design of features.
But I'd never go with references and credentials on their own. On one side, that allows bluffers and bullshitters in. And on the other, it excludes people who would be perfectly good, but either aren't good at selling themselves or don't yet have a track record.
They have a big figure labelled "People Can't Gauge Their Own Interview Perfomance", which shows that when the interviewer and interviee rated the perfomance on a 1-4 scale, 46% of candidates guessed their exact score, and another 45% were off by one.
That seems pretty good to me. Can you really expect any more agreement than that?
The diversity figures could be worse. They could have included a breakdown based on age and compared Facebook vs national norms and firms doing US government/military software contracts.
Age is not required for the EEO-1 filings:
"EEO-1 reports filed by employers with more than 100 employees provide data based on race, color, sex and national origin,but do not report data on age or disability. We are aware that both groups are underrepresented in the tech workforce,
suggesting the need for research to understand the causes and potential solutions."
I think it makes more sense to hire people you like who you think can do the job. Then train those individuals to be the employees you want. That is where your diversity will come in. What happened to businesses and people investing in and training other people? Sure they may walk in a dud in your eyes but there is no reason why they should stay that way.
Secondly, many companies can take a good engineer, not use them correctly, run them off or turn them into a bad engineer for your company. There is too much emphasis on what a candidate already is and not enough emphasis on what you can mold your candidate to be after they are hired.
Training people on the job is where your diversity will come from. I noticed that many people got in the door with less skill than the people they are hiring.
From a purely utility-maximizing perspective, it's easy to see what happened. Training people costs time and money, both in non-productivity of the new person, and lost productivity from the people training them. Also, there's a fair to good chance that once you train a new person and they get a couple years of experience, they will jump ship and leave you in the same position as when you started. If you look at it this way, it's better to hire a person who can already do the job than it is to hire someone who might be able to do it with a lot of training. (And yes I know it's a chicken and egg problem of who betrayed whom first with respect to long-term employee retention over the last few decades).
The notable exception to this thinking is in established firms where there is a specific methodology and persona they wish all employees to have. Ex. the major consultancies, law firms, investment banks, etc. For them, it's generally best to pick a completely fresh person (new grad) and mold them into exactly what the company wants without having to "undo" things they may have learned elsewhere.
I can certainly see where you are coming from. As you stated, it is a chicken and egg problem somewhat.
However, if the person has no background whatsoever that's actually different than someone who has some verifiable experience but just isn't what you would like initially.
Wouldn't it make sense to take in someone who has some experience then train them. Sure they may leave but they may not if you treat them well. An employee leaving in the tech world is always a risk. I notice many companies spend all of their efforts hiring but very little effort is exerted to retain people.
At the end of the day the tech world could stand to give back to the community in some way. If it means taking on a bit more hiring risk, its a small service to the communities they've taken so much from.
Completely agree with you - there is a happy medium with respect to experience and training that the vast majority of hiring completely misses out on today. I think the problem is that's it easier for hiring managers to keep a position open for longer while telling themselves they need a unicorn than it is for them to actually put in the effort to train a new person properly.
And yes, employee retention is a constantly debated topic that most companies only pay lip service to.
I believe that the problem with a lot of these tech interviews is that they reflect a deep-seated belief on the part of the interviewer, that there exists such a thing as absolute intelligence, that it is immutable, and it is the most important factor in hiring. When you think in these terms, racism seems almost inevitable: after all, if intelligence is a measurable, absolute, and immutable quantity, akin to height or skin color, then shouldn't it also be hereditable?
Instead of administering thinly-veiled intelligence tests, interviewers should hire based on two factors: technical skill, and more importantly, the ability to acquire it (i.e., learn). You don't want to hire (or be) a person who believes in the fiction of genius. You want to be and hire the kind of person who believes and demonstrates that ability is a deterministic function of practice, not genes.
The easiest way to fix "diversity in tech" would be to reduce the number of H1B visas, which in the tech sector overwhelmingly go to overwhelmingly overrepresented Asians.
But in practice, "diversity" is ~exclusively used as an anti-white & especially anti-white-male cudgel, so of course that will not happen.
If interviewing was the problem, it would imply that there are a lot of unemployed female developers (thousands and thousands - if they all were hired, we would expect a huge increase in percentage of female devs, so the number of unemployed female developers has to be a huge percentage of the number of all developers). Is that the case? How many unemployed female developers are there?
The other premise, that "diverse people" get less chance to practice interviewing, also seems bogus to me. I don't think good developers go through that many interviews and/or job applications before they get hired.
It may well be that interviewing is broken, what with the unreliable outcome, but it would be broken for everybody in the same way.
What indicates "diversity in tech" is broken? Are there notable examples of wildly successful companies that credibly attribute their success to "diversity", in the same way they attribute it to low overhead, technological innovation, economies of scale, etc?
There have been historical examples of companies that became successful by tapping into cheaper sources of labor (notably in the agricultural sector). Is this what is meant by "diversity"?
There is a significant pipeline problem. Recently there was an article on HN that women are doing reasonably well these days except in the top suite. Again a pipeline issue. Some countries are further ahead like e.g. Scandinavia and India.
Pipeline issues are solved in kindergarten, school by teachers and parents. Role-models and incentives can help. Interviewing is too late. Actually considering that almost all CS grads are employed it is totally ridiculous to assume interviewing will fix anything. A woman can only be hired once.
Making the hiring process 100% objective is dangerous and I'm looking at these instrumented technical interviews as a step in the wrong direction. Of course we can reduce all observations to a single measure and then line everyone up against it. Any yes, that is happening in the end somehow in any case. But there is a huge difference in letting machine (or rigid scheme) do it.
Letting algorithms decide is convenient. It avoids taking responsibility. It allows avoidance of accountability. And more often than not it allows unaccountable manipulation of the process - as particularly the unscrupulous will know and not stop putting a thumb on the scale.
I don't think that first diagram really supports the OP's point. If you look at the top performing interviewees, the ones with a mean of 4, you can see that the majority seems to have scored no less than 3, even in their sub-par interviews. There's a steep drop in standard deviation at that end of the curve. It seems that the people who do best at interviews do so pretty consistently indeed.
The OP makes this point: they say that the tech interview is a game that can be learned, and that the problem is that people may drop out before they have the chance to learn it. That certainly rings true, but I don't see that their (scarce) data shows that employers want to reform their practice.
For one thing, employers may conclude that if consistency is higher for the best performers that's a sign that the tech interview is indeed a good proxy of skill. And if it causes lots of people to drop out, well that's probably a bonus: fewer applications to sift through, fewer people hired that shouldn't be and overall less uncertainty and churn [1].
______________
[1] Managerese for not having a clue how to manage.
This is not about rejection and going on about the process. Yes, it is somewhat a numbers game, but what leads to rejection?
For a person of color to even get to the interview process, you have to be lucky. Now that you have a PoC in the room with other people, thay same PoC has to prove beyond their subconcious biases and prejudices that they are indeed, better than anybody else in the world for that job, including the interviewers. BUT at the same time, that PoC has to deal with the bias and not be too good, lest they offend the people conducting the interview, and not get offended by the blatant racist, misogynist, xenophobic comments that are going to show up in that interview.
Some examples? "Do you know ho to read email?". "So you are an expert, and you proved solving all these technical problems and your resume, but how exactly can you prove that you are an expert?". "You have an accent". "Our clients want someody more like them, white". "You are too exotic for our group".
some people just aren't good at technical interviewing but on the other hand there are a lot of bad interviewers.
I work with a guy I interviewed that gave one of the worst interview performances I had done. He couldn't answer many of the technical questions correctly or only had a surface understanding of them. But, from asking him the soft skill questions I knew he would work well with our team. Then we gave him two simple programming assignment that many of the more senior developers we interviewed couldn't do. He didn't know the syntax of the language well, but you could tell from his thought process, the questions he asked, and how we solved the problem that he was as Joel Spolsky said "smart and gets stuff done".
I along with my manager fought to get him hired. We were right about him. He's very effective, diligent, and if I ever got my own team at another company, I would fight to bring him on to work with me.
Man. Why not just accept folks who might not yet be so good and train him/her. Of course determine if he/she is genuinely willing to learn. Looking at hobby projects should be an indicator that he/she is passionate on programming.
But of course, capitalism compels a company to hire only the best worker to get the most out of the usurped-capital.
What I wanna point out is. It would be great if it was common for companies to help out less skilled programmers. Helping others is more important than making profit.
The next time somebody asks me for help. I'll do my best use any surplus value out of the meager salary I get working here in a third world country.
they make ya feel pretty good but cmon anyone with half a brain knows it's all bullshit. Like seriously this is the best idea we have as software engineers? tell me the big o of an algorithm that can reverse a string? a lil quiz
Dustin muskovitz helped build FB he learned php from a perl for dummies book in one weekend. there's 1000's of these stories all over the world but just replace billions with thousands and millions of dollars but u get it
referrals are preferential because we don't wanna hire someone we can't immediately fire if they suck.
how about how badly do you want this job or how eager are you to learn
I found the article interesting and it sync'd with my experience in one significant way. When I started doing interviews after nearly a decade at the same job I was way out of practice. I blew an interview at Google, I still feel embarrassed thinking about it. But then I upped my game, by taking Coursera classes on algorithms, hacker rank, etc. I really worked on it. I ended up getting so much better. Got a good job. As for the article, it is interesting to me that women are 7x more likely to give up after blowing an interview. Obviously they don't realize how much practice makes perfect.
So, you have no evidence that this "problem" is actually a problem. You have no evidence that your solution to this "problem" actually solves it. And in fact, the only evidence you present indicates that the thing you are blaming ("technical interviews" which you present as a strawman of puzzles) has nothing to do with the diversity "problem". But we should buy your solution anyways?
People normally only care about poor diversity in careers where the pay is good - you rarely hear people complaining about the diversity of cleaners, milk delivery personnel or train drivers.
If the pay dropped, I have a strong feeling that the calls for increased diversity in tech would cease quickly, replaced with complaints about diversity in accountancy or some other high net worth career.
From what I've read, it's more that "colored people" mostly only referred to black people in the United States, whereas "people of color" refers to all non-whites (except asians may or may not be included in "people of color" depending on whatever is more convenient at the time).
"People of color" has always sounded bad to me. It follows the <noun> <preposition> <noun> pattern, with "people" and "color" being both nouns. It sounds to me as if it emphasizes the group, not the individual. To emphasize the person, rather than the group, I think <adjective> <noun> is better.
It gives me a hard time to understand why sociologists think white people are homogeneous. In certain professions, if you don't wear black oxford lace-ups, you are out, even if your skin is #ffffff.
This is one of the reasons why I dislike anti-discrimination laws. For example, one of the methods used to enforce them (particularly in things like hiring) is statistics, most of which assumes employees are interchangeable commodities. They were designed back in the 1960s for things like manual labor jobs. I am willing to suggest a compromise to limit them to these kinds of jobs.
The percentage of woman working in Google is actually above the percentage of woman with an IT degree. So there is absolutely nothing to fix in the technical interviews. At most it's slightly biased towards woman, not against them.
Or maybe these "diverse" people often don't want to go into tech, and we should be so eager to point to the racism spook, lest racism it's meaning (if everybody is racist, nobody is)
Article implies that the pipeline isn't the main problem. However flawed interviewing is lack of diversity in tech is 99% a pipeline problem. It's really easy to see why.
All you need to do is look at the number of minorities with Tech degrees. Boom problem solved.
(Keep in mind that tech encompasses many things and is not exclusively localized to the software world. While in software many people can get a job without a degree, in general, all tech jobs require a degree. )
I'm waiting with great anticipation for the politically correct outcry to solve the problem of not enough women being represented in the mining, construction, sanitation, logging, or deep sea fishing industries, or for there be a popular movement to get more men into teaching or nursing where they're also dramatically underrepresented there.
Let's see if there's any intellectual honesty here, or maybe there's something else behind this politically correct movement?
Gee, I wonder why certain people are trying to pu$h this so hard? You can ea$ily gue$$ what thi$ expan$ion of the labor $upply i$ really about if you think long and hard about it.
When you have an argument that's A) deeper then a copy/paste soundbite, B) doesn't contain an informal fallacy ("how dare you try to fix this one instance of a problem until you've fixed every other instance of it first, and I'll use this no matter which instance you go after first"), and C) doesn't require you to look like a 1990s $la$hdot u$er talking about Micro$$$$$$$$$$$$$$$$$$$oft, maybe we could have a constructive conversation. But the tone of your comment suggests you're not really interested in it, y'know?
As to B, I would say the biggest problem tech faces is the education specifically daycare and elementary school do not have equal gender representation or qualified, enthusiastic STEM instructors. We need to fix that and not only demonstrate in classrooms professionals working together regardless of sex and make STEM something to dream with instead of being dreaded.
Until we fix the classroom that forms early childhood loves and hates, nothing is really going to work with software developers. We will get mostly outsiders that found their love outside of the system.
Also, why would you want your daughters to go into a career that exhibits all the ageism of being an actress?
It's part of the problem, but not all of the problem.
There are plenty of women who want to be in STEM fields, and have pushed for that in spite of everything. It's hard to actually get into a STEM job as a woman, regardless of education or experience, because of various biases in hiring. Once in, there are so many ways that the workplace is hostile to women, and the industry even more so. That leads to a high rate of just giving up, and changing career. There's only so much bullshit you can take before just deciding that, even though you love the work, it just isn't worth your sanity.
Working in a technical role in a non-tech company is often orders of magnitude better. Just like it is in many other respects, because tech companies are just horrifically broken in so many ways.
> It's hard to actually get into a STEM job as a woman, regardless of education or experience, because of various biases in hiring.
Absolutely false. They even have their own hiring fairs and events that men aren't invited to. I'll give you the rest of the points in your comment but getting an entry level job is very easy for men and even easier for equally qualified women.
> They even have their own hiring fairs and events that men aren't invited to.
That's a non sequitur; just because there are things to ease the process for them does not mean that it is easier. The job fairs would mean that it's easier, in a vacuum. It's not in a vacuum. There are other effects that the job fairs can only chip away at.
Throwaway accounts allow people to express views that aren't politically correct. If all your views are politically correct this may seem like a bad thing, but for people with views that aren't politically correct throw away accounts allow participation.
But, if everyone uses throwaway accounts to say what they really want to say, then it just helps perpetuate the same political correctness that they dislike.
I don't understand what you are trying to say - political correctness is all about preventing people from saying things that aren't "politically" correct. It is a tool for preventing discussion about topics which might offend people, and for silencing opposing views. If everyone is allowed to speak freely without the shame of not being "politically" correct than people can say what they believe. You weigh the cost of offending people against the freedom to speak out against the prevailing "politically" correct beliefs.
Because without throwaway accounts people can't express views that aren't politically correct? Look through my history, I express such views all the time. I just don't think virtual points are so important that I need to make sure they're always going up.
I looked through your history but couldn't find a comment where you were being not politically correct, but I didn't try all that hard. Regardless there are certain sentiments that you can't express even though they may be true, to me that is what "politically" correct means. For example, https://en.wikipedia.org/wiki/Lawrence_Summers. You can't even bring up the possibility that women are different than men as a reason there aren't more women in STEM fields without being persecuted, instead you get articles somehow twisting data to make it look like technical interviews are the main thing holding women back from tech jobs - this may be a small contributing factor, but it isn't a primary cause.
Um.... "persecuted"? HN accounts have full support for anonymity. Why do you care if an anonymous account on some board gets "persecuted"? Where "persecuted" means you might get a -4.
This is about throwaway accounts (people creating accounts on the spot to say shitty things, while having their other account for non-shitty things, so they never lose points), not anonymity.
A lot of people's HN accounts, at least for the people who post a lot, are not anonymous. Alternatively if you post a lot it is possible to reconstruct who you are. If comments were being down voted you wouldn't see them at the top of threads - people use throw aways for anonymity not to prevent loss of points.
A lot of people's HN accounts, at least for the people who post a lot, are not anonymous.
So they choose not to take advantage of a feature. Doesn't mean one-time throwaways are a good thing.
If comments were being down voted you wouldn't see them at the top of threads.
This is irrelevant. It's about what kind of votes they expect to receive.
people use throw aways for anonymity not to prevent loss of points
I call complete BS on that. The most common reason given for posting with a throwaway (when a reason is given) is, "using a throwaway because I know I'll get downvoted for this".
Alternatively if you post a lot it is possible to reconstruct who you are.
Your only good point. Throwaways are the worst solution (of many) for this. Look at 4chan. Do we want to be 4chan?
Personally I'm happy to make an argument that given a lack of evidence that gender plays a negative roll, we have a moral imperative to eliminate unfair and discriminatory barriers to entry because its the right thing to do.
But lets say that isn't a compelling argument for you. Our industry has a disastrous success rate. Something is wrong. Most software is not getting written correctly, on time, or on budget. On top of this, it is nearly impossible to fill positions with qualified applicants.
Given that, there is a pretty strong argument that we should change the way we hire software developers and an obvious way to change it is to be more inclusive. If the current population isn't getting the job done, lets open the population up to others.
> Something is wrong. Most software is not getting written correctly, on time, or on budget. On top of this, it is nearly impossible to fill positions with qualified applicants.
True.
> Given that, there is a pretty strong argument that we should change the way we hire software developers and an obvious way to change it is to be more inclusive.
What is this 'strong argument'? Your conclusion "be more inclusive" is based on nothing more than an assumption that change will be good. There are any number of changes that could be made. You need to expand on your reasons for asserting that 'being more inclusive' will fix the problem. It could just as easily make it worse.
You could possibly argue that increasing the pool of candidates by not excluding people based on irrelevant factors (such as gender, race, or age) will mean that we have a better chance of finding qualified candidates. The danger here is if we confuse increased diversity in the hiring process (opportunity) with increased diversity amongst employees (outcome). The first fits your assumption. The second doesn't and could lead to worse outcomes (from a business perspective).
The argument is we could hardly be worse. I'm not convinced we know what qualified even looks like. We certainly can't tell in any objective way.
Given that a purely random inclusion of more applicants is likely to improve the situation. Thats before arguing for the merits of a diverse work force or relying on moral imperatives.
"Diversity" and "inclusiveness" isn't about adding more randomness to a selection, it's about introducing an explicit and deliberate bias. Special outreach programs favor candidates with lower _distribution_ in the available populace. Not only is it discrimination by itself, against the current majority, but it's self-defeating measure, in that every diversity hire skews the remaining pool of candidates more towards the biased majority it's trying to eliminate. This is usually combined with a concerted effort to ignore the actual sources of skew in the first place, because the implications go against ideas of blank-slatism and politically correct thought.
If you want to bring moral imperatives into it, one would think a basic commitment to truth and statistical literacy would be included, but it very rarely is. You'd also imagine diversity of thought would be included as a point of intellectual honesty, but in practice, it is the exact opposite.
As for software projects routinely failing, that has numerous possible explanations. One is that it's one of the most abstract forms of engineering around, in the sense that the material we manipulate and the arrangements we construct cannot be seen or touched, and hence are invisible to outsiders. It must rely entirely on explicit and deliberate communication, unlike more practical fields. The onus is entirely on the engineer to make himself understandable, and it is rare to find people gifted both in abstraction and verbal thinking.
Another is the recurring observation that schools are particularly bad at teaching the practical skills required to deliver software projects, being taught by people with little to no industry experience. It goes beyond basic project and code management skills and goes into product design and usability: people learn to build code when they should be learning to craft tools. But just because currently applications focus more on theory than practice, doesn't mean we'd get better results by turning to people who lack the theory entirely.
>What we do know is that current hiring practices aren't inclusive & they aren't successful.
We don't know either of those things, they are baseless claims. Software gets made, it gets shipped, it kinda works. Given the overwhelmingly horrifying incompetence of the vast majority of programmers, I would suggest we're actually going very well at interviewing and finding the rare competent candidates.
>No idea, but I'm more willing to try inclusion than I am riddles for finding my next candidates.
And I am more willing to put thought into it rather than do something likely to produce the opposite effect and justify it with a terrible strawman.
"After drawing on data from thousands of technical interviews, it’s become clear to us that technical interviewing is a process whose results are nondeterministic and often arbitrary. We believe that technical interviewing is a broken process for everyone but that the flaws within the system hit underrepresented groups the hardest… because they haven’t had the chance to internalize just how much of technical interviewing is a numbers game"
I have not read the entire article, but claiming that the process is nondeterministic is not the same as claiming that the process is discriminating unfairly by gender.
If everyone plays the lottery, then some people will win randomly. Certainly if a hiring causes people to "win randomly", then it's not a good hiring process -- but neither is it a process that discriminates on gender. The article goes on to explain that, although people's interview performance is subject to variance from interview to interview, it does seem that interview performance is clustered around a person's average.
> Most software is not getting written correctly, on time, or on budget.
Oh, sure it is. It's just that the business-people and/or clients driving the projects want "fast and crap" rather than "slow and well-made", because "fast and crap" still makes money.
Engineers (as in, people who have an engineering mindset, in any profession) will naturally fight back against this, which is where the time and budget creep comes from: theoretically, all software could be made "on time" and "on budget" and would be exactly as half-baked as the business-people were expecting it to be (and they would still be able to sell it, believe me.) But instead, engineers want to make something good, despite only having the time- and money-budget to make crap. Thus late nights and burn-out; thus unmaintainable hacks to get features "working for real"; etc.
The problem is fundamental to the collision between these mindsets. Remove either, and the problem goes away. Software can be made using "pure engineering" (see NASA) and succeed. Software can be made using "pure business concern" (see bottom-dollar outsourcing shops) and 'succeed' (at least in the sense it's measured by.) But there is no long-term healthy place on the spectrum existing between these two points.
What about midwifery? With only 0.3% male [1]!! When are we going to see the PC brigade push for 50/50 hiring quotas there? You would think they would be outraged with the diversity being so poor. Far, far worse than in tech. Surely it's rampant discrimination!
> Let's see if there's any intellectual honesty here
Have you tried looking, before just assuming that such things don't already exist?
I mean, a simple Google search will find plenty of industry groups, in multiple countries, dedicated to supporting women in all of those industries. They encourage women to pursue careers in those industries, do advocacy and education, and work with the industry to try to fix the problems that cause the lack of women in those industries. This is true for pretty much every industry that was traditionally male-dominated.
Same goes for men in traditionally female-dominated industries.
None of these efforts are as high profile as business or tech. Doesn't mean they don't exist.
Sure, but if those efforts are directed towards a goal of 50/50 equality of outcome then they are doomed to fail barring a totalitarian takeover of our society. A cursory perusal of western countries reveals that the more egalitarian a society is -- with Scandinavia at the top -- the more lopsided the gender differences are across many industries.
Look, I'm not saying that many industries don't feature heavy discrimination against minority populations. We definitely do need to address that in a variety of ways. I just don't think it can be accomplished by fiat. Forcing people to do things against their will does not make them more tolerant; if anything, it makes them bitterly resentful.
Even if they are initiatives to have inclusiveness into other fields, I think the throwaway account has a point about how in computers it's a bit more about money but more importantly also about influence.
The software we create can be used by millions of people. If all that is dominated by white men, then there are limitations to that. I would advocate that a diverse workforce allows for that more than anything else.
I too await in anticipation for the politically naive to solve the problem of men being under represented in houses looking after their kids full-time, working at home and holding a job or find one.
I'm all in for as many people to do the job as possible regardless of race, creed, sex or colour.
It's not just political correctness. The socially optimal future is one in which anyone, regardless of race and gender, can become a software engineer. Someday, we're going to put in effort to move from our current world to this better future. Software engineering is a highly-desirable, well-paying, forward-looking job and it's still early days. Why not give it a shot?
There are of course many PC-police types who can't give a clear reason why we should pay attention to diversity, but there are good reasons nonetheless.
Sometimes I wonder if software engineers are half as smart as they think they are. I can't think of any precedent or similar situation: a corps of highly skilled workers pro-actively sabotaging themselves in order to share the fate of their country's dying middle class: longer hours, shrinking salaries and cut-throat competition for employment.
I am glad that I have some fuck-you money now. Because the prospects as software engineer seem, frankly, rather poor now.
The first step is to stop thinking that this industry - somehow - matters more than any other or that herein lies the future of humanity. Half of that is marketing garbage and the other results from free kool-aid parties that were held after a few of us either built successful companies or made good exit deals with bigger ones. There is an alarming amount of people who are not only drunk, but blind too.
I might be the bearer of bad news, but hear me out: this industry is just like any other. In other words, you are subject to the same dynamics that fuel workers - shareholders dualism everywhere. Basic game theory: you are going to get screwed and that's not funny.
I agree on the surface of your argument though it's not as bleak as we fear.
While I don't think it's intentionally malicious, the current "cult" dev culture disempowers developers. I think there's two competing movements; the attempt to make programming more like engineering, and the belief that programming is an art.
For the software engineer camp, programming is quantified and implicitly egalitarian. The mantra is "the work speaks for itself" for these folks.
For the creative camp, programming isn't so easily measured and turned on or off.
I think the answer is somewhere in the middle. The first step to solving a problem is being able to talk about it. Many people of all genders and races are interested in being developers. They just don't want to give up their lives to do so.
Imagine being in an interview and being asked about golf balls and school busses. On the other side of the table is a suitcase with $100k. Is it really reasonable to ask them to shake things up when their livelihood is on the line?
The good news is that for all the warts software has, there are no barriers other than personal determination. Anyone can be a developer so long as they're interested.
There is a reason why the software industry and many others try hard to keep a young 'fresh' workforce even tho it contributes to more inexperienced and costly labor force.
After a few years the stars in the eyes ware off. You realise that all the idealism and hype is simply marketing a dream that will get you in the door. Your a cog in the wheel of a rather boring pedestrian industry and replaceable.
At that point you might start to realise that all that overtime is just wasting your life away not work that is going to change the world. All the free food and drink you get at work is just making you fat and you don't have a social life anymore, etc, etc.
We are all like that to one degree or another in the beginning. But the level of sugar coated frothy idealism laid on the SJW's at university now is going to cause serious mental problems for these kids when the sugar high starts to ware off after a few years in the real world.
A) because the evidence of institutionalized discrimination in the field is scanty at best.
B) because the techniques suggested for "giving it a shot" frequently involve cruel social manipulation, elimination of meritocracy, and accusing innocent people of sexism or even sexual assault.
C) because "giving it a shot" also suspiciously often involves handing over money and power to sociopaths who spend their time agitating and attacking others, not writing software.
Look -- the bad guys have poisoned the well, here. If you genuinely and sincerely think the industry needs to change, the first people you're going to have to go through to make it happen are the ones who claim they're on your side.
He did say "in the field". Further, I remain skeptical toward sociology departments until they bump their reproducibility up a bit above 50% or bring their ideological homogeneity down below 90%. And I don't trust gender studies departments at all ("glaciers are sexist" and whatnot).
And in before someone starts ranting about "institutional racism/sexism". No, it doesn't exist in our industry anymore than the rest of the western world, and that's very little; SPECIALLY in a widely left-leaning world such as academia.
The overwhelming majority of the engineering world is welcoming to women and non-whites (I can personally attest to the latter) just like it is of the much reviled "white man", even more at times. As a society we're quick to shame any hint of racism and sexism; anyone who could deny that with a straight face is living in another world.
However, equal opportunity does not directly lead to diversity. It's possible, even likely, that genders are biased towards certain careers even when there is no discrimination at all.
https://en.wikipedia.org/wiki/Hjernevask, a social documentary by Norwegian comedian and sociologist Harald Eia, has a rather interesting segment on this exact issue.
To be clear, there is no moral imperative to maximize diversity, only equality. We have no business pressuring 'diverse' people into careers they don't want to be in.
Both nursing and teaching have been wrestling with how to get more men into those professions for well over a decade, and the number of men in nursing has been rising for the past three decades.
I would have to see proof of this statement in teaching. Daycare is openly hostile towards men particularly where insurance is concerned and it doesn't look like the stats in elementary school are changing.
> Both nursing and teaching have been wrestling with how to get more men into those professions for well over a decade
Where is this wrestling?
Surely the disparity in gender is the result of Misandy at every level of the Nursing industry and these evil Woman should be held to account for there tyrannical Matriarchy.
Where are the media stories about institutionalized Gender bias in Nursing.
Where is the Diversity industry setting up organisations to promote 50/50 Male Female Nursing gender ratio?
Where is the call to lower or scrap Nursing standards to accommodate under skilled Men because its the right thing to do?
> mining, construction, sanitation, logging, or deep sea fishing industries
Given that we're talking about "tech", I think your argument would be stronger if you used examples where physical strength is seldom an important factor in job-performance.
Physical strength tends to be an extremely important part of being a nurse. There's no shortage of women being represented there.
As for the above: my garbage "man" is a woman, so it has nothing to do with physical strength. The truck picks up the can and has for at least 5 years in even the most Podunk town.
One of the things currently being tangled with, in nursing (because contrary to the usual assertion, the profession does worry about this) is the tendency for male nurses to get assigned to difficult patients who need restraint, and what that means for their occupational health.
It shouldn't be though, that's kind of the point. Directing people to a profession to make the representation equal is both counter-productive and IMO HURTS us as a whole because you end up with people pursuing a career they potentially hate because someone gave them a scholarship or promised them more money for doing so.
If more women than men want to be nurses, awesome, let them. If men are intentionally NOT being hired to be nurses that WANT to be nurses simply because they are men, THAT is a problem we need to fix. In the same token, if more men want to be programmers than women, awesome, let them. If companies are intentionally not hiring women for being women, FIX IT!
But PLEASE stop creating problems where they don't exist. I have no desire to take care of other people and the though of being a nurse is about the worst possible day job I could imagine. I'm willing to bet most nurses would rather stab themselves in the face than sit at a computer all day writing code too. Are we as a society really going to sit there and tell them they're wrong? They're just confused and would really love to program if they just are forced into it?
None of those requires a lot of physical strength anymore, machines do most of the heavy lifting. Not that any of them required a level of strength unattainable by women anyway.
There are efforts to try to get more men into teaching and nursing. Unfortunately, teaching pays shit and requires a four year degree and student teaching to get a teaching certificate, so it's not the most attractive option.
Those other blue-collar traditionally masculine jobs have a hard dependency on brute strength that most women can't satisfy. Physiology is almost as cruel a mistress as physics.
a large part of construction is now entirely machine based. how much strength does it take to drive a dump truck? or operate a crane? or drive a bulldozer?
the answer is that it is the same amount as driving an every day car: almost none.
I don't know enough about the other industries to comment.
How about when things break down, and you're out there in the mud turning wrenches and pounding on things to tear the machine apart, fix it, and put it back together? It's not an infrequent occurrence.
This isn't characteristic of U.S. factories; the costs associated with workplace injury are so high that employers are obsessed with near misses (i.e., non-injuries) and ergonomics (lever too high? We'll lower it. Reaching across your chest? We'll change your work station. Standing on concrete too long? We'll install ergonomic floor mats.). These companies employ men through their 60s. Women certainly can (and do!) work in these environments. They just don't do it in proportion to men.
That's kind of moving the goal-posts; we were discussing construction, which, at least in my experience, has a lot less OSHA oversight. Probably it is different in more unionized sectors as well; my experience is decidedly not - smaller logging, construction and power generation companies, where you often don't have the equipment to really do things correctly, for whatever reason, but it has to get done, and so brute strength and ignorance are resorted to.
> Those other blue-collar traditionally masculine jobs have a hard dependency on brute strength that most women can't satisfy.
We were discussing construction in the broader context of blue-collar, masculine jobs. But it doesn't matter really, because if these physically-permissive jobs are still disproportionately male, then there is no reason to believe that the physical demands of construction are what keep women away.
If certain activities have a huge effect on how the world operates, which is kind of the premise of Y Combinator (software is eating the world, etc.) then it's important that the people who call the shots are representative of the people who are affected. This has to happen from the bottom up, since for obvious reasons you can't parachute in "untrained diversity" at a management/strategy level.
What about e.g. social apps where some communities face a much higher risk of receiving abuse?
Looking more broadly, it wasn't that long ago that you could easily find American software developers treating internationalisation as a frill or
people talking about accessibility as a niche concern. (Now a growing percentage of people recognize that in addition to being the right thing to do, it also benefits more people than they thought due to temporary limits due to environment - ever see how many people use subtitles on the subway/bus?, illness/injury, distraction, etc.)
The key point for me is seeing this as a larger goal of encouraging as many people as possible to participate in building the technology right increasingly shapes our world. One key thing is that people aren't limited to certain types of contribution: there's probably no uniquely feminine contribution to C++ but how well the standards community works or how the language is designed will charge based on who's involved. If it's mostly very smart MIT grads, someone else might contribute not because of their race, gender, etc. but because their life experience has been different, and that's usually important for moving something out of the core guru community into broader usage.
Remember all of the guys who decried GUIs as unnecessary crutches when Real Men(tm) used a CLI? The problem wasn't that they were (generally) white men but simply that they had a very narrow view of what people wanted to do and how much training was reasonable to accept just to be able to check your email or edit a file. That's laughable now but it wasn't hard to find examples just a generation back.
> Looking more broadly, it wasn't that long ago that you could easily find American software developers treating internationalisation as a frill or people talking about accessibility as a niche concern. (Now a growing percentage of people recognize that in addition to being the right thing to do, it also benefits more people than they thought due to temporary limits due to environment - ever see how many people use subtitles on the subway/bus?, illness/injury, distraction, etc.)
Is there any evidence that better support for internationalization and accessibility was driven by a more diverse workforce? It seems more likely that these were driven by market forces (increased demand as well as lower costs as i8n/accessibility tools/practices evolved).
> how well the standards community works or how the language is designed will charge based on who's involved.
There's even some evidence that some diversity helps groups make better decisions, but there's no reason to believe that the effect is large nor that the optimal diversity is above the current level. In other words, there's no reason to believe that more diversity will be beneficial.
Exactly this, if you don't have that level of representation it leads to social problems down the line. The bloodshed in Iran and Iraq are shining examples of the extremes of what can happen. Democracy only works as much as it can provide an outlet for friction from different groups by allowing them an equal share of the system.
The representation you should be worried about is ideological representation. That's where true diversity -diversity of thought and worldview- resides.
The vilification of Peter Thiel solely for supporting a candidate that 40+ percent of the country supports should open some eyes to the problem but I doubt it will.
There's nothing to "fix" here. If there were good candidates being passed up, they would certainly congregate elsewhere and create success. If that's not happening, then it's a supply issue. And really it's no issue at all since people have free will and certain demographics just aren't choosing to be engineers. There's nothing wrong with that, we should stop trying to force them into our line of work.
> "If there were good candidates being passed up, they would certainly congregate elsewhere and create success."
BS, that's a dodge. I've seen plenty of people (regardless of their background, ethnicity, or gender) who've been screwed by the system and have spent way too long in crappy jobs where they were unable to make much of a difference. Some people get lucky and early on they find jobs where their talent can shine through and they get on a train that just keeps going up. Other folks may have things line up for them that way only much later in their career, yet others maybe not at all. And if the less lucky decide to switch careers instead of continue struggling and getting frustrated with their ambitions being constantly thwarted then you may never know the potential that was lost from that change of careers. I've also known many extremely talented developers who happened to stumble into the career by accident, and if even some small thing had been different along the way they would have been doing something else.
That's not been my experience at all. I've generally seen good people get ahead. Sure everyone has personal setbacks but en mass it's definitely not an issue.
How diverse would you say your friend/acquaintance group is? Are they from the same background as you? Do they have similar life stories? If not, how can you possibly imagine that you're not just soaking in confirmation bias?
There are countless examples of talented people who have been ill-served by the hiring environment and tech culture we have today. For every one of them that gets lucky and finds success through non-traditional hiring practices at a great company (for example) you have to wonder how many others (others who live where there is less opportunity, etc.) are just passed by and left behind by the system.
Your attitude is very much a "let them eat cake" attitude. You look around and you say "everyone I know is successful, what are all these other people's problems?" Trust me, there are poor people out there, there are disadvantaged people out there, and partly because of unfairness built into the economy and our culture. And that extends even into the tech world. There are tons of talented people who are unemployed, underemployed, or otherwise disadvantaged simply because they don't match the traditional model of what a talented tech person looks like.
> Trust me, there are poor people out there, there are disadvantaged people out there, and partly because of unfairness built into the economy and our culture.
What makes you think that I'm not one of those people? Did you ever think the reason I don't feel there's a problem is because I come from a disadvantage non-majority background and haven't had it used against me?
Real talent excels period. Yes, I've seen it and it's been from a diverse background. If you write great code, you will do well. I see a ton of people wanting success handed to them without the hard work, but no one owes them that.
Do you see anything incongruous in the way you are comfortable casually rejecting InclinedPlane's experience but using your personal experience to conclude that it's not a widespread problem?
Reread what I said and note that I didn't say you were definitely wrong, only that it's inconsistent to treat two anecdotal accounts in completely opposite ways. I'm entirely comfortable accepting that what you wrote is what you honestly believe but you're trying to argue that your limited personal experience represents an entire field so completely that everyone who says otherwise is either confused or lying.
If you want to convince anyone, post some actual data or peer-reviewed analysis. Otherwise it's just a question of whether this is garden variety argument from authority or some sort of stronger argument from Dunning-Kruger version.
> it's inconsistent to treat two anecdotal accounts in completely opposite ways.
I can either believe a random person on the internet peddling a rather trendy political opinion or my own extensive industry experience. I'd expect outsiders to treat both our claims with a grain of salt and instead use their own observations.
To anyone other than yourself, you are the “random person on the internet peddling a rather trendy political opinion”, especially since it's easy to find people with just as much industry experience who both disagree with your portrayal and have reasonable explanations for why you might not be aware of their experience.
Do you not understand that these are not comparable things? Your position is that no one in tech is generally ill-served by the system, which is backed up by your own personal experience. I've shared with you the fact that I've seen many examples of people ill-served by the system. That is a direct counter-example against your position, and as such invalidates your claim.
The only way it doesn't is if I'm lying. Are you calling me a liar? Or are you just too narrow-minded to imagine that there are experiences outside of the bubble you live in?
Are you claiming that my experiences and observations are too narrow and un-representative of the industry whereas yours are more general and representative? By what basis do you make that claim?
Edit: Evaluate it from a logical perspective. There are two hypotheses: that iniquity in hiring in tech don't exist, and that they do exist and are somewhat common. Then evaluate the "evidence". On the one hand we have your experience, where you've seen a lack of iniquity, on the other we have mine, where I've seen plenty of examples of iniquity. And we have the example I gave of other observations of iniquity, and the evidence from the article for this whole discussion, which also highlights examples of iniquity. If iniquity was common, we would still expect some situations where it was locally uncommon, especially among people of similar cultural/socio-economic backgrounds, so you would not expect a complete absence of perspectives like yours, you'd expect a mix of perspectives. If iniquity was uncommon, you'd expect that there would be very few perspectives with examples of iniquity. The only way the evidence in front of us makes sense under that hypothesis is if I'm a unicorn with utterly unusual and unique experiences, as are the examples from the article and from the sources I've brought up. That is a much less intellectually tenable position, to claim that all of the evidence against your favored hypothesis doesn't matter because it's all outliers or otherwise unreprestantive. Meanwhile, how do you explain the statistics which show that there are systematic iniquities in the system? How do you explain the countless stories with examples of people who have been ill-served by the system as it exists? Your claim seems to be incredibly weak and based on nothing more than a refusal to accept that anything outside of your own personal experience is real or important.
Read it again, they are not the same. You are claiming that my observations don't exist. I'm not claiming that your observations aren't true, I'm saying that my observations are still true. If we combine our observations together they are consistent much more with my hypothesis (that iniquity in the industry is common) than with yours (that it almost doesn't exist at all).
By what basis do you claim that my observations are so extremely unrepresentative of the industry that they should be dismissed? I'm not dismissing your observations, you're dismissing mine. Why?
My basis is that it's extremely difficult to hire good developers. They can pick and choose where they work. I've literally never seen a good developer struggle to succeed in 15+ years in the industry. Successful devs come from all backgrounds as well.
We don't need such baseless, inflammatory comments like this on Hacker News. The bar for civility and substantiveness is higher on controversial topics, not lower.
I don't think this was inflammatory or uncivil. Definitely highly controversial, definitely baseless (like every other comment on HN) but not inflammatory or uncivil.
I would have voted it down because I disagree, but I don't think censorship is justified.
On the hiring side, "For the specific case of an online job posting, on average, 1,000 individuals will see a job post, 200 will begin the application process, 100 will complete the application, 75 of those 100 resumes will be screened out by either the ATS or a recruiter, 25 resumes will be seen by the hiring manager, 4 to 6 will be invited for an interview, 1 to 3 of them will be invited back for final interview, 1 will be offered that job and 80 percent of those receiving an offer will accept it (Talent Function Group LLC)." This implies that 80% of interviews lead to rejection.
Given that level of rejection, the key here is to get women to know the odds and keep trying.