[anonytrary]

I'd wager that 90%+ of "tech" companies are hiring software engineers to "solve" technical problems that have already been solved in order to solve business problems that have not yet been solved.

Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.

[q-big]

> Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.

If this was true, it would bring a significant economic advantage to a startup if it would not use leetcode style questions for job interviews, but instead ask hard questions about these textbook architectures.

[YZF]

But someone might be able to answer the questions but not be able to build stuff. The coding portion of an interview is supposed to answer the question "can they code". If they can't code I don't think they can work in either domains (reapplying an existing technical solution or inventing one that doesn't exist). I'm not a fan of some styles of coding interviews but writing code needs to be part of any interview for a software developer (+ a lot more).

[manigandham]

Writing code in an interview is not the same as the "leetcode" riddle questions that the parent poster was talking about. It's usually esoteric language and computer science concepts that are not very relevant to the job role.