Live data from Hacker News

Our SQL interview questions

jitbit.com

111–120 of 227 posts

Re: Our SQL interview questions

#111

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…

Even the worst developers I have worked with could figure out SQL queries like this in an afternoon. If they study before the test, congratulations, we just hired a dud.

Re: Our SQL interview questions

#112

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

Refuse to pay salary? Good way to end up with a terrible reputation and/or a broken nose.

Re: Our SQL interview questions

#114
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…

Jeff Atwood has written about a similar experience in "Why Can't Programmers.. Program?": http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

Re: Our SQL interview questions

#116
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…

"Wow. Is this the state of our industry now?"

Traditionally this happens when HR demands "10 years experience with windows server 2007" and you somehow snuck thru (or maybe worked at MS on the dev team, or were in a beta program or...) anyway by definition the only people making it thru the filter are going to have a weird/cool/interesting background or are going to be pathological liars who inevitably will only get 32 on the 40 point test, because they filtered all the real applicants out by applying a bad filter.

I guess the SQL analogy would be something like:

SELECT COUNT(*)

FROM applicant

WHERE applicant.skill > 40

HAVING applicant.skill < 10 AND applicant.honesty < 0

Re: Our SQL interview questions

#117
post #95

These questions are very simple, though I guess they cover a few of the core concepts. Basic selects, joins, joining the same table twice, left joins and group by. I'm most worried by the comment "(tricky - people often do an "inner join" leaving out empty departments)" . That's a basic question and if that's considered "tricky" you've got a real problem on your hands. Maybe if you're hiring for a junior position you…

I feel exactly the same way. I'm the first one to admit that an ORM can save you a huge amount of time for basic database stuff. However, as queries get more complex I always write them in raw SQL. It's just faster for me. I'm shocked that someone who applies for a programming job wouldn't get these questions right. They're not exactly rocket science, right?

Re: Our SQL interview questions

#118
post #7

This is much more useful than the typical question I've received at some companies - "On a scale of 1 to 10, how would you rate your SQL knowledge?"

I've had this and have answered something like: "Compared to most other devs I work with, 7 or sometimes 8. Compared to people who do SQL for a living, possibly a 4, or a 5 if I'm feeling cocky. It all depends on what the '10' really represents - the best of the best, or the best of the people I'd be working with." Well, something like that. That last bit - I've said it more tactfully in the past.

This is the only way to answer this question.

Re: Our SQL interview questions

#119
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…

And yet people still ask if automated testing is needed. I heard there's a new research project being funded called "People: They make mistakes. Again. And Again."

Re: Our SQL interview questions

#120
post #102
post #95

These questions are very simple, though I guess they cover a few of the core concepts. Basic selects, joins, joining the same table twice, left joins and group by. I'm most worried by the comment "(tricky - people often do an "inner join" leaving out empty departments)" . That's a basic question and if that's considered "tricky" you've got a real problem on your hands. Maybe if you're hiring for a junior position you…

> That's a basic question and if that's considered "tricky" you've got a real problem on your hands. If they aren't warned then it's reasonable to assume that every department has employees. Otherwise why would it exist?

Fair point. Experience has taught me to internally question whether or not each relationship should use a left join or not. The fact that it says "List all departments" made me think it should be a left join. In fact, to me that screams "left join".

Really, in a philosophical sort of way, it's the use of the query that determines which join to use. They want ALL departments, you give them ALL departments. Using a left join you protect yourself in the future - with a performance hit. As you say, if there was a guarantee that the data didn't contain empty departments you'd use an inner join.

Most importantly, a reasonable developer should know to ask the question - if not of the examiner, at least to themselves. Just making an assumption is not the right approach.

Post reply on HN