I feel DSA is a necessary evil at scale. If you are hiring and interviewing 5-10 candidates, low bar for DSA might work. But if you get thousands of application, DSA sort of saves the day.
But this is unfair to candidates, so we moved to mandate only easy questions for DSA and one medium-hard question that won’t be graded. This is good, but i’d couple this with an MCQ round asking questions about the framework that we are using.
Just this should set enough guardrails to filter candidates who can code.
Next, I would emphasise on communication. It doesn’t matter if you’re the best developer, if you can’t sell me your solution. You should be able to speak about your solution, know its pitfalls, convince another person it is good enough. Very similar take, comprehension. You need to understand problem statements before you write the first line of code. Assumptions are expensive and often counter productive. Here, I’d also like to know how much the person was involved in their older job. Are you a code monkey or did you understand your end-user and then build solutions?
Once these three boxes are checked, I’d like to do pair programming on a half-built app. It would probably take you a day or two to create a repository that has a simple half-done app. You can either write unit test cases for unimplemented methods and let the candidate fill it up in an hour to make the test pass, or actually write pipelines to deploy changes so that the other person can test their changes in front of you.
But this takes immense efforts for the interviewer and this can be gamed too. The ROI for the company hiring isn’t great, which is why DSA works at scale.
I could do this for maybe 10-15 candidates. Unless we build a team that only builds problems like this and does technical recruitment and assessment, we’d probably end up having good developers just play the interview game everyday. Because in this process, the interviewer has to know at least as much as the interviewee.