Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Nobody likes being judged in an interview, but on the other hand it has been fascinating to watch how the current style of tech interviews has opened doors for a lot of smart, motivated people who aren’t necessarily born into situations that usher them straight into prestigious tech jobs.

Yes, there is an entire industry around interview prep. Yet it’s also possible to do all of your interview prep without ever giving a dollar to anyone. LeetCode basic is free. There are numerous free websites that will walk you through the solutions to LeetCode problems. There are countless YouTube videos helping build interview skills.

Tech interviews aren’t necessarily fun, but I actually think it’s great that they’ve allowed us to move past the situations where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company. Letting people compete on a level playing field of technical interviews, albeit imperfect, is one of the things I’ve come to appreciate about the tech industry.

View on HN

The problem is that this has become the primary and sole measure by which we're judging candidates. This leads to a pathological condition at many large tech companies where the outputs of an engineer do not matter for their career.

Until you hit the Senior/Staff level, no one really gives a crap if you were editing yaml files, toiling on a legacy app, or building the highest scale app on the planet. It just matters that you can pass the standard tech interview.

Now that people understand this, they are starting to optimize their careers at a company to simply do the minimum until they move externally for higher pay. You can bounce between reasonable tech companies doing literally nothing for higher and higher pay by simply switching once per year.

I suspect that we'll see a steady increase in attention paid for deliverables and a dialing down of the leetcode arms race over the next 5 years. The signal to noise ratio of this interview type is falling.

> Until you hit the Senior/Staff level, no one really gives a crap if you were editing yaml files, toiling on a legacy app, or building the highest scale app on the planet. It just matters that you can pass the standard tech interview.

But big tech all have quarterly OKRs, performance plans and terminations for low performers, and managers/leads are interested to have strong contributors in team to deliver results, and let low performers to go..

Please clarify as to whether you are speaking sarcastically or earnestly in this post.

At big tech this takes time. In some companies a lot of time. It’s also typically done as a comparative process across engineers.

If half the team is simply doing interview prep it’s unlikely management fires half the team.

> big tech all have quarterly OKRs, performance plans and terminations for low performers

...none of which information is shared with future employers. To do so is even considered a legally actionable violation of privacy in most cases.

This is correct. Once you have an industry built around prepping for a test, interview, whatever, the candidates that you end up hiring are those that optimized for the interview. At that point you better be damn sure that interview process is the very best predictor of success for the actual work you need done. Otherwise you end up with a whole lot of the wrong people, who as you put it, can collect a paycheck to get ready for the next round of interviews.

I think what would work better is to get away from leetcode and do more internally developed design and coding exercises that are representations of the kind of things you’d see at that company. Yeah for FAANG type companies who are hiring thousands of engineers per year, maybe you need the leetcode style standardization in order to scale. But for everyone else that cargo culted these processes and doesn’t need to hire 5 engineers per day, it’d be great to step back and actually consider what you want to evaluate for.

Reminds me of a comment:

> Unless you've made it to your "endgame" company that you're happy to stay at for a while, I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews. Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job. Thus we're now seeing the rise of Professional Interviewers or Professional Leetcoders.

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

> The problem is that this has become the primary and sole measure by which we're judging candidates. This leads to a pathological condition at many large tech companies where the outputs of an engineer do not matter for their career.

Very much this. With interviewing having become a second career in an unrelated field, people will choose whether to spend most of their energy in working the job or preparing for the next interview rounds in a year.

I always interview people based on the actual job they've been doing (based on what they claim on the resume). I don't care how good you are at leetcode because that's not what the job will be about. I care how and what you've been doing in your current and past jobs. So we talk about that instead.

> it has been fascinating to watch how the current style of tech interviews has opened doors for a lot of smart, motivated people

And also closed the door for lots of smart, motivated people who are excellent engineers, but do badly in stressed up situations where they need to do something (coming up with an answer on the spot, usually w.o. being able to do any research) that the job they are being interviewed for rarely if ever actually demands of them.

> to move past the situations where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company.

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

Nothing wrong with having a lower than 100% accuracy rate for hiring.

The whole point of tech interviews are to prevent you from making a bad hire who embellishes their skills.

> are to prevent you from making a bad hire who embellishes their skills.

Indeed. And exactly how do code puzzle interviews accomplish that? Because here is the gist of what happens, as described in the article:

    The similarities to the test prep industry are very interesting. Is an algorithm
    interview reflective of how an engineer works in their day-to-day job? Along those
    lines, what is the SAT really measuring?

Whenever I standardize tests, at some point the parameters of my standards become known. It becomes possible to prep for the test instead of what I want to test for.

Which is a good thing because it ensures you at least don't hire someone who you should not have.

How does it ensure that exactly, when the testing methodology evaluates something different from what I want evaluated?

You can practice this stuff to make it less stressful. If you aren't willing to do that, it's not the employers problem

> If you aren't willing to do that, it's not the employers problem

But these sure look like employer problems:

a) Risking to miss out on good engineers that happen to be bad at skills that don't have a lot to do with the job.

b) Risking to hire people that are really good at prepping for standardized tests, but not at the skills the job actually requires.

c) Risking to have qualified people whith a choice simply walking out because they don't like companies using this hiring practice.

For most companies, a bad hire is much worse than missing a good hire. That's why in many ways, companies optimize in that direction.

And, looking at this threads article in the OP, how exactly do puzzle-style-interviews "optimize in that direction"?

As I said in a different comment, I don't think they're necessarily optimal. But a lot of companies do them, which is at least some sign that they have some value. Personally I think slightly different approaches are better, but there are some benefits to a standardized, easy-to-administer test that is better than your random personnel at your company can come up with on their own. (I've seen many far worse ways to value employees than Leetcode-style interviwes).

Also, I'm not sure how easy Leetcode is to practically game. I may be way off here (truly), but most people who can get good enough at solving Leetcode-style problems (and are willing to put in that time) are probably better than those who can't. This certainly misses some people, but as I said, finding a filter that only lets through above-average candidates, even if it misses some others, is what a lot of companies are looking for.

> But a lot of companies do them, which is at least some sign that they have some value.

"A lot do XYZ" is not a sign that anything has "some value".

> that is better than your random personnel at your company can come up with

I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?

> are probably better than those who can't

Better at what?

> "A lot do XYZ" is not a sign that anything has "some value".

It is a signal that maybe there's something you're missing. "I think everyone else is doing this thing wrong" is sometimes true, but often wrong, or at least incomplete (because goals might be different).

> I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?

The problem is that being good at hiring and at evaluating people is itself a skill. A skill that some people have, and some people don't. It isn't necessarily correlated with how good a developer someone is.

The other problem is that if you come up with a different "test" every time, it will make it much harder to compare different interviewees. I still ask interview questions that have to do with a system I built 10 years ago. I of course could update the question to something I'm working on now, and I certainly change the emphasis on what exactly I'm asking. But sticking to a question that I know works well, and that I've used many times, makes it much easier for me to evaluate people.

But let's just be clear - what would you suggest as a hiring criteria? Do you think the team that is hiring (which in large corporations might also not be the team that gets the hire, but that's another story.) You think the team that is hiring should come up with specific questions based on their current work? How often? How often should they change them? Who should be doing it, every team member?

I'm trying to get a sense of where we actually disagree.

> "I think everyone else is doing this thing wrong" is sometimes true, but often wrong, or at least incomplete (because goals might be different).

That isn't the point. The point is, just because a lot of X do Y doesn't indicate that Y is the best solution, or even a good one.

> The problem is that being good at hiring and at evaluating people is itself a skill.

Yes, that's why we have HR departments, and why these can take input from the technical departments to do part of the evaluation.

> The other problem is that if you come up with a different "test" every time

Why would I do that? I am not advocating designing completely new interviews for every candidate, I am advocating not using the same interviewing process for every candidate in the entire industry.

> Yes, that's why we have HR departments, and why these can take input from the technical departments to do part of the evaluation.

HR departments can't do technical interviews. You need technical people for that. But being technical isn't sufficient, you also need to be good at interviewing.

> I am advocating not using the same interviewing process for every candidate in the entire industry.

Is it the same process for every candidate in the industry? I'm not in SV, so maybe it's different here, but I've seen many different processes at many different places, and they were definitely not all identical.

I think everyone in this discussion knows the weaknesses of leetcode interviews, but the disagreement comes from our priors on how bad the non-leetcode hiring process is.

At least leetcode puts the power to look good in the candidate’s hands. Just like the SATs, it’s not exactly fair to the people who can’t afford prep, but it’s more fair than the alternative.

> but it’s more fair than the alternative.

What alternative? Talking to people, presenting them with company problems, and listening to their opinion about them, aka. "how would you do X if you had Y?" kinda questions? Getting to know them in the interview process, to see if they are a good fit to the people already in the department? Taking the time and risk involved to hire people if they seems okay and then evaluating them during a probation period?

Because, to me that looks a lot fairer than "HERE SOLVE THIS PUZZLE REAL QUICK ON WHITEBOARD NO LOOKUP ANYTHING YOU GOT X MINUTES GOGOGOOGOGOOGOGOOGOOGO!"

Yes, the current interview process is a complete disaster to anyone who knows different. Unfortunately it's been going on so long, that's all people know.

I've mentioned this before but it seems to me like the current cargo-culted interview process was designed to not find applicable candidates in the US to get around the H1B visa requirements.

It's maybe "fairer" (though that is very debatable), but it usually gives worse outcomes.

The reason many companies moved closer to Leetcode style problems is that the alternative, which is to not ask people to actually program during interviews, made companies end up hiring people who don't know how to code at all.

And just saying "we'll hire for a probationary period and then fire them if they can't code" isn't a very good idea, for anyone involved. Companies are usually reluctant to fire, so they might end up with a bad employee. And even if they don't, most people don't want to make a major change like starting a new job, if there's a significant chance they'll be fired fairly soon.

> And just saying "we'll hire for a probationary period and then fire them if they can't code" isn't a very good idea, for anyone involved.

And how exactly do puzzle style interviews prevent that, when it's simply possible to learn for the test, instead of learning what the test tries to evaluate?

> the alternative, which is to not ask people to actually program during interviews

The alternative to "puzzle interview" is not "no programming questions". Interviews should always give examples, including architecture questions, questions that test the general understanding of the candidate and at least ine small example problem that has to do with the real codebase.

That's an adequate test to filter out people who can't code, and a far cry from completely arbitrary and unrelated puzzles that can be memorized in advance.

I think we completely agree.

I was specifically responding to this from the parent comment:

> What alternative? Talking to people, presenting them with company problems, and listening to their opinion about them, aka. "how would you do X if you had Y?" kinda questions?

Which I understood to mean that no actual coding would be done, it would be more of an open-ended interview about work history / etc. Which I would argue is far worse than Leetcode style questions.

And I'm also arguing for the idea that the fairest interview is the one that gives the most accurate answer to "will this person be a good developer for the company".

But of course if there's something that's even better than Leetcode, obviously companies should want to adopt that instead.

At our company, we do something very close to what you propose:

- an initial phone screen with a very simple "Fizzbuzz" style programming filter.

- After that, an open-ended architecture problem (how would you build such-and-such system), which can go in many different directions, and can include a few specific coding examples.

- Finally, a real programming task for ~1-2 hours. Sit down in front of a computer with access to internet etc, and do these tasks.

We find that these in combination give a great answer to all our questions (well, the "ability" portion at least, which has the most weight.)

Hiring at FAANGs isn't a matter of "pass the tech test and you win a job". There are lots of other parts to the hiring process. A recommendation from a person high-up in the company, or a Stanford degree, still carries weight. Leetcode is an additional barrier, that people with a privileged background can buy help to pass, and where having the resources to stop working to study full time is immensely useful. People who don't have wealthy parents or personal wealth can't do that.

I believe Leetcode makes tech more exclusive, not less.

I’ll speak strictly to SDE roles at Amazon. Unless you’re recommended by a Senior VP, a recommendation or Stanford degree will not do much more than help you get an interview. A hiring manager can try to fight others on the interview loop and overrule a bar raiser, but they’re really putting themselves out there for you. Maybe they really fight for a candidate once or twice, but it’s not very common.

For sure. I think it’s made the hiring market less liquid. I really did need to study 50+ leetcode questions to do well in an interview. I crashed and burned a few interviews and ended up resigning myself to the grind, and bang, I’d pass those early interviews no problem. It’s a unique tech adjacent skill that not everyone has time to practice. It certainly doesn’t mean you’re a bad engineer if you can’t leetcode.

It’s a form of gatekeeping and hazing. It’s what you get when stem is hyped at every level of education. There are too many people gunning for tech. It attracts all the smart and ambitious students now. There is no programmer shortage.

Tech interviews remind me of employers saying to forget everything you’ve learned, kiddo. Heh, we do REAL work here!

If you want to work for us you better be able to complete this leetcode question! You’re not a real engineer if you can’t!

Then the real work is an awfully designed mostly front end disaster. Nobody knows how anything works. But they passed the interview somehow.

I don’t get the people who do leetcode for fun or who get hyped up about it as an interview process. I guess they made it in life by cramming for tests just to forget it all immediately after.

Wasting time memorizing tedious things that have no value is especially awful and draining for me. It’s not fair some people can just do that if they spend a small amount of effort and try. It’s a monumental impossible task for me when I’m otherwise exceptional with software engineering. I’d rather climb a mountain, to put it in perspective.

I’d rather actually learn the concepts used on tests and be able to adapt them into my learning, rather than have a history test where I fill in an endless amount of blanks with the exact day, month, and year is somehow relevant or useful for anything.

Does anyone actually process those types of questions as actual comprehensible dates instead of memorized strings that are better suited to memorize with a jingle?

I'm going through this right now after I promised myself for a long time that I wouldn't debase myself with this sort of interview process. The rewards are too much, I sold myself out, whatever.

What I'm finding is that the leetcode isn't a memorization game, it reminds me more of my homework in grad school algorithms. Each of the problems is meant to tease out your practical understanding of an abstract concept.

It certainly doesn't guarantee you'll be a good dev if you can pass leetcode type questions, and you're not necessarily a bad dev if you can't, but I can definitely see where performing well at leetcode is a strong signal about SWE fundamentals.

Level playing field? C’mon.

A person using a premium resource most likely have higher quality material and sometimes access to a seasoned professional that can give personalized feedback.

Who has more time to do leetcode? Who has a good network of peers to motivate them when they are not “feeling it”? Who is more likely to enjoy abstract puzzles/quizzes? A single mom in Philly or a wealthy Stanford grad?

Would you also say take home projects are also a level playing field?

It's more level than literally everything else that pays comparatively. At least the single mom in Philly won't have the fact that she didn't go to Stanford completely invalidate her as a potential candidate when it comes to modern leetcode interviewing.

Ha! OP said it’s a level playing field, I’m not arguing if it’s a better system than what you/him compare it to.

Just like how I would argue take-home/side/past projects are an amazing signal compared to credentials. I won’t dare to say it’s a level playing field.

> At least the single mom in Philly won't have the fact that she didn't go to Stanford completely invalidate her as a potential candidate

And when will the single mom in Philly find the time to memorize as many (or more, after all, its a competitive market) default-interview-questions, as someone born into wealth whith lots of free time on their hands and the financial resources to pay someone specializing in prepping them for exactly these interviews?

So, what did really change?

I don't see how this invalidates my original point, can you expand on your argument?

What's the prerequisite for getting good at these questions? Practice and Memorizing.

What resource is required to do that? Time.

What resource is in short supply to the Philly single mom?

Ok, so which comparatively-paying job is a better choice for her then?

I have been through it recently, you are right about the time investment. Though the resources are massively available and they are good quality (to my surprise). Of course you need the motivation, but which kind of interviews does not mandate any motivation? Simply put the non-selective one where companies just need to fill a position with whoever can do the job. People's conditions to prepare will massively differ from one to another, but we can't blame Tech for that. With Tech you will know one thing: you will be assessed based on your interview performance. As always in such debates, we are creating straw-man like "the mother in Philly". How many of such moms were in high-paying jobs before? Are there more or less in tech than other areas? Has the situation improved or not? To the best of my knowledge, I can just say that standardised interviews try to address one aspect of it. It is up to society to do the rest.

> Who is more likely to enjoy abstract puzzles/quizzes?

Assuming someone doesn't, is programming a good fit? (genuinely asking)

>People's conditions to prepare will massively differ from one to another, but we can't blame Tech for that.

Sure we can, and the assumption you give reveals the problem.

>you will be assessed based on your interview performance.

There's an implicit assumption here that as long as you prepare well, somehow you will get the job in tech. As if all you need to do is study up on algorithms, show your best self and it will be okay. At the end of it, you will get a great job which takes away your worries.

Perhaps that is the case in the FAANG/SF bubble, but that is not what is happening to a large section of the junior dev market outside tech bubbles. Requirements are rising and becoming increasingly more specific. Rewards are not keeping up. But to me, the absolute worst part is the ability to ace every measurable metric, to then be ditched for "not fitting the culture" or something related. The problem here is the utter lack of feedback which helps individuals stir themselves in the right direction. The current situation is more akin to walking through your local grocery store at winter to enter the lottery: not the worst situation, but definitely an off-putting situation.

The above is further exasperated by the way most companies filter individuals on personality traits which have no empirical evidence as to impacting the environment or their job performance. Additionally, many companies will not give you feedback on your technical assessment either, which is the bare minimum they could do.

If the tech interview alone was the problem, this discussion wouldn't be as hot as it is. The tech interview itself is just the tip of the iceberg.

I’m not arguing that this system is not better than what you/OP compare it to. I’m only responding to “level playing field”. The Philly mom is just an example to show how obviously absurd that statement is.

At a surface level programming is about coding which is like solving puzzles. But in actual application it is critical to apply a sense of judgement regarding subtleties. Which bugs are actually most important to address? When is a change enough of a fix and what more might be done to make a change the right one, possibly by making other related changes. Reducing the complex balancing act of producing usable and robust software to coding puzzles ignores the most important levels of valuable contribution.

> Assuming someone doesn't, is programming a good fit? (genuinely asking)

Same question, only replace "programming" with literally any other engineering discipline:

Assuming someone doesn't, is marine engineering a good fit? (genuinely asking)

Do we expect someone who designs, plans, builds, tests and maintains seafaring vessels and their components to be great at abstract puzzles and quizzes?

Or do we expect them to know a lot about steel alloys and how they interact with seawater, about the effect waves have on different hull-shapes, and how to figure out how to best install a 7m drive-shaft in an engine room (or whatever)?

> how the current style of tech interviews has opened doors for a lot of smart, motivated people who aren’t necessarily born into situations that usher them straight into prestigious tech jobs.

The underdog could get computer jobs before the current gatekeeping -- on enthusiasm, hard work, merit, and will.

The gatekeeping started by favoring the affluent (suddenly, going into dotcoms made more sense than that Wall Street job), and now other people have to invest in playing catchup on bro rituals.

I agree. Good people never had a problem getting a job. I got my first summer job writing code when I was in high school. My friend wrote commercial video games when in high school. Through history, if you were enthusiastic about writing software, and you were good at it, finding work was never a problem. It's always been finding those people that has been the problem.

I would almost argue the opposite, that this process opens doors for people who are not good software developers to get good software jobs. Since you can relatively easily prep for a software interview but no amount of prepping makes you a really good developer. Whatever the coding interview process measures, it's not how good of a software engineer/developer you are.

yeah, and that underdog now can no longer get a job on hard work and merit, because that is not what leetcode interviews reward.

it also does not take into account any previous work done or any personal projects.

I agree. I didn't come from a prestigious family and I didn't go to a prestigious school. I graduated with less than a 2.0 GPA because I didn't care when I started school. Because of the standardization of tech interviews, I'm able to work anywhere. I don't think it would have been as easy for someone like me 20 years ago. Then again, I have no idea.

It would probably be easier 20 years ago.

Yeah, the hiring goalposts have move significantly from 20 years ago, as in the bar is now much higher.

Doubtful. 20 years ago, the dot com bubble had just burst, there was no money in tech, and jobs were sparse enough that employers tend to require a CS degree and they'd have no shortage of applicants. Microsoft, one of the few (remaining) leading software companies, was famous for asking brain teasers like "Why are manhole covers round?" (I'm not sure whether they asked difficult programming questions -- IIRC Google started the trend later)

The rush of people trying to enter the software industry only happened in the past couple years I think. The demand due to the tech boom drove up both the pay and the numbers of workers employed. Sure, it's probably even harder to enter the top tier companies, but I believe there are much more opportunities than 20 years ago.

What I remember from around that time, if you breathed and was confident, you could get the job. It did not required as much preparation as people put into it now.

opened doors? you must be nuts. all it has done, is made it easier to discriminate candidates, turn a highly specialized field into a commodity, and put more power in the hands of tech companies, especially FAANGs. it has indirectly prevented knowledge workers from organizing.

if people go to university and actually study and work hard to get a degree, it should be normal they don’t have to go through this bullshit.

> it has indirectly prevented knowledge workers from organizing.

i don't see how any of the above indirectly causes prevention of organization of a union.

If it required you to get a degree to get a tech job, far fewer people would be available. Far fewer people would be able to transition from low paid jobs to a higher paid job such as tech.

Making a specialized, technical field into a commodity is actually a global gain - even if those who used to enjoy a highly paid position gets their advantage lost because of such commoditization. Either they specialize into something that is even more valuable, or be lost amongst the commodity. Imagine if, during the iron age, the blacksmiths prevented the commoditization of industrial production.

just like the field of medicine or law owes you nothing, the tech industry owes you nothing. it does not need to solve your problems. it is annoying that people think it should.

the reason that tech prep and tech programs and STEM are promoted, and kids are sold on “learn to code”, is to LOWER THE COST OF DEVELOPMENT.

> is to LOWER THE COST OF DEVELOPMENT.

you say it like it's a bad thing.

Lowering the cost of _anything_ is good for society overall. It makes this resource more affordable for all entities requiring such resources, and it increases total output.

Doctors today costs too much, because there's a lobby group called the AMA that restricts entrants (rightly or wrongly). i would argue that it's better to have lower cost, because this service is valuable to people, and if the cost matches the value (or exceed the value), then some people will miss out on being able to utilize this resource.

I’m a big tech veteran, and I agree tech interviews aren’t perfect. Your assessment on discrimination is misleading. The tech interview is a signal, which is “good enough” but far from perfect, especially in this world of hiring at scale.

>if people go to university and actually study and work hard to get a degree, it should be normal they don’t have to go through this bullshit.

There’s a significant number of candidates, who despite their CS degrees and fancy GPAs, can’t solve basic programming problems. And then there are the senior or principal engineer candidates who can talk a big game but can’t write fizz buzz.

Frankly, you can call it bullshit, but hiring unqualified people, coaching them, and eventually letting them them go is expensive. It’s not just expensive for the company, but it has a personal toll on the candidate, their manager (if they’re sincere), and the team.

Tech interview loops aren’t a perfect solution. We still let go of people who get through these loops. People try to study specific questions and anticipate the same or similar question in their own interview. Or other times, people get hired because the hiring manager is just bringing in “talent” from their previous company to expand their empire and get their promotion. Yeah… there’s corruption in every system.

> it has indirectly prevented knowledge workers from organizing.

I have literally no idea how unions are relevant or how tech interviews encourage or discourage unions.

> There’s a significant number of candidates, who despite their CS degrees and fancy GPAs, can’t solve basic programming problems. And then there are the senior or principal engineer candidates who can talk a big game but can’t write fizz buzz.

The problem is, I am not trying to hire people to write FizzBuzz.

If I am looking for someone to compose a concerto for violin and lyra from scratch, but the question I ask them to determine their qualifications is: "Here is a whiteboard and a pen but you don't get a ruler, draw me a pentatonic scale freehanded in 30 seconds or less, and I will evaluate how similar it is to the picture here in this book on musical theory.", how nice will the resulting concerto sound?

> if people go to university and actually study and work hard to get a degree, it should be normal they don’t have to go through this bullshit.

There are many flaws in this argument: - what about people without degrees but skills, do they deserve such a job? - Is university free? If not, do poor people deserve such a job?

Finally, we are not talking about the average SE job. We are talking about the top 10% of the jobs where competition is fierce. People at this level, as in any domain, are willing to compete fiercely. Should the marathon been shortened to 10k so that people who can't train can compete?

> what about people without degrees but skills, do they deserve such a job?

What about people with actual problem solving and engineering skills, who worked hard to teach themselves, but are bad in test situations?

Some people cope well with tests. Others don't. Neither tells me ANYTHING about how well they will do as engineers.

> People at this level, as in any domain, are willing to compete fiercely.

But the competition is about "who's the best engineer", not "who was best at memorizing leetcode questions".

I work in 'the top 10%' as you describe, and I certainly did not compete fiercely to get here... I was just good with HTML, CSS, and Javascript that I learned from a community college, but what got me into the interview was a BS in Compsci. Now that I'm involved with hiring, I see candidates who obviously have spent many hours on Leetcode, but struggle to write a for-loop, or who might come up with a solution to the interview exercise, but can't describe why it's the best solution. Despite that, I can see when people are willing to learn and grow, and I pass them through to the next interview. The world is not black and white.

Personally, I wish there was a guaranteed pathway from a degree into an apprenticeship with the same pay and benefits as any other employee. If America wanted to grow and maintain its global economic power, it would guarantee a highly compensated job for every college graduate.

Just because people are willing to compete fiercely doesn't mean they have to. You sound like a crab in a bucket[0], when the reality is that the bucket doesn't need to exist.

[0] https://en.wikipedia.org/wiki/Crab_mentality

I also appreciate that anybody who puts the work in can get a good job in tech. But I don't follow your reasoning that the current tech interview process supports that in some way that another process could not.

Sure, but at the other end of the spectrum you get "know a guy" interviews where interviewers just hire their friends if they are the only person in the hiring process.

Where I work (and even other co's my friends work at) even if you wanna hire a friend as a candidate, your friend still has to go through a full interview process.

What's the alternative look like?

As someone in tech but not (professionally) a developer I have to confess that all my (few) jobs since grad school were of a “know a (senior) guy/gal” persuasion. Haven’t had a really serious interview since the 80s. Hav I optimized salary? Likely not but things have worked OK.

But it’s very “unfair.”

The other side looks like this:

That person gets hired and fits in with the team. The team puts more effort into mentoring because they are friends and you end up with a strong teammate.

Team made of friends tend to level each other up or cover for weak areas.

Teams of strangers need to fit in socially.

Relationships level teams up quicker so if you are hiring every 6 months gets friends if you are hiring every 10 years it matters less.

I don't agree with "hiring a friend" but I can certainly say that nothing has higher signal value than previous coworking experience with someone. The validated network of your current high performers is the best place to look for more.

I agree. So should that person get a "skip the vetting process" pass?

At my current org, they don't. They go through the hiring process like everyone else, and the person that recommended them is not involved until they are hired or not.

They will very likely be hired because they are good, but the process makes sure of it.

Or the process rejects known good people?

A middle ground that I follow is to go back to the person referring and ask are we stupid for not hiring this person? Then we try and reconcile the interview performance with the recommendations.

Another thing that I generally do is never recommend to anyone great that I know to come work where I work. Nothing good comes out of that. They already have good jobs. There is some probability they won't be as successful in the new place. I would deviate from that under certain scenarios but as a rule I would not initiate that sort of change. If they come to me I'd happily recommend them (rarely happens, as I was saying, they have good jobs).

Referrals are tricky especially when there's incentives like referral bonuses and everyone starts referring their cousin's friend's uncle's neighbor (some other problems in that sort of culture but we digress).

> Sure, but at the other end of the spectrum you get "know a guy" interviews

And code puzzle style interviews prevent that how exactly?

If the boss's boss want's his golf buddys friends nephew hired, goes to HR and says "hire that person", then that person will go through the same interview process as everyone else, presented with the same puzzle questions as everyone else, and do as good or bad as his preparation allows him to do, just like everyone else...

...and then get hired no matter what, because, just like everyone else, HR people want to keep their jobs as well.

Well if there is such a process that does a better job than the current one at scale then the billions of dollars spent researching the problem at tech recruiting departments haven't unearthed it yet.

> current style of tech interviews has opened doors for [...] people who aren’t [...] born [...] into prestigious tech jobs.

I really take issue with this line of reasoning. The same thing was recently argued in relation to MIT going back to using SAT scores. The argument basically seems to be "Since no alternative to this is conceivable that isn't some form of racist/classist cronyism, this is actually the lesser evil".

At some point in history, people probably said something like "Since no alternative to monarchy is conceivable that isn't some form of despotic warlordism, monarchy is actually pretty good". ...they just hadn't conceived of those alternatives yet.

It sounds to me like simply a reflection of the political climate in the U.S. where there's a weird inversion of burden-of-proof whereby any decision making process is presumed a form of racist/classist cronyism unless proven otherwise.

The more mechanized a decision making process is, the more amenable it is to this sort of proof. But I certainly don't want to live in the resulting dehumanized dystopia.

Also, I'd question whether social reproduction is quantitatively a significant factor in selecting who tech jobs go to. The idea seems to be that engineer daddy gets son interested in engineering by doing science fair projects with him, sends him off to space camp, then pulls strings to get him into MIT and so forth. But, statistically, I'm expecting to have as many daughters as sons, and a daughter is statistically not going to be interested in tech. Even if it's a son, it's not clear whether he would have the personality traits and inclination. I wouldn't want to interfere with them either, as I'm not even sure that going into tech would be something I would want to do again if I could live my own life over.

The latter is not true of wealth in general. I would always want my children to be wealthy, and they would always want to be wealthy, and handing over wealth is as easy as signing a piece of paper. These latter statements are oversimplifications, but they highlight how the analogy breaks down between social reproduction in relation to wealth in general and social reproduction in relation to having a prestigious tech job. -- Also, the question of whether tech jobs can be prestigious seems subjective to me, as there are a lot of negative stereotypes attached to tech.

> prestigious tech jobs

Tech jobs are well known for paying well (compared to the other jobs you can get if you’re not born into money) but have never been prestigious. Unless you’re considering the VP/CTO jobs that don’t involve algorithm solving and do involve being from the right Harvard fraternity.

This is true if you’re comparing exclusively within the tech field.

The job title of “computer programmer” is extraordinarily prestigious compared to, say... barista, waiter, nurse, bus driver, police officer…

Getting into “tech” is a very big deal compared to almost literally any other field that is not law/medicine.

> current style of tech interviews has opened doors for a lot of smart, motivated people who aren’t necessarily born into situations that usher them straight into prestigious tech jobs.

The self taught programmers were always the thing. If anything, current interview style is giving advantage to those from elite universities - it tests exactly those skills.

> where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company.

This absolutely still happens though. Those people will just get "fast tracked" through the process and allowed to skip steps. If there is even an interview at all. Nepotism is still alive and well even in software.

Edit: Oh, or they will get hired as consultants / contractors at a high rate and get to add your company's name to their list of happy clients

> where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company

Critics of the tech interview are certainly not against the merit-based selection --- it's more like the 1.5x engineers fear that the standardised interviews are being abused to allow 1x engineers who are "just-in-for-the-money" to appear as 2x, making their lives harder.

Meanwhile, 10x engineers probably are not bothered by this at all since 2x isn't enough of a threat.

I think this bothers everyone in the industry. Even if you're a "10x" you're working 120% of your time on fairly specialized things. Now you have to put in extra work if you want to switch jobs. It creates friction. Maybe the 10x prepares for the interview in 2 days vs. the 1.5x taking 6 weeks but the 10x doesn't have 2 days and the 1.5x I guess has those 6 weeks ;)

I wouldn't call the coding interview "merit-based" selection either. At least not until we show any sort of relationship between success at that style of interview and the stuff we think matters more. I don't think we're seeing any sort of boom of quality software that has followed the changes in the way we interview, if anything, the opposite.

But you're exactly right in some sense. Back in the dot.com hay days we used to joke that if you had a pulse and could type you could land a tech job. It's sort of back to that. The industry needs a lot more good developers than what we have.

Reply on news.ycombinator.com