How not to assess a developer's ability in an interview

Are you ready for your interview?

Excuse me while I rant a little...

Trying to assess a developer's quality in an interview setting can be very difficult. There's lots of different approaches, from high-pressure in-interview programming tasks, to "homework" style projects, to technical questions, and many others...

However one guaranteed way to not gain any real insight into a developer's approach, skillset, problem-solving ability, working knowledge of best-practices, or instincts is to ask them a series of questions that they could simply Google.

Here are some I've encountered while seeking work as a full-stack web developer:

• Explain how you'd create an ssh key and how would you go about using it.
• Can you explain the difference between the commands: 'docker run' and 'docker exec'?
• How would you find a process and shut it down using the terminal?
• How would you make a file readonly using the terminal?
• What's the difference between git reset and git revert?
• What's the difference between object storage, block storage and file storage?
• What are the differences between MySQL, PostgreSQL and DynamoDB?
• What engines does MySQL use behind the scenes, and what are their differences?
• What's the different between === and ==, and what cases would it be preferable to use '=='?
• What's the difference between an abstract class and an interface?

(Side note: These were all questions I encountered for Laravel short-term contract!)

Some of these are incredibly basic, some of them depend on tech stack experience, but none of them are helpful in giving you insight into a developer's technical instincts. 

If you don't wish to know anything about a developer's ability to work independently solving problems using best practices, you should definitely ask these questions.

On the other hand, if those things are of interest, then giving a homework task that you discuss later, or even better, a group white-boarding session where you can see how the developer approaches novel problems, can tell you a huge amount about a developer.

What are some of the most pointless questions you've encountered in an interview?