Hacker News new | past | comments | ask | show | jobs | submit login
The software industry's greatest sin: hiring (neilwithdata.com)
542 points by nsainsbury 89 days ago | hide | past | favorite | 576 comments



Technical interviews were once seen as a breath of fresh air.

You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired.

Contrast this with other hiring processes which are more irrational, like med residency match, investment banks favoring "target school graduates", law firms favoring "top 14 graduates", etc.

I think whiteboarding is dumb and I'm increasingly unwilling to go through with it. That's a hurdle.

But in many careers the hiring processes are walls, as in there is 0% chance you'll get hired. Because you don't know someone, because you didn't go to the right school. The barriers have little correlation with ability to do the job, and more importantly after some milestone has been crossed it's impossible for you to improve your chances.


It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing.

The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast about how many "top school" candidates they hire.

Tech companies are hugely biased in favoring the upper class. And then they misguidedly try to pay a recompense for this unethical bias by discriminating on the basis of race in favor of "unrepresented minorities". Of course, they still really want those "URMs" to come from a "top school".

Their goal is to counter their active classism through active racism. As if they somehow cancel each other out.


One of my previous bosses (at a large tech company) moved over to the US and was asked to hire 9-10 people in a quarter.

Everyone said it was impossible.

She went to LinkedIn, found people with the right skills (strong data and ability to communicate), and had a massive fight with HR because none of the candidates came from "top" schools.

She won the argument, and all of the hired candidates did a great job.

People (especially US people for some reason) seem overly obsessed with the university someone attended, when it doesn't seem to be that predictive of workplace success.


> especially US people

definitely not. french companies actually have engineering salary tables depending on your age and university


That sounds interesting, is there an english source to read about that?


I can’t find anything concrete, each company does it internally. There are some articles where they publish the starting salary based on your university’s “rank”. Try google translate on this: https://www.google.com/amp/s/www.lexpress.fr/emploi/les-atou...

It discusses how there are 6 ranks for business schools, and your salary for the first N years will be based on that. Same for engineering. It’s funny that one of the companies is proud to declare that they can move salaries by “up to 5%!!!” based on the candidate themselves (whereas the school can make a 20-30% difference...)


Google translate worked really well on the article, thanks! That's kind of insane that the school you went to can give you a raise from 30k euro to 40k euro despite having to do the same job.


The university obsession is not unique to US. It's true in India as well. If you are not from the elite institutions, you won't get past any hiring scanners of top tech companies. You'll still get a job, not the best paying one though.


It's common to all developing nations, and the US (which is both a developing nation and a developed nation in one).


It's common to all nations, period.


It's a heck of a lot less common in Scandinavian countries, or even a large part of (Eastern-) Europe. But yeah, no facts, just an opinion i guess


For the record: not to all nations. In Russia, a really cool technical university (Bauman's, PhysTech, some faculitis of MGU) will give you some advantage in the early stages of your IT career, but not that much.

Source: am a dropout of a shitty university, still have no degree. It does not bother HRs, as far as I could see so far.


Also anecdotally I haven't noticed it in Iceland. I've been part of a number of hiring processes here and although the presence or absence of education has of course been a factor, where that education happened has been totally irrelevant.


The elite don’t like plebs breaking into their clubs.


US is so much better than India. Indian companies openly write in job description that only people with education in premier institutes apply.


>(especially US people for some reason) seem overly obsessed with the university someone attended

That happens literally everywhere, especially at big companies that make easy money. The elites don't like sharing the pie with the great unwashed.


I dunno man, I was really surprised by the behaviours I saw; maybe I have been particularly fortunate in my career but it definitely seemed to me like it was worse in the US.

Perhaps it's bad in other places too. I personally think it's idiotic, as the point of interviewing is to find great candidates, and I have never felt like the University they attended was a particularly good predictor of that.


I don't presume to know what that depends on, but wherever you go, in my experience, there seems to be a mix of job opportunities that are diploma-centric and skill-centric. What's more, the people I'm interested working with are generally in the latter category. So it's somewhat ironic, but the whole me-not-having-a-top-school-diploma thing works to my advantage by inadvertantly pinpointing the interesting opportunities.


This is curious given there are well documented findings that which school you attended doesn't correlate to actual success. This is true in Engineering and Law. The problem, particularly in the US, is that the skills that are tested by the standardized tests (SAT, LSAT) are NOT the skills that make someone good at the job that comes out at the end.


That's surprising.

Can I have a citation?


That entirely depends on the company. The US is nearly the size of Europe, each state is roughly equivalent to a different country. How people think and behave vary vastly.


> most tech companies heavily favor "top school" candidates and actively recruit for them

Good job prospects upon graduation is one of the things that makes a school a "top school" and attracts smart students. If you wanted to hire people with no work experience, and money was no object, a "top school" would be the logical place to go to first. And I say this as someone who didn't go to a top school. So tech companies actively recruit from top schools only insofar as every other company in every other industry does. But that doesn't mean they recruit exclusively from top schools either. Stanford, MIT, and the Ivy League literally don't graduate enough students for that to be a feasible new grad hiring strategy.

You'd have to provide evidence for the first half of that statement though. My personal experience is after you've worked a few years, no one in software engineering cares where (or even if) you went to school. And any software engineer with a pulse located in the SF Bay Area can get at least a phone interview with any of the top tech companies.


> You'd have to provide evidence for the first half of that statement though.

I've worked for 10 years and recently applied for a position. The manager told me I was a good candidate, and that I checked the box for coming from a top school.

He didn't use the phrase "checked the box" but did explicitly say that my coming from a top school meant he could skip most of the technical portion of the interview and just focus on the people aspect.

But for the most part I agree with you. It usually is important for the first job.


For the first job, I agree that it's important and I don't even have a problem with it being a factor. What I do have a problem with is discriminating salary or hiring based on what school you went to 5+ years into your career, by which point it matters a lot less.


> For the first job, I agree that it's important and I don't even have a problem with it being a factor.

As someone who went both to a top school and a very average school, I do have a problem with it. If you've not been to an average school, you may be surprised at how many bright and motivated students there are.[1] And if you've not been to a top school, you may be surprised at how average most of the students are.

I don't know if this generalizes, but it was my observation: Top school students tended to be a bit less honest (soft cheating, etc). At least where I was, it appeared to be clearly tied to the competitiveness needed to get in and get top grades.

[1] My grad school group-mate, who had only been at top schools, once went for an internship in a national lab. He was shaken at the fact that another intern from the University of Alabama-Huntsville was as capable/smart as he was. I saw this often in top school students, where they just assume that if they're doing well in school, that they are somehow better educated than the rest of the country.


I've only ever been to 'average schools.' With no data to back up this claim, I'd be willing to bet even the worst students that graduate from top schools are still better than the lower end of average from average schools, because the barrier to entry (and continued attendance) at top schools is higher. I'd also not be surprised if your claim of top school graduates being less honest were true, for the same reasons.

If I were in a position to interview and hire someone, graduating from a top school would at least garner some attention, assuming the degree was relevant, but it's not a 'free pass' through any of the steps of the interview process, and may even earn them a more critical assessment in the implicit 'culture fit/personality' category.

This is just my opinion on the matter, not trying to make any sort of factual claims.


> I'd be willing to bet even the worst students that graduate from top schools are still better than the lower end of average from average schools,

That may be true, but likely both of these have poor GPAs and thus are filtered out anyway. Usually you'll be evaluating candidates with at least a decent GPA.

I'm not claiming the average is the same between the two. But when there are a lot more average schools than top schools, chances are that numerically most good candidates do not come from top schools.

When I look at resumes of new grads, I ignore the school altogether. GPA has to meet some not-high threshold, and then it's just a peek at interesting projects they may have done.


I've seen some tech jobs here in London essentially requiring to be a graduate from one of 5 or so universities in the country. However,these were more senior positions that'd require years of industry experience. And then they moan they can't get Java devs for £150K/year...


In years past, I've seen a plethora of £700-1200/day contracts in London for candidates with only 2 years of experience and no education requirement.

And it has always made me wonder why they were offering such high pay for such low experience, when salaried positions in London are lower than NYC, and most of the contract work I see in NYC are half that rate.


I don't think most of those ads had any sense at all tbh( I used to see a lot of them as wel) and here's why: 99% of these jobs are in financial sector, especially in trading branches). Most of them may only require 2 years or so experience, however the experience they need are in some esoteric products/services one can only learn/access if in this kind of job( i.e. FX trading platforms, interbank settlement software,some random inhouse thing that connects to NASDAQ,etc.) The reality is that for most of those jobs there are only 50-100 people in the city who can do it and they are all employed and they all know it.So any recruiter worth his salt knows most of them by name,as they just keep crossing the road from one bank to another every couple of years. So all these ads do serve is some newly hired recruiter with no contacts, who hopes some random guy from abroad will have the necessary experience and won't understand the market situation.


Are those jobs in specific industries? Like financial tech jobs.


I’ve been in the industry for 20 years and have worked for a lot of companies, some very big names, and have been in a hiring position for the last 10 years or so. I’ve never once noticed or cared about an applicant’s university, nor has anyone I worked with. So, anecdotes be anecdotal.


Sounds like you're just projecting your own mentality on everyone you've ever worked with for some reason.


That’s probably true to an extent, but I have had many conversations with hiring folks. University never once came up. Anyway, my point is that anecdotal evidence is all I see in this discussion, so who knows what reality is?


Why do you say Google discriminates on the basis of race? I used to work there and was involved in the hiring processes and never saw evidence for this


> Why do you say Google discriminates on the basis of race?

Google told their recruiters to actively not hire white or asian males for certain roles.

https://www.theverge.com/2018/3/2/17070624/google-youtube-wi...


> Wilberg’s lawsuit targets Google and 25 unnamed Google employees who allegedly enforced discriminatory hiring rules, quoting a number of emails and other documents. It claims that for several quarters, Google would only hire people from historically underrepresented groups for technical positions. In one hiring round, the team was allegedly instructed to cancel all software engineering interviews with non-diverse applicants below a certain experience level, and to “purge entirely any applications by non-diverse employees from the hiring pipeline.” California labor law prohibits refusing to hire employees based on characteristics like race or gender.

Perception shaping is always unsavoury, but that's pretty dark.


What ever happened with that lawsuit?


As an employee of Google who is involved in hiring let me tell you the process is extremely rigorous and we work very hard to make it bias free. I am not an unbiased individual myself but when it comes to hiring, I work extra hard to ensure fairness regardless of other person's characteristics.


And as a former Googler who did hundreds of interviews there, let me tell you you're wrong. It wasn't bias free even years ago, and Google has gone much more hard-core SJW since then. It's still much better than at most companies, and the article we're discussing is so wrong about the way executives are hired. But Google isn't some paragon of freedom from bias, far from it.

Ignore yourself. The system surrounding you is not unbiased and never was. Here are some things I'm aware of that happened at Google/other comparable tech firms:

1. Recruiters tracked the quality of interviewers (as judged by candidate and hiring committee feedback) and assign the best interviewers to women/minorities.

2. Sourcers could get much higher bonuses if they recruited women.

3. Comp can end up artificially higher for women, which obviously is a form of recruiting. At Microsoft managers were given bonus pots that could only be allocated to women.

4. Women who failed phone screens were presented for on-site interviews anyway in the hope that they could somehow make up for it. Men were dropped immediately.

5. Women are targeted with specialist recruiting teams, fought over to a dramatically higher extent than men.

6. Men are sometimes just excluded from recruiting events completely, e.g. "Code Jam to IO for Women".

And you seem to have chosen to ignore flashing red alarms like recruiters filing lawsuits with copies of emails where they were told to stop recruiting white men.

BTW, don't look at the firing process. Unlike hiring+promotion, engineers don't control that, HR does (PeopleOps or whatever it's called now). It's an open secret that at Google it's nearly impossible to get fired if you're a female engineer, even if your performance is terrible and your team hates you. At worst they'll start moving you around.


I’ve seen this, too, at a number of places I’ve worked. Pointing it out always gets you downvoted (or whatever the real life equivalent is).


Committing a Career Limiting Move?


Yep, or to state it in AnimalFarm terms:

If cardinality(pigs + sheep) > cardinality(work horses), the truth will be downvoted.

In software, the work horses need to be more proactive and not give up what is theirs.


> But Google isn't some paragon of freedom from bias, far from it.

Not my claim that Google is bias free. I am not denying what you have claimed, it is just that I have not come across such incidents and if you are a qualified person it is extremely unlikely that I will not judge you performance properly because of your gender, race or ethnicity.

There is no doubt that Google has gone lala SJW route in last few years but then many of us put conscious efforts in fixing those problems.


Nothing you're referring to has anything to do with the actual hiring process. None of the issues you listed makes anyone more or less likely to pass the hiring committee. Offers are based on merit as much as they can be. You just have a problem with efforts to reach out to people who normally have a hard time making it into the industry.


Every one of those 6 points made have to do directly with the hiring process. Supporting education and outreach for underrepresented groups is a noble cause, but when it gets to the point of giving a group an easier interview path the hiring is by nature not merit based. In the long run, this will only undermine the efforts to get these groups involved by forcing experience to be viewed with the asterisk that they may or may not have earned their position.


Only one of those 6 suggests an "easier" interviewing path. And it doesn't happen at Google, so I'm still comfortable saying the process is meritocratic.

You're trying to argue that processes to encourage women to join somehow make it easier for them to be hired. Those aren't the same.


Many of those things have absolutely happened in the past at Google. I was told so directly by recruiters and had direct evidence of it myself e.g. I was one of the interviewers that one day started being allocated only female candidates; confirmed by recruiters to be an attempt to boost the numbers. I learned about the females-go-straight-to-HC policy from recruiters as well. Facebook experimented with much higher hiring bonuses for women for a while but I believe they stopped (this is in the public somewhere).

The unfireable nature of female engineers there was rather well known, at least a couple of years ago. The last I heard on that was from a fairly senior manager who after a couple of whiskeys reported he knew of managers fighting to keep female transfers off their teams. Not due to any innate sexism but because they'd realised that female transfers were far more likely to be troublemakers or poor performers than male transfers, due to HR's desperate attempts to recast unacceptable behaviour as just "not being a good fit for the team" and constantly moving them around. I had one on my team who was constantly lying to her teammates, as well as being a completely incompetent coder. For instance she was mystified by a CL she reviewed one day that contained hexadecimal, something she'd apparently never seen before! Some people left the team specifically to get away from her. But, untouchable because the bosses boss was a feminist who thought this young woman with clear management ambitions was just wonderful. Result: she was rapidly promoted into management where she wanted to be, to the disbelief of her remaining teammates.

Most Googlers were never really aware of these practices. Nonetheless, to believe Google is unbiased requires an incredible suspension of disbelief given the rather extreme publicly stated positions Pichai and the remaining senior management have taken, not to mention the Damore fiasco.


> I learned about the females-go-straight-to-HC policy from recruiters as well

I've heard lots of things from recruiters that were wrong. So much so that I generally advise people I know to check with be before believing anything a recruiter says. But because they lie on purpose, but because they're often misinformed.

This goes for compensation, process, and policy questions where recruiter statements reliably break with policy and practice. So pardon me if I don't find recruiters to be a reliable source for hot corp goss.

> Not due to any innate sexism but because they'd realised that female transfers were far more likely to be troublemakers or poor performers than male transfers, due to HR's desperate attempts to recast unacceptable behaviour

Sounds like innate sexism to me, given that the same thing happens with men. It's really hard to get fired. Ive had to deal with (men) not being fired for ages.

> For instance she was mystified by a CL she reviewed one day that contained hexadecimal, something she'd apparently never seen before!

Depending on the language and background, this sounds reasonable. I wouldn't expect a he java or frontend person to necessarily know hex. So yeah you're making my case for me. Sounds like bias against women.


This line of reasoning doesn't hold up. It's just as easy to flip your conclusion on it's head currently; any given member of a majority group could be viewed as only being hired because of internal biases, not merit.

To contribute my own, relatively unique, anecdote, Ive interviewed both as a man and as a woman and the process is considerably easier when you just get to coast through on the "white nerdy guy, must know tech" stereotype.


There are no internal biases in favour of men in any organisation, anywhere. This is feminist propaganda - an assumption that if women dominate a field it's because they're good at it, but if men dominate it's because of innate sexism.

Showing bias in favour of women is very easy: just quote the executive leadership saying things like "we want more women", cite pro-women policies or present one of many other pieces of hard evidence. No such evidence exists for a pro-male bias which is why this argument always ends up relying on logical fallacies and innuendo.


The amount of just unsourced vitriol of your comment is unapproachable. Like, jsut, do some basic math. If you assume roughly even distributions of talent across gender and compound the fact that people tend to not like working in environments where they feel tokenized, hiring women (or any unrepresented minority talent) is just good business sense, no moralizing required.

Maybe try talking to actual women in the field before making such wildly false claims. I do find it hilarious that there's this overarching "feminist propaganda" and despite all that tech companies still routinely have essentially no women in the engineering staff. [0]


If you assume roughly even distributions of talent across gender

Given the differences in the genders of who chooses to study the relevant qualifications, that's obviously a false assumption.

The amount of just unsourced vitriol of your comment is unapproachable

My comments are phrased in a level, factual manner. They're mostly retellings of things seen or experienced first hand, thus I am myself the source. But if you want sourced evidence of similar claims, by all means, go read the recruiter lawsuit against Google that was filed. It has plenty.

Maybe try talking to actual women in the field before making such wildly false claims

If you're going to assert a claim is false you need to pick something specific and show it's false, otherwise you're just blustering. And having direct experience of talking to women about this, I can tell you that many recognise the built-in advantage they have and are quite uncomfortable about it.

I do find it hilarious that there's this overarching "feminist propaganda" and despite all that tech companies still routinely have essentially no women in the engineering staff. [0]

It's pretty ironic that you put citation number in square brackets and then don't actually provide one, given your moaning about unsourced claims. As for "essentially no women" you mean about 15-20%, which is far cry from essentially none. It's this sort of thing that justifies my claim of propaganda; it's normal for jobs to have unbalanced distributions of genders. Very few jobs have exactly equal proportions of men and women. For instance HR has a higher proportion of women than software has a proportion of men, but I don't see much talk of the terrible anti-male bias that must obviously pervade the HR industry. /s


My bad for the previously missing source that's on me. Ive expanded on the thought below with references. (and despite calling me out you still can't find a single source for your claims (short of a vague, go read a document I clearly haven't read for me, which is just, beautiful))

Edited previous comment for the missing source, that's my bad. (and despite calling me out you still can't find a single source for your claims (short of a vague command to go read a document you clearly haven't read, which is just, beautiful))

Let's even abandon, for the sake of argument, any desire to see ratios in engineering even approach demographic ratios and instead just look at the rates graduating with CS degrees. That puts the ceiling closer to between 30 and 40 percent[0, for a representative top tier school] and, by your own admission, we close to half that on average (the numbers fall of faster if you consider technology leadership[1] or look more at smaller companies (which is harder to source considering a lot of places aren't very open with regards to their hiring stats, but in my experience working in nyc I’ve only seen sub 10% (N=3). Sub 10% to me essentially none, since that can basically evaporate with normal engineering churn). If we were to assume there was a grand bias, you'd expect an over representation in relation to the rate graduating at the very least.

“Thing exists” does not imply “thing normal” or “thing ideal”[3]. That’s a common logical fallacy used to justify traditionalism in all forms. Also, as an aside, people are talking about inequality in the HR field, you’re just not paying attention to it (tldr it is weird that there are more women and even with the numerical advantage they’re still underrepresented in leadership which reflects in their comp) [2]. When we look at technology it’s especially strange because there is no clear mechanism (outside of social bias) that might explain why we’d see the ratios present. Despite what men on the internet like to believe there’s no evidence women that go into math or computer science are worse at it than men. Estrogen is great but it doesn’t change your ability to write code. Hell no mechanism to explain why the ratios are more skewed than medicine [5] or law[4] even.

As for women being “uncomfortable talking with you about this”, I’d suspect that has a lot to do with your fear of a nonexistent feminsit boogieman and repeated claims that they don’t deserve their jobs than any kind of conspiracy. Imposter syndrome acts across genders and this repeated narrative plays to a lot of people’s insecurities.

[0]http://oue.gatech.edu/sites/default/files/Georgia%20Tech%20C... [1] https://www.statista.com/chart/4467/female-employees-at-tech... [2] https://recruitingheadlines.com/71-percent-of-hr-professiona... [3]https://www.logicallyfallacious.com/logicalfallacies/Appeal-... [4] https://www.enjuris.com/students/law-school-female-enrollmen... [5]https://www.ama-assn.org/residents-students/specialty-profil...

This was far more effort than you deserve, but, I can only hope one day the culture at some of these major tech companies start to change, if only so I don't have to hear think pieces about how hard it is to hire from people that auto exclude 50% of the population. I can't imagine why women are uncomfortable talking you, a proud sexist that openly claims there's feminist propaganda involved in their hiring. I can't think of any reason short of shame of being involved in such an obvious conspiracy.


short of a vague, go read a document I clearly haven't read for me, which is just, beautiful

This isn't even a grammatical sentence, but you appear to be suggesting that being told what to read isn't providing a source, which is nonsensical.

Go read: https://www.documentcloud.org/documents/4391847-18-CIV-00442...

To repeat - for most of what I've written I'm the source. Make of it what you want. What I've seen is consistent with similar claims made by others, many times in many contexts. The tech industry discriminates against men systematically, and it's because of the distorted ideological beliefs of people like you!

That puts the ceiling closer to between 30 and 40 percent[0, for a representative top tier school

GA Tech isn't representative. Even your own linked document says that: "Georgia Tech also awards more engineering degrees to women than any other U.S. institution"

GA Tech is famous for having a much higher proportion of women on its courses than normal. I guess someone told you it's a success story and now it's your go-to example.

They "achieved" this by systematically discriminating against men, which has led to a Title IX complaint against them for no less than ten different programs:

https://www.aei.org/carpe-diem/title-ix-updates-ocr-opens-in...

They routinely ban men from all sorts of events so if you believe this is an example of an unbiased selection process you're making my case for me. Men are systematically discriminated against and women never are: the disparate outcomes reflect fundamental differences and NOT some sort of non-existent bias against women.

Let's even abandon, for the sake of argument, any desire to see ratios in engineering even approach demographic ratios

You act like it's an absurd position to "abandon", but it's an absurd position to have in the first place. Let's not do for-the-sake-of-argument, let's deal with reality. Nearly all jobs have distributions different to base demography.

Here's a chart you should look at: https://www.bostonglobe.com/metro/2017/03/06/chart-the-perce...

You're picking on engineering here, but why not pick on:

1. Kindergarten teachers, 97.% female

2. Dental hygienists, 97.1% female

3. Nurses, 90% female

4. Phlebotomists, 86.% female

5. Insurance claims processors, 85% female

All these jobs are less representative of the population than programming, which at merely 80% male is significantly less far from 50/50 than a huge number of teaching and medical related roles.

If you scroll the list you'll see that most professions aren't even close to 50/50.

“Thing exists” does not imply “thing normal” or “thing ideal”[3]. That’s a common logical fallacy used to justify traditionalism in all forms

Actually this kind of thinking is itself a logical fallacy. You're starting from a base point of assuming you can understand the reasons for absolutely every fact about the world, which clearly isn't the case. To believe you can decide what is ideal in any area of human existence requires a vastly over-exaggerated sense of one's intellect.

What you call traditionalism is really just a starting assumption that when studying complex evolved systems there are reasons for its current state that you may not understand. This is a perfectly rational assumption and made all the time in e.g. medicine. It's an assumption of incomplete information and inaccurate methods, that can lead to creating new problems instead of solving them. It's what led to "first, do no harm" as a medical concept.

When we look at technology it’s especially strange because there is no clear mechanism (outside of social bias) that might explain why we’d see the ratios present.

This is the root of the problem - that belief is pure ideology. The obvious explanation is that women find technology less interesting than men because they're women and women are different to men, in all sorts of complex ways. This statement is like saying "there's no clear mechanism for why almost everyone who works with children is a woman". Of course there's a clear mechanism for it: they're women, they have babies, they evolved to want to care for children as a result and thus women very often enjoy children's company more than men do. The idea that anything other than the base 50/50 case must be bias ignores not only vast amounts of basic evolutionary theory but also common sense.

In the end I'm arguing with you because it's people like you who ultimately argue for and implement anti-male discrimination, on the belief that you're on some grand moral quest to eliminate discrimination against women. But like Animal Farm, the evil you think you're fighting is in fact yourself - the only gender based discrimination I've ever seen in my entire career was done by feminists.


All of that should be illegal


Why? None of what he said suggests to me than an incompetent women would be hired over a competent man. The outrage over incentivizing minority hires is ridiculous to me. You’re more likely not to get hired because of random noise in the interview process than because you happened to apply at the same time as an equally qualified minority. If companies like google were actually actively discriminating against competent asian/white male developers in favor of minorities their engineer demographics wouldn’t be 80%+ asian/white male. There’s also legitimate business interests for a company to have a diverse body of engineers and managers.


I used to believe that, when I was younger, new to Google and basically naive about these things.

Having had direct experience of how it works over the years, absolutely, incompetent women are more likely to get through the process. You can't constantly, for years, tell everyone that reducing the proportion of men is a critical priority and not have people bend the rules and make exceptions as a consequence. They're only doing what they're told to.

If companies like google were actually actively discriminating against competent asian/white male developers in favor of minorities their engineer demographics wouldn’t be 80%+ asian/white male

Likely the proportion would be higher. But yes, it's hard to change the demographics in areas where hard skills are measurable and where women don't really want to be anyway. Probably that's why feminists are moving on from targeting engineering roles: their current thing is leadership positions where less tangible "soft" skills are more important, comp is higher (the ultimate goal) and it's easier to manipulate the recruiting process. Hence laws enforcing that women be allocated board seats, things like that.

And there lots of men have witnessed women being put into management roles in software they were completely unsuited for, over and over. I think most guys have a story like that by now.


I don't think that people care about how it is actually done, we are all in an in-demand sector. People care about the hypocrisy of companies saying, we only hire the smartest! We don't discriminate! Quickly turning around and saying we need to be more diverse (which is a good thing) so let's throw those CVs out.

And it's always HR... they aren't impacted at all with ok:ish hires.


i've only seen 2 at my workplace. There are positive incentives for hitting women recruit goals but also there are no negative consequences for not doing so.


That's entirely a matter of perspective. The exact same policies can be phrased as "your full comp is not available if you hire men".

Fact is, hiring is in the instant a zero sum game. If recruiters are prioritising women it means they're putting men to the back of the queue in the hope they won't be forced to hire them. It's sexism, it's wrong and it makes a mockery of everything feminists claim to believe.


Underrepresented groups get more attempts and are actively recruited more.


Underrepresented groups are actively recruited but don't get more attempts. If you think otherwise just ask an engineer from an underrepresented groups about their recruiting experiences. They would probably know better. All their interviews include an underrepresented candidate, so their sample size is probably larger :)

The active recruitment is to counterbalance the fact that referrals, one of the biggest sources of talent, is not a diverse pipeline. Everyone's network is mostly male and white or Asian. This is even true of engineers from underrepresented groups. If you want a shot at hiring qualified underrepresented candidates, you have to actively recruit them. Your existing workforce cannot help identify them. That's what's meant by diversity and inclusion.

Now whether you agree that diversity and inclusion are worthwhile is another discussion altogether.


> Underrepresented groups are actively recruited but don't get more attempts.

Other posts in this thread make claims oppose that.

One person says that bad phone screens for men? No call back... bad phone screens for women? call back and face-to-face to get them another chance.

that's the definition of "more attempts".

Whether said comment is real and honest is unknown (random internet comment) and whether "diversity and inclusion" are worth it (actively choosing ("recruiting") someone on race/color/etc to battle perceived racism is... a form of racism itself) is of course another battle...


I can't speak to other companies, but in my experience, inhouse recruiters have no incentive to pass bad candidates past the phone screen. I have no incentive to pass bad candidates to onsite. We want to spend as much time needed to find the right candidate and no more and we don't want miss out on anyone. But we don't want to waste our time either.

I just want to call out that diversity and inclusion are not about battling "perceived racism". Diversity and inclusion measures are to counterbalance the fact that professional (and personal) networks in tech are not diverse. The status quo left alone would bias itself toward white and Asian males irrespective of intent. By actively looking for underrepresented candidates, companies can counterbalance network effects in hiring.


> Underrepresented groups are actively recruited but don't get more attempts.

Yes they do. They are not subject to the same cool down period on a phone screen failure. Remember, google pitches it as “looking for a good signal” so retrying until the candidate passes isn’t lowering the bar in their mind (even though it is because phone screens are flawed but that’s another discussion).

> If you think otherwise just ask an engineer from an underrepresented groups about their recruiting experiences.

I have, I worked there when this started several years back. Several got a chance at a phone rescreen sooner than the normal back-off and one got an invite to come back for a second on-site because “the signal wasn’t clear” on the first.


Take a close look at the diversity report they publish each year.


Not sure why this got downvoted. Google publishes some pretty detailed stats (which I applaud), and the "thumb on the scale" could not be more obvious.

Whether or not you feel this is a problem, it's worth reviewing the data.

[And for the record, I've enjoyed every female or minority colleague I've ever worked with, and made efforts to ensure their success, whatever their ability. I don't particularly object to AA hiring, but I don't like wasting my time on "fake" interviews, so I think publication of stats like this should be required.]


> They would rather higher someone provably less qualified from a "top school" than someone else.

Is this true? I can see this being the result of poorly implemented hiring processes, but I can't see this being the explicit goal at a reasonable company doing reasonable things.


"Provably less qualified" means a cheaper hire so yeah many reasonable companies would choose that option. It's good to remember that you can easily be overqualified.


That's a whole lot of bold, unsubstantiated claims.


I know someone who does a LOT of hiring and he ended up preferring some schools over others.

It wasn't that there were not qualified people from each school, it was just easier to find them at schools with hard-<subject> educations.

There were other schools that were physically closer even within a few miles, but he could go all day without finding a promising candidate.

He hires many minorities, women, people of different orientations, so it wasn't that.

It was more like, "does anyone understand a linked list?"


I wouldn't say that's true of most tech companies, maybe the most selective ones.


I'm not sure how much I want to replace the pseudo-IQtest system with the system where we hire based on classism offset with racism.


Those are not the only two options, you know...


Your response seems to imply that class and race are not related to each other in any way. In fact, they're deeply intertwined.


While I'm pro meritocracy(and think that, contrary to an increasingly popular opinion, anyone of any background is capable of showing merit in this field), technical interviews can be done very poorly and swing so far the other way that they dehumanize the candidate.

Years ago, I had an interview for Yellow Pages. I know, who the hell still uses Yellow Pages? Well, this was back in 2014, though I'm still wondering this now. Anyway, the entire interview process was very depersonalizing. Nobody asked me about my background, why I was interested in working for them, or anything like that.

They had me go into a room and sit down at a computer with someone who was presumably an engineer. I had to solve several code problems in JavaScript and Ruby, each one having to be solved in under a minute. If you didn't finish one, it would just erase what you worked on and moved on to the next problem.

After those shenanigans, they brought me into a board room with 6 other people, and I they asked me to solve several brain teasers, including the "burning rope" problem. These people were stone cold! No humor about them. Fortunately, I memorized most of these brain teasers from the internet and previous interviews, so this part wasn't so much difficult as I had to act like I hadn't heard those questions before.

I didn't get hired, and it was for the best because I'm not a robot, and I don't like brain teasers.

YellowPages.com looks a lot better than it did in 2014, but let's be honest, it's a glorified ripoff of Yelp with shitty search results. In fact, it looks nearly identical to Yelp. I wouldn't have been proud to work on that.


Yelp actually ripped off the Yellow Pages. The name comes from YEL-low-P-ages. The Yellow Pages was a paper-based business telephone directory that started decades earlier.


Oh, for sure, but comparing the state of Yellowpages.com now to its state in 2014, it's clear that someone decided to make the design and UX uncannily similar to that of Yelp. Of course Yellow Pages the concept was around before Yelp.

However, YellowPages.com ripped off the concept of yellow pages just as much as Yelp.

https://en.wikipedia.org/wiki/Yellow_pages


What made yelp good was the reviews, not the listings. This is the part that yellowpages turned around and ripped off.


That's not exactly an original concept, though.


I think people are misunderstanding what I meant.

I'm saying that the YellowPages.com is a ripoff of the Yelp design and experience. If you changed just the logo and the color, it would look identical to Yelp, or at least how it looked before the recent redesign. Of course business listings and ratings are nothing new.


I personally find whiteboarding / diagram drawing very irritating, for the same issue as most physics exercise: given a complex problem and you have to discard 95% of the problem to come up with a result that the teacher might thought.

The same with diagram drawing, 10 boxes and arrows, but missing most aspects of the architecture that actually matter. As a hiring manager I much more prefer to talk through the problem to see if the candidate can ask the right questions, thinks about NFRs, can suggest alternative solutions in light of new information.


On the positive side:

As business gets more intertwined with tech, workers need more technical competency - in parallel with automation of traditional jobs.

My take is that the more traditional companies will have to compete with tech firms on attracting talent, which in turn means that they'll have to change their ways when it comes to hiring, on how they do their hiring.

I think the old days of "We only hire Harvard / Yale / Princeton / Stanford grads with 3.5+ GPA and top internships" are starting to die out. Yes - some of the most competitive jobs will probably continue to use proxies like that, but even firms with the worst gatekeepers are starting to see that there's talent everywhere, and that modern tools can help identifying them. (Remember, one major reason that prestigious firms only hire candidates from top schools and programs, is that they only do their campus recruitment at those schools, because it's a pretty labor and resource costly activity - you can't visit every school in the country, and check out the top students there)


We do whiteboarding, but not because we want to see how God your are to draw neat things. How mucb right you (sure bonus points for vetting it 100 percent right) but if you get it 60 percent right. Explain it nice, asks the right questions. And say where you have no idea. How to go abkit something and maybe even suggest two or three ways to figure it out (or workaround the missing knowledge, technology) the better.

Thats what we want to see.


It’s largely still that way - you need to know someone to get the referral to get the whiteboard interview (after two phone screens).

That said it’s at least a partially objective skill check and I don’t know a better way.


Counterexample: I got an interview at Google a few months ago, with no referral and one phone screen.


Same here. Knew nobody at Google. I didn't even go to a particularly good school or anything. I was approached by a recruiter. Didn't pass the interview, but oh well.

Out of the handful of companies I interviewed at, Google was the only one who offered feedback on where my interview went wrong. I thought that was nice of them.


Yeah it's not impossible, but it's not easy.

Did you go to MIT, Stanford, Berkeley, CMU, Harvard, a different highly selective University?

Were you previously working at another highly selective/famous company?

If so it's pretty easy to get the interview, if not it's pretty hard without a referral.


At the time I started, my university had a 75% acceptance rate. I didn't do any interesting side projects or have amazing extra curriculars.

I just went to the jobs page and clicked the "I'd like a job please" button. And what do you know, a recruiter contacted me a few days later to setup an interview.

I think people underestimate how desperate big tech companies are for warm bodies right now. It's not that hard to get an interview.


Maybe things have changed then (or you went to a highly selective brand name school in which case it’s easy).

I went to RPI which isn’t a bad place, but isn’t MIT. I had a good gpa and decent projects but got ignored or instant rejections from Google and Facebook, I was able to get other interviews (Twitter, Palantir) and after working at a famous company now it’s easy to get interviews, but there’s a randomness to it.

If you don’t have a brand name school or don’t know someone it’s still difficult. Not the fault of the companies really, there are just too many applicants.

Since I was in school there are more companies tackling this like triple byte so maybe it’s better now?


I went to Case Western and got in to RPI as well. So similar tiers of schools IMO.


I work at a FAANG right now - I received interviews for FAANG, top unicorns (Palantir, Uber, Lyft), quant/finance (Citadel, TS, Jane St), with an unrelated degree (Biochem), average school (top Canadian school), and 2ish YOE at a no-name startup. So I would say it's better than I had expected.


Plenty of people freely offer referrals, since they get referral bonuses (or feel like they wanna help people out).


Maybe for FAANG (though even that isn’t super easy if you don’t know them personally), but it’s harder for interesting smaller companies.


> Because you don't know someone

Let's be honest. It totally helps to know someone even in tech even with technical interviews. If you know someone in a group you're interviewing in they'll often give you hints about what the questions will be. They'll even give the exact questions that will be asked. This helps a lot in narrowing down your studying for the test... err... interview.


Well, it's problematic to me. I can ace any test on written paper, but my social anxiety is configured in such a way that I become a blubbering idiot if someone is looking at the back of my head.

My ability to do really well on written tests actually got me into Stanford, despite coming from a pretty normal middle class background -- my dad worked for suburban city government. If I had majored in CS instead of science, I would be a shoe in, but alas I didn't.

If they could just do the tests slightly differently I could ace them. Instead, I'm mainly just avoiding the FAANG world. If I spent another 80 hours practicing them I might have a shot, but eh...


Oh good weekly 'hiring is broken' thread.

I was stuck in stages 2 and 4 ( anger and depression) of 'unable to land a faang(ish) job grief' for years and would make angry comments on this weekly thread.

I think I've made peace with it and I hope to be in stage 5 acceptance. I've been leetcoding every single day for last 3 months, 300 problems in I can hit my target of one easy and one medium with 1 hr goal. I hope to reach my target of 1 easy, 1 medium and 1 hard within one hr. I regret not doing this sooner.

Even if don't land a faag job, this process has led to me accept the process and make peace with it. I really don't care if hiring is 'broken', it is what it is, its an obstacle i need to overcome. Bring on 'trapping rain water' , 'describe one time you had conflict with your team' garbage. I am ready!!


I'm guessing you're being downvoted because your response hasn't offered anything terribly constructive to the conversation, but I have to actually commend your attitude as I have reached a similar mentality. I am Leetcoding, still suck at it but persisting. I'll play the game because I'm not sure what other choice I have. I don't enjoy my current job and in order to get the jobs I want with the people I want to work with this is the price. That being said, it's absurd we have to do this EVERY DAMN TIME. Even moving between FAANG requires you to do this. That in and of itself is a clear indication of how bad of a signal this interview process is. Reviewing reddit and team blind and HN, it seems many folks working at a big tech company still need to leetcode to move to another big tech company despite already passing the bar at one! If that isn't a clear indication of the type of information these interviews provide I don't know what other evidence we need.

Considering how standard it is, we might as well just make it a part of a software developer certification/license that you have to do once to break into the industry.

Then maybe companies can actually focus on hiring for the job?

Even then, I've started to ask what "hiring for the job" means. General aptitude in our field should be a good indicator of ability to learn and pick up skills in different specialties.

The funny thing is, despite our best efforts to not become a real standard profession we are behaving a lot like one, except we don't realize it and keep making candidates jump through the same hoops repeatedly.

Getting many software jobs is still about network and recommendations.

Getting many software jobs is about a standardized base level skillset and knowledge (i.e. leetcoding).

Getting many software jobs is about specializing in a domain and skillset (for e.g. ML or finance or cyber security and all their respective languages and frameworks).

And as many commentors have mentioned we aren't as meritocratic as we would like to believe. We still bring our biases to the hiring process. We still hire people we like for subjective reasons over others.

My point is this. Maybe, just maybe, it's time we as an industry standardized the profession officially and codified what it takes to get certain positions. That's what I can offer to this conversation constructively.

Yes, knowing algorithms and data structures IS imporant to being a good software developer, even if you are building CRUD or mobile apps. But, how many times to do I need to prove I know them? Yes, showing leadership skills IS important to being a good software developer. But isn't being a leader mostly about conflict management, moral obligation and being ethical?

Maybe we can stop fearing becoming a real profession that is beholden to standards and public scrutiny and embrace it. It will end up being better for everyone. Then we can revisit the criteria regularly to make sure the tests we need to pass represent what it means to be do our jobs and do them well.


> your response hasn't offered anything terribly constructive to the conversation

because this hiring thing is the ultimate dead horse of HN. Every single comment here is a rehash of something that has been said a million times.

Here is the one from last week

https://news.ycombinator.com/item?id=22739605

exact same comments.


> Considering how standard it is, we might as well just make it a part of a software developer certification/license that you have to do once to break into the industry.

I think it is only a matter of time for this to happen. All it would really take would be two major companies deciding to standardize on some set of criteria, and smaller companies would follow suit for the sake of simplicity (and because no one really feels like they know what they're doing anyway).


I'd be 100% fine with difficult technical interviews if they actually reflected the job I was going to do. I wouldn't resent spending time outside work studying things that will help me in my day-to-day anyway. What sucks is having to bust your ass studying things that you'll never use.


There is a spectrum of whiteboarding interviews. When I was 20, I loved whiteboarding interviews. Writing perfect compilable C code to insert into a linked list was awesome! I thought that was super fun. But now days it’s more difficult / intense at some companies.


Thank you for eloquently articulating my feelings on the subject. Yes, technical interviews can be infuriating. But in many ways they are more egalitarian than the hiring processes in other professions. Anyone with an internet connection can start practicing leetcode problems today and give themselves a shot at landing a job.


It has never ever been true that you can “be a nobody” and get hired on merit alone. Even with dozens of responders to this comment coming to say that’s how they got hired, it’s total round-off error compared to size of tech hiring at large.

Your credentials and political connections are what allow your resume through the ten arbitrary filters before you even get to the technical screen, collaborative coding, etc., and those same credentials / connections are what get you hired over everyone else who completed the technical assessments just as well as you did.

The tech screens exist as a political gatekeeper filter. It allows people who are fighting over petty authority among codemonkeys way down the food chain to enforce arbitrary and capricious standards, especially on cultural capitulation, to ensure they are hiring people that meet a good mix of (a) competent, (b) don’t know what they are worth, and (c) can’t quickly politically outrank you because you forced them to comply with your tribal pecking order bullshit on the way in the door.

That’s all it has ever been about. It has never ever been the least bit about meritocracy.


I met this kid 20 years younger than me at my last company. He had a thick country accent that made him sound like a redneck, and he never went to college, he only graduated from high school.

One of the best programmers I've ever met.

He couldn't do complex big-O analysis because he never learned it having started to work straight out of high school, but other than that, his code was meticulous, he gave excellent code reviews, and just had this natural understanding of technology and how to program. Probably the best programmer on our team, much better than me and I often sought out his opinion on things, even though I could have been his dad. I always learned things every time I talked to him.

He is a multi-millionaire now, and still works as a programmer but does it for fun.


Every job I’ve met people like this. Charismatic, professional, skilled, and friendly. I try and keep up with how they’re doing when I move on.

I wish more of them were millionaires now. Many of them are still programming (degrees become more important as you move up), which is a shame because they’d probably make fantastic people managers.


One question, how did he make that much money?


Apparently, his childless loving uncle passed away and left him a fortune. You know how these stories go... :)


He went to work for a unicorn very early, and became very rich.


One of the most surprising things to me after seeing the inside of large tech companies was the amount of utterly incompetent politicians who were hired and constantly promoted due to pedigree, nepotism etc. However, at least for the more junior programmer levels I think you're vastly underestimating the amount that merit matters and gives people opportunities they wouldn't dream of having in non-tech fields.


Large organizations, especially if they are swimming in effortless money, will always be very political.

Go to small startups if you want it to be about competence and teamwork.


Totally not my experience.

And I do 3-4 hiring interviews a week here in NYC. What connections? First show that you can code; a lot don't pass this filter. Then show that you can architect a large distributed system on a whiteboard; a lot of people applying for a senior software engineer position lack the breadth of knowledge and the consideration required.

And after that you'd speak to CTO, where maybe you can say or do something so silly to be rejected; this happens very rarely.


Ah yes, the bane of my existence, again: "senior" == "ability to build large distributed systems".

I mean, hell, that's a great skill. I wish I had it. Then again, I've seen people forced to build "large distributed systems" to solve things I can solve on one thread on one CPU because they don't have my skills. It's almost as if there is more than one skill that qualifies you as "senior" or something!


What is funny is I had spent more than half of my career working in the SEO space building "efficient," "high-scale," "single server" web applications, because people don't want to have to hire teams of people to manage all the different "-ops" that go along with the modern, micro-service, distributed architecture that is unnecessary 90% of the time.

All of those quotes were because they are all relative terms. Like high-scale meaning 10,000s of concurrent users; and single server for the web app (separate database server, or utilities server for cron jobs, offline processing, etc); and efficient meaning nothing really.


I don't think every system needs to be large or distributed. 90% of engineers aren't going to need to go beyond the basics of load balancing.


What we do is just that, so we're trying to see if a potential hire will be able to work with what we have.

Non-senior SE candidates don't have to do this exercise.


I have my doubts about your conclusions given your statements. It seems you have 3 steps in your interview process: code assessment, architecture assessment, and CTO interview. And the candidate who does well on all three gets the job? So, does your funnel filter to exactly one candidate every time? And if it does not, then what criterion are used to funnel all candidates who finished this process successfully? Perhaps, you will argue it comes down to whomever did better on one of the exercises. But that is never a guarantee and would seem a trivial differentiation if multiple candidates had viable and correct solutions.

So, genuine question then: What are the final and most important criterion that would be used to differentiate between two completely successful candidates being equal in their performance in your pipeline?

I think the answer to that will give more credit to the comment you are trying to negate.


In my experience, if there are multiple qualified candidates it usually comes down to things like who lives closest (so we don't have to pay to move them here)? Who was the most friendly/likeable? Who might have a skill that we might need in the future? Etc.


Asking candidates where they live is illegal. You can not discriminate based on exact location. (It’s okay to ask if they need relocation of course, but you can’t decide based on who is “the closest”)


I don't need to ask them. I've never ever seen a resume (and I've seen thousands of resumes) that doesn't have the candidates home address at the very top.


> to things like who lives closest

Yikes! You may want to review laws about hiring... immediately.


Have you ever seen a resume that doesn't have the candidates address at the top of the page? I haven't. We typically receive hundreds of applications for any one job. We phone interview maybe 20 of them and in person interview maybe 10 of them. Those who we don't hire are never given a reason why we chose someone else. They don't know if it is because they don't have the requisite skills or because they live 2000 miles away and we would have to pay to move them to our state.

This isn't to say that we never hire anyone from out of state. We have done so on many occasions. But if there are 2 equally qualified candidates, we are more likely to choose the one that already lives close by and can start immediately.


These responses cast serious doubt on some of your earlier comments.


In what way?


My experience as a hiring manager disagrees with yours. Large system design interviews are par for the course - everyone knows how to do them and everyone has lots of experience. They don’t tell you really anything about a candidate, to the point that we should stop using them.


In my experience, this has been rather selective.

Some people have very little idea about load-balancing, DNS, database scaling (replication, sharding, etc), fault tolerance, graceful degradation, queues, throttling, caching, you name it.


If candidates take a course like this, does that mean they're self-starting go-getters trying to expand their knowledge to become good engineers, or people trying to game the section on the interview- or both?

https://www.educative.io/courses/grokking-the-system-design-...


I thought about this myself as I went through this exact course. For context I had been exposed to and even implemented some of the concepts (like db sharding) at work but much of it was still new to me.

An ideal interview should reflect the actual work you'll do during the job. And I think system design interviews accomplish that job pretty well (certainly much better than coding interviews). Will you ever have to design and build a system like you during the interview? Likely not - a startup, while does require building a lot things for scratch, rarely requires the scalability and intricacy outlined in these interviews. While large companies will have the components broken up by team, so you'll often be silo'd into just one part.

That said, knowing how your systems work at a high-level is much more useful than knowing something like shortest-path algorithms. Even if you are silo'd, understanding upstream/downstream interactions can be crucial.


If they actually understand the stuff they learn this way, I'm fine with that! It's strictly better than just doing nothing.


These topics are covered extensively in cookie-cutter interview prep materials like Hacking the Coding Interview. Every candidate is treating these things the same as leetcode trivia. There are whole YouTube channels devoted to how to rote memorize the path to answer open-ended system design questions like designing a fault tolerant Twitter feed, asynchronous video streaming, etc. The rote memorization even extends many layers deep into “nuanced” follow up questions that are supposed to distinguish mere rote memorization from real experience.

This is just every candidate, certainly at the senior level. It’s impossible to use these questions to discern anything. Even asking them to give these details about past real systems they designed you’re just getting the same 5-layer-deep inception rote memorization of everything they could be asked and every follow up contingency.


> It has never ever been the least bit about meritocracy.

You might find it as amusing as I did to learn that the word ‘meritocracy’ was intentionally coined to mean more or less the opposite of what you think and how you used it here — meritocracy was a derogatory word intended to highlight the social injustice of thinking that ‘merit’ is somehow fair and can be measured and used to rank people.

https://en.wikipedia.org/wiki/The_Rise_of_the_Meritocracy

Anyway, I’ve gotten hired into a good spot in a company without knowing anyone there. Maybe the dozens of responders are some indication it’s more than round-off error? Why are you so certain?

> Your credentials and political connections are what allow your resume through...

Wait, aren’t credentials one type of “merit”?


> Wait, aren’t credentials one type of “merit”?

Credentials are only a weak signal of merit. They are often gained illicitly and are no substitute for actual ability.


What is your proposed alternative for a hiring process that doesn’t involve credentials? (And have you actually tried it?) How do you demonstrate merit in a practical amount of time? What is a strong signal of merit? What does “merit” actually mean to you?

When I hire people, I care about potential and attitude more than merit. I don’t care as much about what someone has accomplished as I do about whether someone wants to learn, is smart and eager to be part of a team. I’ve seen with my own eyes people that come with a lot of accomplishment and a ton of skill, people who have a lot of merit by any definition, and who are terrible people to hire who cause real damage on teams. I don’t believe that “merit” is a particularly strong signal for job performance.

What are you referring to about credentials being gained illicitly? How often does this happen? Are you talking about degrees? I’ve never met someone with an illicitly gained degree, and it would be stupid to try that; you’d get caught immediately. It’s not as easy as just lying. If you’re talking about degrees, I serious doubt that happens “often”, but feel free to provide some evidence that it’s more than statistical noise or anecdotes. If not degrees, what are you talking about?

Lastly, and maybe most importantly, the meta point here is that “actual ability” is to some degree a socially unjust metric. IQ correlates with family income. Why? Because people with more money get better nutrition, more training, better schools, stronger business networks. The advantages in life are, statistically, a major component of what leads to “ability” in the first place.


> How do you demonstrate merit in a practical amount of time?

I do think standardized tests do a pretty good job. Test mostly on algorithms/tech related questions and you'll mostly find people with interest in these topics. You're right that people who do well on these types of tests may still be terrible people, but it hasn't been my experience that interviews are good at snuffing out terrible people as opposed to people who aren't like the interviewers (ex. people who grew up in poor environments whereas the interviewer didn't).

> What are you referring to about credentials being gained illicitly? How often does this happen?

Regarding degrees, it's well known for example that the Ivy League have large biases towards legacy admissions and for example Asian Americans are highly penalized due to affirmative action. Any effects caused by these types of biases are immoral to me, maybe "illicit" wasn't the right choice of word.

> IQ correlates with family income. Why? Because people with more money get better nutrition, more training, better schools, stronger business networks. The advantages in life are, statistically, a major component of what leads to “ability” in the first place.

This is not true. In the US at least, the effect of shared environment on IQ is known to be very low by late adolescence. IQ correlates with family income because smarter parents have higher income and pass their genes down to their children. https://randomcriticalanalysis.com/2016/05/09/my-response-to...


Are you advocating standardized tests as a hiring process? Have you actually hired people this way? How many? How well does it work? Does it actually solve any of the problems the article at the top was talking about, or any of the comments up to this point?

Other than the writing tests, math and science standardized tests fail to predict college and especially graduate school performance very well, and it gets worse for predicting career performance. Standardized test scores absolutely correlate with SES, according to the testing agencies themselves.

https://www.act.org/content/dam/act/unsecured/documents/R160...

https://journals.sagepub.com/doi/full/10.3102/0013189X209021...

If you think Ivy League racial bias is immoral, why do you believe that “merit”, which is racially biased in the US isn’t immoral?

Graduates from Ivy League schools represent only a tiny percentage of people, and what you’re actually referring to is Harvard, not even the whole Ivy League, a lawsuit at one single school brought by people with a political agenda against Affirmative Action. This was your argument for dismissing credentials and claiming they’re a weak signal. Are you reconsidering this point of view? That seems like really thin evidence for the strength of signal that credentials do or do not provide. If you believe that standardized tests are a strong signal, and standardized tests are used for college admissions, then doesn’t it follow that gaining the degree credential is at least as strong a signal as the standardized tests you advocate?

I don’t know anything about the anonymous blog post you’ve linked to, but it’s not a scientific source, nor a meta-study, and it appears to be cherry picking and have an agenda. I certainly wouldn’t blindly adopt the “inferred” conclusions you read there, just because it all seems plausible or convincing to you. Claiming that money doesn’t affect IQ or merit or outcomes doesn’t even pass the smell test, there’s strong evidence that being poor hampers ability, even stronger if we’re talking about extreme poverty.

There are pretty well known, well documented problems with cultural bias, in the US and globally. Financial inheritance and pure financial advantage are real; money can and does overcome the disadvantages of low IQ. Being rich has immense advantages in every way. If you are convinced that social biases don’t affect merit and that being rich doesn’t influence merit dramatically, you’re certain that poor people must be poor due to IQ, and you aren’t at all curious about why some smart people believe “merit” might be a subtle way to perpetuate the ideas of Social Darwinism, then we should probably stop here.


I've worked for a Fortune 150 company for nearly 2 decades. In that time I've been involved in hiring tons of people. I've never cared about what school they went to or their political connections. That would literally be the last thing I, or anyone else I know, would care about. The thing is, I don't have any political connections and I didn't attend an ivy league school, so why would I care about anyone else having those types of things?


This statement is so wildly uncommon that it does not bear relevance.


What part is uncommon? Working for a Fortune 150 company? Being involved in the hiring of new people? Not having political connections (seriously, who has political connections below the c-level?)? Not attending an ivy league school?


> Technical interviews were once seen as a breath of fresh air.

> You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired.

I think it stops being seen as a breath of fresh air when e.g. Google's explicit expectation is that you will spend multiple months studying for the privilege before interviewing with them.


That's how long people study for the bar and board exams.

And that's after investing years and hundreds of thousands of dollars in extra schooling.

You also don't get to retake those every couple years.


There is a huge difference between a one time evaluation of an aspiring candidate to become a professional and a routine job interview for an established professional changing jobs in the same profession.


It would be pretty nice if as an industry we could figure out how to apply the DRY principle to interviewing. It's the biggest waste of time for both for candidates and interviewers that we need to establish whether a candidate with 20 years of experience can write a for loop every time they apply for any job.


In my uneducated opinion, Google's hazing interview is not to establish whether one can write a for loop or not but to establish how dedicated one is to working at Google. An anecdote: I interviewed at Google ~10 years ago and failed. They did not ask anything complicated (I don't know if it was because the polices were different or they actually needed someone with my expertise) but I had a complete brain freeze for some reason. Anyways, ever since then a Google recruiter reaches out every year or so. I always tell them to get lost because I already failed and they always respond that most of their employees pass on second or third time only.

Now, recruiters could have been lying about that but on the other hand, they obviously know that I applied before yet want me to apply again. I'd imagine a regular company would have done something about their recruitment process if they had that many false negatives. However, if I wanted to get dedicated employees, that would be exactly how I hired.


This is the real difference between the bar exam and a Google interview, in my eyes. The bar exam is intended to pass everyone who meets the standard: your score on the bar is supposed to be an accurate measurement of you. And conversely, if you know the material, you should pass the bar. California's bar exam is considered infamously difficult because the passing rate is "only" 45%.

None of that is true of the interview. There is no notional standard. Assessments of the same person vary wildly from sample to sample. If you know the material, you are nevertheless expected to fail.


This is very true. Unlike an examination there is neither a well defined set of questions nor even a well defined condition for succeeding! It's not good or bad as an interview should be an informal and subjective evaluation. But it does make comparison to an examination invalid just from the procedural point of view.


You can keep your Google job for 20+ years if you want.


> You also don't get to retake those every couple years.

What? Yes you do.

https://barprephero.com/learn/how-many-times-take-bar-exam/


But once you pass it and are admitted to the bar, you're set (assuming you renew your membership, don't change states, etc).


> you're set

If you mean set in terms of money, lawyer pay is strongly bimodal these days, with most lawyers earning the lower amount: https://www.lawcrossing.com/article/900049851/Is-Law-Still-a...


You're set in the sense that you don't have to take the exam again.


For those you get credentialed once and you're done. Not the same thing at all.


This was my same thought. Bar exam is an exam that leads to holding a professional license, I’m not seeing the comparison either other than “people are committed to the process”. Which...seems flimsy given (among other distinctions) the earning potential over the lifetime of a licensed attorney and the lifetime of someone who interviews for a Google job.


Most of those accreditations exist only as a barrier to join the guild and limiting the supply of people in an industry, driving up costs. They establish some baseline of competency but it's mostly just a way to keep people out of the field.


Perhaps, but it won’t be one or two binary pass/fail questions at random. Because that would be… ridiculous.


I hear this sentiment a lot about FAANG in particular.

Of course their bar to entry is very high, they are the one of highest paying employers in tech. If you want the pay and prestige, you have to play their game.

Where I would agree with you is when non-Google companies use Google tactics for hiring but pay like a mom and pop shop.


As an ex-Googler who did many interviews while there, I've never heard of that expectation.


Well, now you've heard of it.

I've heard of it, and I've heard that they just sort of take their good old time (and yours) with round after round after round of the process.


The interview process often moving way too slow is a well-known, long-standing problem. Expecting you to spend lots of time studying is another thing.

I've heard that people do it, though.


Interviewees are, as I mentioned above, explicitly informed of it. Interviewers may not be. Why would they be?


It’s part of the recruiter correspondence. They recommend books, practice sites, etc.


Google ≠ the industry.

If you're not a fresh graduate, likely you've had much of the preparation as part of your previous job experience.


You get to grind leetcode at your job?


No, but I get to write real code at my job.


They're not the same. I've never used Dijkstra pathfinding at my work, but I and yet, I seem to asked questions about it in interviews pretty consistently.


The goal isn’t to make sure you have memorized a graph algorithm. The goal is to identity people who can convert a scoped problem definition to code and to identify people who can convert a vague problem definition to a scoped one.

This can be beaten by brute force by memorizing a huge amount of material, but that isn’t the goal. It isn’t like the interviewers think you’ll need to implement their question in your day job.


Half the leetcode becomes obvious when you actually solve engineering problems as a part of the job.


That wasn't my experience at a FANG - the joke was that we spent most of our time moving protocol buffers around. Very rarely encountered anything as challenging algorithm wise as leetcode medium.

On the other hand working at FANG encourages developing soft skills (cross team wrangling etc) that no amount of leetcode would teach you.


That's why I don't work for FAANG any more.


What do you consider engineering problems? Many engineering problems aren't about algorithms but rather solving a real world problem.


Algorithms are just more tools to solve real world problems. Algorithm questions might be better if they were geared toward application rather than implementation.


This was a huge realization that I recently had. I didn't study CS in school, so the past couple months I've decided that I should learn the fundamentals in hopes of becoming a better developer. Learning about data structures and algorithms has definitely changed the way that I look at the world. It's nice to have knowledge of different types of problems and how to find solutions to them. Just a couple of hours ago I used a greedy algorithm to choose how to best structure my study time over the next week.


You usually don't need to re-implement an algorithm.

But very often you have to understand which algorithm to choose. Then you can pick an existing implementation.

In interviews I conduct I gladly allow to read the wikipedia page with a reference implementation (say, for the mentioned Dijkstra algorithm), or pick an implementation from a standard library of a language (say, for a priority queue). What I'm looking for is a conscious and reasonable choice of an approach, and understanding its trade-offs.


That's great! The interviews you conduct are atypical because allowing open book is most definitely not the norm for the format that forces candidates to Leetcode in order to practice.


Maybe due to the importance of soft skills ? or maybe a shift into the belief that they are important ?

How was it in the 80s or 90s ? could you be hired just because you can fix or implement something even if you don't fit that well with a group ?


80s: we need to hire somebody who can code

90s: we need to hire everybody who can code


I like white boarding for only one reason: so I can really ask questions that makes the interviewer uncomfortable. I don’t like jQuery. I don’t like your big stupid framework or your bullshit design patterns. I am a developer because I like writing code to solve real problems. I want to see, in the flesh, how scared and uncomfortable you are at seeing a candidate write original solutions to real problems. I want to see that arrogant look on your face when I violate your unmentioned code style rules. If that scares the shit out of you, as is so often the case, I know I don’t want to work there.

Unfortunately, I have also found that looks impressive during interviews only to not work out in practice once being hired. Not matter what, as a JavaScript developer, people are scared to death if you write original code.


> I want to see, in the flesh, how scared and uncomfortable you are at seeing a candidate write original solutions to real problems.

I've no doubt your code is the best in the world (have you a github repo?), but with that attitude you'd be shown the door quite soon.


Earlier the better. I am not there to waste your time.


Damn you’re edgy


That depends on the audience. Sometimes that sentiment, here on HN, is downvoted to oblivion and other times it gets 60 up votes. Yesterday a different comment that said almost the exact same thing got 37 up votes.

https://news.ycombinator.com/item?id=22821318

I suspect certain threads, by title, attract different population segments that differ on their programming interests, sensitivity, defensiveness, individuality, and so forth. Hiring threads normally have increased sensitivity, and I suspect the sensitivity is ramped up right now with many people being out of work.

As for my personal bias software hiring is horribly subjective. When I am interviewing the technical considerations of the interview are generally time consuming substance of no practical value in the consideration of candidate selection. Knowing that going in I prefer to watch the interviewer to gleam what decisions that forming and not disclosing.


We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together.

So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figured maybe some people might prefer that, but probably wouldn't be feasible for most.

Every candidate since has chosen that route, with very good outcomes - so far, everyone who did well in the trial period has been a good hire. Some of our best hires did not interview well (and would not have been hired under our old process), but were outstanding in the trial period. And, a couple candidates interviewed so well we almost skipped the trial period, but they struggled to complete even simple tasks during the trial.

We've now optimized interviews for that process, where the decision is primarily about whether it's worth moving to a trial period. That usually only takes a short screening call and a 1-hour call with the team (we're a remote team, even before quarantines).

BTW, if you'd like to experience this first-hand, we're hiring - https://news.ycombinator.com/item?id=22753515


I do think this is really the best way to "interview"... it's weird how hard it is to correctly evaluate somebody in two hours of talking to them and yet how easy it is to evaluate somebody in even two days of working with them.


I'm sure you get good outcomes from this, but I'd be willing to bet you are completely weeding out whole classes of people. For example, most parents or caregivers (single or otherwise) don't necessarily have the time for this. Senior engineers are less likely to want to go through this.

I would guess that most of your hires are single young people. And you are already kind of teaching them to work nights and weekends, which sounds like you are, again, choosing people who would not have a problem with a bad work life balance.

I also wouldn't be surprised if your process isn't teetering on the illegal side. Not on purpose, but it might be accidentally favoring or disfavoring a race/gender. Probably not enough to get you in trouble though, because those things are hard to spot. And unless your company is really big, probably nobody cares.


I think I'd like this even if I were married, as long as the trial period isn't too long and interview experience indicates that I should have a good chance of landing the job.

Contrast with the alternative: I'm a senior, considering switching jobs, but I have no real way to evaluate the potential new employer beyond word-of-mouth and interview experience. What if it turns out to be a place I don't like and I just gave up my former position for something worse?

Working a few evenings & weekends (and getting a little extra $$) to evaluate the new company sounds like a superb way to gain the confidence and jump ship without regrets. In best case, I get a new job I like. In best case, I get some extra money and keep my old job which is better than the new one proved to be. Win/win? What's the worst that could happen?


When we offer the trial option, this is the #1 reason most people are interested in it. They are just as concerned about evaluating us, as we are about evaluating them.


Not to say you’re wrong, but, as one data point, I’m a parent and would be very game for this. I’ve actually done things only slightly short of it. I’d rather go full bore working with the team than do these multi day projects in isolation or with just occasional contact with the hiring manager. Basically I find at a certain level (often reached by the time you have kids) all hiring processes tend to be time consuming.


IMO, it would be a ridiculous, unproductive perversion of justice/excessive impingement on freedom if this practice were illegal.


We don't require the trial period - it is offered as an option - we're not going to jeopardize a good candidate if they can't do a trial period.

Everyone we have offered the option has taken it, and they're usually pretty enthusiastic about it vs traditional interview process. We're working with them a lot during the trial period, and after if they get hired - lots of opportunity to find out how they're doing, and so far no negative feedback.

At the point where we move to the trial, we don't usually know age (because we haven't even seen the candidate) or family status. From what I've picked up, it's a mix of ages (usually a bit older - we've found some experience is necessary to be successful as remote-only), and mix of single, married, and families.

For those who have ended up hired - I think most are parents with younger families.

Other than the trial period, nobody usually works nights or weekends.


> I also wouldn't be surprised if your process isn't teetering on the illegal side. Not on purpose, but it might be accidentally favoring or disfavoring a race/gender.

Almost all processes do (though in this case, family status is probably the more relevant protected class it biases on.) That's not illegal, if it's sufficiently connected to the actual needs of the job, and they seem to have at least tried to evaluate that for their hiring process more than most places do, so they are probably less at risk of disparate impact discrimination than most hiring processes in tech.


Also, lots of companies have clauses against this in their employment contracts, or close enough, that candidates wouldn't risk it. Anti-moonlighting clauses and clauses about IP ownership, specifically.


This one is big and so often ignored. I am breaking my employment contract if I code for money or if I write code that will be used for anything. I have to get written approval for contributing to open source. Do you, as a potential employer, want to start our relationship with me violating employment contracts?


We wouldn't want someone to violate any obligation. When we offer the trial period option, we always have a discussion about whether that's something they're able to do, and comfortable doing - work-wise, family-wise, etc.


I suppose this could be done during the day? Taking a day off or two for pair programming is like taking time off for on-sites interviews.


That sounds way better than stressing people out with inane whiteboard questions. It wouldn't work for me since I won't take a gig that doesn't lock down cash flow for at least six months. I do love take home tests that are directly applicable to the stack I'll be working in. Following up with a code review style interview is great, too. This way more closely emulates the actual engineering workflow of pulling a ticket, cranking, then submitting a PR.


Since it is happening on weekends, and pretty much everywhere a new person needs on-boarding. Does that mean your existing team needs to be also available over the weekend so it can answer any question the new candidate might have?


> paid trial period

Wow, if you say so, but that seems weird to me: every job I've ever had (and everybody else I've ever seen hired at any job I've ever had) it's taken quite a while before I was really able to contribute much productively. Just getting acquainted with the codebase, figuring out the deploy process, and learning all the unwritten rules about the company culture takes a non-negligible amount of time.


Excellent candidates can and do find ways to deliver value in their first week and more in their second. Even if it’s demonstrating the ability to learn how the product it deployed and how the team work, that ability to learn quickly and communicate with the team is valuable.


As someone who's worked in over 20 companies as a technical consultant, I mostly agree. However, some companies are better than others at onboarding new engineers. My rule of thumb is to make a meaningful PR within the first week, and do whatever is necessary to make that happen. That sometimes involves bugging the crap out of people with questions, but I try to make up for it with a fast ramp and prodigious output.


Yes, we've had to tweak our on-boarding process for the trial period.

Most candidates have a local dev environment up and running in the first couple of days, and complete their first task (from our real backlog) in the first week. Within the 2-3 week trial period, most are able to finish several meaningful tasks.


Have you written down some kind of instructions for how you do it? What tasks to select, preparations for both sides etc.

Also, do you give them tasks on your actual code base? If yes, you are likely biased towards people already familiar with your tech stack (getting really productive with an unfamiliar tech stack takes more than a week, but short enough to make hiring somebody from a different background still worthwhile).

Any thoughts on this? (I realize that some amount of bias in the process is OK)


We actually treat the trial period very similar to a new employee starting, with a few tweaks.

We do a subset of on-boarding, just enough to get them running a local dev environment and able to push commits and connect with the team.

We pick real tasks from the backlog that don't require a lot of ramp-up to complete.

We assign someone to work with them during the trial period, help get their environment going and orient them to the tasks, help them if they get stuck.

Someone with experience with the technologies (Java, C#, Javascript, Linux) used in our stack can usually get up and running and complete a simpler task in the 1st week. Over 2-3 weeks, most people accomplish several tasks of increasing difficulty.

We discuss with the candidate how things are going each week, how they're feeling about things and how we think things are going. Usually by the 2nd week it becomes pretty clear if it's a good fit.

Since we are remote-only, candidates have to be capable of figuring things out mostly on their own - technically and organizationally, so we look for more experienced people - who probably are more likely to be successful with this kind of interview process.


> remote-only

Oh, that changes a lot. I think it would be a lot easier for people to log in a couple hours here and there as part of a trial than to commute to an office and spend an entire day.

I actually like this a lot, thank you for posting. Maybe the COVID-19 situation provides companies around the world with enough experience on remote work to make this kind of remote trial more attractive.


I've always learned new technologies and stacks as needed before I start the gig, so I can crank straight away.


This is very much the contract to hire route. I honestly think this is a mostly sane route, but it does leave the person to be hired in perhaps an awkward position. I have a family now, working nights and weekends is almost impossible.


This works against people who are on a visa. The visa rules prohibit income from multiple sources (except perhaps investment income).

IANAL, so some of my phrasing may be wrong.


I praise you!


> Developer hiring is broken

This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are claims without evidence, nor objective comparison to hiring for other industries. When looking for jobs, I’ve never been evaluated on IQ or code alone, it has always come with communication and personality and culture fit evaluations, among many other things. When hiring, my own team does everything this article claims isn’t being done. So I might be completely unaware of the major trends out there... how can I see those trends from where I sit? Are people not getting jobs who should, has there been high unemployment? Are companies not able to hire people? If hiring is broken, what are the problems it’s causing?

> It's a disguised IQ test

It is amusing to me that many blog posts and comments around here argue for exactly that under the same banner ‘hiring is broken’. Lots of developers are frustrated about being evaluated by how well they communicate and not by their code. Lots of people here complain about in-person interviews and tests and argue that take-home coding should be the norm, or that coding tests should not used at all.


These positions are entirely consistent, it's just a "pick your poison" situation.

Whiteboard interviews are a skill unto themselves, with only a glancing relationship to day-to-day job content, artificially high-pressure, overly performative, etc. You measure hours invested in Leetcode, not suitability for the work.

Take home projects probably collect good signals, but present a high and (crucially) asymmetric burden on the candidate. No one wants to burn a weekend or vacation days pouring effort into something that the employer can just glance at for 5 seconds and throw in the trash. Also, many candidates would prefer to reuse their time investment over arbitrarily many interviews instead of starting from scratch on each company's assessment.

Interviews focused on personality, culture fit, communication skills, and "gut feel" overemphasize the interviewer's personal beliefs. Likable candidates aren't especially likely to be good, and good candidates aren't especially likely to be the kind of people the interviewer wants to have a beer with.


>Likable candidates aren't especially likely to be good, and good candidates aren't especially likely to be the kind of people the interviewer wants to have a beer with.

See I would much rather invest time and money into somebody that I like being around and who I think is capable, rather than have some jackass who is really really good off the bat.

Of course there are biases, but that's true weather you hire for skills, personality, or both.

I think a lot of programmers think that your skill level is the only thing you should be judged on, but I think thats mostly because there are a lot of very unlikable people in this field and they'd rather hide behind their perceived skill level than attempt to be a semi likable person.

There is a sweet spot, somebody who has skill but is also not terrible to be around, and can learn quickly. The problem is that most interviews swing too far one way or the other to properly asses for both.


Yes, but likeability in an interview measures something only loosely related to likeability in the long run. Someone who is a little shy can make a great coworker/employee/friend/whatever, but you won't find that out watching them squirm in front of a whiteboard. An interview only directly measures the ability to win over strangers, and that might right for a sales position, but for most engineering positions it's a big extrapolation to guess how the candidate will perform in a team when comfortable.


Pretty good description of all the gripes people have.

Hiring software devs is a damned if you do, damned if you don’t proposition—somebody is always gonna bitch.


The only unambiguously wrong position is that the system works well and isn't worth improving.


I'm a software engineer working at a company in the hiring space. I've done over 400 technical interviews in the last year alone, and ... this is a hot take, and not the view of my employer, but I think developer hiring processes are fine (At least, at most mature companies.)

There's a problem at the moment in the market that there's a huge amount of pent up demand for senior developers. The market has responded with bootcamps and the like, and we have a ton of junior devs with very little knowledge and experience pouring into the workforce. The sad truth is that most devs fresh out of collage or a bootcamp aren't valuable enough to be worth hiring at large tech companies like Google. Most people who apply to any hiring role you advertise won't really be able to program effectively. (And if they can, they won't know the conventions of the language they use, they won't know anything about security, they won't be able to read code others write in order to debug it, etc etc.).

Programming is hard. It probably takes about a decade of practice to become good at it, and I don't think schools have figured out a replicable way to take someone off the street and teach them programming yet. (For example, most fresh grads have never had to read the code another programmer wrote. Imagine teaching people how to write without teaching them how to read!)

I think there's lots of angry junior folks out there saying "Hey, I can write a simple for() loop in python, and lots of people are hiring - but I apply to lots of jobs and keep getting knocked back! The hiring process must be broken!". And a few angry senior engineers out there saying "Why do I have to keep writing fizzbuzz? Its like I have to prove over and over again that I can program at all!".

Of course, nobody wants to admit that the reason they failed their 6th whiteboard interview in a row is because they aren't very good at system design. And the reason for that is that their collage didn't teach them any system design skills, and they have no experience, and they never learned how to use words to communicate technical ideas. And ArbitraryProductCo doesn't have the runway to train you up.

Of course there's the occasional person who is really skilled and somehow still manages to fail programming interviews all the time. But if the goal of a technical interview is "make sure we don't hire anyone who wouldn't be effective at the job", I think they're fit for purpose. I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.


> The sad truth is that most devs fresh out of collage or a bootcamp aren't valuable enough to be worth hiring at large tech companies like Google.

.. which is really unfortunate, because those big companies are the ones that have the most resources to hire, train, and mentor juniors. At the opposite end we have small companies that can literally go bankrupt when their hire doesn't work out and is unable to deliver working software. Even if the hire works out well enough, they're not learning as much as they could in a well resourced team with enough serious talent & seniors to mentor them.

> I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.

I don't know if it's useful to tell people that they aren't very good. It's a serious chicken & egg problem because everybody wants to hire seniors that can hit the road running and nobody wants to train the juniors. The juniors really don't need to be told that they aren't good enough, they need a place where they can get good!


> have the most resources to hire, train, and mentor juniors

In theory. I'm a pretty senior programmer now as in "been doing this professionally since the mid-90's" and as far as I can tell, modern project management principles are explicitly designed to make sure that I spend as much time as possible cranking out code and as little time as possible helping newcomers out. That may not be what the "scrum manifesto" says, but it's how the project management professionals charged with executing it interpret it.


Yeah? Being managed poorly doesn't mean they don't have the resources to do it differently. It just means they're not willing to expend those resources.

My point is, if we look at the other end of the spectrum, we have small companies that literally cannot afford to mentor juniors while paying them a salary (and tying up the seniors' productive time). Here it's not a question of how your company chooses to manage things, it's a question of whether they can afford to spend 20% of the budget on something that may turn out not to produce anything of value. Even if they're willing, it's a big gamble and can really put the company out of business in worst case.


> I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.

So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know?

The most maddening thing about interviews imo is the opacity. There's always uncertainty about where exactly things went wrong, and how it should be fixed next time. It's almost a meta-engineering problem of its own. And it's a metaphor for the lack of software engineering standards.


> So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know?

Programming education is broken. I did one year of computer science at one of the top universities in the world (switched into mathematics after that), and I'd see that course as useless if not actively negative. The only way of learning that I've seen really work for anyone (myself included) is more like a craft apprenticeship, working closely with someone more experienced. We shouldn't be surprised that that produces widely different approaches.

Frankly the field isn't mature enough to have standards. If you tried to set a professional exam based on today's best practices, in five or ten years the answers would mostly be wrong. We still don't know the right way to write software. Million-dollar systems still come with laughably simple bugs.

What does the interview process look like for a craftsperson? That's probably the best we can expect from a field as unsystematic as ours. The one thing that strikes me is that in creative fields it's normal for people to show a portfolio of past (client) projects, whereas in software past employers usually keep all copies of your code. I have no idea how we'd go about changing that norm though.


> What does the interview process look like for a craftsperson?

Welcome to my shop. Here's some wood. Make a chair!

In most of the interviews I conduct, I get the candidate to write follow a spec we've written and some code. And I get the candidate to debug a program with some failing unit tests. About half of the candidates I interview fresh out of school have no idea how to get started debugging a program they didn't write. You need to do that just about every day at work, and its usually not even mentioned at school.

But I've worked as a teacher too. I will move heaven and earth for my students, but in my darkest moments I think taboo thoughts. Maybe IQ is a real thing, and maybe some people just don't have the neural hardware to ever be good at programming. If thats true, we do those people a huge disservice. We steal years of their lives and tens to hundreds of thousands of dollars training them in a skill they can never master. I'd love to see the stats on how many people graduate from a CS program, try but never find reliable work in our industry. I worry the numbers might be damning.

A few months ago a candidate I interviewed asked for feedback at the end of the interview. He wanted to know I recommended that he practice so he could improve. I said he should pick an opensource project on github - preferably something thats not too big and look through the issue tracker. Pick a simple looking bug and try and fix the bug and submit a PR. His whole manner changed after I said that - the idea of doing that was so incredibly daunting to him. But that right there? More or less, thats the hiring bar. As an interviewer I'm trying to answer the question "If I hire you, can you do the work?". Read, think, understand, modify, write code, communicate it to your team. Thats the work and thats the bar.


We maintain a queue of beginner-friendly tasks, and someone familiar with the codebase sits down with the new hire to orient them to what's needed, why, and the relevant files/modules to make the change. Then they're available for questions and patient with a laborious code review. You do 3 or 4 of these before you're expected to be independently productive.

Approaching an open source project cold is a bit higher than the bar.


Both of your "taboo thoughts" seem blatantly obvious to me, and not especially taboo. Intelligence obviously exists and some people have more of it than others, even if the metric "IQ" doesn't perfectly capture it. And yeah, some people are not cut out to be programmers. Why are we pretending otherwise?


I find that there's a borderline self-contradictory aspect of hacker culture. While we romanticize the concept of the 10x programmer, which is an individual of genius, our culture also stresses the concept of autodidacticism. Teach yourself to code. Just use MOOCs. Build it yourself. Hack on an open source project. So there's this tension between valorizing the inborn superhuman and the belief that it's possible to reach greatness- though perhaps not 10x greatness- by pulling yourself up by your bootstraps.

In a way, this is mirrored by the organizations themselves. Startups who make the right moves, and work hard through grit and 60-hour weeks, can become unicorns. Also some startups are led by visionary founders and cannot fail.

So all of this, buttressed by real world labor demands, create incentives for people to try to become programmers. Even those who aren't "cut out to be programmers." Our increasingly cutthroat and unequal society also incentivizes people shifting to programming as a safe career choice. "Learn to code."

I don't know how we can stop "pretending otherwise." Tech companies continue to complain about the engineering talent shortage. Bootcamps and online courses continue to promise people that they can become that talent. There aren't any agreed-upon industry standards by which to exclude people who truly aren't fit for it. FAAMG has infinite money and power in the industry to continue their entrenched practices. Most startups cargo cult the leading megacorps' processes. So instead, candidates are encouraged to continue grinding Leetcode and apply, apply again.


> I find that there's a borderline self-contradictory aspect of hacker culture. While we romanticize the concept of the 10x programmer, which is an individual of genius, our culture also stresses the concept of autodidacticism. Teach yourself to code. Just use MOOCs. Build it yourself. Hack on an open source project. So there's this tension between valorizing the inborn superhuman and the belief that it's possible to reach greatness- though perhaps not 10x greatness- by pulling yourself up by your bootstraps.

Those seem like orthogonal aspects. If we stressed the idea that you had to do (say) a 4-year degree at a great university, or something akin to the bar exam, would that be any more compatible with the idea that some people are 10x better than others? If anything I'd say the opposite: we'd expect most of the Harvard graduating class to be on roughly the same level, it seems a lot less wild that some self-taught people could be 10x better than others.

> So all of this, buttressed by real world labor demands, create incentives for people to try to become programmers. Even those who aren't "cut out to be programmers." Our increasingly cutthroat and unequal society also incentivizes people shifting to programming as a safe career choice. "Learn to code."

This happens in every field though? You get people who are desperate to become a doctor and apply to med school year after year, despite being completely unsuited to it. You get people who insist they're gonna make it as an actor/musician/comedian and spend decades working crappy day jobs so they can live where the action is, when really they'd be better advised to pick a career they're good at.

> I don't know how we can stop "pretending otherwise." Tech companies continue to complain about the engineering talent shortage. Bootcamps and online courses continue to promise people that they can become that talent. There aren't any agreed-upon industry standards by which to exclude people who truly aren't fit for it. FAAMG has infinite money and power in the industry to continue their entrenched practices. Most startups cargo cult the leading megacorps' processes. So instead, candidates are encouraged to continue grinding Leetcode and apply, apply again.

Well, if we told people outright that programming is a matter of IQ, and gave an actual IQ test rather than an IQ-like test in interviews, that might help some people realise it's not for them. You're right that what catches on in the industry is largely a function of what the most successful companies pick, but ultimately that list of top companies is not static and we'd hope that companies with better hiring practices will (eventually) rise to the top.


> If anything I'd say the opposite: we'd expect most of the Harvard graduating class to be on roughly the same level, it seems a lot less wild that some self-taught people could be 10x better than others.

That's not the point I was trying to make- I'm saying that in programming we both prize talent born of nature, and skill honed by nurture. (Though admittedly that may exist in many other disciplines.) Because of the latter emphasis on grit, hacker culture encourages self-improvement and going beyond the capacities one started with. That dogma of self-improvement goes against the notion that people are not cut out to be programmers.

Though of course, this could also be a marketing ploy for recruitment on behalf of management: "Anyone can code, you should learn to. But we only hire from the best." By encouraging an increase in talent, they have a larger labor pool to choose from (and potentially undercut wages), while plucking out the few that can pass their interviews.

> This happens in every field though?

To some degree, but the details vary. Medicine or law used to be seen as safe secure careers into the (upper) middle class, but doctors are limited through the AMA, and currently law is a notoriously difficult and costly profession with dwindling prospects. Entertainment and the arts is universally known as a risky proposition. We're talking about software, which has had the reputation of being the current surefire path to a stable, even successful, career, for at least the past two or three decades.

> Well, if we told people outright that programming is a matter of IQ, and gave an actual IQ test rather than an IQ-like test in interviews, that might help some people realise it's not for them.

Leaving aside the legality of using IQ tests to exclude candidates, that opens up the questions of if there is a direct correlation between programming good software and IQ, why programming out of all STEM fields should focus so heavily on IQ, and why all of those other technical and engineering professions don't need to resort to IQ tests for hiring.


> Read, think, understand, modify, write code, communicate it to your team. Thats the work and thats the bar.

So do your students do this? Why not?


Computer science isn't supposed to teach you how to program, and it's kind of silly to judge a whole subject by the first year. In fact I think you would be making a mistake to focus on the practical courses rather than take as many theoretical and foundational (e.g. advanced algorithms, Theory of Computation, Compilers) courses as you can. A good CS student, who understands the coursework and doesn't cheat, should easily become a good enough programmer just from completing coursework in a mostly theoretical program to get hired basically anywhere. Programming is something you learn incidentally because it's intertwined with what you're doing anyway; and to be blunt, most practical programming is rather mundane and simple compared to a rigorous CS curriculum.

I see it as like if I were hiring for something as generic as "writer". It's easy to have a generic "writer" produce a small sample for you on the spot, similar to a CS interview. Of course you can always practice writing directly itself, but I would imagine someone who had completed a lot of coursework in linguistics, classics, literature, etc. would on average be very well-prepared if they were a good student. But you could still practice and teach yourself on your own if you wanted to


> Computer science isn't supposed to teach you how to program

Perhaps, but it's still the closest thing the industry has to a "programming education"; I think it's the first thing employers look for, rightly or wrongly.

> it's kind of silly to judge a whole subject by the first year

How many of my limited days on the planet am I supposed to sink into something before I'm permitted to pass judgement? At some point Stockholm Syndrome would take over.

> A good CS student, who understands the coursework and doesn't cheat, should easily become a good enough programmer just from completing coursework in a mostly theoretical program to get hired basically anywhere. Programming is something you learn incidentally because it's intertwined with what you're doing anyway;

That's not what I saw happening (unless you count the official lectures/colloquia as "cheating"; certainly I saw cases where the meat of the answer to a supervision question was spoon-fed to us directly). The people who could program at the end of first year were the people who could program at the beginning or who "got it" immediately. I never saw people struggling with a new concept but then gradually being taught it (which is something I did see happen a lot in the mathematics course), and a frightening proportion of the students I was friendly with were coming out of that first year knowing seemingly nothing, certainly not being able to program or talk coherently about algorithms or computability. I suppose it's conceivable that those students were somehow getting something out of the system design type courses, but it seems implausible.

I understand there was a shake-up in that CS department a few years after I graduated, so maybe I went through it during a bad time. But the students who graduated there in the meantime aren't going to get a do-over.

> I see it as like if I were hiring for something as generic as "writer". It's easy to have a generic "writer" produce a small sample for you on the spot, similar to a CS interview. Of course you can always practice writing directly itself, but I would imagine someone who had completed a lot of coursework in linguistics, classics, literature, etc. would on average be very well-prepared if they were a good student. But you could still practice and teach yourself on your own if you wanted to

I'd suspect the overwhelmingly important part of writing is actually writing; I only know one person who I'd call a great writer, and hanging out with him the thing you notice is that he writes the way other people check their phone. All the things you list can enhance writing, certainly, but if you don't actually write then any amount of knowledge of linguistics or classical literature is meaningless (at least in terms of how it affects your writing ability).


>How many of my limited days on the planet am I supposed to sink into something before I'm permitted to pass judgement?

More than the first quarter of it. I took at least a year of math classes, and I don't feel qualified to pass judgement on the math department.

There's a huge difference between intro and upper level classes. Just like there's a difference between Calc I and proof heavy upper level math class.

That being said I think the overall pedagogy is better in the math department, but then again they've been doing this for a lot longer.


What's that saying, takes about 10,000 hours of study, practice and application to master anything, regardless of what it is.


> am I supposed to sink into something before I'm permitted to pass judgement

I don't have a medical degree, but I still trust medical science. Why? Because it achieves positive results, and people I trust for other reasons trust them.


Ok, but is that true of CS teaching? The best programmers I've worked with have mostly not had CS degrees (tended to have degrees in maths, physics, or that sort of area).


>The best programmers I've worked with have mostly not had CS degrees (tended to have degrees in maths, physics, or that sort of area).

There's no you were rigorous enough in tracking this for this statement to be useful to anyone. The people who don't fit the mold stand out.


> There's no you were rigorous enough in tracking this for this statement to be useful to anyone.

Sure, but has anyone claiming the opposite done rigorous analysis? Is there any evidence that having a CS degree makes for better programmers than not?

> The people who don't fit the mold stand out.

I'm not thinking about people who stood out as particularly unusual. Most of the time I didn't find out which field someone's degree was in until months into working with them.


>Sure, but has anyone claiming the opposite done rigorous analysis? Is there any evidence that having a CS degree makes for better programmers than not?

I'm not making that claim, you're the one making a claim that people with degrees other than CS are better programmers without evidence.

I'll only make the claim that a CS degree made me a better programmer. Specifically the upper level theoretical classes. I can verify that there are many problems I've solved because I realized that the problem I was working on had already been solved 50 years ago.

I also worked about a decade as a professional programmer without a CS degree, before I went back. Personally I am a better programmer.

Would I have been an even better programmer had I taken another few semesters of math classes instead of CS classes? Who knows? Absent any other evidence though, the simplest explanation is that domain specific knowledge is likely useful.

>I'm not thinking about people who stood out as particularly unusual. Most of the time I didn't find out which field someone's degree was in until months into working with them.

The point is that the more unusual someone's background is, the more likely you are to remember it. Particularly if there is some confirmation bias involved.


> Absent any other evidence though, the simplest explanation is that domain specific knowledge is likely useful.

Disagree; surely the null hypothesis for any given training programme is that it has no effect.

> The point is that the more unusual someone's background is, the more likely you are to remember it. Particularly if there is some confirmation bias involved.

There isn't anything unusual about professional programmers having a degree in maths or physics rather than CS. At least in my experience it was pretty close to an equal split.


>Disagree; surely the null hypothesis for any given training programme is that it has no effect.

That's not what's under test here though. It's training program A that includes domain specific knowledge or training program B that does not.

>There isn't anything unusual about professional programmers having a degree in maths or physics rather than CS. At least in my experience it was pretty close to an equal split.

Look at the number of graduates, the only way that is true is if almost every single physics or math graduate goes into programming. The fact that you think it's true is just further evidence of bias.

According to the Stack Overflow Developer Survey [1], about 8% of professional developers with degrees majored in math, or natural sciences vs. 63% in CS, software engineering, or computer engineering. There could be some sampling bias, but that's a huge difference.

1. https://insights.stackoverflow.com/survey/2019#education


I'm not talking about a maths or physics degree specifically. I'm talking about having a CS degree or not. The stack overflow survey seems to have shifted towards CS recently; the 2015 results (earliest I could find) imply 52% of professional developers had CS degrees at that point, which was about halfway through my career so far, so 50:50 for people I've worked with sounds about right.

I suspect SO surveys are heavily biased towards younger developers, but even taking those 2019 numbers at face value: about 20% of professional developers have no degree, and of those with degrees it's about 75% CS/information systems/sysadmin/webdev, 17% maths/physics/engineering, and 8% other. So a typical 15-developer team would be 9 with CS degrees, 3 with no degree, 1 with an engineering degree, 1 with maths/science and 1 other. The non-CS folk are not exactly rare unicorns.


>I'm not talking about a maths or physics degree specifically. I'm talking about having a CS degree or not.

Well then why did you say this:

>There isn't anything unusual about professional programmers having a degree in maths or physics rather than CS. At least in my experience it was pretty close to an equal split.

You said explicitly math and physics degrees vs CS degrees. And you previously said the best programmers tended to have math, or physics degrees or something similar.

This isn't me being pedantic, it was the entire context of the discussion.

The point is that you are prone to confirmation bias as evidenced by your belief that it's close to an equal split. Your mental model is overrepresenting people with physics and math degrees likely because it confirms your belief that they are better programmers.

>So a typical 15-developer team would be 9 with CS degrees, 3 with no degree, 1 with an engineering degree, 1 with maths/science and 1 other. The non-CS folk are not exactly rare unicorns.

That's not the point, it's that you are more likely to remember the background of the 1 person on a team who has a Math degree because she is relatively rare compared to all of the people with CS degrees. This is a well known and well documented phenomenon. And it's one of the primary reasons that anecdotal evidence, even a large amount of anecdotal evidence is so often wrong.


> You said explicitly math and physics degrees vs CS degrees.

I was giving those as examples of degrees that are normal and don't stand out. We don't think there's anything particularly odd about a programmer with a maths or physics degree. That's all I was saying.

> you previously said the best programmers tended to have math, or physics degrees or something similar.

A category which would include engineering, at which point we're at 20-25% of professional programmers with degrees by your numbers (which I still think are significantly biased).

> The point is that you are prone to confirmation bias as evidenced by your belief that it's close to an equal split. Your mental model is overrepresenting people with physics and math degrees likely because it confirms your belief that they are better programmers.

My mental model is that it's an equal split between CS degrees and not, and per your own sources that's accurate. You're fixating on a couple of specific examples of non-CS degrees that I mentioned when that's completely beside the point.


I'm not fixating on anything. This entire chain started as a reply to a post you made where you switched to math over CS, and specifically to this statement.

>The best programmers I've worked with have mostly not had CS degrees (tended to have degrees in maths, physics, or that sort of area).

That's the entire context of the discussion. The assertion that CS majors have worse outcomes (with respect to programming ability) than math, physics or similar majors.

>A category which would include engineering, at which point we're at 20-25% of professional programmers with degrees by your numbers (which I still think are significantly biased).

If you are including math, all natural sciences, and all other engineering degrees you get 17%, not 20-25%.

>My mental model is that it's an equal split between CS degrees and not, and per your own sources that's accurate. You're fixating on a couple of specific examples of non-CS degrees that I mentioned when that's completely beside the point.

There is no other logical way to parse this statement

>There isn't anything unusual about professional programmers having a degree in maths or physics rather than CS. At least in my experience it was pretty close to an equal split.

than that you were talking specifically about math and physics.

I get it, you don't like that there are numbers that contradict you, so you are grasping at straws trying to find alternate interpretations to reconcile your statement with the numbers. You obviously don't like being wrong. I don't either, that's fine, but no one other than us is reading this far down. There's not point denying you farted when there's only 2 of you in an elevator.


"The best programmers I know didn't have a degree in CS" has become a pretty tired cliche at this point...


As someone who dropped out of the process 1/4 of the way through you're not really in a good position to comment on the effectiveness of completing it.


1/3, and I dropped out of it because it wasn't teaching me (or any of the other people I met there, including those who didn't have my prior experience) anything - I got a first in the first-year exams if that's the kind of thing you care about. Absolute best case is that that degree has two years of useful content, and I rather doubt it.


When I was in university doing a CS degree, if you had dropped out 1/3rd of the way through, you'd have pretty much only gone through a handful of weeder intro CS courses that were more math than programming. So yes, if you had dropped out at that point, you would not have really gained any useful programming skills.

I don't entirely disagree with you, there were certainly some later classes that were similarly not useful in the long run, but it wasn't a total crapshoot. My senior year included a year-long group project on a team of ~10 people that basically took us all the way through the lifecycle of a project -- from inception, to design and architecture, to polish and QA, to 'releasing' it. It was a very useful course that placed you into a startup-like atmosphere.

But I think this kind of confirms that apprenticeships may be far more useful to the programming field than college degrees. If my CS program did not include that senior course, I would probably pretty vehemently agree with you. And anecdotally, at my current workplace, one of our best programmers is a kid we hired basically right out of high school who has since grown in skill considerably thanks to the attention of more senior engineers.


> So does this mean that programming education is broken?

Of course it is broken, it rarely mention naming, debugging, and never emphasize reading code. The real fundamentals are not there and you learn them on the job.


I disagree. Programming education exposes you to the stuff that you would probably never discover on your own like complexity theory and circuit design: the practical stuff like debugging and SQL are things that are best learned by practice anyway.


Isn't it the companies' role to turn those junior developers into senior developers? Where else are they going to come from?


I don't know! Is it their job?

The attention of senior engineers is the single most valuable, expensive and scarce commodity of a modern software company. The incentives are absolutely not aligned for most companies to make it worth their time to hire junior engineers.

But obviously thats a problem - because as you say, where else will senior engineers come from? And I don't think we have a good answer here. The old school answer was apprenticeship - a company trains you up, and in exchange you work for them for a time. But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

For my money this, right here, is the real problem with modern programming / career development. Whiteboard interviews are the least of our problems.


But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

This is only true in bad companies. Good companies understand that people move on, and don't assume that someone is hired in to a role forever. Once you realise that hiring is an expensive process that you will always be doing you then you can optimize it appropriately.

Some really good companies even use it as a point in job adverts. There are plenty of senior developers who actively want to teach and mentor juniors, and will be happier working in companies that encourage that process. It's a good way of retaining those staff.


> Good companies understand that people move on, and don't assume that someone is hired in to a role forever. Once you realise that hiring is an expensive process that you will always be doing you then you can optimize it appropriately.

Yes, they understand this, so they simply do not hire people who need to be trained for a year or two to be effective hires.


After the Y2K-bust, where are these good companies?


> The old school answer was apprenticeship - a company trains you up, and in exchange you work for them for a time. But most companies are loathe to do that because you're likely to quit and go somewhere else for a pay bump as soon as you have enough skills and experience that you're worth hiring.

One problem is that companies with the means to fund this- FAANG and the like- are also the ones are incentivized to gatekeep the most to maintain their elite status and engineering superiority that leads to business edge. Startups, being naturally less risk adverse, are less likely to engage in formalized apprenticeship programs for juniors.

What happens instead is that you get the half-hearted approach of hiring college students to be interns or co-ops. Not all students are able to intern. The ones who do have a leg up once they graduate. Hence the stellar reputation of U of Waterloo grads.


There is the part where you give junior pay raise after he or she learns enough to get raise elsewhere.


If you're going to end up paying what it would cost you to hire the trained person anyway to avoid having your staff leave for higher wages, that heavily reduces your incentive to put a lot of resources in to training. Training + market rate compensation is more expensive than just market rate compensation.


But is training + market rate more expensive than hiring + market rate ?

Also, it seems to ignore the fact that training people is actually an incredibly useful thing to do to hone your skills as a senior dev, and that having to teach forces you to cristallize, simplify and explain thoughts and processes that you possibly never challenged before.

Tbh, I think I'm more productive and learning more when I have a decent intern to coach in my team than otherwise. So it's really a win-win situation.


While this is true, it seems to me that most companies don't actually have both choices. Instead it's "training + market rate compensation" or "you will forever struggle to have enough senior devs to accomplish your goals". If you can't attract talent, you have to grow it and pay to retain it. Simple as that, no?


Even if your junior-turned-okish developer goes away, if you did a good job and part on good terms you now have a working advertisement in another company. And maybe a couple years down the line they'll come back.

Investing in your workforce for the long term: when you're big enough I think you should do it. Having a "reserve" is also useful. You don't have devs doing nothing: you have devs learning, teaching and ready in case a business opportunity appears.


I think you also have to account for the cost of acquiring senior staff. If you train them and pay them, your pipeline becomes more predictable than plucking them ad-hoc from other companies. That makes planning (your roadmap) more predictable.


Market rate for junior + training while he/she is junior is not more expensive.


A lot of companies struggle to match internal comp changes with what they'd actually offer on day one, for some reason.

But there are bigger problems. I've experimented with training people in various ways over the years.

Reality is programmers move around a lot. They are attracted by interesting new problems where they feel they're learning. Staying at one firm for 20 years isn't likely these days. There's nothing wrong with that, but it means if you spend a few years training someone then after that time period they may leave anyway, even if their comp is reset to be competitive, because the new place can offer them equal comp + new problems.

Another issue is that a lot of training junior-to-senior is about imparting experience, wisdom, beliefs etc. At some point they can code and it's about the decisions being made, rather than inability to do them. A characteristic of junior devs that are growing their skills is they tend to latch on to trends harder and quicker than senior people who have maybe seen it before, and can differentiate their CV without buzzwords. If a junior comes to work one day and says "We need to Kubernetize all our things" and you say "Actually, our server count is stable and low, we don't need to use Kubernetes, but we do need this new customer-facing feature implemented" then it's quite possible they'll get frustrated, want to argue with you. Of course replace Kubernetes with Haskell, Linux distro of the day, Rust, Go, whatever seems hip and new.

It can just end up being draining for everyone. Of course debating these issues can be teaching of a form, but often juniors don't see it that way. The student wants to become the master faster than sometimes makes sense.


> if you spend a few years training someone then after that time period they may leave anyway

If it takes years of training till the person is useful and worth it, then there is something wrong with the way training is organized. We give juniors easier tasks then to seniors and train them, but we also expect them to be useful from the start basically.

It really should not take years till they make enough work for for salary + training.

> If a junior comes to work one day and says "We need to Kubernetize all our things" and you say "Actually, our server count is stable and low, we don't need to use Kubernetes, but we do need this new customer-facing feature implemented" then it's quite possible they'll get frustrated, want to argue with you. Of course replace Kubernetes with Haskell, Linux distro of the day, Rust, Go, whatever seems hip and new.

There is no difference between senior wanting to change things. This sort of conflict is normal and final decision is not done by junior.

Most people actually can handle not being given their way all the time. If they have no zone for own autonomy or decisions then they will get frustrated. But that zone should be smaller then the massive architectural decision.

Moreover, portion of people pushing toward new technology and being willing to experiment is something that company should have to keep healthy. Otherwise you all will stagnate.


A lot of it is about opportunity cost. Do you take someone fresh out of school or someone who's been around the block a few times if the latter costs only 50% more? The cost of even a junior but basically able programmer can be quite high if their work has to be redone (heck the cost of a non-junior but bad programmer can be high), so you end up needing to assign tasks that aren't that important or for which large slips can be tolerated. It can be tough to find a supply of such tasks sufficient to keep people fully throttled.

There is no difference between senior wanting to change things

Seniors are more likely to have been through several jobs and environments, and learned that tooling choices aren't that big a deal at the end of the day. They've also already (hopefully) got some accomplishments under their belt and don't need to redo other people's work to have something to show - they're more likely to do higher risk strategies like trying new things as a consequence.


They can make that decision if they want, or they can wait a bit to hire a more experienced dev for money money. I wouldn't say it's their "role" - nobody's forcing them to do so, and if it doesn't help them, I don't see why they would feel obligated to do it


I feel like this is a bit of a self-reinforcing cycle:

“Why would we train them up, they’ll just leave anyway” -> “screw this place, I am going to leave when I get the chance” -> leaves -> go to step 1


Two things that have never happened in more than 200 interviews:

1) Anyone with >0 years of experience outperforms a Waterloo internship candidate on the coding or algorithms round.

2) Anyone interviewing for a senior position performs well on the other rounds and fails only system design.

I'm pretty sure it's large companies that can afford to play long-term big-picture strategies with talent, and small ones that have such low-rent concerns as which languages and frameworks you know.


> huge amount of pent up demand for senior developers

But is leetcode really the way to find them?


Isn't Google known for analyzing the hell out of their candidates for predictors of success? They dropped the GPA requirement, college degree requirement, brain teaser questions - but they kept the leetcode questions. It's probably least bad of everything else they've looked at.


Google talks a lot of shit about rather missing out on a good candidate than hiring a bad one.

What removing a metric tells you is that people that they regretted hiring people who looked fine on those metrics. They have no way to determine if people who failed on other metrics were better than the people they hired.

The problem is that if you measure someone by a metric you can’t actually disregard it in your decision process. Even a double blind affects the subject’s behavior.


> And a few angry senior engineers out there saying "Why do I have to keep writing fizzbuzz? Its like I have to prove over and over again that I can program at all!".

You didn't address this part of the problem. This friction is one of the reasons the job market is so distorted.


Oh sorry I wasn't clear. The reason is that successfully completing a simple programming exercise puts you in the top 15% or so of resumes that get sent in for most programming roles.

When you apply for a company, they have to assume you aren't very good, because most people who apply aren't very good. (Because people with strong skills get snapped up, and people with weak skills spam their resume everywhere they can.). Figuring out who's worth spending time interviewing is a hard problem in itself. And there's no silver bullet here - people lie about their work experience all the time. There are so many user accounts on github with copies or forks of random people's code, with basically no changes. I suspect they exist support lies on resumes.

I don't think it distorts the market, but it is annoying. A recruiter I talked to a few years ago said she thinks its crazy we don't use an agency model for programmers like actors do. The idea there is that good programmers pay a small percentage of their salary to a manager, who's job is to find you the best roles that suit your skills and negotiate pay on your behalf and so on. She tried to set up a business doing just that but she couldn't get enough clients to make it work. Good programmers balked at the idea of paying a few % of our salary to someone in an ongoing way, to look after our career. Having to prove your skills in each and every interview, and form those social connections on your own? Thats a choice we make.


> (Because people with strong skills get snapped up, and people with weak skills spam their resume everywhere they can.)

It's extremely saddening how prevalent this prejudice is.

But what if I am still looking for work and companies literally don't reply to my applying to them? I might be the next John Carmack but if nobody gives me a chance (for reasons outside of my control and unrelated to my proficiency) then according to you I suck. :(

It's very broken to assume that skilled people get snapped up immediately so whoever is available must be mediocre (or bad).

It is an awfully imprecise assumption!


> It's extremely saddening how prevalent this prejudice is.

Prejudice?

Look, companies wouldn't be advertising for roles if they didn't think qualified candidates (like you?) are out there. But its a numbers game; of course there are more unqualified people looking for work than qualified people at any given moment. Qualified people don't get snapped up immediately; but they aren't usually actively looking for work for long. And they often are picky about which places they apply to - for good reason. A highly qualified candidate might apply for 3 roles, get 2 offers and accept 1 of them. A weak candidate might apply for 50 roles. If those are the only two people sending out resumes - (or in general the pool has 50% strong candidates and 50% weak candidates), still only 6% of resumes will come from strong candidates.

Thats not none. And I really hear you about how frustrating it must be for companies to not even bother to reply - I mean, thats pretty rude. But ... what behaviour do you expect? What would you do with a pile of 100 resumes if you expected only 6 of them will be strong candidates? Should they bring all 100 people in for interviews, just in case there's a young John Carmack amongst them who has terrible resume writing skills? (I've interviewed 2 people who fit that description out of the 400 or so I interviewed in the last year. They definitely exist. But finding those people is prohibitively expensive for most companies.)

Flawed? Yes. Biased? A little. Prejudiced? That seems like a stretch. Can you think of a better system? That conversation seems more interesting than just complaining about it.


What I extract from your reply is what I am actively trying to teach myself: DON'T. TAKE. ANYTHING. PERSONALLY.

Yeah?

BTW I am not exactly young -- 40 y/o with 18 years of professional experience (not claiming anything about quality). I was just objecting to your general premise that if somebody isn't snatched immediately then they must be mediocre because I've witnessed programmers times better than me (whose sole efforts turned entire companies around) slag around jobless for 6 months and not being able to move beyond 2nd interview even if EVERYBODY told them they like their expertise and demeanour and that they are a good cultural fit.

But you are very likely correct that it's a numbers game and that various circumstances prevent companies to actually actively look for the gems.

So again, I do my best not to take anything personally.


> you are very likely correct that it's a numbers game

On the surface it's numbers game. But 2/3rds of getting hired is a confidence game.

https://en.wikipedia.org/wiki/Confidence_trick

See also

https://en.wikipedia.org/wiki/Affinity_fraud

Some programmers are really good at what they do but they just suck at playing the game. Or more likely they suck at it worse than the average hiring manager.


Interesting reads, thank you.

As for confidence, I should learn to fake it already I guess. I am a realistic down to earth guy who doesn't deny when he doesn't know something -- nobody can know everything. But that's likely not the point; more likely it's about projecting an image of "nothing can give me a true pause"?


It's not like fake it, think of it being more like an actor playing the roll.

It's a skill some people are naturals and some aren't everyone though can get better at it.


Imagine a scale from 1 to 10.

A 10 means "The interview process is fine. It judges people fairly and objectively, and works well for both candidates and companies".

A 1 on the scale means "The whole interview process does a disservice to almost everyone it touches, and reflects badly on our industry as a whole"

Where do you think we are?

Personally I think we're at about a 7. Which is to say, I agree with you. I've interviewed people like that and it breaks my heart every time to hear their stories. But I think there's a silent majority for whom the interview process works as intended.

- About 0.5% of people I've interviewed had amazing skills but were unable to explain those skills on a resume, and wouldn't be able to get their foot in the door at most companies they applied to

- At a guess there's probably another ~3% or so of candidates who just for one reason or another don't come across well. They don't look or sound like they know what they're talking about, or something else is going on for them. But they actually have great technical skills when you get down to it. I suspect those people struggle to find work in most normal hiring processes.

- (I have other criticisms too - like how we don't give people feedback after interviews)

But thats ... I mean, it matters, but I think the cohort of "unappreciated gems in the rough" has to be in the small single digit percentages. There's a lot of blog posts complaining about hiring in general that hit the front page of HN, but I don't think they're fair representation of the state of software engineering hiring across the board. Great people getting looked over are the exception. The awful truth is that most people, most of time are judged fairly in job interviews based on their skills. Its just that programming is really hard and almost everyone in the world is terrible at it. Its so hard to learn that you can go into massive debt and spend years studying it in school, and still be mostly unemployable out the other end. In fact I suspect most people fresh out of school struggle to find work, because they just aren't very good yet.

So no wonder these posts get upvoted on HN. People have a really good reason to feel angry and let down by the system. The story that you're a gem and you're being passed over by the soulless corporations is a much easier pill to swallow than the idea that you're being looked over because you aren't very good at programming. And your degree means nothing, and from here it'll take you years to get good at programming, if you ever manage it. And nobody wants to take the time to teach you on the job. And nobody thought to tell you any of this while you were in school.

I don't know who's fault it is - if anyone's. Companies are doing whats in their best interest. Schools are doing their best to teach CS to everyone who wants to learn it. People think going to school to learn programming means they can find useful work out the other end. I'd like to think that most do, eventually. But there's a chasm in the middle that nobody talks about. A chasm between knowledge and programming jobs. Many people never find their way out of that gap. We don't even tell people its there.


Where is the evidence for any of this? Like, truly, I hear this line about how there is approximately nobody who is competent, and I honestly think it is BS. What evidence is the claim based on? Is it that you've seen how well people do in interviews and noticed that only a small number of them perform well? How would you falsify the hypothesis that those people are fully capable of being excellent employees and are just not good at playing this particular interview game?

I think people with your mindset have just repeated this over and over again to the point that we all take it as axiomatic. It also strokes our ego ("I can do something that basically nobody can even learn how to do!") so it's easy to maintain the farce.

This is the second time in this thread that I've seen the claim that the anger is driven by people who feel let down by the system. That's not me, the system has worked really well for me. But I still think it is a hall of mirrors that could be serious improvement. Not a 7, more like a 3 or 4, and held back by both people who think it works really well and people who think it's a bad solution but that there isn't really a better one (which I'm more sympathetic to).


FWIW, I appreciate you sharing this perspective. I concur, more or less, with your position here after having interviewed many hundreds of people over my career. I've found internships were the best way to identify who was quality out of a class. It seemed of every 100 new grads I interacted with maybe 3 or 4 were skilled and engaged in learning more. But there are also some standouts and I really wish more companies did internships with larger cohorts and allowed their senior folks time to mentor. Some of my best experiences in my career were mentoring interns and I made some solid life-long relationships that way as well.

I've often posited among friends in the industry that it's partly due to apathy and mismatched expectations. College students go into CS because they expect a good paying job, not because of any specific aptitude or interest. CS isn't the study of software engineering, nor of the act of programming. They graduate, with no appreciable skill, and no real desire to learn, and can't find work. We can argue about fairness until we're blue in the face, but the reality of the situation is that motivated students who are actually interested in learning have vast free resources available to them to learn and free resources available to them to demonstrate their competence. Anyone not taking advantage of these resources is going to be subpar compared to others in the labor market.

Pretty much anyone who went to college in the last 20 years should have been able to anecdotally identify the stand-outs in their classes, and in general on the other side of the pipeline those are the only folks having an easy time getting hired. I dropped out of college, even though I was one of the stand-outs, because I wasn't learning anything I hadn't already taught myself. I've had less difficulty in my career than some of my former classmates I keep up with and my salary is multiples of theirs when they are employed, we're all the same age and they're technically more credentialed. It comes down to the fact that most people are just not very good at programming or at systems design. In fact, I'm not a good programmer, my skill-set is very much in the arena of systems design.


> I've often posited among friends in the industry that it's partly due to apathy and mismatched expectations. College students go into CS because they expect a good paying job, not because of any specific aptitude or interest.

This is not unique to CS. I feel this is the general mindset among most people who go to college: "I get a degree and get a job" and is the reason for so many young people coming out of college with a 4 year degree and no job.

Just getting a degree doesn't mean you are smart, curious, or driven. I have friends who got liberal arts degrees who are smart, curious, and driven and went on to have great careers and friends with business degrees who don't care and are unsurprisingly "underemployed" by their degree, but not by their personality and the way they live their life.


Or what if I’m being picky? I made a mistake of expediency in accepting my current job, and it’s not the first time. Several people I trust have been trying to talk me into applying to more places and turning them down if I don’t see what I’m looking for on their end. But they tend to overbook and one of the first things to go is your opportunity to ask questions.

Which is, really, as good a way to learn about someone as most of the techniques we try. You only have ten or fifteen minutes to ask the company questions. What did you hunk was worthwhile to expend that time on?


Not sure what part of my comment you replied to exactly?

I also am kind of picky although I am not sure how wise that is in the current crisis.


Yeah that's a fair question.

I think it depends on the context. To be picky, you could just send out a lot of resumes, and I as a prospective employer wouldn't have any clue how many you've sent, as long as you are still at your old company the whole time.

However if you have a good emergency fund, your old company folds, and you are being picky, people start to suspect you are unemployable after a bit.


> When you apply for a company, they have to assume you aren't very good, because most people who apply aren't very good.

Is this a problem for other professionals? Why not? When an accountant with a successful career spanning 15 years applies to a new job, does the company "have to" assume that know exactly nothing?

It does distort the market. It trades off against the desire to switch jobs, which distorts the availability of job switchers. When I get an email from a recruiter, I'm not just thinking "would that job be better for me?", I'm also thinking "am I willing to practice and perform the whiteboard code ritual right now?".


> A recruiter I talked to a few years ago said she thinks its crazy we don't use an agency model for programmers like actors do. The idea there is that good programmers pay a small percentage of their salary to a manager, who's job is to find you the best roles that suit your skills and negotiate pay on your behalf and so on.

Such things do exist (at least in some form) but I haven't had a good experience. Same old story: like everyone else, they're looking for seniors, turning down juniors, and complaining about shortage of talent.


This is the issue I have faced, and probably why I am leaving this whole mess behind. I still love engineering, but it's time to move to a mentor/consulting role. I've been in this game for over 10 years, and just can't be arsed to do any more testing. I once had someone ask me what a "cookie" was...

Storytime: I used to work at a huge Japanese multinational (you can probably guess which one), and I rose through the ranks pretty quickly. After two years (which given their turnaround, made me pretty ancient), I left the firm for greener pastures.

A few years later, they started a new sub-division, and a personal contact recommended me. It was a decent pay bump, and despite the negative press, I didn't mind working there, during my tenure. I figured I'd be a shoo-in. It was for a non-technical role (PM), but they wanted someone with a tech background, which I had. They then wanted to give me an online engineering test just as a formality. It was a quick test, and I solved it with little issue.

Fast forward 2 weeks and I get a rejection email, saying that my code wasn't up to snuff, and they'd be moving on. It took everything in me to not write back saying, "Hey, go to your main service and log-in. Ok yeah, so the interface and client backend to your SSO and the user management services that millions of your users interact with each day -- I wrote all of that. Oh yeah, your absurdly complicated coupon system -- I wrote a lot if not all of that too."


Another observation: I don't think there is a single company I've successfully working at in the past, where I could pass their interview process today (including my current company). Companies are being extraordinarily picky now, and the interview bar just keeps going up and up.

Companies keep complaining that they can't find talent, while their interviewers are asking candidates to implement red-black trees on a whiteboard in 5 minutes.


"It took everything in me to not write back saying..."

Sometimes it is worth writing back. Because people often don't realize there are flaws in the process they are using. Either they will ignore the feedback and it's business as usual or they will take it and work towards improving the system.


If the whiteboard warriors were good at system design. Google would be the top video-conferencing tool over Zoom.


> working at a company in the hiring space. I've done over 400 technical interviews

TripleByte ?


Sorry but if I wanted to be clear about where I work, I would have done so.


definitely TripleByte


> I've done over 400 technical interviews in the last year alone

Have you gotten any actual work done in the last year?

> in the hiring space.

Oh wait. This is your job.


One thing I do is:

a) Open time. I give them a couple problems in the morning and they can take as long as they want to think about them before the interviews. This takes away the 'deer in headlights' situation that so often happens to people - all of us. I'm good on my feet, but 1 time out 3 'I just don't see it' immediately. But if I have some stress-free time, I usually do.

b) Don't test their knowledge of algorithms. Who cares if they've practiced certain things a lot? Doing homework is a small measure of what you want. I give them fairly basic problems that have nice side-show questions to ask and just have a discussion.

c) I try to test for knowledge where they should have it: if they've been on tools & build or dev ops they should have a good grasp of things there. Another way to say: you're looking for strengths not weaknesses. I keep an open mind and think 'how can we leverage this person's talent'? Maybe they're not good over here, but better over there.

d) Fairly simple code, idiomatic, etc. not rocket science.

e) Mature communicator and by that I almost literally mean not too crazy. I think most of us are 'abnormal' and that being a 'decent communicator' is a little bit rare. Companies are full of weird dynamics they have to be resilient a little bit.


Unfortunately, I don’t think there’s much data around hiring outcomes because companies really don’t have a reason to share that information. For a lot of people, it comes down to personal experiences.

I’ve definitely interviewed with companies where I was put in really unnatural situations that I struggled to shine in. For example, I bombed an interview in which I had to do a live coding challenge where I had to talk through what I was thinking while coding, which the interviewer insisted on so they could understand “how I think”.

I thought it was an incredibly cumbersome and useless request because I never talk when I code, and coding in front of others in an interview is tough enough as it is. I asked if we could discuss the solution once I completed the problem, but they declined that idea.

Needless to say, I didn’t get the job and the assessment felt like a huge waste of time. I think a lot of people see companies doing stupid stuff like this and get frustrated because candidates are often capable while being placed in high-pressure situations that don’t enable abstract creative thinking, which programming requires.


> For example, I bombed an interview in which I had to do a live coding challenge where I had to talk through what I was thinking while coding, which the interviewer insisted on so they could understand “how I think”.

FWIW, there is limited time to collect data about a candidate in the context of an interview, and being able to observe a candidates’ thought process can help a lot with that. Obviously, this biases hiring towards candidates that are more observable, all else being equal.


Not sure where you interviewed maybe it's not relevant, but a lot of jobs you will not always be in a position to do the work 100% isolated and by yourself and sometimes there will be other people in the room.


And most of them will be not actively evaluating your skill constantly.


It varies among the FAANGs, but in my experience Google was the worst with the algorithms above all approach. I actually had one interviewer cut me off after about a minute when I was describing an interesting problem I worked on, saying “yeah ok that’s great let’s get on to the algorithm question.”

I’m sure it varies between interviewers but the lineup I had at google clearly didn’t want to dedicate more than a minute or two to non-algorithm questioning.


It's because background/experience questions are useless.

Whenever hiring comes on up on reddit or HN I see a lot of posts that can only come from people who haven't been an interviewer much.

First rule of hiring: most of the people you talk to want your money. The candidate is selling themselves to you. They know firing people is hard and there are almost never consequences for misleading interviewers.

What happens when people are asked to talk about their prior projects, experience or really anything that isn't a highly controlled and repeatable coding question?

1. They pass off things they saw or read as their own experience.

2. They claim a team's accomplishments as their own.

3. They massively exaggerate or try to BS you in other ways.

4. They give uselessly vague answers, not necessarily deliberately.

Maybe you don't do these things, but back when I bothered asking these sorts of questions I did encounter such answers pretty frequently.

Companies have converged on live coding because that's something concrete, real and largely un-bullshittable. Yeah, toy programs in interviews aren't "real" programming but it's a lot closer to real than listening to someone ramble in a disorganised way about "their" previous project, and at the end realise you still don't know what that person actually did and what was done by others.


Your recruiter was rating you on your performance on the algorithm question, them cutting you off was actually them trying to help you spend enough time on the question.


Good point. Maybe I'm unusually generous, but when I'm in the interviewer seat, I generally try to steer candidates into territory where they can succeed. I want to give that "hire" recommendation! But I need pull enough signal from the noise to be able to support that recommendation, and ultimately I need to measure that signal using the measuring stick defined by my employer. If I didn't need to conform to that measuring stick, I'd just do interviews that were casual conversations about projects. But I need to ask certain types of questions to measure certain dimensions.

The "tell me a little about an interesting problem" question is usually there to gauge your ability to summarize a cool problem and solution down to to an appropriately sized story. Sometimes when I ask this question, candidates just launch into stream-of-consciousness expositions, talking just-in-time as the details come to their brains. At the 2 minute mark, I start thinking come on, don't do this to yourself. At 5 minutes, I will gently try to hint to the candidate to try to summarize and wrap it up. Some people just try to fill every silence with words and I have to finally firmly yank them back and cut it off. I hate to have to do it, but if the candidate can't time-manage the answer, I have to time-manage the questions.


I get that, but it just made it obvious that nothing else mattered but the whiteboard (or in this case, luckily, a chromebook with text editor).


Is Google having trouble finding qualified engineers though? If so, what is evidence of this?


I’m sure they aren’t for the most part. They have so many people trying to get in that they can afford to have a lot of false negatives though.


it was for your own benefit. intro is just to get you relaxed. most of them don't even consider that part in the evaluation. so the less time spent there the more time you can spend on the algo q.


It's counter productive though if the interviewee is cut and gets more stressed out.


I would say the issues with interviews are

* they're not cheap (although not that expensive all things considered), assuming you spend say 10 person hours on two calls and an on site.

* they produce false negatives. on the spot exam style algorithms interviews don't reflect day-to-day work, and they filter out people who might be great at the job, but aren't used to the specific type of stress that interview creates.

* they can produce false positives. failure to check for interpersonal skills in leet koders can leave you wishing you had never hired them.

* they're painful for the candidate. ideally your role is the best fit for a candidate. people only have so much emotional and logistical bandwidth. they may take an offer after interviewing with a handful of companies before they ever find you.

now, I don't have numbers for those last three points. I don't know if anyone does. but we can look at most hiring processes and see that they are a problem, we just can't tell if it's a big enough problem to consider the process "broken".


> we can look at most hiring processes and see that they are a problem

I’m not seeing a compelling problem with the outcome. The question is: are companies not able to hire good people? And: are good people not able to find jobs?

Interviews are also expensive for a company. And I don’t really see a clear or compelling argument that interviews somehow cost the candidate money. How much money? If the candidate doesn’t have a job, then what exactly is money or time cost to the candidate? Doesn’t the eventual job with income outweigh all interviewing costs? Isn’t the cost somewhat irrelevant if it’s not egregious, and there’s really no choice if you want a job? Isn’t the alternative, choosing not to interview, potentially way more expensive?

If you’re going to frame it as expensive, I think it’s more than fair to counter with you need to average the cost of the interview over the time period that you’re employed. If you interview for 10 hours, and you work there for 5 years, the cost of the interview is 20 seconds per day.

> they’re painful for the candidate

I agree that interviews have a time cost and that candidates have a finite budget. That means someone looking for a job should invest wisely, figure out how & when to decline an interview, study the companies before interviewing.

This is subjective, and it’s not a solvable “hiring problem”. This is something the candidate has to fix for themselves. Nobody is going to give you a six figure salary and ask you to work with them for many years without vetting you. It will always take time, and it will always be somewhat uncomfortable and emotionally draining. Some people prepare for interviews, and some people like to interview. If you view it as a skill, one that you can learn and improve at, maybe it will become less painful for you. But don’t expect that companies are ever going to do that for you.


I think we all like to complain when we don't get the job we want.

It doesn't matter what the process is, some form of song and dance is needed.


I think the thing people are "on about" is that we have become so cynical about the current status quo, that there's no oxygen left to have a real conversation about what constitutes a true "false negative".

It would require some sort of longer-term data gathering around the rejection / ghosting process.

For example, Google claims to be very objective and data-driven about their hiring process, but once a candidate is rejected there is no further data.

How would one solve such a problem?

If we agree that it's just window dressing around a "song and dance" (I prefer to call it "the rituals of gate keeping"), there is no problem to be solved.

But I still feel like giving in to cynicism is the wrong answer.


It's a really interesting point you raise. Road not taken etc. I wonder if google quantifies the impact of hires over the long term. How productive are you? How much does your contribution make the company and if you weren't here would google notice?

If google could know when it was about to deny a speculative false negative it could hire them exclusively into a part of the company where everyone is a speculative false negative. Then you could just watch them compete with those who pass and try and measure something objective.


I’ve been rejected from Google, and a year later they reached back out asking if I wanted to try again. The recruiter even told me over the phone that most people they hire these days have already been rejected at least once before. So they openly acknowledge that a lot of times their best bet is to get people back in the door who they know were close. I’m curious how they determine the timing. Why wait a year vs 6 months vs 1 month?


Similar situation; I was rejected around 2007-ish. Many years later when they reached out the recruiter told me that they changed their process and they believed their newer process was bringing in better hires.

For what it's worth: Someone who works well in an established company isn't always the right person to hire in a young company.


Would you put more weight on complaints despite getting the desired. I got the job I wanted and I still think it's a terrible system.


Once you're inside the company there is data about your performance.

My point is that there's no control group and therefore no way to test the process in an empirical way and possibly improve it.

But the idea of finding a way to measure the performance of people who didn't get hired seems ludicrous, so we're back to being stuck in the status quo.

That's what I'm on about. I would love to see an article that talks about this rather than the screeds and diatribes that show up on HN so often.


The trouble with the idea of false negatives in hiring is that you can't really define what they are.

Every job is likely to legitimately reject good candidates.

Most hiring is for a specific position. If you get 10 viable, or even excellent candidates, you can often still only hire one of them.

The one that gets it will take the job in their own direction. Almost by definition, the winning candidate is therefore the best fit.

Whatever roles the other candidates end up in will go in their own directions. Even if, a year on, you can objectively compare the performance of the one you hired against the one you didn't, their performance was within the context of the role they did win. They may not have been as good a fit for the role you didn't offer them.


If the interview sucks I decline before an offer is made. Why work for someone with a bad interview?


Yeah this approach doesn't make sense in my experience. The quality of my jobs has not been at all correlated with my opinion of the interviews to get those jobs. I think one of the reasons the system still lumbers along is that it's still a good trade to go through the hazing in order to get a well compensated and challenging job. But I think it's still worth expressing dissatisfaction with the system in hopes of seeing improvements.


I think the real issue is that people assume that the success of the company depends on the quality of the employees. This isn’t true, what dominates is the match between consumer and product. And you simply can’t predict the market that well, that’s the benefit of capitalism.


In software, the product is built by the employees. It would be weird if the quality of the product (abstractly and in product-market fit) were entirely divorced from the quality of the employees.

I see it slightly differently; I think that 95% of the success of companies is driven by key moments or decisions by 5% or less of the work. (That’s usually by a similarly small slice of the workers as well.)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: