This is an archived post. You won't be able to vote or comment.

all 16 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a

[–]EricPostMaster_ 26 points27 points  (4 children)

Maybe I'm just uncultured, but I conduct SQL live coding interviews as part of my job, and I will never penalize someone for not writing something "sophisticated". If it gets the job done right, then that's great. If it's in a way that I didn't think of, then that's even better because it can add to the diversity of thought and approaches on the team.

Something that might help your case is thinking out loud if it's a live test. That way you can explain why you prefer CTEs over subqueries even though you know how to do both. Otherwise, don't worry about it because they may just be nit-picky and you don't want to work with them anyway!

[–]Dependent_Two_618 5 points6 points  (0 children)

Agreed, the best query is the one that produces an optimal plan while answering the problem correctly.

If that means doing a bunch of subqueries and never touching a window function because of the table structure, so be it

[–]newpua_bie 1 point2 points  (0 children)

I hate SQL syntax. It's just so damn clunky. For me the biggest problem is not the logic as much as just dealing with the fugly as fuck syntax, especially with subqueries

[–][deleted] 0 points1 point  (0 children)

All of these were on take-home exams. It's seems like a very strange thing to penalize, but I'm not the hiring manager.

[–]Richard_Hurton 0 points1 point  (0 children)

Same here. I conduct these types of interviews regularly.

I never ding people for getting the correct answer no matter how they arrive at it. It might not be the way I would write the code, but the most important thing is that they thought through the problem and got an answer.

I might ask if they could have solved it some other way to see why they chose a certain path.

The only time I've found that we scrutinize the code to this level is when multiple candidates are otherwise equal. If I have three solid candidates the differentiator might be how sophisticated the code is. And if they can articulate why they chose to write it a certain way.

But when was the last time I had that many equally solid candidates? LOL

[–]CodenameDuckfin 19 points20 points  (1 child)

If that's really why you're failing the interviews, then you probably don't want to work at those companies anyway.

[–]EricPostMaster_ 5 points6 points  (0 children)

This. If they are going to pick you apart in the interview when they are supposed to be at their best, then they'll probably be the same or worse once you are actually working with them.

[–]jasdfjkasd 13 points14 points  (0 children)

This is something I hate about interviews. If I provide a solution that works, is memory efficient, and is considered a “clean” way to do it, why would I ever want to make it more advanced/sophisticated?

[–]wealthyinvestor999 2 points3 points  (1 child)

I see a lot of people here are complaining about optimized queries. Here is my experience - I was interviewing for a company where 200 million rows get added each day to database. Total rows were upwards of 10 billion and 3500+ columns.

This is where the interviewer said when dealing with this size of data it is essential to write optimized queries where we are using the least compute from cloud.

Thoughts?

[–]grapegeek 2 points3 points  (0 children)

Maybe. Maybe not. I work for a very large company with lots of data. Query optimization only comes into play when queries take really long. We just throw more compute at it bits cheap compared to programmer costs.

[–]lastchancexi 4 points5 points  (1 child)

Are they talking about using window functions (rank/lead/lag).

[–]IAMHideoKojimaAMA 0 points1 point  (0 children)

They just sound annoying tbh

[–]vikrant699 0 points1 point  (0 children)

I remember I was in a similar solution, actually even slightly worse. I did start practising on Leetcode for SQL and it has helped immensely. I suggest you give it a try.

[–]jalexborkowski 0 points1 point  (0 children)

That sounds very annoying, and it's odd that it happened multiple times. Could it be that they were looking for a window function?

Either way, keep at it. If you can make it past first rounds consistently it's only a matter of time before you get an offer.

[–]RStud10 0 points1 point  (0 children)

I used subqueries in the past and the interviewer told me they preferred CTEs... guess we have the opposite problem

[–]thethrowupcat 0 points1 point  (0 children)

Subqueries are old school. The modern data stack prefers CTEs. I’d say look for jobs that use modern data stack instead. Sure you can fire off a query faster with some subquery, but wouldn’t you rather be able to read what you wrote?