Live data from Hacker News

Our SQL interview questions

jitbit.com

61–70 of 227 posts

Re: Our SQL interview questions

#61

I'm not a SQL Developer, but anytime I get questions for which Google has answers to be found in 5 minutes or less, I'm quite hesitant to work there. I respect interviews that go along the lines of: "What would you do if..." after giving a detailed description of their environment. But then again I'm a tools/OSes admin, so maybe it makes more sense for my job description. But anytime guys are too focused on third opt…

I don't run a school. Anytime a web-developer does not know basic sql or other basic knowledge, I refuse to pay salary, and even deduct the 1$ per minute. That five minutes just cost you $10

Ignoring the fact that 1$/minute * 5minutes = 5$ -- I wonder which _knowledgeable_ person is willing to work with someone who thinks like you do...

Re: Our SQL interview questions

#62
post #59

Much better than this question i got asked once: "Which is faster: select from a table or from a view?"

I don't see why that is a bad question. A reasonable answer is selecting from a table. Of course it depends on many factors. I often ask questions like this just to get the candidate to tell me why there is not an absolute answer.

Re: Our SQL interview questions

#63
The second question is actually trickier than one might think.

The obvious answer - something like

select Name, MAX(Salary) from Employees group by DepartmentId

is wrong.

Re: Our SQL interview questions

#64
post #48

Earlier quoted context omitted.

In a business setting, the conceptual/relational, logical and physical design of a database happens far less often than querying such databases. Indeed, one of the reasons normalisation is such a Big Deal to relational bigots like me is that it makes SQL's querying tools much more useful and versatile.

True story, but such questions are just senseless. If someone knows about set-theory and the ideas behind query-languages, knowing SQL isn't a deal breaker, it's just a nice to have.

If someone knows set theory, they're likely not interviewing for a LOB CRUD job banging out Rails models.

Re: Our SQL interview questions

#66
post #24
post #18

A 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".

I made the tables quick to go through them. It could do with more data really but its got a few rows. https://gist.github.com/abkr/5662615

In the same vain here are some very quickly put together answers if anyone is interested. I haven't tested these so they may not work. If you see any errors please let me know :)

https://gist.github.com/dritterman/5662750

Re: Our SQL interview questions

#67
post #62
post #59

Much better than this question i got asked once: "Which is faster: select from a table or from a view?"

I don't see why that is a bad question. A reasonable answer is selecting from a table. Of course it depends on many factors. I often ask questions like this just to get the candidate to tell me why there is not an absolute answer.

Unless, of course, the view is a materialized view.

Re: Our SQL interview questions

#68

Earlier quoted context omitted.

I don't run a school. Anytime a web-developer does not know basic sql or other basic knowledge, I refuse to pay salary, and even deduct the 1$ per minute. That five minutes just cost you $10

Not a big fan of on-the-job training, then? Instead of paying a nominal price for people relearning some primitives for a specialized area of IT/software dev, nowadays most companies want the new kids to go to $80,000 worth of college for the same. That way, the employer gets to skip training, and the student is less likely to leave because he or she has too much damned debt to be mobile. Maybe I'm projecting.

Actually I am a big fan of it.

But I'm not a fan of people stating that see these kinds of tests as an attack, or see it as something which is unnecessary. There are a lot of people out there are unable to answer these questions, even with "google". And most of them are either unwilling or unable to improve themselves.

I'd rather have a very eager "junior" who loves what he does, and works hard to understand and develop him/herself than someone "senior" who knows a couple of tricks and is too arrogant to do these kinds of tests.

You keep people if: * they can improve / if they learn * if the colleagues are nice * and the product is interesting, aka they have meaning * management is done reasonably * there's a future for them

this is why startups are popular (learn lots of things, meaningful, good upside) as well as corporates (carreer path is flexible, good management, etc).

Re: Our SQL interview questions

#69
post #34

Earlier quoted context omitted.

Yep, I've done a lot of PL/SQL programming, and we've always used (+)= syntax and joins with all the tables after commas and all the joining conditions after WHERE. Now I work on different project and we use join syntax, but I could easily imagine people that do joins all day, and not know JOIN .. ON .. syntax.

I came to Oracle after it adopted the ANSI syntax, so that's what I use. So my experience is the opposite of yours -- when I see the (+) I need to look up the syntax to remember if it's left or right outer.

And then I ask, hey, where's my BOOLEAN? And then I drink.

Re: Our SQL interview questions

#70

"List employees (names) who have a bigger salary than their boss" SELECT e1.Name FROM Employees e1 LEFT OUTER JOIN Employees e2 ON (e1.BossID = e2.EmployeeID) WHERE e1.Salary > e2.Salary "List departments that have less than 3 people in it" SELECT d.Name, COUNT(e.EmployeeID) FROM Department d LEFT OUTER JOIN Employees e ON (d.DepartmentID = e.DepartmentID) GROUP BY d.Name HAVING COUNT(e.EmployeeID) "List all departme…

Curious question: why do you always use table aliases? To keep your query shorter? When I don't need an alias I just use the full table name for readability:

  SELECT
    Department.Name,
    COUNT(Employees.EmployeeID)
  FROM Department
  JOIN Employees
    ON Employees.DepartmentID = Department.DepartmentID
  GROUP BY Department.Name
  HAVING COUNT(Employees.EmployeeID) 
Post reply on HN