For typical dev jobs, hardly anyone writes sorting/searching algorithms, or algorithms at all. In fact, if someone working on web/apps/database stuff is spending time on algorithms, they are doing it wrong. Algorithms are a sort of pleasant luxury for most devs.
Depending on details, it's similar to asking an author to recite, verbatim, Shakespeare verses and calling gotcha on every mistake.
There are situations where it is legitimate, but for app/web/db devs it's just a rigged trivia competition.
Then what should the interviewer ask when it comes to coding question?
Take home small project? "Half" hates that.
Leetcode? The other "half" of population can't stand that.
Fizzbuzz? Too easy.
No code? How can they tell you can code, naturally?
Framework specific questions? Write something in Flask? What if you're looking for someone who's good at development but have not used a specific tech stack?
As the interviewer, I approach candidates with an open-ended friendly gesture. I tell them flat out I want to assess their coding ability, but on grounds they are comfortable and familiar with.
Before the interview, I tell them to bring whatever materials they want to the interview, whether it is virtual or not. Books, notes, videos, whatever, I don’t care. The materials are to support them showing off to me, in their favorite language, with their favorite ecosystem (editor, IDE, compiler, version control, etc.), solving a typical task they address that takes up about half a page (or more) of code on a standard US letter or international A4 sheet in 12-point Courier New, 1.5 inch or 3.8 cm borders, no lines that are entirely a comment (when counting just code).
The hyper-specific layout specifications were emerged by all sorts of crazy responses I got in the early years when I started this approach.
Could be a standalone program, a function, a code fragment, a library, really anything. I’m pretty comfortable in a very wide range of coding environments, and always happy to learn new ones, so I’ve been comfortable navigating the responses I get.
I even tell people I don’t care whether it is their own code or something they literally copy and paste off the Internet. But they need to be ready to talk about it, and take it in different directions. Just tell me ahead of time the toolchain, materials and code they chose.
I tell them I’m going to ask them to teach me about the code, and ask questions to clarify for myself along the way as if I’m going to take it over and maintain it myself, and customize the code and they will help me troubleshoot the customizations.
Through this approach I’m looking for the ability to communicate about code. Without springing surprises upon them. Being able to code is table stakes and this approach quickly flushes out who cannot code at a specific level required for the position. But I work exclusively in settings where there are teams of coders, and even “lone wolf” coders must be effective at conveying what they’ve built to others in case they win the Powerball/Lotto.
I can work with a variety of levels within a certain band of coding ability. I can work with someone who isn’t familiar with my clients’ specific toolchains. I can work with poor documentation, commenting, and writing skills. What I’ve been unable to solve for so far though, is someone not only utterly incapable of communicating what they’ve coded, but completely indifferent to improving.
You’ve missed some other formats that are already used in production. Domain-specific pair programming exists for both web and mobile engineering interviews. There’s also “read this code and debug it” which is an underrated format.
I’m not even sure the Leetcode style needs to be abolished, so much as it can be tweaked to remove some of the additional pressures of the format (time limits, stress from monitoring, overuse of memorization)
> What if you're looking for someone who's good at development but have not used a specific tech stack?
Then you have an interview specific to that use case of candidate. It doesn’t invalidate the format used in interviewing other types of candidates.
There will always be, I think, people who don't like whatever way you choose to do software job interviews, because they're not good at it, and then, some of them don't like it.
> Take home small project
Hmm yes it's unfair that some people don't have the time. What if everyone got to start at the same time, say, 12:00 UTC the 1st Saturday each month, and everyone got exactly 2 hours. Maybe that could work also for people with kids -- after all, 2 hours isn't much more than travelling to and back from an on site interview (in the same city).
Time and days could vary, trying to make it work for everyone
Depending on details, it's similar to asking an author to recite, verbatim, Shakespeare verses and calling gotcha on every mistake.
There are situations where it is legitimate, but for app/web/db devs it's just a rigged trivia competition.