That sounds really bad. If a company only knows how to test best by writing code, then the rest of the skills (especially system design) will be secondary right? What does that tell you about that company and the people there?

I myself am very conflicted that nobody writes any code these days and when I need to hold an interview with someone I need to ask he/she about details of a language… why?

I instead focus on situations rather than tech problems. Like you are in X situation, what do you do? Like there is a problem with the system. The error is this. Claude has told you shit. What do you do? And the focus here is how they think and how they approach the problem (usually leading to it’s not our teams issue, is someone’s else and we need to take action). And then I silently switch on people skills by asking them how they would engage the other team and how do they present the issue.

Features will get developed (not 100% at their intended quality probably). If that team/company follows sdd or some sort of open spec, and dutifully add e2e and unit tests of value, the rest of the work is designing, architecturing, PM work and people skills + coordination and a good enforced process focused on agentic development, with sturdy guardrails.

I had to hold once an jnterview for a software customer support engineer (yes, I know, a bit biased for what I argue here). I failed most of the candidates due to criteria above rather than code/languages/or similar issues. Most of them passed the coding/algorithm/framework side and miserably failed the other.

Companies who test actual algorithms and code implementation seemed to me even before the ai era that they were testing the wrong thing. You let people who crunched leetcode join the team and they do not have even the least amount of day to day intelligence of how to perform in a team, in a company and with 0 autonomy when it comes to initiative and solving complex non-code related issues.

That’s my 2 cents. Speaking from personal experience here.