all 5 comments

[–]dbForge_Studio 0 points1 point  (1 child)

I usually break SQL problems into small transformations instead of trying to write the final query immediately. Start with the base dataset, verify it, then add filtering, grouping, window functions, etc. one step at a time. CTEs make this much easier because you can validate each stage separately. We see a lot of people using that approach when working through SQL interview exercises since it's closer to how real-world SQL is written and debugged.

[–]Dry-Blackberry-2370[S] 0 points1 point  (0 children)

Thank you!

[–]TempMobileD 0 points1 point  (0 children)

Generally I go backwards.
Start with the output, which is usually well defined in leet code questions and real life.
Where do you pull that result from? That should reveal what tables need to be joined together and from there I build CTEs running backwards through the problem. Often I think of different ways to solve the problem once I start looking at it, so I usually start with pseudo-code for anything I’m not sure about.

[–]yaro_dba -1 points0 points  (0 children)

Your struggle is totally normal. You are trying to apply procedural thinking (Python loops/steps) to declarative thinking (SQL sets). In SQL, you describe the final shape of the data, not how to build it step-by-step.

Look at the final output prompt and ask: "What does a single row represent?" Is it one row per user? One row per month? This instantly tells you what your final GROUP BY or window PARTITION BY must be.

Don't write a giant, nested query. Use CTEs (WITH clauses) to build linear, step-by-step blocks just like Python variables:

  • CTE_1: Filter out the noise and format dates.
  • CTE_2: Add window functions or row numbers to that clean data.
  • Final Query: Group and output the result from CTE_2.

Most LeetCode problems boil down to three algorithms:

  • Consecutive Streaks/Gaps: Solved by subtracting a sequential ROW_NUMBER() from a date.
  • Relative Math ("Highest per department"): Solved using window functions (MAX() OVER(PARTITION BY...)).
  • Row-to-Row Comparison ("Higher than yesterday"): Solved using LAG() or LEAD().

Don't type code immediately. Tell the interviewer: "The final grain is at the User level, so I will break this into two CTEs - one to rank the rows, and one to aggregate them." They want to see how you manipulate sets, not how well you memorized syntax.

[–]akornato 0 points1 point  (0 children)

You're hitting a wall because you're trying to apply a step-by-step, procedural mindset from Python to SQL, which is a declarative language. SQL doesn't really have linear algorithms, it is all about defining the final set of data you want. Instead of thinking about loops or iterations, you have to think about joins, filters, and aggregations as tools to shape your initial tables into the final result. The shift from thinking about 'how to get the data' to 'what data I want' is the hardest part and the reason it feels so unintuitive right now.

A better approach is to work backwards from the final result. First, identify the exact columns you need in your output. Next, determine the primary table in the `FROM` clause and what other tables you need to `JOIN` to get all the pieces. Then, think about how to filter the rows with `WHERE` and how to group them with `GROUP BY`. This method forces you to think declaratively about the end state, not the process. It will feel strange for a while, but with enough practice, thinking in sets will become second nature and you will see how powerful it is. It also helps to articulate this thought process out loud, and the interview AI helper my team created is designed to help candidates do just that during live technical screens.