We have FAANG to thank for this. They pioneer counterproductive interview questions (remember puzzles?), and the industry just copies these trends, like zombies.

Then what happens is these Leetcode heroes, never having built anything from scratch in their lives, create a hazing ritual for new candidates.

What is the point of, say, a system design interview asking to design a planet-scale system when most people never came close to one or, again, never built one because they are just out of school?

And, yes, I know - "how would you interview a recent student?".

Fine, I was a student in 2004, so why are we having the same goddamned test?

> We have FAANG to thank for this.

Not entirely, though FAANG companies certainly didn't do anything to help make it better.

I'm 51 and have been a professional software developer since the early to mid 1990s and tech interviewing was already a strange hazing ritual disaster before FAANG existed.

I distinctly remember interviewing for a QA position in the 90's where I was asked how I would test a soda vending machine. I was dinged because I didn't mention that I would make sure the sodas were cold.

Actually Microsoft started this in the 1990s, long before FAANG was a thing. They just all adopted it.

“Why are manhole covers round?” “How many dry cleaners are in the city of Seattle?” were both infamous Microsoft interview questions.

Previously known as "Fermi questions"- commonly asked of undergrads and grad students in quantitative fields.

I think quant finance is similarly bad

The real problem: How you accurately evaluate a candidate without these questions? I dislike them as much as the next person, but I don't know a better way. Literally, all the best tech firms and ibanks do it. They pay the most and are most profitable. They must be doing something right. The real trick is finding a "fractically complex" question with many levels. The one in this blog is pretty good! No candidate can solve it perfectly in the allotted time, but you can have a good discussion about the "edges" of the problem -- where good candidates shine.

How do you accurately evaluate candidates with them?

It's an artificial test that doesn't reflect your working environment at all, and so you're not actually getting to see what they'd be capable of doing faced with real world coding work.

It's a discriminatory practice that is proven bad for a lot of neurodivergent candidates, like folks with autism, or ADHD.

You end up eliminating a whole lot of good candidates just by the structure, and then end up picking up a candidate who happens to do well out of that small subset and it still won't stop you from hiring developers that are terrible.

One of the worst developers I've ever worked with will absolutely sail through leetcode exercises. He's brilliant at it. Something about his brain excels in that environment. If only work was like a leetcode interview, filled with leetcode style questions, and someone watching and evaluating his work as he did it, he'd be a fine hire anywhere.

He can't write actual production software to save his arse, needs deadline pressure breathing down his neck, and then what he'll produce at the last minute (always technically makes the deadline), will probably work but is the most unmaintainable nightmare that needs to be rejected and redone by another developer.

I have had the exact same experience with the exact same kind of person. We used to be in the same team for years and after we collaborated once, I absolutely hated any work interaction related to his him or his work. Outside of work we got along well, he was fine, socially stunted, but that's OK.

When the layoff time came, everyone had to scramble to move by themselves to a small selection of teams. The second I heard that guy was interviewing for the same team as me, I had gotten an offer at that point, I told the hiring manager, me or him. That's how bad working with those kinds of people can be. He ended up elsewhere and I'm still in that team. I just could not deal with him anymore. Perfect interviewer, but couldn't write production code to save his life... He's still employed by the way, bumbling around from team to team because the consequences of his incompetence take months or years to feel...

>> They must be doing something right

What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices. Likely other hiring practices would have worked fine as well.

>> Literally, all the best tech firms and ibanks do it. They must be doing something right.

Reasoning by first principles isn't exactly the software industry's strong point.

> What tech companies did right is found a ridiculously profitable business model. It is not clear that their success is correlated with hiring practices.

Agreed though I'm not sure I'd be as generous as you are when it comes to their business models being that great in absolute terms.

Strip away all the confirmation and survivorship bias and IMO it is pretty obvious a lot of the success of tech in general for multiple decades running was almost entirely the result of the free money lottery system funded by zero interest rates.

It's always

- someone else's money (zirp, middle-eastern sugar daddies, juicy government contracts)

- adverts

I really counsel everyone to stop thinking like this. The appealing to authority doesn't work when you are talking about different sized businesses.

All the best banks and tech firms do a lot of things that could be categorized as wasteful, useless, inertia maintaining, etc, adopting their practices without a thorough understanding if it applies to your business is plainly just stupid.

Your business is not structured like those big business, you are not as anemic to risk as they are (otherwise you wouldn't even create your business in the first place), you don't have their cash, you don't have their ability to spend an enormous amount of time hiring every single person because your profits cushion you from all your dumb decisions.

This is my own experience but I find the evaluation on interest and intellectual curiosity to be more validating long term than being able to rote memorize problems.

Edit: To add some color, I want a candidate who is excited to program, I don’t care as much about their ability beyond having the basics which I find pretty easy to figure out in an initial conversation. Candidates who are excited for the opportunity are generally the ones who I find to excel in the long run.

If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.

In my experience the signal is pretty strong.

Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?

Gut feeling based on the generally very high competence of my colleagues when I was at Google.

I trust they were really competent, but it's a bit depressing that these competent people will need to go through the leetcode rituals and 5-10 interviews to get a new job at Meta, Netflix, AWS or adjacent companies. That's actually the point of the original post; you are never judged by your (years of) experience or even your past companies, only by the results of a test from a random person/company.

I disagree; I don't think a full day of interviews is a huge price to pay for a FAANG job. The stakes are high for the employer, the rewards are high for successful applicants, and if you get to that stage, you've already passed a lower-stakes phone screen.

Put yourself in the employer's shoes: You want a high-quality SWE, you're prepared to pay them top dollar, but if they turn out to be not so great, it's expensive to get rid of them. Would you be satisfied by years of experience at other companies by itself, when you know that (like in many job markets) there's a big market for lemons? I wouldn't. I would want to see the candidate demonstrate some specific skills -- ideally the skills they'd be using day-to-day, but if that's not feasible for time reasons (it usually isn't), then adjacent skills that generally imply (though are not necessarily implied by) them, like recognising the shape of a toy problem, and knowing and applying the right algorithm to solve it.

I am not commenting on the interview effort-salary ratio, but the fact that credentials and experience mean nothing to the tech industry, also comparing to the rest of professions. I mean working in Google/Meta/Netflix, is like working on the best hospital if you are a doctor, in the best construction industry if you are an engineer, to best law firm if you are a lawyer, etc. Imagine having to pass a leetcode or iq test everytime you want to move to the next one. I definitely know that my cousin, who is an exceptional doctor in Greece with only 10 years of experience, laughs about it.

I think it should be the other way round: In an ideal world, everyone, including doctors and executives, should expect to have to demonstrate their skills when applying for a new job.

It's just unfortunate that there isn't (TTBOMK) an easy way of measuring, in a few hours, how good an executive is at executive-ing. Which is why the field is crammed with useless pretenders who nevertheless manage to flit from job to job, soaking up fat compensation packages before their incompetence is exposed.

I'm curious why there doesn't seem to be the same market for lemons for doctors. Or is there? How does a person actually know if a doctor is good?

    > executives, should expect to have to demonstrate their skills when applying for a new job

They do. The interview process is a review of your "wins and losses" (public and verifiable is the gold standard), plus you need to complete some case studies.

That's better than nothing, but not much better -- many people have an outsize ability to "dress up" any arbitrary thing as a win, and in that case what the interviewer is really testing is a mixture of (1) that person's ability to produce wins, and (2) that person's ability to dress things up as wins.

(As far as I can see, there's no obviously better way to interview executives, since in general their actual day-to-day work -- building relationships and making strategic decisions -- takes months or years to prove out, and in any case the outcomes are heavily dependent on external factors and their ability to read them.)

    > experience mean nothing to the tech industry

This is not true. It is basically impossible to hit L7 before 30 years old. A lot of it is indirectly related to experience: What have you accomplished for us. MDs on Wall Street trading floors are similar. It is very hard (nearly impossible) to make MD before 30 in this era.

I am glad that you mentioned Google. At this point, their interview process is legendary. It is so good that many other companies have tried to copy it.

For me too, anyone that does horribly, bad signal. Anyone who does perfectly, bad signal.

I've found that looking for mediocre and sub-par results will give you professionals that spend their time getting good at the profession instead of getting good at leetcoding.

I have never and will never hire code monkeys. AI already takes care of that.

ask deep technical questions and evaluate the response.

I've had better success, by a wide margin, doing this, than any code challenges ever gave.

I don't know why the industry is so averse to this, it really does work, and I know others who also swear by it.

You can find the bullshitters pretty quickly even in this ChatGPT driven world

I think the pushback here is from the following:

1. Because it is so dynamic and subjective, it is very hard to systematize this kind of interview, which makes it very hard to work into a repeatable or scalable process. The need to compare incoming candidates is an unfortunate reality of the industry for many companies.

1b. It is basically impossible to control for bias and things like "was the interviewer having a good day".

2. This kind of interview overly rewards charismatic speakers -- this is partially ok, depending on the role, because being able to speak accurately and cogently about the work you're doing and are going to do is part of the job (especially for staff+ engineering). It isn't necessary for all jobs, however.

3. Many people aren't good at driving this kind of conversation for whatever reason. When it goes well it goes well but when this kind of conversation goes poorly it reflects badly on the company.

4. People Ops want more control then this gives them, across many dimensions.

"Write some code to solve this tricky problem" seems like a deep technical question to me. Can you give some examples of what you have in mind?

define "tricky problem". Given the nature of something being tricky, it could well be too heavily reliant on the 'trick'.

I had in mind the problem given in TFA, but I should have been explicit about that.

I think it's probably too hard as an interview question, but also that it actually is a somewhat realistic problem that I'd expect a senior programmer to (eventually) puzzle out correctly. (As opposed to, say, the archetypal bad interview question, "How do you swap two integer values without using a temporary?", where many people happen to already know the trick, and if you don't, you're unlikely to figure it out on your own in the space of an interview.)

    > deep technical questions

Can you provide some examples?

not OP, but i was once asked from the HTTP layer down to PHY layer (a role for embedded system)

> The real problem: How you accurately evaluate a candidate without these questions?

The fact this question needs to be asked really reinforces parent's point.

Perhaps we should examine at how other respectable fields validate their candidates and follow suit?

If we don't have any form standardization for this stuff, I think that speaks more to the lack of maturity of our field than anything else.

Do other fields really have this figured out?

I guess bridges, buildings and houses generally don't fall.

Is that only due to hiring though? It seems more like physics doesn't change. And people who can do audits and inspections are probably pretty good.

I did an audit for my software at work. It's like talking to a child. Talking to a home inspector is way different experience.

> Literally, all the best tech firms and ibanks do it.

So do all the worst - look at the extent to which hiring this Soham Parekh fellow has become a badge of honour instead of abject failure.

Hiring that guy is a badge of honor because admitting otherwise would be to admit that the interview processes have nothing to do with the job, thus the real incompetence here is with the companies and people following that interviewing style.

Instead of correcting themselves, those interviewers chose to dive deeper into delusion.

Accurately evaluating a candidate is impossible, but surely asking a candidate these questions will yoeld a lower quality worker than if you ask them something related to the work they might do.

I disagree. I always go back to the blog posts that Joel Spolsky wrote 20+ years ago about his theory of hiring. The primary goal is to avoid bad hires. Even simple tech problems can easily eliminate (or rank) many software devs. As someone who regularly interviews candidates, I am blown away how bad are many of them.