3 ms·

I consider the critical path to SQL performance to be understanding what the data looks like and the type of queries to be executed against it rather than gener

by tom_b 13y ago

I consider the critical path to SQL performance to be understanding what the data looks like and the type of queries to be executed against it rather than general guidelines. To be frank, knowing the difference in how to write an inner and outer join when given a three table schema and a desired output is a frightening filter of candidates. Having an instinct that some type of index could help a query probably makes you a db wizard.

tbrownaw 13y ago
knowing the difference in how to write an inner and outer join when given a three table schema and a desired output is a frightening filter of candidates Even just asking for a basic understanding at the "use this to look up that" level -- since SQL syntax is easy to learn if you know what you want, and whoever does the recruiting has taken to mostly finding us new college graduates -- filters out an absurd number of candidates. I guess it's the same thing as makes FizzBuzz a useful question.
- RogerL 13y ago
  I honestly don't grasp why this is a good question. Sure, I write a SQL query now and again, but if I have to join I look it up. I don't do it a lot. If I had to do it a lot for you, I would learn it inside out. If I told you I was a DB wizard, then sure, I better already know how to join. But I know tons of people that don't really do SQL. They are eminently hire-able and valuable. source: a guy (me) who was bounced out of an interview because he didn't recall some specific detail about boost::shared_pointer().
  - cwyers 13y ago
    If you don't know how to do a JOIN you really don't know how to use SQL, and that's not a tricky use of JOINs at all. If you're hiring for a position that mostly uses an ORM or something and raw SQL is only important in cases where the ORM is giving bad performance, maybe not knowing how to do a three-table join is fine. If actually writing SQL is part of the job regularly, though, the sort of thing grandparent is talking about is absolutely a bare-minimum of knowledge needed, maybe even below the bare minimum.
  - tom_b 13y ago
    To clarify, two SQL questions were asked during an interview round for a job description that specifically required the ability to write ANSI SQL against databases for reporting/analytics purposes. Opposed to bringing candidates in for a job description requiring Java experience and then dropping a couple of SQL "gotcha" questions on a surprised candidate. I think at this point, most HN'ers would accept that a work sample test (of some limited scope and effort) is a better test than any interview question or whiteboard coding process. From that perspective, no question is really a good one. Unfortunately, at my workplace, there are strict rules in place specifically prohibiting this type of applicant process.

by tom_b 13y ago

tbrownaw 13y ago

knowing the difference in how to write an inner and outer join when given a three table schema and a desired output is a frightening filter of candidates Even just asking for a basic understanding at the "use this to look up that" level -- since SQL syntax is easy to learn if you know what you want, and whoever does the recruiting has taken to mostly finding us new college graduates -- filters out an absurd number of candidates. I guess it's the same thing as makes FizzBuzz a useful question.

RogerL 13y ago
I honestly don't grasp why this is a good question. Sure, I write a SQL query now and again, but if I have to join I look it up. I don't do it a lot. If I had to do it a lot for you, I would learn it inside out. If I told you I was a DB wizard, then sure, I better already know how to join. But I know tons of people that don't really do SQL. They are eminently hire-able and valuable. source: a guy (me) who was bounced out of an interview because he didn't recall some specific detail about boost::shared_pointer().
- cwyers 13y ago
  If you don't know how to do a JOIN you really don't know how to use SQL, and that's not a tricky use of JOINs at all. If you're hiring for a position that mostly uses an ORM or something and raw SQL is only important in cases where the ORM is giving bad performance, maybe not knowing how to do a three-table join is fine. If actually writing SQL is part of the job regularly, though, the sort of thing grandparent is talking about is absolutely a bare-minimum of knowledge needed, maybe even below the bare minimum.
- tom_b 13y ago
  To clarify, two SQL questions were asked during an interview round for a job description that specifically required the ability to write ANSI SQL against databases for reporting/analytics purposes. Opposed to bringing candidates in for a job description requiring Java experience and then dropping a couple of SQL "gotcha" questions on a surprised candidate. I think at this point, most HN'ers would accept that a work sample test (of some limited scope and effort) is a better test than any interview question or whiteboard coding process. From that perspective, no question is really a good one. Unfortunately, at my workplace, there are strict rules in place specifically prohibiting this type of applicant process.