Kenan Tufan K.’s Post

I used to save SQL questions for later but this time I actually solved them. I came across a post by Pradeep M with SQL interview questions and decided to work through them one by one. • Solved 10 questions • Practiced joins, aggregations, and window functions • Worked on real-world scenarios like DAU, retention, and segmentation I focused not just on the solution, but on understanding why it works - especially around edge cases and function choices. Sharing my solutions and approach in the document below 👇 Thanks Pradeep M for sharing these, really helpful for practice. Open to feedback and always looking to improve. #SQL #DataAnalytics #Learning #InterviewPreparation #OpenToWork

📊 Today I Learned: Using JOIN in SQL As part of my SQL learning journey, today I explored how to combine data from multiple tables using JOIN. 🔍 This is one of the most important concepts in SQL because real-world data is usually spread across different tables. 👉 I practiced using INNER JOIN to connect customer data with their orders. 💡 Key Learning: By joining tables, we can easily analyze relationships — like which customer purchased which product. 📈 This is a powerful step toward turning raw data into meaningful insights. #SQL #DataAnalytics #LearningJourney #BusinessAnalysis #OpenToWork

Today I spent some time revisiting the difference between NOT IN and NOT EXISTS in SQL to strengthen my understanding. At a basic level, both are used to filter out records, and they often look interchangeable. But when I explored a bit more, I realized they behave differently in certain cases. One important thing I noticed is how NULL values can affect the result. If the subquery used in NOT IN contains NULL, it can lead to unexpected results or even return no data. On the other hand, NOT EXISTS works differently and checks row by row, which makes it more reliable in such scenarios. Takeaways: NOT IN works fine when you are sure there are no NULL values NOT EXISTS is safer when dealing with real-world data Small differences in SQL logic can have a big impact on results This helped me understand how important it is to not just write queries, but to think about how they behave with actual data. Still learning and improving step by step. #SQL #DataEngineering #Database #LearningInPublic #OpenToWork

Day 7 of my SQL series Today I solved a real-world SQL problem using GROUP BY and HAVING. This is how data analysts summarize data and extract meaningful insights. This type of question is very common in interviews. Next: SQL Joins #SQL #DataAnalytics #Learning #CareerGrowth #OpenToWork

🚀 Day 2/30 — SQL Basics Every Beginner Must Know If you’re starting with SQL, these 3 commands are your foundation 👇 1️⃣ SELECT → Used to choose columns from a table 2️⃣ WHERE → Used to filter data 3️⃣ ORDER BY → Used to sort results 📌 Example: Imagine you have a sales table SELECT name, revenue FROM sales WHERE revenue > 5000 ORDER BY revenue DESC; 👉 This query shows top-performing customers with revenue greater than 5000 Simple, but powerful. 💡 What I realized today: SQL is not about memorizing queries, it’s about asking the right questions from data. 💬 Question for you: What was the first SQL query you learned? Let’s learn together 🤝 #SQL #DataAnalytics #LearningSQL #DataAnalyst #OpenToWork

One small SQL mistake can completely change your insights. I learned this the hard way. I used an INNER JOIN instead of a LEFT JOIN… and lost 30% of my data without realizing it. No errors. Just misleading results. 🔍 "INNER JOIN" → only matching rows 🔍 "LEFT JOIN" → keeps all records In analytics, this matters more than it seems: * You might exclude users with no transactions * Metrics can become misleading * Decisions can be based on incomplete data That’s when I realized: "Good analysts don’t just write queries, they question their data." Now I always ask: “Am I accidentally dropping data?”🤔 What’s a SQL mistake that taught you something valuable? 👇 #OpenToWork #DataAnalyst #SQL #DataAnalytics #CareerGrowth #DataAnalytics

🚀 SQL I recently solved an interesting SQL problem that focused on calculating a confirmation rate per user using joins and conditional aggregation. 🔍 Key Concepts Used: LEFT JOIN (to include all users) GROUP BY (to aggregate per user) Conditional aggregation using SUM(condition) Handling NULL values with IFNULL Formatting output using ROUND 💡 Core Insight: Instead of writing complex subqueries, I used: SUM(action = 'confirmed') / COUNT(action) This approach efficiently calculates the confirmation rate while keeping the query clean and optimized. 📊 Final Query: SELECT s.user_id, ROUND( IFNULL(SUM(c.action = 'confirmed') / COUNT(c.action), 0), 2 ) AS confirmation_rate FROM signups s LEFT JOIN confirmations c ON s.user_id = c.user_id GROUP BY s.user_id; ⚡ Outcome: ✔️ Accepted solution ✔️ Optimized performance (Beats 87% submissions) 📌 What I Learned: Writing clean SQL is more important than complex SQL Conditional aggregation is a powerful interview technique Always handle edge cases (like NULLs or division by zero) I’m continuously improving my SQL and Data Analytics skills as I transition into a Data Analyst role. #SQL #DataAnalytics #LearningJourney #LeetCode #OpenToWork #CareerGrowth

🚀 **SQL Window Functions changed the way I analyze data.** When I first started learning SQL, I mostly relied on **GROUP BY** for aggregations. But I quickly realized one limitation: once you group the data, you lose the row-level details. That’s when I discovered **Window Functions** — and it completely changed how I think about SQL queries. Instead of collapsing rows, window functions allow you to **perform calculations across rows while keeping the original data intact**. With concepts like **ROW_NUMBER(), RANK(), DENSE_RANK(), LEAD(), LAG(), and running totals**, SQL becomes much more powerful for real analytical work. The more I explore SQL, the more I realize that **small concepts can unlock powerful data insights**. #SQL #DataAnalytics #WindowFunctions #LearningInPublic #DataSkills #OpenToWork 

One SQL function every Data Analyst must know 👇 RANK() 🎯 Simple concept. Powerful output. RANK() skips numbers on a tie! 🤯 And its two cousins 👇 → DENSE_RANK() — No gaps in ranking 🔢 → ROW_NUMBER() — Always unique, no ties 🔑 Quick memory trick 🧠 🏅 RANK() = Olympics rankings — gaps exist 📦 DENSE_RANK() = Packed tight — no gaps 🔑 ROW_NUMBER() = Always unique — no ties One interview rule that will save you ⚠️ Never filter RANK() directly in WHERE clause. Always wrap it in a CTE first. 💡 Save this. Thank me later. 😄 Found this helpful? Like and share so others benefit too! 🙌 #SQL #DataAnalyst #DataAnalytics #SQLTips #LearningInPublic #DataScience #Upskilling #CareerGrowth #OpenToWork #SQLServer #MySQL #InterviewPrep