Would you recommend algorithmic interviews?
No, they don't. You can't make sure if a person can solve the problems they're supposed to and if they'll fit in to your team with such practices.
Interviews I do now are more like having a conversation with the person. I mostly want to know what they are doing right now. How much do they understand about it etc. Then we'll move on to understanding what they understand about technologies they use and their opinions about that. Later I'll introduce some problems that we solved in the product I'm working on currently and get their thoughts on how they'd have approached it and how they'd have solved it. By this point I'd have a fair idea if they're a good fit for the team.
Later I'll enquire about their aspirations and ambitions and talk about our team and company.
Now the process explained above takes about 90 minutes for me. So it's better to do it with really promising candidates. Here's a process I was following in my previous company.
Following such a process helped us concentrate our time and efforts on right candidates
Prepare a set of simple questions, where each question can be solved in about ~20 lines of code and doesn't require more than 5 minutes of thinking.
When you get applicants, send them 2 or 3 such questions, (maybe mark one of them optional).
If they pass, bring them in for an in-person interview. There, show them a couple more questions. Maybe have another set of question for in-person interviews that are a bit more challenging.
This is necessary because when they submit solution via email, you can't tell if they solved it themselves or had a friend help them with it.
Also, prepare a set of questions that don't have a specific/definite answer. Like, "Suppose you are tasked with building a program that does X, Y, and Z. How would you go about implementing it? What high level components do you think you will need?"
It really surprises me how many companies will do an "algorithmic interview" and hire a developer that doesn't actually know what they're doing at the actual job. As many have already answered here, a conversation-style interview is way more effective. Ask the candidate real world questions, and about projects they've worked on in the past. If they're struggling on a question, have them talk their way through it and see their thought process on how they'd go about solving it. It's perfectly valid to answer with "I'd probably Google how to do ____ and then check the documentation for ____" because that's how most people realistically work. The most important thing is how willing they are to learn and figure out new problems, rather than how many algorithms they've memorized.
Siddarthan Sarumathi Pandian
Full Stack Dev at Agentdesks | Ex Hashnode | Ex Shippable | Ex Altair Engineering
Jason Knight
The less code you use, the less there is to break
Terms like "Algorithmic interviews" set my teeth on edge; it reeks of marketing scam double-speak.
TALK to them. ASK them questions. SEE if they can verbalize the answer. HAVE the interviewer know something about the topic so they can ask MEANINGFUL and RELEVANT questions.
One of the things I learned about hiring developers back in the '90's was that if a new hire couldn't verbalize the answer to a programming question, it was even less likely they'd be able to code it.
I know in this age of half-tweet TLDR mouth-breathers who freak out "aah, wall of text" that communication skills are at an all-time minimum, but without good communication skills a developer is unlikely to be able to work properly within a group, ask about things they don't know, teach others the things they do know, and properly participate in a proper workplace.
... but right now so many workplaces are utterly banjaxed in this regard as "program managers" push version control software into projects that don't need it, so instead of doing their damned job they can sit there playing Farmville (or whatever fly-by-night Facepuke game is trendy right now) all day.
The biggest problem though is that many 'static' interview techniques -- like "Algorithmic Interviews" are like teaching to the book; you're only testing their memorization skills, not their critical thinking. If I were to use the standard questions you'll find in texts and sources about the subject, it would be as a list of things NOT to ask because dimes to dollars the prospective hire has read and memorized the answers. It's like giving a drug test and letting them pee at home and bring in the cup whenever.
ASK them for examples of their code, ASK them questions directly related to your projects. TALK to them naturally, not off some pre-processed pre-devised off the shelf script!
In other words, TREAT THEM LIKE A PERSON NOT A COG!