Teaching yourself SQL when your job is ops
I taught myself SQL. No bootcamp and no data degree. I took an online course, did a lot of practice problems, and then started answering real questions at work. If you’re in sales ops, RevOps, or finance and thinking about learning it, here is what I’d pass on.
Start with questions, not syntax
Pick three questions you get asked every month. Which reps are creating pipeline? Where do deals stall? Which accounts have gone quiet? Learn only what you need to answer those. SELECT, WHERE, GROUP BY, and one JOIN cover more ground than you’d expect.
Do the practice problems anyway
LeetCode-style problems feel artificial, and they are. They still build the habit of breaking a question into steps, and they put window functions and CTEs in front of you long before your day job would. Twenty minutes a day beats a weekend binge.
Learn window functions earlier than feels reasonable
Most operations questions are really “compared to what?” This month against last month. This rep against the team. First touch against latest touch. ROW_NUMBER, LAG, and a running SUM answer a large share of them.
Distrust your first answer
A query that runs is not a query that’s right. Joins quietly duplicate rows, and filters quietly drop them. Count rows before and after every join, and reconcile one number against a source you trust before you send anything to anyone.
Write it so the next person can read it
The next person is usually you, three months from now. Use CTEs with plain names, and leave a comment on anything that isn’t obvious.
The payoff is speed. The gap between having a question and having an answer shrinks from days to minutes, and that changes which questions you bother to ask.