Coding Interview Criticism

Been interviewing for over a decade. Tests like this do not really tell you whether someone is a good programmer, they tell you whether a person has spent a lot of time practicing problems like this. The only way to tell if someone is good at the job is to have a conversation with them and pay attention to how they answer your questions. Ask your candidate their opinions on API interface design or whether they favor mono-repos. A good candidate will be able to speak legibly and at length about t

coding interviews do not test what matters.

the point here is that not everyone goes through the same recruiting process because of these programs. also, coding interviews do not test if you are a good software engineer or computer scientist. they test how well you memorized optimal solutions to problems and how quickly you can reproduce them. they also discriminate against those with anxiety or other mental issues or those who have not recently graduated. and they do not test many important skills besides writing code.

Try to look on a hiring problem from another side. Companies getting a lot of applications and at least some either stretch the truth on their CV or just lie, so trusting CV is not something a company can rely upon. Instead a company need an universal for all applicants way to filter out ones who likely cannot write code and then spend time only on candidates who've passed this test. Unless difficulty of this coding interview is miscalculated any experienced developer should be able to pass

Yes you're the exception.Somehow we arent really adept at interviewing at what the day-to-day requirements of a position.Instead were much more interested in edge-case stuff like bubble sort.I wonder if this is some assessment of "are they capable of substantially more complex tasks, and if so, safe to assume they're capable of less-complex minutiae.Seems about right, as often these evaluation type things are proxies.

Want to know a great strategy for hiring lemons? Ask only Leetcode-style questions. Don't ask anything relevant to the job. Don't ask about past experiences, architecture, tech-specific questions, or anything like that.Only. Ask. Leetcode. Questions. If it's not a stupid algorithm disguised as something cute like a dog jumping over a river, then don't ask it.You will be in the exact situation this article describes: Passing up on good engineers, and not being able to te

I'm not sure what your startup does, but I would bet there are better things to ask a candidate than this. You get these problems in school and become quite good at them in the moment but after doing real world work, this mindset will fade. I consider myself a pretty good coder. I've made full production apps that work just fine. But who knows how I would handle this problem if handed to me at an interview I'm already nervous about.Give this problem in the same setting to some of your current

Leetcode exercises are pretty effective at weeding out incompetents. If they have a false positive rate, that's fine, you've got plenty of applicants. If they weed out some of the best that's also fine, because the number one concern when hiring is to find someone competent enough that they don't become an embarrassment to anyone involved.Real world business decisions are dramatically less optimized than people imagine they are.

Yes, you can weed out 50% of incompetent applicants, but that is not the issue. The problem is that the people who will excel in these questions are the ones playing the leetcode game for months. The people with real jobs will pass your question but will do so-so compared to the leetcode gamers, and the second group will get the job. Also, doing exceedingly well in the coding questions doesn't guarantee these people are any good at the real job.

I don't think you're being too hard, but your instrument may be too blunt. If you basing a large part of your hiring decision off this one test then you may be eliminating people unnecessarily and occasionally including someone who doesn't belong. For example I'm pretty rusty as a programmer, having graduated to management many years ago (and a linux admin before that) and I could pass this test, but you wouldn't want me as a senior programmer.The point I'm getting at, is that like any scienc