3 ms·
Valuable yet fairly common. I remember interviewing at FAANG and being asked to code up various tree traversal algorithms... and moments later I would be asked
by drej 8y ago
Valuable yet fairly common.
I remember interviewing at FAANG and being asked to code up various tree traversal algorithms... and moments later I would be asked to write window function aggregations in SQL. And it was like this for all the interviews with that company - it was fairly bizarre as I wasn't sure what the aim there was. I understand that SQL is omnipresent, but surely people with algorithmic knowledge would be able to pick up SQL in hours or days, while the opposite doesn't quite hold.
(Oh and I agree with the article and I do like SQL for all sorts of workloads, that's not the point.)
- saagarjha 8y ago> I understand that SQL is omnipresent, but surely people with algorithmic knowledge would be able to pick up SQL in hours or days, while the opposite doesn't quite hold. As someone who knows essentially zero SQL, is this really true? How long would it take me to learn it well enough to be competent with it?
- FroshKiller 8y agoIn my experience, "algorithmic knowledge" doesn't indicate that you'll be any damn good at SQL. I think the time it takes depends on what competence looks like for your use case. If we're talking about just retrieving records that match certain criteria, you might get over the hump of understanding joins faster than a non-programmer, and you could probably write 90% of the queries you'll ever need in a week or less. Reporting is different. Designing schema is different. Troubleshooting data issues in a poorly designed database is way different. Tuning queries and indexes for performance is way different. Not all use cases include those things.