Many of us transitioning into the data analyst field struggle with professional experience. it's that Catch-22. How do you get hired without experience? But how do you get experience without getting hired? But one of the best ways to get experience with a professional role is to build a portfolio, with specific projects. Creators like Alex Freburg, Luke Barousse, John Pauler and Avery Smith recommend this route. Along with others who have transitioned into the data analytics field. If you need ideas on what kind of projects to build, check out my article, 10 Project Ideas for Beginner Data Analysts. Having an individual personal portfolio can set you apart from other candidates who have only taken courses. It showcase your ability to take what you've learned and apply it to a project.
I've been building my portfolio for almost a year now. Here are three lessons I've learned from creating four plus projects. If you want to check out my personal portfolio click here.
Lesson 1: Always check the data
Inspect the data to make sure it's not dirty. For my Harry Potter data analysis project I noticed a problem with the dialogue data which had over 5,000 lines of dialogue. I wanted find the number of times a spell was spoken in the dialogue. To figure out the most popular spell. While searching I saw that several spells were spelled incorrectly. I cleaned the data and inserted the correct spelling so my analysis would work.
In this case, the only reason why I knew a spell was spelled incorrectly is because I'm a Harry Potter nerd. It did teach me the importance of always checking the data. Even if someone claims it's already been cleaned. It helps with preventing using dirty data in your analysis. You also get practice cleaning data which is an important role in what you do as a data analyst.
Lesson 2: Prioritize the message
Make sure the main goal of any project is to the message across. In my first dashboard for the LinkedIn Hard Mode challenge I combined views, likes, comments in one graph. Because I liked how compact it looked in my dashboard. But after posting it on LinkedIn, someone commented that it was difficult to see the difference between views and engagement. As they said "because views dwarf comments and reactions", they recommended creating a separate graph for engagement (likes and comments) and views. I changed it, I separated the view and engagement into two separate graphs. You can view my post about it here. As I said in my updated LinkedIn post, I made the mistake of prioritizing design over clarity. When in reality good design is about clarity. When making any dashboard or chart the main purpose is for it to be understandable.
This concept goes for any project you are working on. You want to make sure your idea gets across. Whether that's through clear documentation, a readable dashboard, or well-written code. Either way the more straightforward it is the better. It lets you in practice with communication. In this case you are being clear about what kind of project you are creating.
Lesson 3: Stick to general standards
Iff you're using a specific tool like python for instance. Make sure to stick to general naming conventions and other things. I created a program in Python, Restaurant Picker, to randomly pick a restaurant based on a few criteria. When I posted on LinkedIn someone commented with a few suggestions to my code. They had suggestions to adhere to professional Python standards. For instance, for my restaurant objects I used Camel Case. Which is not common in Python. While the program does works and does what I wanted it to. If I use it in a workplace setting, I need to stick to general conventions that are accepted within the language. Why? It's easier for others (and yourself at a later date) to read. It helps convey the code clearly.
Another example is while you can write all of SQL in lowercase you shouldn't. First, it's quite uncommon. The traditional convention is having your keywords (i.e. SELECT, FROM, WHERE) in capitalized letters. Second, is if you write in only lowercase it becomes confusing to anyone reading your code. It's essential that you stick to this convention. Especially in the workplace if someone else needs to read your code it's more readable with a mixture of uppercase (for keywords) and lowercase words (for everything else) . For charts, a general standard is for positive numbers (increasing) to be colored in green and negative numbers (decreasing) are red. Switching these colors can be confusing for anyone who looks at your chart/dashboard.
That's all the tips I've come up with. If you'd like to share your tips with me feel free to email me at kelly@kellyjadams.com. If you enjoy these types of posts subscribe to my newsletter, Kelly's Bytes for weekly blog updates.
Kommentare