Please stop the coding challenges

TFA: Coding interviews are a standard way of hiring.

Also you: “Too many people in the software development industry don’t know what they’re doing.”

The lack of cognitive dissonance is remarkable.

- Cracking the coding interview.

- Elements of programming interviews in Java|Python|whatever...

- leetcode & other sides with paid premium subscriptions...

- mock interview bootcamps...

It's no longer about skill, it's only about gaming the system.

GP is of the opinion that coding interviews filter out people who can't code.

If you've actually worked at a large company, you'd know that 90% of the real work is done by like 5% of people (maybe even less). If the interviews worked this ratio would be so much better.

I’m serious. It’s not even guaranteed you’ll get the job if you do the above but everyone who passed the big tech interviews will acknowledge they fucking studied for it. What do expect here?

If you do the above prep work and pass the multiple interview loops you’re pretty smart honestly. The vast majority couldn’t do it even with all the study possible and even the smartest couldn't do it without any study at all. The bar is pretty high.

How can we even ban them using LLMs in their "ML-leetcode" problem when the problem is on LLM tokenization or something?

Like, if I lose a candidate because they're experts at using cursor + claude to do their coding (i.e. they solve it by writing 3 prompts and filling in 2 errors which are easily spotted in a total of 10 minutes), despite them having NeurIPS caliber publications and open source code, did I filter out a fake grifter, or did I filter a top tier candidate?

I just don't buy that leetcode style problems make any sense for anyone whose doing anything involving LLMs, and like it or not, increasingly large amounts of the cushy 500K/yr FAANG+ jobs will involve LLMs going forward.

And frankly, if they're able to adapt a random leetcode problem to be able to solve the coding test that I give them, then that's exactly the kind of adaptability that I'm looking for in a prospective software engineer.

"I want to work for your company"

"Ok, prove yourself"

"Sorry, I don't have time"

How do you expect that conversation to go from there? If you don't have time then make time. It isn't anyone's problem but your own.

The companies ask that candidates learn how to solve algorithm problems and the candidates do it.

I would call it “everyone playing a game they agreed to play by the rules they agreed to play with.”

And I don’t know what you mean by “it’s no longer about skill.” It still takes a lot of skill to be able to solve hard algorithm problems, even if you took a course on how to solve them and practiced solving them for 6 months.

When you audition for an orchestra they give you the sheet music ahead of time. It doesn’t mean you have no skill if you practice first instead of just showing up to sight read the music.

I've seen interviews where you actually have to present a thing you've done and then explain the decision making process behind it, tradeoffs, outcomes, etc. those are more common outside of CS and I'd like to see more of that in CS. Or hell, have them write an essay describing the tradeoffs about some theoretical engineering decision. That'll give me actual info on how a person thinks.

For context, I used to work in self driving cars and had to interview many people who claimed to work in that field and claim to have worked on huge projects themselves. Then you dig deeper and it turns out they were part of a huge group, they never heard of this problem, that problem, never heard of this industry standard, etc. it's like, forget coding, this person doesn't even know the domain as much as they claim and not being upfront about that disqualifies you immediately in my books.

No talking (other than me showing them how I fixed it). No bullshit questions like "where do you see yourself in 5 years" or "talk to us about your strengths" etc.

Second best - they asked me to design and write pseudo code for a simple system. Don't worry about syntax, but make sure to follow good design practices, within reason. Gave me a pen and notepad and left me alone for an hour. I wrote it, explained my thought process, they made an offer.

Then I had shitty interviews - one very large, very famous insurance company - they had 5 rounds of interviews back to back, for a normal developer role, lol. Asked me about some obscure options for grep etc. It was an exercise in them showing off their skills (more like their memory of Linux commands) than learning about my skillset. I couldn't wait to get the hell out of that building.

Of course interviews can't be light when you are hiring for highly technical, high critical positions (like security, for example). But for most software dev positions, the formats above are very efficient. Most software devs are writing "glue" code, not rewriting some mission critical real time OS.

Loonnnng time ago (25+ years) I remember appearing for an entrance exam of a very famous, hard statistical course. It was a 3 hour exam, with only 7 or 8 questions. The exam explicitly stated that they do not care much for the actual answer, but the path taken to get to the answer (all questions were math problems). As a kid this sounded weird to me, but now it makes sense. Someone with good problem solving instincts will get to the right solution (even if it takes a couple of attempts to get there) vs someone who got lucky the first time (or brute forced their way)

LLMs are another great example

Pretend I was hiring a restaurant chef and the industry standard test was "run a mile in 4 minutes", a test that 98% of all candidates fail!

So professional chefs practice by jogging daily so they could prove themselves during the famous "run a 4 minute mile" weeding test so they can be hired to prepare meals for people.

That's what we're talking about here. I've had to write out the mathematical proof of various algo complexities of B* trees exactly 0 times when writing SDKs for some CRUD application but that's what's expected during the interview.

It's as correlated with the ability to do the job about as much as running a 4 minute mile in that younger, more desperate, easier to control, and thus cheaper people can do it better. That's what the actual filter is for - to find candidates that are easier to abuse and take advantage of - smart enough to do the work and foolish enough to take the job.

I've hired large teams at multiple companies where such tests were used and that was exactly why we did it. We didn't want the experienced 45 year old wanting to work 40 hours with vacation, we wanted the foolish 25 year old that gave us their weekend.

Actually saying that is illegal, but using a stupid test that selects for it is not.

"But this isn't relevant to my job, a subordinate will always do this kind of stuff."

"We are a fine dining dinner restaurant, I'll never need to make an omelette."

Doesn't matter, make a damn omelette. If you can't, you aren't suited to be a head chef, or any other kind of chef.

Knowing basic data structures and algorithms and having problem solving skills is absolutely critical to a software engineering job. In fact it is the entire job.

outside the geography where the salaries are an order of magnitude less, we yet go through the pain because of companies copying each other's approach.