Nice set of questions.
I would also use some sample real world data to check if my queries scale well instead of inserting 10 rows and running all queries on it.
http://stackoverflow.com/questions/57068/good-databases-with...
Our SQL interview questions
11–20 of 227 posts
Re: Our SQL interview questions
#12My first weed out question is asking them to describe a Left Outer Join. They don't have to get it exactly right, I just want to see if they ever did anything more than a two table inner join. For a Web Developer the first weed out question is to tell me the difference between a GET and an POST. Here all I really want then to know is that a GET is what generally see in the URL and a POST is commonly what you see in H…
Interesting, so I think I'll pass your first screening even though I'm not a (web) developer but (most of all) a system/network engineer :D
Re: Our SQL interview questions
#13I could nail those with the Django ORM, but I'd struggle to write syntactically correct SQL, not having done it in a while. But it says that your test machine has MS-SQL; with the machine in front of me, I could probably puzzle it out the join quirks with a couple minutes of trial and error.
Re: Our SQL interview questions
#14Seems to me to be a solid test, though I might include a small amount of sample data to nudge them in the direction of some of the potential issues (empty departments and so on) - maybe I'm just kind like that. ;-)
In interviews I've always been amazed how few people who claim to know SQL can use GROUP BY, HAVING and aggregate functions (or depending on the question self joins or sub queries that will allow them to achieve some of the same things).
My normal question is to present them a table with a level of duplication ask them to write something in SQL that identifies the duplications and something that removes them which covers much of the same syntax.
Re: Our SQL interview questions
#15I could nail those with the Django ORM, but I'd struggle to write syntactically correct SQL, not having done it in a while. But it says that your test machine has MS-SQL; with the machine in front of me, I could probably puzzle it out the join quirks with a couple minutes of trial and error.
How would you solve the first one using Django ORM?
Re: Our SQL interview questions
#16They seem to be quite simple. For what profiles are you asking these questions?. I have used very similar questions for dev ops role.
You'd be surprised how many people claim knowledge of relational databases but who could not answer those questions.
Re: Our SQL interview questions
#17I find it kind of interesting that the first comment on the article says they wouldn't be able to answer the questions by they use an ORM. I'm not really a fan of ORMs, personally, because I don't think it's useful to try and "map" a relational model onto an object-oriented one.
Re: Our SQL interview questions
#18A sample SQL file with dummy data would be much appreciated, I think. I guess some of us would like to try their luck.
At least this should be quicker in an interview situation than the usual "normalize this database" or "given this situation, define a database schema".
Re: Our SQL interview questions
#19They seem to be quite simple. For what profiles are you asking these questions?. I have used very similar questions for dev ops role.
Yeah they seem quite obvious really. Serious question: is this really the types of questions asked for a dev job interview? (was still interesting to see.)
>List all departments along with the number of people there (tricky - people often do an "inner join" leaving out empty departments)
inner join seems the non obvious way to do it really IMO.
select
departments.name as "department name",
(select sum(salary) from employees where employees.departmentid = departments.departmentid) as "department total salary"
from departmentsRe: Our SQL interview questions
#20They seem to be quite simple. For what profiles are you asking these questions?. I have used very similar questions for dev ops role.
Yeah they seem quite obvious really. Serious question: is this really the types of questions asked for a dev job interview? (was still interesting to see.) >List all departments along with the number of people there (tricky - people often do an "inner join" leaving out empty departments) inner join seems the non obvious way to do it really IMO. select departments.name as "department name", (select sum(salary) from em…
The empty department remark is the clue. They want all departments; if it's an empty department they still want to see that it's an empty department.
An inner join will hide that row because there's no equality between a set (departments) and an empty set (employees in that dept, of which there are none). A correctly structured outer join will.