3 ms·

Eh, HAVING is something that can be learned in 5 minutes. So filtering out for that is probably generating a lot of false negatives. I quiz them on indexes and

Eh, HAVING is something that can be learned in 5 minutes. So filtering out for that is probably generating a lot of false negatives. I quiz them on indexes and table design. Those can be done without writing a single SQL query.

SkyPuncher 7y ago
I look up HAVING every time I write it. I just don't use it enough to keep it in memory as a first class concept. A quick google search with an example is enough to jog my memory. If I got asked about it on an interview, I'd be completely blank.
- babuskov 7y ago
  I'm curious now. What's there to look up? It's just like WHERE, but you use it on aggregate values. WHERE filters the data before you aggregate it, HAVING afterwards. That's all there is to it.
  - alasdair_ 7y ago
    Simply remembering that fact is language trivia that is easy to refresh when needed. It’s like asking if intel x86 is big-endian or little-endian. It’s trivial to check but if I haven’t had to use that fact in a while, I likely won’t bother to remember because it’s trivial to search for.
- ordinaryperson 7y ago
  Exactly. "I use [x] all the time and know it well, so [x] will be a good filter for evaluating someone's technical skills." No. People do different work tasks depending on the project or company. Sometimes I'm knee-deep in SQL. Others in React. I'm often forced to do PHP. My familiarity with specific SQL syntax ebbs & flows with what I'm doing. There's no point in keeping something in your brain if you're not going to use it every day. Just remember the general concept and Google the specifics when you need it. Just one example why interviewing is terrible and interviewers really should be trained on what not to do.
  - SkyPuncher 7y ago
    Exactly the same with me. Need me to write an ETL. I probably can't crank it out in an hour like a data scientists, but I can get it done in a reasonable amount of time. I just need to do some major context shifting. Have me write only ETL's for a week, I'll be cranking them out after the first few.

SkyPuncher 7y ago

I look up HAVING every time I write it. I just don't use it enough to keep it in memory as a first class concept. A quick google search with an example is enough to jog my memory. If I got asked about it on an interview, I'd be completely blank.

babuskov 7y ago
I'm curious now. What's there to look up? It's just like WHERE, but you use it on aggregate values. WHERE filters the data before you aggregate it, HAVING afterwards. That's all there is to it.
- alasdair_ 7y ago
  Simply remembering that fact is language trivia that is easy to refresh when needed. It’s like asking if intel x86 is big-endian or little-endian. It’s trivial to check but if I haven’t had to use that fact in a while, I likely won’t bother to remember because it’s trivial to search for.
ordinaryperson 7y ago
Exactly. "I use [x] all the time and know it well, so [x] will be a good filter for evaluating someone's technical skills." No. People do different work tasks depending on the project or company. Sometimes I'm knee-deep in SQL. Others in React. I'm often forced to do PHP. My familiarity with specific SQL syntax ebbs & flows with what I'm doing. There's no point in keeping something in your brain if you're not going to use it every day. Just remember the general concept and Google the specifics when you need it. Just one example why interviewing is terrible and interviewers really should be trained on what not to do.
- SkyPuncher 7y ago
  Exactly the same with me. Need me to write an ETL. I probably can't crank it out in an hour like a data scientists, but I can get it done in a reasonable amount of time. I just need to do some major context shifting. Have me write only ETL's for a week, I'll be cranking them out after the first few.