Why tech job interviews became such a nightmare | Hacker News Reader

Why tech job interviews became such a nightmare

wired.com

74 pointsnamanyayg154 comments

My perspective has long been -- since well before the free money printer stopped going brr -- that the reason tech interviews are insane has little to do with rising interest rates or monetary factors per se.

It's because tech dev / coding jobs are one of the few white collar fields that, historically, have not de-facto required a pile of advanced degrees. Maybe i'm getting old, but "you don't need a degree if you're hot shit" has long been part of the atmosphere: from old school hackers to the long history of founders who drop out of school to work on their startup, etc.

This directly leads to interviews being the gate: if we can't know what you are by what degrees you have / what papers you published / what lab you did your dissertation in / what bar exam you passed / what hospital you did your residency in / who you clerked for / etc. ... then we're going to have to do all 4-8 years of post-undergrad pain and suffering all at once, during the interview, so grab a whiteboard and buckle up!

It's ... less than ideal.

edit: what's less than ideal is the perverse incentive force that creates bad interviews. The recognition that a degree doesn't guarantee job fit is not a bad one, though; you really can be more successful in software dev if you're self-taught / uncredentialed than you can in many other disciplines.

I would like to say that I’ve known and worked with PhDs that were good and some that were totally useless. I wouldn’t trust it as a very useful signal for a job interview.

Programming is more of a trade and academic institutions barely teach the craft.

In my experience the ones to avoid (at work and in life generally) are the folks with PhDs that bring it up all the time as if it's important and bestows upon them some special power.

What's the point of getting a PhD if people don't call you DR?

I've always thought that was a bad strategy. Better to underpromise and overdeliver in life.

Most PhDs in this field are going to be in computer science. Computer science is not programming. Most of us are not hiring scientists.

OPs point is that if you were a hospital, you would take a different stance on the relevance of a doctorate degree to your hiring criteria.

They'd probably take the same stance, that a PhD is useless, since in a hospital you want nursing staff, or medical doctors. PhDs are going to be about as good as JDs (honestly likely even less useful).

I think it should be obvious that when I said ‘doctorate degree’ in that context I meant an MD.

A PhD mainly teaches you how to do research. If your particular job isn't research focused then it's unsurprising that usefulness isn't correlated with the degree.

Tech companies dont trust pedigree when it comes to programming.

They kind of do. If you graduated from Stanford, Berkley, MIT, Ivy leagues, Oxbridge, Imperial College of London, Waterloo, etc you have a much easier* way in to top tech companies or finance tech than coming from "no-name" universities in some small countries

*)Easier as in the recruiters will actually reply back or even them hitting you up instead of you getting ghosted when you apply, not that they make the interview process much easier for you, you still have to pass the same bar as everyone else but you have a much greater chance of being called back

You have to pass the same tests during interviews. The main difference is that if you come from a no-name university in a tiny country you need something special to even get an interview.

Of course that is for algorithm interviews, in less objective interview formats you are right where you studied etc is a massive factor.

It's also true that the questions are overwhelmingly written by people from "elite" universities, where certain subjects and approaches are emphasized. So if you aren't from one of those you're less likely to nail it. Elite universities also have connections I'm sure, and generally prepare students for interviews much better than average ones.

Largely because those institutions are known to be extremely selective. If they let you in then you must know a thing or two.

They've been extremely selective for folks with no relationship, yes. They've never been particularly selective for the family of donors or legacy. But, there's not really any way to tell if John Doe Harvard '23 got in because his great-great-grandfather also got in, or because he's hot shit.

I don't think this is altogether a negative, if you're hiring an investment banker then yeah the rich or connected family they come with is a benefit so you're probably in a good space regardless.

Institutional reputation has never had much sway with me but what little it did have has pretty much evaporated of late.

There is also a goodharts law thing.

Coding is more like weight lifting then running. There are some weights that some people just can't pick up. And so if the job involves lifting things that are usually light but occasionally heavy, then a squat becomes a good measure for candidate.

But once everyone knows a big squat is the way in, they train squats, they show up in lift suits and the whole thing stops being a good measure.

Because on the job you don't squat in a squat rack, but pick things up where they are found, in the conditions on the ground.

Now you have a bunch of people optimized for a task that isn't exactly the job.

And then when you try to design an interview process that mimics the conditions on the ground you get people decrying it (sometimes rightly, sometimes wrongly) as too hard, or too long, or whatever.

"ive been in the industry 15 years, doing this shit is an immediate no!"

then you try to get them to explain TCP/IP or fix a for-loop and they're stumped.

So this. We always give realworld actual mini 'regular day at the office' assignments, and it was a great filter. We ended up giving it a lot because people would ghost or give up after days of (fundamentally bad) work, then the right candidate would arrive and nail it in hours.

We had recruiters tell us not to do tech interviews, nobody likes them, etc, but our team was so strong for it.

And really, we were mostly testing generics. Use stack overflow by all means, but just know what you are copying and how to modify it!

And yet here I am with my 10+ years of experience, without a degree. I've met people better than me with less experience and no degree, and people who aren't very good that have MANY degrees.

Yet we've gone through many iterations of the interview process (and testing, things like leetcode) to avoid having to basically accept a gut check of "do I think this person will perform well".

It's more of an art versus science than I think people give it credit for.

So is interviewing itself.

The thing I don't understand is why so many companies are so inefficient at hiring developers. They'll spend months giving out interviews and take-home tests and disqualifying people for the smallest subjective hangups and then finally hire a friend of an existing employee who talks a big game but can't code their way out of a paper bag.

Meanwhile, I've helped several clients hire new remote devs before and all it took was a few basic coding questions to weed out 90% of the candidates, followed by a small paid trial task before hiring them long-term. The results we got were fantastic, completely merit-based, and easy to reproduce.

Well I mean you've answered the question right there. The salaries and benefits for the current employees are a sunk cost and are getting paid no matter what. So having them spend a few months talking to people isn't an additional cost in the accounting sense of things. The minute you add "paid trial task" you're talking about a (usually non-trivial) expansion in budget. Where does the money come from? How many of the devs on that team are going to be happy with smaller bonuses, smaller raises, so they can pay someone to write code they're going to reject?

Maybe this is objectively The Right Way to hire developers, but good luck convincing the accountants of that, and good luck convincing your current developers to pay for it.

Presumably it would come out of the budget for the new employees own salary.

Note: I’m not the original commenter and I have not used this hiring method, but I do have to budget.

Okay so teasing that out a bit, you're now offering a lower salary than similar competitors because you're paying a bunch of people to do an interview.

Are you applying for that job? Are you willingly taking a lower salary because they're paying the people you interviewed against hundreds or thousands of dollars?

Do you have an opinion on a decent website these days for sourcing some "reasonably priced" developers to hack on a proof of concept web app, preferably Eastern European or some similar straight talking culture?

I dunno about hiring from specific countries, but I would say that some combination of Indeed, Upwork, and Linkedin can cover just about whatever you need.

ElixirForum.

I have been heavily involved in the tech interview/hiring process for a few unicorns, doing a couple hundred interviews in that time, and my experience was:

1. A lot of people have no idea how to evaluate a candidate, even with a rubrik. I have been in many evaluations where I tracked with particular interviewers said about a pros or cons of a candidate and it is near noise when you get beyond candidates that are clearly not qualified. Even simple questions like "dedup a list of integers". Sometimes the interviewer really focuses on if they maintained order of the dedup list, other times it doesn't matter, other times they care about time complexity, sometimes not. This is especially bad when an interviewer is allowed to choose the question that they ask, because they choose questions that have something they find "cute" and if the candidate doesn't pick up on that "cuteness" it's really hard to evaluate them.

2. A lot of people I have met think that an interview process should be able to evaluate some random developer you pluck off the street without prep. The larger companies are less inclined to believe this but smaller ones I have found either don't know or don't have the person-power to prep interviewees. Again, a lot of people think whatever knowledge they like is the knowledge everyone should have.

3. A lot of people I have met think that you can understand after 5-7 hours worth of interviewing, where one person probably only interacts with the candidate for an hour or so under stressful conditions, it that translate to someone you can be around for 40 hours. It just doesn't.

4. A lot of companies look at interviewing as finding the missing puzzle piece of the company rather than shaping the puzzle piece. They just want candidates to join and go. That's really tough to do at even a moderate scale.

I think a lot of companies don't really realize how both difficult and high leverage hiring is. You're spending a few hours with someone to determine how they will work over thousands of hours. They want hiring to be easy, you just see if the person passes the checkmarks and they are in! And if you don't confront the reality you can't adequately solve the problem.

If only there were a group of people who could reliably evaluate people based on a rubric, and issue a certificate to people who are satisfactory so that you don't even have to waste copious amounts of time and energy figuring out what a person is capable of. Wait a minute...

I think a lot of people buy into the fallacy that there is a single best candidate, and you must find that candidate. I choose to approach hiring assuming that there are many good enough candidates. Furthermore, hiring is the process of finding the best candidate within the given constraints on the hiring company/manager: time, effort, primarily.

A lot of software dev hiring is not on demands, to fill a pressing gap, but more like an opportunistic background process. The perfect candidate will be added to the herd, but if that perfect candidate fails to show up, the opening will remain open forever. Not hiring the almost-perfect candidate is a hedge against the scenario of the perfect one entering the market while the company is not advertising an opening.

> The thing I don't understand is why so many companies are so inefficient at hiring developers. They'll spend months giving out interviews and take-home tests and disqualifying people for the smallest subjective hangups and then finally hire a friend of an existing employee who talks a big game but can't code their way out of a paper bag.

That kind of sounds like a general organizational dysfunction: someone designs and elaborate and expensive process that doesn't work and rejects 100% of the candidates (which was almost certainly sold a a "process improvement"), then people end up working around it to get things done.

Or, it's the type of job where a degree doesn't guarantee that someone is a good coder, and that's easier to test with a whiteboard than other kinds of engineering for instance.

...and after passing that hurdle, you're suddenly exposed to a large body of work in the organization that has no processes to ensure continuity and modernization other than some rudimetary coding styles and PR/code review flows. The only way to stick around is to make your output so incomprehensible that the only way to maintain it is to keep the lead around.

For all the talk about hiring the best, once they're in the goal becomes to stop hands-on development as quickly as possible and to add friction to improving the knowledge repository as much as possible.

If that’s the reason, I think it’s much more ideal than selecting a resume by the degree you have, or by which university you went. Orders of magnitude more ideal.

The problem is that being able to do a particular LeetCode in a particular amount of time is not going to be any more useful a metric than "has a Master's in CS" or "went to Stanford."

But it’s much less exclusive and, in my opinion, more just than requiring people to, e.g., go to Stanford.

Also, leetcode is just one way of doing technical interviews. There are others that also do not require going to Stanford.

So why do people with multiple degrees still need to go through such a painful process?

Because the degree doesn't mean you can code, which is sort of the point of this entire thread.

Because a lot of book smart people lack the creativity needed to solve problems on the fly.

> This directly leads to interviews being the gate: if we can't know what you are by what degrees you have / what papers you published / what lab you did your dissertation in / what bar exam you passed / what hospital you did your residency in / who you clerked for / etc. ... then we're going to have to do all 4-8 years of post-undergrad pain and suffering all at once, during the interview, so grab a whiteboard and buckle up!

Couple of solutions:

- Open source contributions, especially in the tech you are hiring for. Need someone who is good with spring boot? Makes sense to see the open source contributors in the spring ecosystem.

- Open sourced side projects. You get to see the code the candidate wrote, even before hand, and have them walk you through the decisions they made.

White board is still path of least resistant - its for the lazy hiring managers, and they usually do not even know how to do it well which is why there is always so much attrition.

Edit for clarification - open source + projects do not have to replace the in-person white board. Rather, it can be additive.

Who would you rather hire - someone with hi-quility open source contributions, or someone who can implement LRU cache bc they happened to do that problem on leetcode?

This feels like it could end up being the software equivalent of musicians/artists to do free work "for exposure".

I can see a lot of value in contributing to open source being an alternative way of demonstrating competency. However, I don't think I'd want to see it become the only or primary way.

This is a hollow excuse.

It doesn't have to be a replacement for traditional interviews. Rather it could be a way of distinguishing candidates instead of only relying on a white board.

When I was trying to get my first job out of bootcamp, I had a built a mobile app with my team mates, and we had it on our phones. The idea behind that was we could pull put our phones during interviews and show our interviewers exactly what we did.

"Btw, hiring manager, I happen to have that app on the projects section of my resume on my iphone as we speak - would you like to see it? Happy to walk you through the commits I made on github if you would like."

But...

Most hiring managers were not interested at all. Instead, it was all white board. The whiteboard brain worm infection in hiring managers just runs too deep, there's probably no cure at this point.

Who would you rather hire -- some one who could show you an actual project, code and all, or someone that can implement LRU cache in under 25 mins bc they happened to already do the problem on leetcode?

Not surprised interviewers aren’t very interested in looking at an app with you. Having produced some code that runs is the lowest possible bar to cross, and if your resume said ‘I wrote this app’, they are probably willing to give you the benefit of the doubt and believe that yes, indeed, you got an SDK to emit an executable that actually ran. Seeing the app isn’t going to give much more information.

This rules out good developers who work/worked at places that limit open source contributions.

Also opens the door to a lot of ultra-low-effort open source contributions that are done for the sake of it :/

I help maintaining a quite popular package ATM, I prefer when people do it for pragmatic reasons or for passion, rather than to improve their GitHub stats :/

But you can see them and filter out the low quality contributions. And ask about the good ones.

Totally true, but I was talking more from a package maintainer PoV.

Filtering them out and dealing with the resulting drama is an additional drain on the maintainers' time.

Most of the best commercial product developers that I've worked with had zero open source contributions. If they have some then sure, take a look. But it's not an effective filtering mechanism.

There is also now an underground economy built around fake open source contributions and even entire projects. This exists precisely because some employers do care about open source contributions, so hiring managers now have to verify that those contributions are real.

Open source contributions/projects is an extremely weak signal in my experience, and sometimes can be an negative signal. Open source software is developed generally differently than closed source software, much more async, and much more slowly. It is rare for people that professionally develop software to want to go write more software after work, and so quite often open source projects indicate they had a lot of free time for some reason, or they read something that they should do an open source project to increase chances of being hired.

The places I've worked in the past 15 years generally take open source contributions as a very slight positive signal, but only one of many.

> Open source contributions/projects is an extremely weak signal in my experience

What's a strong signal in your experience?

There really are no strong signals, which is why interviewing is relatively painful. Instead, there are a bunch of weak and moderate positive and negative signals, that you have to aggregate into an overall signal. Unfortunately the error bars on those signals are significant, and so usually you only hire on a relatively strong aggregate signal, and even then get it wrong occasionally.

Plus, nervousness and comfort with the environment and questions makes the error bars bigger.

Depending on the level, but assuming a Senior role, then some stronger (not strong, just stronger) signals are:

- ability to code basic solutions in the language of choice - ability to reason about code complexity

- ability to get to a solution

- ability to explain their reasoning

- demonstrate they understand the nuance and complexity of software development

- understanding common tools in the domain they are interviewing for (sharding for distributed systems for instance)

Same, but on the negative/bad side of things:

- arrogance, argumentative, rude (nervousness is totally fine and expected)

- one true way-ism

- complaining about interviews during an interview

- inability to solve basic coding questions

- lack of understanding about basic data structures (too many people I've interviewed don't even understand how a hashmap is used)

This is a bad idea. Even if "additive", giving significant weight to OSS work has a systemic effect of filtering for candidates with the free time, prior expertise, and/or liberty to do OSS work. In turn, those filters penalize: candidates trying to break into the field from other fields; candidates without a lot of free time outside of their existing work; candidates with more than full-time commitments (e.g. a lot of candidates from diverse backgrounds who are combining pre-existing FT+ employment with school to try to break into programming); entry-level candidates who might be able to code a TODO app from a quickstart, but aren't experienced enough to make substantial contributions to larger OSS projects; people whose prior employers didn't allow contributions (as another commenter pointed out); people whose programming experience is niche such that OSS contribution opportunities are rare.

Like, whiteboard interviews and leetcode grinding are not good filters, no argument there. And OSS is good and we should encourage more contributions in general. But using OSS/hobby contributions as an interview filter is just as bad as leetcode, in that it inequitably narrows the field of candidates and further compounds the hiring diversity problems in the US tech industry.

I think that being unwilling to train entry level employees might also be a factor? I.e. someone with a CS degree has demonstrated that they probably have the aptitude for programming; however, they may or may not already be good at programming.

Ideally, entry level positions would hire for potential with the expectation that they will be training their employees.

IBM and other companies used to hire entry-level programmers with based on an aptitude test. This was before programming was widely taught in college, and far fewer workers had college degrees at all.

https://thecomputerboys.com/?p=369

Curiously, there's also the exact inverse happening as well, without contradiction: unless you go for the extreme junior position of straight from university, employers expect a perfect tech stack match. If you haven't worked with exactly the same framework, philosophy and process, you're out. Few other fields have this to a similar degree, outside of commercial aviation where you're either certified for, say, 737 or you're not.

I blame it on the very unspecific headcount demands in software projects: there's never a hard target number "we need ten keyboards to be manned at all times!", life just goes on when you are nominally understaffed. Perhaps slower, perhaps with more crunch, but nobody really knows what difference a hire or two would have actually made. So software development HR keeps throwing out their net, who knows, perhaps tomorrow the perfect candidate applies, and rejects a lot. It's a bit like the pattern of attractive people trapping themselves in an infinite dating treadmill, but with the plot twist that their salary depends on it.

I find that this becomes less of a problem when you move up from senior positions. Staff, principal, lead, etc.

IMO this doesn't make sense. I don't think a senior dev should have problems switching stacks or languages.

I guess the idea is that if you set up a team for something greenfieldish you want some to lead by example in terms of how the stack will be used. You don't want someone generally experienced to go deep discovering their way to use the stack, you want to buy usage patterns. Once the position is out of the trenches, it's not really a tech job anymore and you basically need someone who knows the language (of the field, not a programming language!) and who is good at not running into process traps.

From the buyer side it makes a lot of sense, the problem is that when you're on the selling side and too old to get accepted in a junior role, you either have the precisely fitting CV (and can prove it through the interview stages), or you're bound for a tech stack consisting of an uber-accepted car.

That really varies by the organization. Smaller companies or those using less common platforms are more willing to hire based on transferable skills and then train.

Most airlines do the same. The majority of pilots flying 737s were hired without that specific type rating. Usually they're moving up from flying smaller jets at regional airlines.

Airlines are at the polar opposite end of the spectrum of clearly defined minimum headcount requirement: they know exactly how many keyboards they must have manned, they can't wait it out if there aren't enough candidates who don't require training into the type rating.

Our campus job fair was last week and I'm watching very closely as a new batch of seniors get hit by reality.

I feel like the financial engineers are eating the lunches of CS folks whose only skills is to "sling code". These 22 year old finance kids didn't need a CS degree (or at least major) to develop the coding skills necessary to express themselves and every, single one of them is highly competitive. I know one CS guy who is doing well too, but he's an industrial engineering double major. Definitely hearing a lot of moaning from the CS kids that just followed the curriculum and didn't develop some side hustle already.

Point is that we've very quickly hit a point where the market is saturated for people who can only code and nothing else, at least from my observation in the US mountain west region. School projects and even internships don't seem to be cutting it anymore, at least if you're attending a state school I guess.

I think you've hit the nail on the head, and for what it's worth it's the same in the midwest now too.

Ten years ago if you could write good code you could get a job. Yeah you might not get a FAANG interview if you didn't know anybody and you went to Southern Regional State College or whatever, but you could get a job making twice what your English major friend got, and a lot easier.

Being able to write code is no longer a differentiator. You need to know something about product, or design, or finance, or entrepreneurship, or at least show through the other parts of your resume that you can be a benefit in some of those areas given the opportunity.

The root is that you are not owed a job at all, let a lone a cushy six-figure one where you can type JavaScript into a computer for a couple hours then call it a day. So if you believed the lie of "just go to school for 4 years, major in CS, do what your professors tell you to, and you'll be set for life" then you're in for a rude awakening when September rolls around and you're still looking, or you're writing Java for a bank for $45k/yr.

> Ten years ago if you could write good code you could get a job. Yeah you might not get a FAANG interview if you didn't know anybody and you went to Southern Regional State College or whatever, but you could get a job making twice what your English major friend got, and a lot easier.

I was 100% this guy 10 years ago. Engineering school dropout but could build things on a LAMP stack, so I had more work than I could really handle. But it should have been apparent to anyone that this couldn't last, so I went back to school and explicitly avoided software because if I could teach myself this stuff, these econ, finance, and stats people were going to as well. And here we are!

> writing Java for a bank for $45k/yr

Yep that's the type of job you're going to find in Pocatello, Idaho... working for Regional Bank of the West integrating bank software their mobile apps and websites. The interesting jobs are currently going to the mechanical/electrical and hell industrial engineers who did a code bootcamp. This isn't my suspicion, it's what is actually happening on the ground and I hope the 19 year olds feeling a bit of buyer's remorse on their choice of degree program take note.

I've seen several entry-level analysts over the years quickly move up the ladder due to their resourcefulness and willingness to learn the technical side of things. It starts out as needing to dig deeper than what aggregated data (e.g. cubes) can provide. So they learn SQL and start querying tables directly. It just snowballs from there.

When consultants come in and ask for data, this is the person that gets them what they need. This is also the person that stays off the chopping block whenever the consultants propose their solution.

I feel the need to add a very important point to your third paragraph. Most times these interviews persist even if you have all of those. And what is worse, they are performed by HR people. And I'm sorry, but... wtf does a socials major in HR know about a highly technical and specialized engineering job? Nothing.

I have a PhD on Embedded device security and last time I went through 3 interviews with HR people before I ever got to speak to an engineer. 90% bullshit questions.

The point of the HR people is to weed out the people who are blatant liars and misfits. They should simply record your responses to trivial technical questions and pass along a score or something for consideration by a more qualified person. You have to imagine that every job gets tons of applications from people with zero experience or credentials, and you don't want engineers wasting time on that.

I can imagine how 1 meeting with HR would help weeding out people for junior and early senior positions with little requirement in terms of CV. You could get a couple thousand applicants there. For sure.

However, I can not imagine a situation that would ever call for 2 or more meetings. Nor can I visualize any circumstance where a meeting with HR would help with highly specialized position hiring.

Once your job description calls for 5+ years of experience, a master's or even a PhD, maybe a certificate or two and even publications on the field, there should not be more than a couple hundred applicants. Not even a hundred to be honest. And every one of those claims can be verified by manual online searches or automated tools. Furthermore, the only way of verifying the applicants actually know about those subjects is a meeting with a fellow engineer.

Just because a job listing demands specific requirements doesn't even remotely mean the applicants will be qualified. Anyone can generally apply to anything, especially in this industry which is so eager to say anyone can get in regardless of qualifications. I agree that one screener should be enough, but maybe it happens twice on occasion because the authorized person is on vacation and they don't want to leave you hanging or something.

>And every one of those claims can be verified by manual online searches or automated tools.

No it can't. There is no central registry of every graduate in the world, and even if there was it would be expensive to have a subscription. If it was cheap to do background checks on everyone, it would be done up front instead of after they decide to hire you.

>then we're going to have to do all 4-8 years of post-undergrad pain and suffering all at once, during the interview, so grab a whiteboard and buckle up!

Even in academia, I think this view is counterproductive. We shouldn't be imposing suffering on folks just because that's how it's always been done. I prefer to take a different approach: give people every chance to make themselves look good, and see if they're able to capitalize on the opportunity.

I think "job talks" could have a useful place in industry hiring. Ask interviewees to prepare a 5-minute lightning talk about any technical (or technical-adjacent) topic they want, and open it up for Q&A from the panel afterwards. This is a way both for the interviewee to set the stage on a topic they're confident in, and for the interviewers to gauge the applicant's communication skills and technical knowledge.

Kind of an unpopular opinion, but we should create a formal certification system for developers. Not something like a license to code, but something more like a professional organization where to get in you have to do all the BS that you get in interviews. This is how it works for lawyers, doctors, accountants and other professionals. Imagine doctors going on job interviews and being asked trivia questions from high school biology like draw the Krebs Cycle on a whiteboard. It's ridiculous. If we could get the BS out of the way, job interviews could be more about finding out what an individual can bring to the organization. Everyone would be happier.

But does it work like that for other professions which also don't require a formal degree/license? Also how it would work world-wide or do you mean a national one and bar expats until they pass it?

For doctors and lawyers one may need to go a long mile to get necessary paperwork done in order to work in another country

What certification could do is ensure a bare minimum level of knowledge. You wouldn't be able to skip the interview, but you could shorten it and not require ridiculous things like FizzBuzz and "write a 'for loop' for me". It's not a silver bullet.

Triplebyte tried to do this, but apparently companies were only skipping phone screens for those candidates, not interview rounds.

There are professional certifications for engineers, which are common in UK and Europe.

For example, INCOSE for systems engineering. Ladder is based around 3 career steps: book knowledge; ~5 years experience; senior roles on major systems. Qualification depends on documented experience, reference systems, review from within the community, and interview.

https://www.incose.org/certification

Interviews are inherently subjective and for _some_ people it is easy to slide through. But how easy is it to slide through those other "gates". Gates that have developed, and have been tested, over long periods of time, longer than the idea of "tech dev / coding jobs" has even existed. The question to ask IMHO is what role does the "free money printer" play in whether someone calls themselves "successful". Is borrowing money "success". It is success in borrowing money.

No doubt, software developers without degrees have been very successful in borrowing money. And burning through it.

What you're really asking is "What role does the macroeconomic climate play in whether someone finds themselves successful?" At the end of the day, you might be very talented and be a failure because you didn't find a job in a reasonable time frame. That could mean competition was too high for too few jobs, at least at acceptable wage levels. Of course your failure to get a job does not mean the escalating job standards are necessary or reasonable, it is just what the market demands and what we have chosen to tolerate in this industry.

> Richardson also encourages hiring and engineering managers to test candidates on collaborative problems during live-coding tests, instead of simply observing how an engineer is working alone.

This can be just as terrible as a twelvw-hour take home. Having a stranger state at you while you're trying to code under pressure can make some fantastic programmers into deer in the headlights. Unless your company only works that way you should have this kind of test only as an option.

I think one of the most trying things that ever happened to me was when I was working on a time critical task and my manager suggested I switch to the desk besides his for the time.

It was really distracting to have someone checking my screen all of the time, which is why I remember this episode right now. Even worse, no 15 minutes went by without him breaking my concentration by asking a question or making some vague suggestion until I politely but firmly told him that I really need to be able to concentrate if he wants the job to get done on time, and that he isn't helping.

Collaboration doesn't have to mean staring at someone while they're trying to code.

Collaboration in actual programming work tends to be up front in figuring out together how a problem will be solved, as needed while working through the problem, and then review at the end. A coding interview can be structured in a similar way.

I am suprised anyone still gives out take-home coding assignments as part of the interview process. I have been hiring for 15+ years and have tried this approach many times. While long time ago maybe it did help a bit even then its usefulness was questionable. But last few years I am quite convinced it's the worst thing you can do as part of your hiring process, as it dramatically worsens your candidate pool and makes it harder to sift through.

The basic premise of take-home test is that it is meant to entirely eliminate the bottom percentile of your candidate pool at the cost of also eliminating a chunk of the top percentile (which is supposed to be an acceptable trade off, especially if you are hiring for junior to mid roles). But I found it does not eliminate bad programmers at all. In fact, after we did some in-person interviewing we discovered a negative correlation between take-home test score and actual coding ability. Most likely explanation is that those with really good scores are the ones who paid 50 bucks to some comp-sci prodigy from <random_country> to sit with them in screen share session for an hour. In contrast, those with poor scores are the ones who actually tried to do the test honestly. Another unintended consequence here is that your candidate pool now has a higher percentage of unscupulous people than it did before the test. Our conclusion in the end was that we still have to test the coding ability in person, which means take-home test does not really eliminate any work for us as part of the interview process, but imposes additional costs as per above.

Are tech job interviews really such a nightmare? Compared to other professions with similar pay? Leetcode can be a bit annoying and unrealistic, but it's not the end of the world, it just means putting in some study time before interviews.

Jobs are also becoming better and lower risk. Many companies have gotten rid of the one year cliff on RSUs so you can potentially take a job that doesn't work, leave after 10 months and get 9 months of equity. That's a huge win when a lot of these roles have been half equity and you used to get zero.

Entry-level and non-senior positions have truly hellish interview processes. Five-six interview stages, week+ take-home projects, ghosting, zero-feedback. Large number of companies interviewing with no intention of hiring. This is absolutely worse than other professions, I've recently made a bit of a career change and the interview involved one informal conversation, and my past experience/education was actually taken at face value.

That mirrors my experience. Recent interviews have been mentally challenging because the other person was poking hard at the limits of my knowledge, but the process itself was easy.

Example question we spent half an hour on: Tell me a decision you made at your last job that you would do differently now. That opened the door to a million roads. Is candidate self-reflective? Can they admit mistakes? Was the mistake a reasonable idea given limited knowledge? How deep can they go with their explanation? Can they explain their work to others?

That was fun because it let me show what I can do, and it would be damn near impossible to bluff one’s way through. It beats the hell outta take-home exercises or “let’s say you’re writing a program to calculate the volume of a lake…”-type coding tests.

I always ask those kinds of questions. I also ask what people are proud about.

But I rarely get good answers, it's always some generic answers like "I built software for the company". Some people even fail to remember anything.

Interviewing is hard :/

I’ve been on the other side of the table my share of times, and it’s so hard. I think that style has lots of signal, though. I don’t really wanna work with someone who can’t describe something they spent the last 2 years working on.

Cheers for Team Grown-Up Conversation!

Yep, totally agree. I feel the same as you.

The problem I see is that the things that I'm most proud of (that had the most value for the company) aren't necessarily the things that are likely to get me a job. E.g. by far the biggest impact that I've had at my current company is not any of the code that I've written; it's having interviewed and recommended for hiring several developers who have become top performers. The second biggest impact has been reforming processes that didn't bring value and killed moral. In fact, actually coding has been one of the smallest areas where I've contributed to my company.

However, saying all that isn't going to get me a coding job. It's all about how many tickets you completed or at best features you implemented.

No, that’s exactly the kind of thing I’d like to hear about! Show me that you can think about those million things beside writing code that make you great to have around!

Exactly.

It's great knowing those extra talents beforehand.

One developer I hired also does Figma designs. Since I also do, I decided to hire them and we now do the designs ourselves.

> it's having interviewed and recommended for hiring several developers who have become top performers

That's actually a great answer.

> Some people even fail to remember anything.

This is me. Part of the reason is that there is a never-ending torrent of problems that need to be solved. You've got this really tricky issue sorted out? Great, there is more stuff waiting down the line. This doesn't leave room for remembering and acknowledging the significance of things.

However, there are some things that I actually am proud of, now that I think about it. But these are the moments, when I'm able to help a coworker with some technical obstacle and I've solved the issue within a few minutes because it's easy for me to see what's wrong. It's the exact opposite of a herculean effort but it causes a huge relief for my coworkers. But is this something that a recruiter would want to hear? I doubt it. They are more interested in me taking care of my tasks instead of the tasks of other people.

If I suspected I could hire someone that would never write a line of feature code but could make everyone else on the team 20% more productive, I’d hand-walk their application through HR.

Have you ever considered specializing in platform and tooling work? Become the office hero!

Not your parent commenter. I considered it many times and with time became a tooling expert in many, many CLI areas. It's rare for me to be asked "do you know of a CLI tool that does X and Y?" and for me to be unable to answer. 1 out of 20 times, probably.

Problem is that nobody wants to pay only for that, or I had a really shitty luck and didn't make a special effort to find better companies (reflecting back, sadly both are true).

So wherever I worked, I was the senior dev + the tooling expert everyone was asking advice from. The latter part became like a hobby that I never managed to monetize.

Minor things are better than the super popular "I helped create a blockchain app that served 2 billion users and moved 5 trillion dollars per day". Those I legitimately don't care for, and the other answers must be good to make up for it.

Disorganized answers are fine. Technical interviews are a place to talk shop. Run away from interviewers looking for perfection.

Recruiters forward the answer to us, so at least in my case the more techy the better.

Come to think of it, the best intern I ever worked with was hired after an informal "talk shop" chat with the CTO.

On the other hand, the worst I had was hired after going through a convoluted process.

Problem is, informal chat makes it difficult for certain candidates that lack people skills.

> informal chat makes it difficult for certain candidates that lack people skills.

I think that's nearly right. If it were just a people skills issue, then a "failed" informal chat would be a valid reason not to continue with a lot of candidates--people skills are much more important than widely thought in programming, and doubly so for entry-level engineers whose early work is largely going to be learning/pairing/correcting.

However, informal-chat-with-the-CTO filters are made unfairly difficult for the kinds of people who would not find themselves with quality face time with the CTO, which is a much bigger problem: remote candidates, non-native language speaker candidates, disabled candidates, and candidates at the "far end" of the funnel--people graduating from no-name colleges distant from the employer with no network connection that they could parlay into an informal chat.

And that is a problem for informal face-time as an interviewing practice.

Also, "informal chat" style interviews (at least those without quantifiable scoring) can be fraught with bias. Did the CTO "like" the chat with the candidate because he was measurably technically qualified, or was it because he was a lot like the CTO in many ways, and their personalities gelled?

Good points.

But on the other hand, I enjoy working more with people whose personalities and style also gel with me. So I don't really know if this is that big of a problem.

Communication is very important, and this is half the battle.

EDIT: But to answer your question: it was for an internship position, so an informal "talk shop" chat was more than enough to measure what we wanted.

Normally it takes a few rounds of technical interviews to get actual information from people who are less, let's say, "passionate". What would be better was if everyone could be as open as this person, so we would be able to just have the chat, instead of having technical questions and long interviews.

In this case it was someone who applied for a position and then asked to come to the office for a visit.

But you're right that it excludes people working remotely.

The two people who made us end our internship program actually aced all the technical tests. But they were so terrible at communicating that we decided that it wasn't worth it having interns.

10 years ago it was usually 1 hour discussion with a hiring manager and the team. Worst case a FizBaz question. Now it's 5-6 interviews that involve leetcode or fairly long/complicated programming tasks (and sometimes take home test). I think it's just ageism, we have too many developers with family obligations and they are pushed out of the market because they can't spend doing 6 hours of leetcode preparations after 9 hours of day job.

I think it's unintentional ageism, but that's definitely what it becomes. The fear is that people had gotten pretty good at one-hour discussions and FizzBuzz that a lot of inexperience was getting through the funnel. But the current state of things is absurd; grinding leetcode at 45 for an engineering manager position had me questioning my life choices.

That’s not historically true. Last time I was heavily interviewing was around nine years ago in the Boston area, for principal-level engineering roles. Standard procedure then after passing a technical phone screen was three or four hours of onsite interviews with various peers/managers - usually two whiteboard coding exercises, one system design, one to talk about my background and past work. That was common across public companies, pre-IPO startups, and even small consulting shops.

I don’t think it was a new practice at the time.

> 6 hours of leetcode preparations

Anyone who needs that much 'preparation' is likely not a target candidate for the job.

It is either unintentionally/intentionally designed to be left unfilled or only meant for recruiting literal geniuses.

If it's being awhile since graduation that is about an average time people spend on leetcode from me talking and reading about it. But again some people spend 10 hours for a month and some 2 hours per day for two years.

Non-target candidates can still get recruited via chance and happenstance but that doesn't negate the principle, it's not meant for cramming.

It's like cramming for an IQ test.

Let’s compare. I’ve interviewed for and been offered both high paying tech jobs and investment banking jobs. My interviews for tech really required me to have a deep understanding of the technology and how to solve problems with it. They tested my critical thinking skills. For banking, sure there were some technical questions but a lot of it came down to what school I went to, how I acted, who I knew. I suppose either one could be a “nightmare” depending on who you are. I do think the tech interview process was much better at hiring generally competent people. There’s also consulting which I have not directly interviewed for but the interview style is more similar to tech with more of a focus on mental math, those can be very difficult if you don’t have that skill.

> Are tech job interviews really such a nightmare?

They're awful and I avoid interviewing at all costs these days. My current employer is going to have to fire me to get rid of me because I'm not willingly putting myself back into that meat grinder.

Part of the issue is that there is no real standard to these interviews and the interviewers can have widely varying expectations at times. I once failed a technical interview on a coding question, not because I did not give them the optimized answer (I did and the interviewer even acknowledged it) but because they wanted a one liner rather than a full explanation of the algorithm. I guess I should have known to ask them about that before diving deep? But to be honest, I have never had an interviewer want the 'one liner' answer to one of these DSA questions before. In the end I was rejected and lost 4 hours of my time to their elongated interview process.

How do you know why you failed an interview? Do recruiters share that detailed from interview feedbacks?

I know I failed the technical interview because the interviewer made it clear during the interview that my approach was not the answer they were looking for.

> Are tech job interviews really such a nightmare? Compared to other professions with similar pay?

What other professions have a standard lengthy process with multiple rounds of interviews even for interns?

Most positions with comparable salary to software dev involve interviewing with a hiring manager, a VP/director skip level, and usually a ‘behavioral’ interview which is often with an HR person. Take-home problems like doing a competitive analysis or preparing a presentation are common.

The big difference is, for a position in a softer nontechnical role, there aren’t any remotely objective criteria the interview can possibly assess you on - if you hate being tested on your technical skills, consider the alternative: being asked fuzzy ‘tell me about a time when..’ questions, and weird ‘if you were an animal what would you be?’ popquizzes by an amateur psychoanalyst who thinks they can get deep insight into you by watching your body language.

You also get judged a lot more for your looks in nontechnical roles. For example, if you're doing sales, simply being attractive could be a huge advantage. It makes sense but it also sucks if you aren't in that category.

"Are tech job interviews really such a nightmare?"

Yes. It's not just about the leetcode questions - the entire process of interviewing in tech these days is Kafkaesque. Interviews with half a dozen people or more, take-home assignments, radio silence for weeks... and then it's not uncommon for them to pull the req and have to start over with another company.

Last year I did a rush of interviews with a company, kept being told I was a top candidate, etc., "we should have a decision next week" every week for five weeks, another interview, a "we should have a decision next week" again, and then... the req got dropped. About six weeks later they opened up a different role that was also in my wheelhouse with a different manager, but... they wanted me to do a homework assignment that meant spinning up AWS resources to try out their thing and write about it, which required a demo signup (which went into /dev/null because they gave me the wrong link), etc. Finally I decided "eff this" and dropped out of the process.

"Jobs are also becoming better and lower risk"

I guess that depends on what you consider risk. I consider having to switch jobs frequently a risk in and of itself, because I have a family and need the insurance. When you switch insurance frequently, expect pain. "Oh, we're just going to deny your claim because we 'think' you have other insurance, we see here you used to be insured by..." (Not to mention starting from zero with deductibles.)

To sum up, yes. Absolute bloody nightmare.

> Are tech job interviews really such a nightmare? Compared to other professions with similar pay?

Yes, much worse. The main problem in software is that companies don't value experience at all, you're always interviewed as a fresh grad with endless leetcoding.

Compare that to say an experienced surgeon. From some I know, interviews are about cultural fit and trying to convince them to join. Their career experience is already proof they know how to do the job.

If doctors had to interview like software engineers, a heart surgeon with 20 years experience would be told to do a hip replacement (you should remember how hips work from medical school!) with one hand tied behind their back and only allowed to use a scalpel. And then mocked for clearly not knowing anything about medicine.

If software engineers had to train like a surgeon, they would have an additional 4 years of school, then 5 years of on the job training where they frequently work 80+ hours a week (for less pay than new grads get today). They would also have to apply for the training and the vast majority would not be accepted.

Tech interviewing really sucks, but it is still far easier than anything a physician goes through.

> Tech interviewing really sucks, but it is still far easier than anything a physician goes through.

Except doctors can go through that once, when they are still young and then they're done with that part.

Software engineers need to do the leetcode dance every single time for their entire life. Which gets harder and harder when you have a family and then kids.

Its 7-11 years of additional school, exams, training, and internships. You often work 60-80 hours a week. Most have to move across the country more than once, and apply at every level to work in the field they want -- most are rejected outright at the start, and many won't get into the specific field they want -- ever. I graduated medical school. It is incomparably more challenging than software engineering interviewing. I get it and agree, it really sucks, especially once you have kids. But trust me, people that struggle to survive the leet code grind are most likely the people that would not get into something akin medical school to begin with.

The other thing is most employers of surgeon's are highly reputable and held to regulatory standards. You kind of know what the minimum quality bar is for someone's employment. Compare that to a random tech company and realize there are people out there who have the same one year of experience twenty times and you start to realize why we have more rigorous interview vetting.

I kind of feel like the alternative to interview processes that evaluate in depth is top employers only hiring people with extremely reputable companies on their career trajectory and I feel that would be a loss for many people in tech.

> the same one year of experience twenty times

I dislike this meme and how it's supposed to be bad somehow.

That heart surgeon with 20 years experience? Yes, been doing heart surgeries for 20 years. That's a good thing.

We don't ask surgeons to switch to a different body part every year so that they can avoid having multiple years of experience in the same thing!

What would you call someone with 20 years experience in 20 different things? A rank beginner in all of them. That's not a good thing.

If I need someone with experience in something, I want the person with the 20 years doing that thing.

> Broadly, the US job market is still strong, with the unemployment rate at a low 3.7 percent.

No, it's not. Unemployment rate is a bullshit metric and people need to stop relying on it. It measures the number of people collecting unemployment benefits, not people who are unemployed. Labor Force Participation[0] is a better metric. Since Jan 2000, the US is still down nearly 5% participation. And since COVID, we're still down nearly 1%.

[0] https://fred.stlouisfed.org/graph/?g=1hY50

The article didn't really address why the interviews are "such a nightmare", other than insinuating that the balance of power has shifted to employers.

Worse still, it pretends that interviews only became nightmarish last year, and everything was great up to 2022.

I will say that brutal, annoying many stage interviews used to be more common at FAANGS, with your average shop usually just having a whiteboard interview and 1-2 phone screens. I think the thing that's changed is that with the influx of all the laid off FAANG engineers, non-FAANG shops have started being more picky/asky.

I've been a manager in software development on and off for the last 20 years now, and to echo what many of the more experienced managers here say, interviews at best give you some negative signals, but very rarely anything that I would consider a hugely positive signal. At best, I've quite gotten along with a charismatic candidate, but in my own career, even this has little correlation to people that I liked actually working with.

That being said, I think that a candidate's work history and general questions is good enough. In my experience, it's been painfully obvious everytime someone is bullshitting (or at least I think so, I never hired those people), and I haven't had any experiences where I've hired anyone directly that was a true disaster. Of all the people I've managed, I've had to fire very few, and in the cases that I did it was entirely unacceptable office behavior that led to the dismissal, and it also should not have been a surprise to anyone involved.

That isn't to say everyone worked out perfectly every time, but as a manager, I've been able to address most of those situations (and in the cases where I couldn't, it ended up being some of the very few dismissals). Approaching people who work with me with the benefit of the doubt has broadly been more successful. I address problems as something I want to help people fix, and not as something to be punished. Of the 50 or so people I've directly managed at this point, there's only a handful I wouldn't work with again.

I have a theory.

1. Interviews are hard. Hiring is hard.

2. The best hires I've personally been involved in have been personal references, not blind hires.

3. The need of FAANG-class firms to scale, and to churn (rank-and-yank), means they have to hire a LOT -- far more than personal references can supply.

4. But they still don't want to hire duds (except, of course, in the case of the egregious unethical and cruel "hire to fire" brought on b/c of rank-and-yank).

5. So they create a Process -- an Algorithm, if you will! -- and then keep adding steps and attributes and whatnot over time.

6. Eventually this Process resembles any other long-running, poorly-expanded codebase.

And here we are.

https://archive.is/TrQPt

HR is the problem especially as organizations grow. People in HR are some of the worst. I equate them to used-car sales. They end up hiring mediocre brown-nosers because they tend to have longer tenures and this gives HR better performance metrics. And that also works out for mediocre staff because they don’t want to be exposed. This dynamic creates a long-term loop within the organization: mediocrity hell.

I wonder if articles like this and the candidates they interview are simply focusing on the top tier FAANG level companies, which are going to always be nightmarish. And so we are not getting an accurate picture. From what I know, smaller engineering firms or software shops, maybe in smaller cities, and lower pay, have 2 round interviews and don't always even require coding during the interview.

I know of no other fields (correct me if I'm wrong) with multiple employers hiring many people at > $150K/year less than 5 years out of college. That leads to an enormous number of applicants (Google gets > 3 million per year), and the necessity of stringent gatekeeping. Any hiring process in big tech will by design drop at least 95% of applicants.

This is a valid problem to point out, but white board does not solve this problem.

In fact it may be causing more noise than signal, resulting in candidates passing hiring committee + receiving offer, then spending many months in the team matching phase, bc no candidates don't meet skill + exp fit with teams that have openings. [1] That plus high short term attrition makes for a busted hiring process.

[1] https://www.teamblind.com/post/Google-just-got-easier-no-mor...

Is it really a “nightmare” to have to endure a take home test and 5 hours of interviews for a job that will pay you like $250K/yr to start? Guess what, plenty of people want to do that job, and people aren’t going to hire you just by looking at your resume and having a quick conversation. If you don’t like it, great, less competition for the rest of us.

How many of us do you think are actually starting with $250k and land the job with just 5 hours of interviews? You are also excluding the amount of time it takes merely job hunting and jumping on call screenings before even getting to an interview.

Here's the thing about take-home tests. Let's say I put 5 hours into it. That's all right, if I get the job. But let's say I don't. I don't get the next one, either. Let's say it takes me 20 tries to land a job. Well, that's 100 hours just on take-home exams. That's 2.5 full-time weeks on take-home exams.

So, no. It's a nightmare, and it's one I won't subject myself to. I mean, for one job, I might if I really wanted that particular job. In general, though, no. Just no.

See, with an interview, if you waste my time, you also waste your own - you have skin in the game too. But if you give me a take-home exam, and I spend 5 hours on it, and you never look at it, it costs you zero. Or you give it to 30 people and spend two minutes looking at each persons' results. You can waste my time without wasting your own. And I have a strong suspicion that interviewers do in fact waste applicants' time with take-homes. They don't bother to be efficient with the interviewers' time.

Almost nobody gets $250K annually even if senior, and 5 hours is a gross underestimate of the total time spent per interview process.

With such a wrong premise your argument does not hold weight.

Risking a visible failure hiring a bad candidate, with no reward for hiring a good one, managers defer hiring as long as possible, preferring candidates with credentials or people they know.

"It's not what you know, it's who you know."

In general places are hiring but so many people were put into the market at the same time causing a lot of competition presently. A very different dynamic to previous years to be sure.

There’s also a lot of roles that rely on technical skill sets like sales engineering, consulting/services, product management, support, etc. Sometimes broadening your horizons can lead to great things too.

I’d rather have a non-ideal or different role at a great company than what I’d consider ideal at a mediocre one. Remember, once you’re in you can build a reputation and move to other parts of the organization if the role you took isn’t going it for you.

I don't know why you need an article to explain that. Sh@tton of people in IT were let go in the last 1.5-2 years, so every job posting gets a huge number of responses, including from people who are not a good match and in some cases will not even qualify but they apply anyway because they're desperate. So it became incredibly difficult to find qualified people among those hundreds and hundreds of applicants.

Isn't this just people complaining that learning to code will not bring those desired easy replacement jobs they immagined?

Gatekeeping also has something to do with this.

Leetcode interviews are actually very similar to asian country style college entrance exams. Foreign engineers (> 75% of engineers at FAANG are foreign), will spend months studying. Turns out people willing to study like that also make reliable employees that proved they can learn computer science. This to the detriment of regular americans that dont want to prove themselves every time they switch jobs.

As an American, I'd much rather someone else prove myself for me when I switch jobs. I'm willing to be a convenience charge for the huge salary I take home if someone is willing to get it for me.

General opinion I see is that its fine when youre young, but when you get experienced with kids, solving leetcode hards/mediums in 30 minutes becomes a nightmare.

In my experience though being able to learn computer science isn't actually a very useful indicator of your ability to deliver the sort of software most companies are developing. I'd be willing to bet that even within Google or Microsoft there's far more software which just queries a database and displays some results than that which requires actual computer science to develop.

The hard bit of most development jobs is the fuzzy stuff. Working out what it is you're building in the first place. Negotiating on which of those requirements can be dropped to massively reduce complexity. Trying to avoid being talked into building a simple piece of software as eighteen intertangled microservices each with a dedicated team. Once you've dealt with those bits the actual software development is usually easy.

Having done many interviews, I can say that studying that much often doesn't help as much as one might think. Yes, I think someone in industry for 10 years will need to brush up with a few days of revision, and I think that's a bit of a pain, but I've had many candidates who have spent months of free time doing leetcode who can't actually think about an abstract problem, or who can't code their way out of a paper bag when it gets to a more real world example.

My previous place used to have a 3 hour (capped) take home assignment. Most candidates who progressed claimed to have taken ~90-120 mins and finished comfortably (although they were not judged based on this). Over the years a number of candidates went "above and beyond", without asking, and submitted an "even better" solution after 8+ hours. None of them passed, even based on their final submission.

More does not equal better. I think at most FAANG places you need a baseline knowledge, but many people go overboard, and over-fit, possibly because they don't have the baseline ability and are trying to make up for it. There are a bunch of issues with FAANG style hiring, I'm not a huge fan, but I don't think what you've described is the problem.

Completely disagree. I actually think people are generally completely unaware of how much studying is done by engineers passing the interviews at high paying companies. I'm not talking about jobs paying 150-200k. I'm talking at the 350k+ level, people are spending 20 hours a week for 3 months or so.

The facebook interview basically requires perfect memorization of a certain set of leetcode problems. Luck plays a factor as well

And so it sounds like when the article mentions Meta is now offering $50K less, they mean at that top tier level ($300K rather than $350K)

Any source on that number (75%)? Looking up ethnicity stats at Google/Amazon, neither has more than 50% Asians and only a subset of those will be non-citizens.

I doubt Google is publishing these stats publicly for engineering.

I’ve worked at similar public companies and I can safely say the stat they’re quoting is accurate. It really is 75%+ Asian and overwhelmingly foreign born.

These stats are internal only, for obvious reasons.

All jobs have most been like this. Y’all had it right but just had to make it more draconian.

it was google that started the leet code 100 stage interview trend.

cargo culting.

coupled with saturation from learn2code

and rise of the recruiter and hiring manager

stacking layers of bullshit on top of each other.

Because they can.

Reply on news.ycombinator.com