That's how I view them as well. It's why a lot of people can get through them by doing lots of Leetcode in the same way that one might do lots of logic problems in order to score higher on an IQ test.
Leetcode practice gets you through a particular kind of coding test. I would say that only covers ~half what a good coding test interview should cover. It makes you good at the "how", and solving algorithmic or textbook architecture questions.
The questions I prefer to ask are about writing a basic but readable and maintainable piece of code, maybe 50-100 lines long, that requires the candidate to talk about why they are making certain trade-offs, questions that look at when they would involve other team members in decisions (when do you ask a Product Manager or Designer for help?), questions that try to understand whether they can solve problems rather than the one problem in one language given to them in the interview. I typically do those interviews in Python but some of the best candidates have never written any Python – but their communication, intuition, and problem solving abilities were great.
For junior positions, I tend to ask very simple questions. Reverse a string or given an array and an int count how many times that number occurs (or variants thereof). Something that requires a loop and some ifs. It opens the posibility of endless discussions about extensions, refactoring, runtime, edgecases - it gives a solid bases on which to judge their ability.
For senior positions, it's slightly more advanced. But if they make it through to second round, we have them bug hunt and refactor some piece of code.
Programming is a craft and I need to evaluate that craft.
At least there’s considerable variance in the problems on an IQ test so your intelligence is diversified across many problem types. The type of shit I’ve come up against in past interviews has often been essentially an all-or-nothing single problem. Which is why I now refuse technical interviews.
Advice on getting a job as a software engineer without a technical interview? Literally 100% of the dozens of interviews I've had in my life were coding interviews.
Have projects available online that showcase your ability/ingenuity/creativity. Just reject the technical interview and explain your reasoning, offer an alternative.
Works for me because I don’t want to work anywhere where interviews aren’t being conducted by people competent enough to handle fluid requirements.
I don't see how asking a potential software engineer to write a 30 line function in 30 minutes is bad. Being able to write code is part of the job description.
I don’t need to “prove” that I can write code by memorizing an algorithm. I have made more than enough code available on my GitHub which I’d be happy to explain in depth with anyone who is interested. Not interested? Great, you’ve made it easier for me to make my decision.
Depending on what those 30 lines are supposed to do and whether they have to be asymptotically optimal at doing it, writing down 30 lines of code while talking about every decision you’re making, to show the “thought process” might very well be more than a 30 minute task.
I didn't mean to imply that this is the only way, just that it's a way that has worked for me.
I've worked with embedded systems and with desktop software that was used by my employers (electronics manufacturers) rather than sold by them, and I have never been asked to code in an interview.
