Hacker News Reader

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.

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.

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.

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.

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.

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.

My use of SQL beyond very basic is very sporadic (I do remember about HAVING though). If you ask me out of blue I would most likely fail tests. From time to time however I do have to design database for particular product and in a matter of few days my knowledge gets from basic to very good one. Only to go down again a short while after database design implementation and testing completes.

That does not mean that I do not know basic concepts about how different databases work, including underlying storage engines etc. To the point that for one product I personally designed actual NoSQL (EAV to be precise) database engine and query engine largely resembling SQL to go along.

So would you fail me in your test?

Exactly. You don't use it, you lose it. That doesn't mean you don't have the capacity to reacquire it in a short period should you need it again. Most humans are not encyclopedias.

I can describe for you in detail the different index types on MySQL and Postgres, and go into when/why you would use each. But it's been so long since I crafted a complex join by hand I would definitely have to google it. However I don't doubt that I could write the query in a short time. One of the most realistic interviews I ever had, they gave me a laptop and allowed me to google during my answer. I took the job.

I like to structure my questions such that they could using HAVING or a CTE or subquery and not test on the piece of knowledge directly, but the application of knowledge.

Like in Python if you asked lots of questions with list of numbers ... and then generalized it to infinite lists of numbers. If the first case I'd like to see list comprehensions, and then generator expressions or possibly the use of itertools.

That tends to be how it leads in. We’ll talk through building a simple CRUD application with a single table and then ask questions about how to get specific data for somebody in marketing.

There are a lot of ways to answer it, but HAVING is the simplest.

My experience with interviewers is that they all believe that their pet question is "a surprisingly good filter". Considering that there is rarely a data-driven approach to recruiting, usually this statement has a heavy confirmation bias.

Usually when you add data to the mix, you'll find that most questions are not significantly correlated with candidate success/failure once you condition on "ability to write any code at all".

That is my experience too. I had people swear by "multiply two numbers without using a multiplication sign" as their one and only coding challenge.

Completely agree. Early in my career I had what I thought was "a suprisingly good filter" question I would ask candidates. For a couple years I did this. We hired one guy who had failed my question and then fired him a couple months later, which heavily reinforced my belief in the value of this question.

A couple years later I found the stack of resumes, some we hired, some we didn't. I realized that some of our best engineers had failed my question, and I had subsequently voted "no" (I was outvoted, fortunately, by my fellow panelists. Another reason I strongly advocate panel interviews but that's a separate discussion).

I soon realized that my question was good at filtering out people who didn't think like me, not at filtering out people who would make good engineers.

My takeaway was that everyone, especially me, could use a healthy dose of humility and self-skepticism. Not advocating swinging the pendulum into Impostor Syndrome (which I now struggle with sometimes), but somewhere in the middle is good and healthy IMHO.

I knew a guy, a really good engineer, who used to ask people about a specific thing you would see in a log file from a particular open source server. The SQL "having" question isn't quite as bad, but neither question is good at assessing one's ability to solve problems.

Is the pun of saying knowing “HAVING” is a good filter intended?

It is now.

I can barely get candidates to join two tables.

I’ve hand written thousands of sql queries, including a year spent writing nothing but PL/SQL stored procedures. I’d fail your test, not because I’ve never used it but because I’ve not had to use it in years and, importantly, I rely on Google to remind me of syntax trivia when moving back to a language I haven’t actively worked in in a while.

I HATE trivia questions and I’m convinced they are a sign of a lazy interviewer. If you want to test someone’s knowledge of sql, give them a sample schema, an internet connected computer and five minutes to write an appropriate sql query for your use case.

It’s not a trivia question. It’s directly related to GROUP BY and is a core part of standard SELECT syntax.

I’ve never met somebody who has spent any amount of time writing raw SQL who didn’t know it.

I’ve met a lot who overly rely on their ORM but “have done a lot of SQL” who don’t.

Brightball, how many years of coding/sql/developer experience do you have?

Going on 20

How much time would you think, the (+)average programmer, say with 10 years experience needs to learn _basic_ sql, along with the HAVING clause, assuming they have never learnt sql during their entire working career? ( we are talking RDBMS concepts from scratch. like Primary keys, normalization etc, and finally sql).

(+) average= meaning the programmer should be able to say 'solve' the FizzBuzz under comfortable conditions. Or say add the first n items in an integer array etc...

Largely depends why you ask? I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from.

My interviews are conversations to get to know you, your background, your professional interests, how you think about problems and how closely your resume lines up with those conversations. I like to get people talking about their work to see where their energy level goes.

When we start talking through a hypothetical data problem there are people who will describe the problem from the UX perspective, the app code perspective and the database perspective. The question prompts that portion of the conversation.

>I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from

Precisely. And why not? I have my fellow developers do that ( ask trivia and label the interviewee incompetent, if he cannot answer it) , and most people who have reacted to your post have also probably seen that.

Anyway humor me and tell me how much time it would take?

Learning the concepts? A few hours

Using the concepts in how you naturally think about problems?

That will only come from experience. I can't say exactly how much but I'd imagine something in the realm of 6 months minimum of applied usage to different problems.

I went to a job interview recently where the interviewer was trying to phrase the question properly: "I'm trying to figure out how to ask this next one, so if you have a lot of Customers, and... umm..."

And I interjected during a long pause and said "It sounds like you're trying to ask a question which could be answered by using a HAVING clause. So something like, only those Customers who have two or more orders, which would be 'GROUP BY Customers HAVING count(Orders) > 2'."

I was right, he was looking for that. Still didn't get the job.

How would you know it’s a good filter? What position are you interviewing for?

It's about as good a filter as asking a candidate what a "gyascutus" is.

ROFL. You've made my day.

Trivia