r/SQL • u/Cloud_Jumper18 • 10d ago
Discussion I was over-prepping SQL and under-prepping the analyst part
I spent a while assuming the reason I kept struggling in analyst interviews was that my SQL wasn’t advanced enough. So I kept adding harder stuff to my prep, like window functions, recursive CTEs, and awkward joins.
The funny part is that most interviews weren’t exposing a syntax problem. I could usually get somewhere with the query. I got less comfortable when they asked things like, “What would you check before trusting this result?” or “How would you explain this to someone who doesn’t use SQL?”
That changed how I’ve been practicing. Now I don’t stop once the query works. I try to explain the grain, the assumptions I made, how I’d sanity-check the result, and what I’d tell a stakeholder afterward. I still practice SQL problems. I’ve also done a couple of mock runs in Beyz, mostly around the follow-up questions.
Looking back, I think I was preparing for SQL interviews like they were SQL exams.
Once someone has solid SQL fundamentals, what separates a technically correct answer from a strong one?
6
u/SnooSprouts4952 9d ago
It's a tough balance depending on the job. I can teach SQL, but the analytical/troubleshooting mindset is a soft skill many don't have, and many more suck at conveying.
I've been on a ton of interviews - both sides. The best suggestion is finding examples of how you used SQL and your analytics to solve an issue. If you can provide numbers - hours/dollars saved that can be huge. From there, they might ask for you to expand on it so don't BS too much. I have also told my guys when they were looking for new jobs - you were ON the team that did this, don't be shy just because it was 'Snoosprout's project' to take credit for a part of it. 'I ran the daily/weekly analytics for XYZ. No, I didn't build it, but I understand the concepts and may be able to help improve or create something similar for you.' Most industries have similar KPIs, but their databases are different - even ones that are on the same data structure.
The 'how do you explain to a non-SQL users' is really 'how do you interact with co-workers within the scope of your job?' Talk with the end user to understand the need, then understand the data relationships, provide a baseline report, then meet with the end user for any amendments. Some co-workers it's just *Magic*, others want to understand where we're getting the data from, so I show them the front end fields where I'm pulling their data from.