> This is bullshit. Let me explain why. Hi, Jason here, CTO of CoScreen, and author of this article. Thanks for your candid opinion Richard. > The reality is

> This is bullshit. Let me explain why. Hi, Jason here, CTO of CoScreen, and author of this article. Thanks for your candid opinion Richard. > The reality is that the Leetcode style coding interview, as we know it today... I'd love a guide, or other details about how to best pose a "Leetcode" style interview, and refine it. It sounds like a lot of work, but I'm sharing my personal experience interviewing engineers over the last 20+ years. I don't pose just hackerrank like challenges as the only method, but also whiteboard/and ad-hoc in person interviews. I'm willing to believe there are ways to get better results using these async type methods. But, for my last several companies, including being in management/hiring positions for several startups, I have found them to be very poor at predicting on the job performance. > In the author's eyes, he thinks that more weight should be given to the soft skills. I never stated this. I'm not sure where you are getting this from. Being able to read code isn't a soft skill, nor is being able to navigate large code bases, debug, read documentation, and research. Absolutely these are skills that you can learn on the job, but not by any means easily. > And different companies have different needs. When you're a startup, you need to code fast and quick, ship the product, and iterate. I definitely agree with this. > That's what allows companies to be efficient with their hiring: people are interchangeable. Have you been working for software companies where you found engineers immediately fungible and replaceable? This is really different than my own personal experience. > And how could you do this effectively at scale without screwing over your own company's resources (again, think startups. Only so many engineers to go around.) My experience hiring has primarily been for startups, and in both Director/CTO, and other positions, have had to spend an inordinate amount of time hiring developers. Scaling to three, or four engineering hires isn't difficult for a startup. The cost on the other hand, to the point I made in this article, of making those two or three hires bad hires, is extremely high. > without going into Leetcode would be the company to put a probationary period on new-hires. Most good programmers are gainfully employed, and won't agree to a probationary period when being hired... Why would they leave a stable role for one that is tentative --- I wouldn't... I think the onboarding project (could be paid/contracted) like I suggested in the article, as well as a pair-programming session, is what I am suggesting here. You could think of it as a commitment free probationary period on both sides, without requiring the engineer leave their current position. > But if a bunch of smart and successful engineers can consistently land offers, then why can't other smart and successful engineers? I'm not sure, really, I'm just offering advice for startups, like mine, that is earnest and based on my own experience. >Leetcode interviews and his thesis would actually screw over smaller companies. I don't really mention leetcode once in my article, and mention other forms of traditional interviews--- like in person whiteboard interviews... I call out doing hackerrank challenges. I'm not sure why you're so focused on leetcode. If I would have based my hiring on hackerrank alone, I wouldn't have hired one of the best engineers I have worked with in my career. These coding challenges really don't prove competency in software engineering, again in my personal opinion, based on a large amount of experience in this area. It's fine for you to disagree with that, but as the Dude would say: that's your opinion man.