In the last few months, several large players, including Google and Facebook, have released their latest and ultimately disappointing diversity numbers. Even with increased effort and resources poured into diversity hiring programs, Facebook’s headcount for women and people of color hasn’t really increased in the past 3 years. Google’s numbers have looked remarkably similar, and both players have yet to make significant impact in the space, despite a number of initiatives spanning everything from a points system rewarding recruiters for bringing in candidates from diverse backgrounds, to increased funding for tech education, to efforts to hire more candidates from diverse backgrounds in key leadership positions.
Why have gains in diversity hiring been so lackluster across the board?
Facebook justifies these disappointing numbers by citing the ubiquitous pipeline problem, namely that not enough people from underrepresented groups have access to the education and resources they need to be set up for success. And Google’s take appears to be similar, judging from what portion of their diversity-themed, forward-looking investments are focused on education.
In addition to blaming the pipeline, since Facebook’s and Google’s announcements, a growing flurry of conversations have loudly waxed causal about the real reason diversity hiring efforts haven’t worked. These have included everything from how diversity training isn’t sticky enough, to how work environments remain exclusionary and thereby unappealing to diverse candidates, to improper calibration of performance reviews to not accounting for how marginalized groups actually respond to diversity-themed messaging.
While we are excited that more resources are being allocated to education and inclusive workplaces, at interviewing.io, we posit another reason for why diversity hiring initiatives aren’t working. 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. Getting a few interview invites here and there through increased diversity initiatives isn’t enough. It’s a beginning, but it’s not enough. 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.
A brief history of technical interviewing
A definitive work on the history of technical interviewing was surprisingly hard to find, but I was able to piece together a narrative by scouring books like How Would You Move Mount Fuji, Programming Interviews Exposed, and the bounty of the internets. The story goes something like this.
Technical interviewing has its roots as far back as 1950s Palo Alto, at Shockley Semiconductor Laboratories. Shockley’s interviewing methodology came out of a need to separate the innovative, rapidly moving, Cold War-fueled tech space from hiring approaches taken in more traditionally established, skills-based assembly-line based industry. And so, he relied on questions that could gauge analytical ability, intellect, and potential quickly. One canonical question in this category has to do with coins. You have 8 identical-looking coins, except one is lighter than the rest. Figure out which one it is with just two weighings on a pan balance.
The techniques that Shockley developed were adapted by Microsoft during the 90s, as the first dot-com boom spurred an explosion in tech hiring. As with the constraints imposed by both the volume and the high analytical/adaptability bar imposed by Shockley, Microsoft, too, needed to vet people quickly for potential — as software engineering became increasingly complex over the course of the dot-com boom, it was no longer possible to have a few centralized “master programmers” manage the design and then delegate away the minutiae. Even rank and file developers needed to be able to produce under a variety of rapidly evolving conditions, where just mastery of specific skills wasn’t enough.
The puzzle format, in particular, was easy to standardize because individual hiring managers didn’t have to come up with their own interview questions, and a company could quickly build up its own interchangeable question repository.
This mentality also applied to the interview process itself — rather than having individual teams run their own processes and pipelines, it made much more sense to standardize things. This way, in addition to questions, you could effectively plug and play the interviewers themselves — any interviewer within your org could be quickly trained up and assigned to speak with any candidate, independent of prospective team.
Puzzle questions were a good solution for this era for a different reason. Collaborative editing of documents didn’t become a thing until Google Docs’ launch in 2007. Without that capability, writing code in a phone interview was untenable — if you’ve ever tried to talk someone through how to code something up without at least a shared piece of paper in front of you, you know how painful it can be. In the absence of being able to write code in front of someone, the puzzle question was a decent proxy. Technology marched on, however, and its evolution made it possible to move from the proxy of puzzles to more concrete, coding-based interview questions. Around the same time, Google itself publicly overturned the efficacy of puzzle questions.
So where does this leave us? Technical interviews are moving in the direction of more concreteness, but they are still very much a proxy for the day-to-day work that a software engineer actually does. The hope was that the proxy would be decent enough, but it was always understood that that’s what they were and that the cost-benefit of relying on a proxy worked out in cases where problem solving trumped specific skills and where the need for scale trumped everything else.
As it happens, elevating problem-solving ability and the need for a scalable process are both eminently reasonable motivations. But here’s the unfortunate part: the second reason, namely the need for scalability, doesn’t apply in most cases. Very few companies are large enough to need plug and play interviewers. But coming up with interview questions and processes is really hard, so despite their differing needs, smaller companies often take their cues from the larger players, not realizing that companies like Google are successful at hiring because the work they do attracts an assembly line of smart, capable people… and that their success at hiring is often despite their hiring process and not because of it. So you end up with a de facto interviewing cargo cult, where smaller players blindly mimic the actions of their large counterparts and blindly hope for the same results.
The worst part is that these results may not even be repeatable… for anyone. To show you what I mean, I’ll talk a bit about some data we collected at interviewing.io.
Technical interviewing is broken for everybody
Interview outcomes are kind of arbitrary
interviewing.io is a platform where people can practice technical interviewing anonymously and, in the process, find jobs. Interviewers and interviewees meet in a collaborative coding environment and jump right into a technical interview question. After each interview, both sides rate one another, and interviewers rate interviewees on their technical ability. And the same interviewee can do multiple interviews, each of which is with a different interviewer and/or different company, and this opens the door for some interesting and somewhat controlled comparative analysis.
We were curious to see how consistent the same interviewee’s performance was from interview to interview, so we dug into our data. After looking at thousands of interviews on the platform, we’ve discovered something alarming: interviewee performance from interview to interview varied quite a bit, even for people with a high average performance. In the graph below, every represents the mean technical score for an individual interviewee who has done 2 or more interviews on interviewing.io. The y-axis is standard deviation of performance, so the higher up you go, the more volatile interview performance becomes.
As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.
Despite the noise, from the graph above, you can make some guesses about which people you’d want to interview. However, keep in mind that each person above represents a mean. Let’s pretend that, instead, you had to make a decision based on just one data point. That’s where things get dicey. Looking at this data, it’s not hard to see why technical interviewing is often perceived as a game. And, unfortunately, it’s a game where people often can’t tell how they’re doing.
No one can tell how they’re doing
I mentioned above that on interviewing.io, we collect post-interview feedback. In addition to asking interviewers how their candidates did, we also ask interviewees how they think they did. Comparing those numbers for each interview showed us something really surprising: people are terrible at gauging their own interview performance, and impostor syndrome is particularly prevalent. In fact, people underestimate their performance over twice as often as they overestimate it. Take a look at the graph below to see what I mean:
Note that, in our data, impostor syndrome knows no gender or pedigree — it hits engineers on our platform across the board, regardless of who they are or where they come from.
Now here’s the messed up part. During the feedback step that happens after each interview, we ask interviewees if they’d want to work with their interviewer. As it turns out, there’s a very strong relationship between whether people think they did well and whether they would indeed want to work with the interviewer — when people think they did poorly, even if they actually didn’t, they may be a lot less likely to want to work with you. And, by extension, it means that in every interview cycle, some portion of interviewees are losing interest in joining your company just because they didn’t think they did well, despite the fact that they actually did.
As a result, companies are losing candidates from all walks of life because of a fundamental flaw in the process.
Poor performances hit marginalized groups the hardest
Though impostor syndrome appears to hit engineers from all walks of life, we’ve found that women get hit the hardest in the face of an actually poor performance. As we learned above, 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:
A bevy of research appears to support confidence-based attrition as a very real cause for women departing from STEM fields, but I would expect that the implications of the attrition we witnessed extend beyond women to underrepresented groups, across the board.
What the real problem is
At the end of the day, because technical interviewing is indeed a game, like all games, it takes practice to improve. However, unless you’ve been socialized to expect and be prepared for the game-like aspect of the experience, it’s not something that you can necessarily intuit. And if you go into your interviews expecting them to be indicative of your aptitude at the job, which is, at the outset, not an unreasonable assumption, you will be crushed the first time you crash and burn. But the process isn’t a great or predictable indicator of your aptitude. And on top of that, you likely can’t tell how you’re doing even when you do well.
These are issues that everyone who’s gone through the technical interviewing gauntlet has grappled with. But not everyone has the wherewithal or social support to realize that the process is imperfect and to stick with it. And the less people like you are involved, whether it’s because they’re not the same color as you or the same gender or because not a lot of people at your school study computer science or because you’re a dropout or for any number of other reasons, the less support or insider knowledge or 10,000 foot view of the situation you’ll have. Full stop.
Inclusion and education isn’t enough
To help remedy the lack of diversity in its headcount, Facebook has committed to three actionable steps on varying time frames. The first step revolves around creating a more inclusive interview/work environment for existing candidates. The other two are focused on addressing the perceived pipeline problem in tech:
- Short Term: Building a Diverse Slate of Candidates and an Inclusive Working Environment
- Medium Term: Supporting Students with an Interest in Tech
- Long Term: Creating Opportunity and Access
Indeed, efforts to promote inclusiveness and increased funding for education are extremely noble, especially in the face of potentially not being able to see results for years in the case of the latter. However, both take a narrow view of the problem and both continue to funnel candidates into a broken system.
Erica Baker really cuts to the heart of it in her blog post about Twitter hiring a head of D&I:
“What irks me the most about this is that no company, Twitter or otherwise, should have a VP of Diversity and Inclusion. When the VP of Engineering… is thinking about hiring goals for the year, they are not going to concern themselves with the goals of the VP of Diversity and Inclusion. They are going to say ‘hiring more engineers is my job, worrying about the diversity of who I hire is the job of the VP of Diversity and Inclusion.’ When the VP of Diversity and Inclusion says ‘your org is looking a little homogenous, do something about it,’ the VP of Engineering won’t prioritize that because the VP of Engineering doesn’t report to the VP of Diversity and Inclusion, so knows there usually isn’t shit the VP of Diversity and Inclusion can do if the Eng org doesn’t see some improvement in diversity.”
Indeed, this is sad, but true. When faced with a high-visibility conundrum like diversity hiring, a pragmatic and even reasonable reaction on any company’s part is to make a few high-profile hires and throw money at the problem. Then, it looks like you’re doing something, and spinning up a task force or a department or new set of titles is a lot easier than attempting to uproot the entire status quo.
As such, we end up with a newly minted, well-funded department pumping a ton of resources into feeding people who’ve not yet learned about the interviewing being a game into a broken, nondeterministic machine of a process made further worse by the fact that said process favors confidence and persistence over bona fide ability… and where the link between success in navigating said process and subsequent on-the-job performance is tenuous at best.
How to fix things
In the evolution of the technical interview, we saw a gradual reduction in the need for proxies as companies as the technology to write code together remotely emerged; with its advent, abstract, largely arbitrary puzzle questions could start to be phased out.
What’s the next step? Technology has the power to free us from relying on proxies, so that we can look at each individual as an indicative, unique bundle of performance-based data points. At interviewing.io, we make it possible to move away from proxies by looking at each interviewee as a collection of data points that tell a story, rather than one arbitrary glimpse of something they did once.
But that’s not enough either. Interviews themselves need to continue to evolve. The process itself needs to be repeatable, predictive of aptitude at the actual job, and not a system to be gamed, where a huge benefit is incurred by knowing the rules. And the larger organizations whose processes act as a template for everyone else need to lead the charge. Only then can we really be welcoming to a truly diverse group of candidates.
I really enjoyed this article and much of it resonates with me. As someone who has worked diligently to shape my interviewing and hiring practices over the years, my concern (regardless of D&I) is more around making an interview as stress-free as possible, than finding the perfect puzzle question to find only the smartest of the smart. This usually means having the candidate bring their own laptop to the interview and work on some of their own code, or pair programming so the candidate isn’t the only one writing code, as this is far more indicative of a typical work day.
I’m curious how companies strike a balance, though: diversity and inclusion are certainly appropriate goals… however, many of the companies I’ve been fortunate to work within as a technical hiring manager or interview lead have not been large enough to “afford” a lesser candidate because of D&I numbers simply to boost numbers. Isn’t my responsibility to the company to hire the best engineers I can find to solve the problems we have to meet deadlines or customer/shareholder expectations? I don’t often have the luxury of taking several months to find some combination of smarts/diversity just to meet a D&I goal to bump a statistic.
That said, I’ve hired plenty of people from widely diverse backgrounds, genders, nationalities, to fill a role who were also smart enough or had the exact hands-on skills required, but this feels far from the norm.
I agree. I understand D&I are buzz words right now but in some way D&I creates discrimination itself. As a woman, perhaps from a place where the process seem more healthy, I felt almost offended by American well known company that offered me a job because of my gender. Clearly I noticed during interview my achievements were secondary.
That “lesser candidate” will most likely work twice as hard once they are hired, because they know they have to prove that hiring them was justified. That “lesser candidate” will bring a completely new perspective to your development team because of their different backgrounds. That “lesser candidate” is probably only lesser because they simply have never had the same opportunities as your standard white male developer. Given those opportunities, they will quickly prove their worth. The best, most efficient, and most creative development teams I’ve worked in have all been mixed race and mixed gender. And when I say mixed, I don’t mean one token “diverse” developer.
Ian, this is a weird take because of the paradigm you have set up, in which D&I *detracts* from your ability to “hire the best engineers I can find to solve the problems we have to meet deadlines…”
You have in fact answered your question yourself when you say how diverse your hires have, in fact, been. And that this is far from the norm.
The point of D&I is specifically to ensure you are actually getting the best people for the job and getting rid of unconscious biases. Good D&I practices mean you can attract the widest range of candidates. As this article shows, if women or disabled people stop applying, you lose their skills and expertise. This also means your company won’t have insight into lots of its potential customers.
This is an excellent article and one I intend to route to everyone at my organization who participates I hiring. But…
Processes that involve judging people based on limited information will always be gameable systems. Because we will always use proxies. More information and better approaches may mean better proxies, but proxies are as inevitable in interviews as they are in dating, voting, or any other choice. The key is to analyze our proxies and remove those that have a (intentional or accidental) racial or gender bias. No evaluation will be in gameable. The best we can hope for is to design an evaluation where it’s easier to win by getting good than by leaning the test
Take all the “diversity” rhetoric, studies, graphs and everything else, throw it in the garbage. Now, hire the most qualified person. Done. Tech is now fixed, again.
I love all the millennials that think “tech” is a charity or some kind of make-work. I come from a time where the best person was hired, period. All employees respected each other because their skillset was respected and understood for time and effort it takes.
I await the replies of non-developers to tell me how *-ist and *-phobic I am, as if the opinion of people who should never be in this profession matter to me.
The entire article was about how the current process does not result in hiring the best candidate. Let all the resumes and coding challenges be anonymous – the hiring demographics would change. If you think you have no bias, you’re lying to yourself.
You only think the ‘best’ person was hired.. The entire purpose of this article is that all the actual hiring DATA shows 0 correlation between hiring someone who companies ‘think’ is the best and their actual performance.. ITs a crap shoot, you might think the guy you interviewed is awesome, the best, #1, but the data shows that its 50/50 that they will actually perform at the level you perceived them to be at.
I think you meant 9 coins! I’m not very good at puzzles, but I don’t see a way to figure out 8 coins in less than 3 steps. 9 coins can be done in 2 steps, though.
http://www.cut-the-knot.org/blue/EightCoins.shtml
I won’t summarize the solutions here, lest I spoil the fun for others.
Interesting article.
One solution would be to have real programming problems that the applicant would solve on site. Each applicant will come to solve a small number of programming problems using a laptop that they bring with their favorite tools installed. The test would be done in a room with no internet access and would be monitored by someone that isn’t part of the interview team. It is a level playing field in the same way that candidates for a symphony orchestra are asked to play music behind a screen: those listening cannot see the candidate but hear what they can do.
You still need face-to-face interviews to see if the person is a good fit for the group. I’d rather have a grade B programmer on the team who is a team player than have an A+ programmer who can’t get along with others.
RE: “We discovered that after a poor performance, women are 7 times more likely to stop practicing than men”.
That’s a stunning observation.
I’m not worhty to be in the same forum. ROTFL
I was with you until “no internet access”. The whole point of the interview is: can this person do their job in normal conditions. Do you normally work with no access to internet?
Just make sure the task is not too trivial like yet another “program for finding out if given number is a prime” which can be copy pasted from Wikipedia. If you have a somewhat more complex problem, there really is no reason for not allowing internet access. I’d argue even more: I’ll always take a person who proves they can use internet efficiently. It’s shocking how many people have to be sent to lmgtfy.com.
As a fun fact. We have a fairly simple coding task that we send out to candidates to be done at their own leisure. No time limits, no control over what resources they use, nothing. Just give me your best. Still, we get probably 30-40% solutions that don’t work at all, another bunch that “sort of work” (concurrency problem, and they send solutions that are effectively forcing single threading), some with horrible coding style, no tests, some don’t even compile… So really. Giving someone ability to Google doesn’t necessarily give a huge advantage. You still need to know how to use it well (quickly and not blind copy paste), and imho that’s a *very* important part of being a developer.
“Each applicant will come to solve a small number of programming problems using a laptop that they bring with their favorite tools installed.”
So you’d require them to own a (powerful enough) *laptop* with a properly configured environment, and to take it away from home for a few hours. It might not seem such a big requirement, but that in itself might exclude a few people : people who only have a *desktop* computer, or those who share their computer with the rest of their family (and thus cannot take it away from home anywhen)
Define a set of minimum requirements for applicants.
Take all applications that meet the minimum requirements, and roll a die to select the winner.
Pingback: The discussion about the Why and How – Becoming Senior
This article is interesting on multiple levels. I wish to comment on two aspects in particular.
First, this is the first article I’ve seen of any substance which not only describes the technical interview as a sort of game which requires skills which are not necessarily the same as those needed to do the job, but suggests that it isn’t even supposed to and that this fact is no secret. That’s refreshing, but also disappointing, since one would hope that companies could at least attempt to use the very short time with a candidate for something other than posing a stunt competition which has a very loose connection to the necessities of the job.
Second, the delicate issue of race is raised in this piece. There is a common opinion, reflected in at least one or two of the comments posted on this article, that race should be a non-factor in the hiring process. The thinking is that for tech in particular, it should be relatively easy to hire the most qualified people and take race out of the equation. This sounds reasonable at face value, but this sentiment is problematic on several fronts.
For one thing, this philosophy necessarily presumes that if all or nearly all of a company’s employees were of a single race or demographic group because of their superior performance on some objective measure, that the company would perform in a superior way because they have the top employees. However, it fails to take into account the various advantages a company has simply by virtue of being diverse. It is these advantages that companies increasingly recognize and therefore they attempt to diversify their workforce.
Finally, and I realize this is controversial, the United States has made some progress in regards to individual racism, especially in the corporate world, but we still live in a less visible morass of systemic racism in almost every American institution. Much like Equal Opportunity and Affirmative Action-type programs, the need to reach out to minorities and underrepresented demographic groups in the Tech and corporate worlds comes as a sort of counter-measure to the fact that a big reason why those groups are underrepresented and sometimes underperform in the first place is because the bigotry and intolerance interwoven into our established ways of doing things makes it so. Those who object to this line of reasoning or call it favoritism do not recognize and appreciate the fact that certain groups actually do not get to play on a level field and never have, despite what we say or believe. And that is a problem that won’t be solved soon, won’t be fixed by any sort of interview methodology, and is well beyond the scope of this article.
Pingback: A recruiter analyzed results from 3000 tech interviews to find the most successful candidate traits — Quartz
I have taken every type of interview possibly imagined in the 42 years I spent in the corporate environments of IT organizations. I have also given many interviews myself and every one of my recommendations worked out for the company.
The way I interviewed all of these successful candidates was with two underlying concepts during the interview process…
1… Does the candidate have the ability to learn new technologies?
2… Does the candidate exhibit a keen interest in his or her chosen profession?
That was it.
My technical exams were a mix of very easy and very hard questions but all with scenarios that technical professionals would have to handle on a regular basis. I also scored each question differently. The harder a question became the more I sliced the answer to fit in with the score for the question. In other words. A candidate was thus scored for each question based upon a percentage of the answer he\she got correct. So if a person got 50% of the question he\she was given a half point and so on.
Just as importantly, the candidate was given credit if he\she stated that they honestly didn’t know instead of trying to make up an answer.
The majority of interviews given by people in Information Technology through today are people who have no idea what they are doing or have any concept of what they are looking for. They all view people as some new form of sentient, mechanical beings that should be able to regurgitate with precision answers and scenarios with the skills of a brain surgeon when our field is predicated mostly on research.
So more power to all of those who are now trying to resist this rampant stupidity in our profession… 🙂
Dear highly educated “White Man”,
While you were the most qualified candidate for the IT role, we regret to inform you we’ve gone in a different direction. You see, our recruiters receive bonuses, and our company tax incentives, if we discriminate against your sex and race. The system drives conformity to hire those who are NOT white men. We must maintain a percentage of certain groups as a full-time employee even if they’re not fully qualified. Yes, I agree with the fact woman aren’t really a minority, and as compared to the 8 BB people on earth white men are the minority, AND there is an all out war against men in leadership roles, however, we can not afford to be penalized and fined, or receive bad press, because we aren’t compliant with ridiculous hiring requirements. Furthermore, we understand the politics of merging Hispanics and Whites into all being Caucasian, and by 2050 whites will officially be the minority in the US, but we are shortsighted, have a mob mentality, and so we must comply. Personally, I realize you spent $100,000 on your education, which you likely borrowed with interest, that you earned great grades and have worked hard, but your sex and color have eliminated you from further consideration. We further realize you had NOTHING to do with the oppression white men have caused in the past, that 600,000 northern soldiers died freeing the southern slaves in the civil war, but they still relive the pain. Of course, your family had nothing to do with any of this as your ancestors migrated to the US after the civil war. Finally, because of the history conducted by ignorant white men (which was legal and acceptable by society (worldwide) at the time), we feel justified in repackaging such oppression and calling it justice and or worse inclusion.
We hope you enjoy the next 33 years of hell in dealing with the tidal wave of oppression which will come upon you soon enough.
Good Luck,
Every US Company
Shut the hell up
Do you enjoy thinking this way? Being an asshole on the internet? You are the definition of an inferiority complex.
Pingback: Программисты не могут написать алгоритмы без помощи: ещё раз про интервью – Русский Эпик
Although, I understand the sentiment that hiring needs to be fixed, this analysis is severely flawed. This is an instance where a “hypothesis” is constructed with a pre-determined outcome already in mind. There is nothing scientific about this “study” at all.
https://lh3.googleusercontent.com/-sSp_3AYqBuk/WKRiBRsSKdI/AAAAAAAAc7o/IKK4RJZPFCYmo-881DLFC4QcWvAI6K_DgCL0B/h484/7874724163267922725%253Faccount_id%253D1
Pingback: Reading List March 3 – 15, 2017 – Jega's Blog
Pingback: Gender diversity in tech: one simple part of the solution - College Recruiter
Pingback: Diversity quotas suck. Here’s why. | Aline Lerner's Blog
Pingback: This is why recruiters are failing at hiring diverse tech candidates | Inclusion Business
Pingback: Impostor syndrome strikes men just as hard as women… and other findings from thousands of technical interviews – Planet Report
Pingback: [Перевод] Синдром самозванца затрагивает мужчин не меньше, чем женщин… и другие выводы из 10 000 технических собеседований – CHEPA website
Pingback: 5 issues you are able to do at present to empower ladies in journey expertise - Techi Blog
Pingback: Five things you can do today to empower women in travel technology – PhocusWire
Pingback: Five things you can do today to empower women in travel technology – MyCityTravelGuide
Pingback: The Eng Hiring Bar: What the hell is it? - interviewing.io blog - NSO News
Pingback: Планка найма для инженеров: что это за зверь? / Хабр
Pingback: Планка найма для инженеров: что это за зверь? - Дорвеи и Сателлиты
Pingback: “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
Pingback: Here's what job seekers need to know about LeetCode, the coding-skills platform millions of developers use to ace the notoriously difficult technical interviews at firms such as Apple, Amazon, and... - Times News Network
Pingback: Here's what job seekers need to know about LeetCode, the coding-skills platform millions of developers use to ace the notoriously difficult technical interviews at firms such as Apple, Amazon, and... - Times News Express
Pingback: Here's what job seekers need to know about LeetCode, the coding-skills platform millions of developers use to ace the notoriously difficult technical interviews at firms such as Apple, Amazon, and... - News Nation USA
Pingback: Here's what job seekers need to know about LeetCode, the coding-skills platform millions of developers use to ace the notoriously difficult technical interviews at firms such as Apple, Amazon, and... - WealthInsider | Follow The Money
Pingback: LeetCode: Inside the Coding Practice Test Devs Use for Technical Interview Prep - Business Insider - My Blog
My past 20 jobs we have mostly H1B people from india. They are diverse right?
I realize that you have a product to sell, but the conclusions drawn here are just… lacking.
Women are socialized differently, and that plays out into how pair programming works–even when its done by a woman (she succeeded by mastering the dominant male way of interacting, so she’s implicitly testing for that). Display hesitation? You’re lacking tech skills. While she might be looking for agreement, a common way that women communicate. This is just one of a great many ways that this plays out, and I’m pulling it from the top of my head.
The fact that I’m even RESPONDING and daring to contradict you is not something women are socialized to do. “I disagree” is not allowable in most social contexts when it comes from a woman who is not designated as powerful.
Maybe the right idea isn’t to teach women how to do this better but to teach interviewers how to spot knowledge, experience, and promise in a candidate who isn’t a dominant-culture male. JMO, feel free to dismiss it entirely or take credit for it later.