Ich finde es etwas ... seltsam logisches Verständnis abzufragen. Wenn jemand mehrere Jahre Entwicklung macht, sollte man von logischem Verständnis ausgehen...anonsten hat man den Job nicht lange. Es macht in DE weniger Sinn LeetCode abzufragen, da die meisten Bewerber hier diese Katas nicht lernen bzw. üben. Das wäre für den dt. Markt unüblich. Viele Unternehmen finden zu wenig Leute bzw. haben zu großen Bedarf, als dass sie 80% der Leute aussortieren weil diese nicht auf LeetCode Aufgaben vorbereitet sind.
Es ergibt mehr Sinn auf die eigesetzten Technologien einzugehen. Wenn in den CV steht, dass man an einem Projekt mit Framework XY gearbeitet hat, dann sollte man eine typische Frage stellen, die jemand beantworten kann, wenn Erfahrung mit XY da ist. Man sollte so überprüfen, ob man im CV dick aufgetragen hat, oder ob es den Tatsachen entspricht. Wenn drin steht, dass man mit Azure gearbeitet hat, dann sollte man nicht an üblichen Fragen zu Azure scheitern usw. Es geht dabei weniger um logisches Denken, als um fachliche Kompetenz mit Technologie X. Hierbei muss man nicht die Doku 1:1 widergeben, sondern durch freies Sprechen Wissen verständlich vermitteln können.
Es können auch Fragen drankommen wie z.B. welche Vorteile hat Design Pattern X gegenüber Design Pattern Y wenn Technologie Z im Projekttyp A eingesetzt wird. Das betrifft nur begrenzt logisches Denken... man muss wissen was Technologie Z ist, was die Design Patterns grob machen...und dann entweder Wissen oder durch Logik herausfinden, welches Pattern vermutlich für Aufgabe A besser geeignet ist. Kann auch eine Fangfrage sein, weil Y üblicherweise bei A eingesetzt wird...mit Ausnahmen etc.
Kurz: Man spricht Fragen an, die sich auf die Projekte aus der Vergangenheit beziehen...und die jeder Entwickler, der an solchen Projekten gearbeitet hat, normalerweise beantworten kann.
Dies sollte nicht per schriftlichen Test geprüft werden, sondern einfach in einem netten Gespräch zwischen Bewerber und einem Vorgesetzten für das entsprechende Team (bzw. kann man langjährige Entwickler hinzuziehen).
Edit: Ausnahmen hier sind evtl. Embedded Programming, Kryptographie etc. ... dass sind aber Spezailfälle