{I posted Day 1 and Day 2 on the same day bcz i wrote about Day 1 yesterday but had the idea of posting it here today only, so...here it is}
Today I realized something. SQL isn't actually the difficult part. Thinking is. I spent hours writing queries, but the challenging part wasn't remembering GROUP BY or CASE. It was figuring out what question was actually worth asking. Before writing a single query, I had to stop and think, "If I were the HR manager, what would I want to know from this data?" That changed the entire way I approached the project. At first, I was mostly counting things. How many people left? How many employees travel frequently? But then I realized that counts don't really tell the full story. If one department has more employees than another, of course it'll have more people leaving. What actually matters is the attrition rate. From today onwards, almost every query I wrote included:
Attrition Rate = Employees Left / Total Employees × 100
That one metric made my analysis much more meaningful.
One thing that surprised me was how often my assumptions turned out to be wrong. I noticed that the Sales department had the highest attrition rate. My immediate thought was, "Maybe they work the most overtime." Sounds reasonable, right? So I tested it. Turns out, the overtime rates across departments were pretty similar. My explanation didn't hold up. That was a good reminder that data analysis isn't about proving your assumptions correct. It's about testing them, even if the result isn't what you expected.
I also learned that one answer usually leads to another question. For example: Employees who travel frequently have higher attrition.
Does that mean one department travels more?
Does overtime explain the department with the highest attrition?
Does work-life balance change things?
What if I combine work-life balance with marital status?
Every query naturally led to the next one. I stopped writing random SQL and started following a trail of questions.
Another lesson was about percentages. At one point I found that divorced female employees with certain work-life balance ratings had 0% attrition. For a second, I thought I'd discovered something interesting. Then I checked the sample size. There were only a handful of employees in that category. Lesson learned: percentages without context can be misleading. Whenever I see 0% or 100% now, the first thing I want to know is, "How many people does this actually represent?"
I also finally understood why MySQL kept throwing ONLY_FULL_GROUP_BY errors at me. Earlier, I was just fixing the errors somehow and moving on. Today, it clicked. If I'm grouping by one column but trying to display another, MySQL has no idea which value I want it to show. Once I started thinking from MySQL's perspective instead of just memorizing rules, those errors became much easier to understand.
Another small realization: not every variable should stay as it is. For things like distance from home or age, looking at every individual value wasn't very useful. Grouping them into broader categories made the results easier to understand. I even changed my distance groups midway because the smaller groups were showing almost identical attrition rates. Sometimes simpler is actually better.
One thing I'm consciously trying not to do is let Chat GPT think for me. There were plenty of moments where I wanted to ask, "Give me business questions for this dataset." But i was like nah ima not do that. The goal of this project isn't to finish it as quickly as possible. The goal is to become someone who can look at a dataset and naturally start asking good questions. If I outsource that thinking, I'm only cheating myself.
Finally, I realized that this project isn't really about SQL anymore. SQL is just the tool. The real skill is asking good questions, testing ideas, accepting when they're wrong, and slowly building a story from the data. That's what I'm trying to practice.
No comments:
Post a Comment