Stop Interviewing with Leet Code

> IQ does not tell determination/hard-working-attitude

this is what everyone said a college degree was for. Or experience. Neither of which matter when a senior dev with 10 years of experience and two kids still has to find an hour or two a day for three months in a row to grind out textbook algorithms to fake problems. Just to switch their fucking job. Thanks to cargo-cult insanity, god help those stuck in miserable jobs that just want out.

Novel solutions aren't as helpful as you think. Pragmatic, simple, vanilla solutions are reliable.

You won't create your own linked list library, you'll use one from the standard library.

General runtime analysis can be helpful - but production, real-world benchmarks trump all theoretical performance values.

Code changes - how do I make a change to a production system in a million line code base that has good test coverage and when deployed, won't bring the entire system down. That's an exercise in the coding interviews that is completely ignored but most useful in the day-to-day professional setting.

More appropriate interview would be "figure out how to get permission to change this setting"

Sorry, I've had both my kids go through the WISC-V "IQ" test in the last few years and there's no single "intelligence" number that comes out of that that would be meaningful for employment. It measures all sorts of things and you can be off the charts high in one kind of mental / reasoning skill while being average or below average in others and yet that still might tell you nothing about how well someone writes code at a job.

Most of us aren't doing intense mathematical reasoning stuff at work. Sometimes we have to, but most of the time the actual amount of novel algorithm stuff being done pales in comparison to "synthesize this knowledge from 10 different sources and evaluate the best way to integrate that into a reasonable solution."

I don't think coding tests are a good substitute for that, and an IQ test would not give you a clear answer there either.

> But.. why? Does that reflect anything close to the job they would be doing?

Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour.

> putting them on the spot in an already tense situation and expecting them to code while you watch

There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything.

> meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method

That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there.

By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate.

I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens.