I am sick of LeetCode-style interviews

This isn't working hard. And you are competing with the people that are working smart. Such as people having a separate computer/screen to either look up the answer to a problem or ask an LLM to regurgitate some code you can transcribe. It selects for people that are dishonest.

> 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question)

See above. A lot of the problems have nothing to do with real world coding scenarios. Do I need to pull out memoization and know how to work with grammar rules off the top of my head? Or the functionality of quad trees and how it applies to partitioning? No; I've literally never used them in my career and likely never will. What I do need as a software engineer is understanding the high level concepts and when to apply them and refresh myself on the use case when and if appropriate.

It leaves out looking at the engineering skills it takes to put something past the finish line on budget.

It's at best, an adjacent sideshow and at worse a proxy for ageism to preference people closer to 19 and less capable at getting quality software out the door.

And maybe that's why the industry has such a damn hard time getting quality software out the door.

Maybe.

Here's a far better idea. Give them a broken build or crashed code or some other failure and ask them to fix it. If they can navigate around a system, diagnose a defect, find the cause, offer a patch, and match the coding/commenting style etc, that's an actual player you need, not someone who can still solve an algo question from their CS101B midterm exam at 37.

This version can go deep as well. You can have separate branches and an issue tracker, maybe with the conversation of the bug already going. Maybe the comments have a patchfile that needs to be manually applied. Maybe the patch has a new bug in it ... Perhaps it's a red herring and addressing a similar but unrelated issue. Maybe it's a closed bug and a regression and nobody wrote a unit test for it. Maybe the unit test is there and it's up to the candidate to discover it or the unit test is out of date, buggy and useless.

This is the real stuff.

Get them to communicate after. Saying something like "the unit tests were broken" versus "I was unable to understand how to get them to work right so I moved on" ... That's a huge difference in attitude - only one of them is a team player.

A while ago I posted a Ask HN question about the usage of Pseudo-IQ test which is very common in Swedish interview process. Pseudo-IQ test in the sense that it is almost always just Raven Matrix test + maybe math or personality test. I tend to score pretty well on those tests and it takes maybe 1h tops, but it's annoying and stressful either way, especially knowing what ideological foundation it comes from....

Seems like the answer from the Ask HN point towards that those tests used to be common in US/SV/Software position interviews too, but it then got kinda replaced by Leetcode-style interview.

And sure, having a person staring at you commanding you to only use your brain to solve a toy problem is definitely not how you work. But it in combination of a bit of back-n-fort traditional interviewing is definitely more informative to the employee (and fair) than some pseudo-IQ test.

I just hate when Leetcode is used as *the first screening* it's such an asshole move that show high level of disrespect towards the applicants time. Maybe you can get away with as FAANG, but small companies that do this to me just signal extreme arrogant (or delusional/dysfunctional) HR or C-suite.

The best coding interview I've had is just the format "You've received a PR from a junior dev. The code compiles without error and pass the unit test. Would you pass/reject this PR and motivate why" and it often requires a better understanding of the language (such as difference between modern C++ and C++12)

Many companies have question banks that are specially designed to be fair/have some contextual relevance (ideally) to some "realistic" problem. Or at least, many of the companies I've interviewed at follow this model. I consider these coding questions to be "leetcode" style because at the end of the day they are an isolated coding problem, even though they may not be a problem from leetcode verbatim.

Companies that execute on that style of interview well are generally fairly pleasant interviews, at least in my experience. Good companies/interviewers will gauge more than just the final code to determine a hire or no hire. And a large portion of companies also have hiring ratings on a scale to make it less binary.