Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our SQL interview questions

jitbit.com

Post reply on HN
Print view View original

161–170 of 227 posts

Re: Our SQL interview questions

#161

Post by xanadohnt »

pessimizer wrote: post #143
xanadohnt wrote: post #84

If the position you're filling is directly dependent on more-than-average SQL experience - creating a DB driver, an ORM, for ex. - then SQL-specific questions are applicable. But, by and large, this type of specific-knowledge testing is not very useful. I want to see a developer's general abilities at problem solving and the source code to back it up. If you have solved complex problems in C# - and can prove it - the…

These are very simple, though. If you say that you know SQL (or have known SQL, but are a bit rusty) and you can't at least make a strong showing on these questions, you are lying. This is not complex problem solving, this is problem solving. I'm not sure what memorization has to do with any of this. SQL is a language with only maybe 10-15 important words. It's not like trying to get around Paris without a phrasebook…

It's called Query by Example and there are quite a few DB management GUIs that have it. I found it pretty intuitive for setting up joins by right-clicking join lines and setting the particular properties of that join. Of course now that I have committed all types of joins to memory it's far faster to write them simply by hand. But my lacking that memorization 10 months ago wasn't really insite into my ability (or lack thereof) as a developer.

Re: Our SQL interview questions

#162

Post by chrislomax »

specialist wrote: post #96
edw519 wrote: post #33

I took a similar test, on-line while being watched. 4 sets of 10 multiple choice questions: SQL, unix commands, vi, & HTML. Make your 10 choices, click submit, get your score. It was kinda silly, but what the heck... It was ridiculously easy and I got all 40 right without much thinking, as many people here would also, I imagine. Then I asked, "Why bother with this after reading my resume?" They answered, "We have to…

We also set up an online test to screen candidates. Because HR and the recruiters kept sending us such terrible candidates. I just can't understand how people don't score 100%. Alas, not many do. It's saved us devs a HUGE amount of time.

I dislike the whole interview process, I'm only young so the interviewing process is still very new to me. We find that people lie heavily on CVs to the point where it is annoying. We had someone once who had 5 years CSS experience yet found it hard to center some text.

I think an online test would help our cause some but I don't know how simple to make some of the questions. How long would you expect the candidate to be taking the test? Do you tailor the test to the candidates?

Re: Our SQL interview questions

#163

Post by VLM »

versk wrote: post #152
VLM wrote: post #150

Earlier quoted context omitted.

Ah I was trying to imply two sets of filtering and probably have them reversed, where HR is filtering on lack of honesty which only implies lack of skill or at least average skill, whereas the secondary filtration (the having clause) would imply the test for skill.

Don't you need a group by clause in order to have a having clause?

This is yet another of those things that gets the pgsql folks all wound up about mysql. mysql is generally permissive best effort rather than restrictive follow the spec, so HAVING is allowed to reference stuff not in a GROUP BY or an aggregate (like MAX or COUNT). As you imply, this is not allowed by the SQL standard so philosophically I would Strongly Expect pgsql to error out unlike mysql. I donno what ms-sql does, don't use microsoft stuff. Oracle costs too much, so another I donno.

About 99% of the noise about mysql vs pgsql boils down to this overarching philosophical different of "try yer best" vs "only perfection is permissible". There are minor other differences aside from that, none of which I can remember at this time.

I was mostly trying to make a joke and making the psuedocode kinda sql inspired rather than cut and paste into a window like a stack exchange answer. I could have implemented it "properly" as a nested subquery I suppose. Or to make the point a little more .. obviously, just "select 0;"

Re: Our SQL interview questions

#166

Post by EGreg »

It's an interesting debate. While I also feel that developers should know the underlying SQL, however all that stuff like joins, indexes etc. are actually very hard to scale beyond one machine. MySQL cluster does attempt to do it automatically, but even it has limits, and places most stuff in memory. In short, if I was looking for developers to do sharding, I would actually prefer to AVOID queries with joins, non-pk lookups etc.

Having said that, I have discovered a heuristic over the years: that if you are using an ORM, you probably don't want a relational database. You should learn something like Riak and let it handle the distribution and provide all the partitioning and availability for you. The CAP theorem shows that you can't get it all, and most likely you want to use one of those data stores instead of a relational one.

For regular sites that won't have millions of users constantly using it, though, a relational db is fine.

Re: Our SQL interview questions

#167

Post by wambotron »

This is the perfect interview test. It's easy enough that a candidate can roll through it relatively quickly, but deep enough to prove they have the experience they claim to have. Kudos on having a smart interview test!

Re: Our SQL interview questions

#168

Post by brown9-2 »

twistedpair wrote: post #151
codegeek wrote: post #44

"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…

You assume that all people have bosses. The top boss has no boss. You also assume that all department names are unique. Nitpicking, yes, but these questions certainly allow for a deeper discussion with the interviewer.

You assume that all people have bosses. The top boss has no boss.

Isn't that why a left outer join is used?

Besides, if you are referring to question #1, a person without a boss can never be a part of the set of employees who have a higher salary than their boss.

Re: Our SQL interview questions

#169

Post by metaphorm »

twistedpair wrote: post #142
jebblue wrote: post #90

Earlier quoted context omitted.

I heard about it in the last year or so here on HN, otherwise I wouldn't have known what a FizzBuzz was. I've been coding for 20 years professionally and 30 for fun. I've never coded a Fibonacci either. I think colleges need to teach how to code a microcontroller to do something, build a multi-platform application, build a database application, set up a CI server, etc.

Fibonacci? That's a recent invention, right?

not sure what you mean?

coding a simple function for evaluating the fibonacci sequence is a reasonable alternative to FizzBuzz that allows for some slightly more sophisticated requirements: like "code a recursive function that evaluates the first N members of the fib sequence. use memoization in your implementation and show how this runs in O(n) time complexity."

Re: Our SQL interview questions

#170

Post by brown9-2 »

xanadohnt wrote: post #84

If the position you're filling is directly dependent on more-than-average SQL experience - creating a DB driver, an ORM, for ex. - then SQL-specific questions are applicable. But, by and large, this type of specific-knowledge testing is not very useful. I want to see a developer's general abilities at problem solving and the source code to back it up. If you have solved complex problems in C# - and can prove it - the…

I think you are assuming that the company is using SQL interview questions to test whether or not the candidate is a strong overall developer than a strong SQL developer. It seems to me that they are testing for a very specific skill and area.
Post reply on HN