I read this article and it didn’t sit well with me.
https://towardsdatascience.com/5-common-sql-interview-problems-for-data-scientists-1bfa02d8bae6
This has got the be one of the worst ways to conduct an interview.
Of those 5 problems, only two of them I have ever had the need to perform. They are the duplicate email and the highest salary. Sadly I did not appear on the list.
The other three are just fictitious exercises. In fact, the second highest salary reminds me of a practice question in a SQL Server 2000 or 2005 book.
Why is it bad?
You could work out the solution, but most developers these days don’t spend hours solving problems. They just ask Google or YouTube.
You get an error code, you Google it. You get an error message, you google it. You have to work out how to configure something in Sql Server, and you YouTube it for a walk-through. You have to use a window function but aren’t 100% on the syntax, you Google it.
Asking interviewees these problem-solving questions in an interview without providing them with the correct resources is nonsense. When do you ever verbally explain these types of solutions?
No one works like that so don’t interview like that.
So what should you do?
What I’ve observed is that both good and poor candidates will struggle with tough questions. So don’t ask them.
The point of differentiation is with easy questions. Poor candidates struggle to answer some of the easy questions. And by easy, I mean really easy.
For example:
- What’s the difference between a varchar and a char?
- What’s the difference between varchar and nvarchar?
- What’s the difference between and INNER JOIN and an OUTER JOIN?
- How many Primary Keys can I have on a table?
Not a word of a lie, I have interviewed DBA’s who have got one or more of these wrong.
What you can expect from a good candidate are very prompt answers. But what you really want, this is the important part, is some sort of reaction as to why you’re asking really basic questions. They’ll likely recoil, in a “What the …?” kind of way. They’ll also relax quite a bit because they’ll know they’ve nailed the interview.
The candidate will then be concerned you’re a bunch of amateurs so you need to reassure them shortly after that you know they are entry-level. Let them know that this is your “smoke test” to quickly flush out any pretenders.
Because if you don’t know those; that’s a concern! The candidate will completely agree with you on that.
Ok, so where are the interview questions?
Well …. sorry. Other than those above, I’m not going to share my list. But the list is not that hard to come up with. It’s really basic 101 questions.
But if you do have some pretty cool questions I’d love to hear about them in the comment section below.
EDIT: 30/05/2020:
This post has most of the core areas I would quiz people on. Joins, aggregates, conditional statements, data types (especially dates) and window functions.