"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup And so it is with interviewing techniques.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup And so it is with interviewing techniques. You say "[leetcode] interview processes are not the only way," which is of course true. But it is also true that all other interviewing techniques are also unpopular on HN and with programmers in general. Of course each programmer has one or more techniques that they prefer, but there is no single technique that has even simple majority support amongst engineers as a whole. Let's review some common techniques and what HN would say. NB: not expressing my opinion on any of these, just compiling common complaints you can find in any HN thread about interviewing. Leetcode problems: rewards rote memorization over real ingenuity, not relevant to job, high stress. Take home problem: company not incentivized to respect candidate's time; bias towards candidates that are unemployed, not engaged at current job, or otherwise able to devote large amounts of time to the task; easier to outsource; basically asking candidates to "work for free" Review of github profile, OS projects, blogs, etc...: bias against candidates that "have a life" and don't program 24/7. Discussion of previous work: highly subjective, susceptible to frauds and/or exaggerators, prone to false positives (complaint usually phrased in a form like: "we did this at my last company and we hired a bunch of people who couldn't code.") “I don't know what the l̶a̶n̶g̶u̶a̶g̶e̶ interview technique of the year 2̶0̶0̶0̶ 2030 will look like, but I know it will be c̶a̶l̶l̶e̶d̶ ̶F̶o̶r̶t̶r̶a̶n̶ unpopular on HN.