Category Archives: career

Blog post 1

The first quarter of the semester has come to a close. In CM-348 we have gone through a number of Git and GitHub features. Learning about pushing and pulling data, as well as doing some data cleaning was a great learning opportunity. As I finish my last year of school, I am trying to look at these processes in an analytical sense because that’s what I want to do moving forward.

In my free time over the past few weeks I have watched a lot of Alex The Analyst videos on YouTube. He has provided free knowledge on what it takes to become a data analyst. From interviews, to Git, to data visualization he provides a lot on his channel for people who want to learn. This week I watched his “2 Hour Data Analyst Masterclass” video. In this video, Alex breaks down what a data analyst interview process looks like from start to finish. He discusses what kinds of technical questions to expect, the importance of storytelling with data, and how to demonstrate value through projects or case studies. He also covers common interview mistakes, like not being able to explain one’s own projects clearly or failing to connect technical skills to business outcomes. This video was very insightful, he showed his viewers what skills you really need to get into the field, and it personally showed me some things I might need to work on.

I chose this resource because it’s directly relevant to where I am in my career path, as well as in my learning. I’m starting to build my portfolio and think seriously about interviews and job readiness. Alex’s advice helped me see how important communication is in data roles, it is more than being technically skilled, also being able to explain how your work impacts decisions. This connects to CM-348 because version control, documentation, and communication are key parts of the Git workflow. I am doing a bit of projecting here, but I look forward to watching more of his videos.

From the blog CS@Worcester – Tristan CS by Tristan Coomey and used with permission of the author. All other rights reserved by the author.

Week 13

The next classes will be about Software technical review it would be great to get a step ahead by delving into the concept. We only started with the review section of the code but fully understood it before the class could skip the barriers of never implementing this idea. Whenever doing something new there is always a barrier which can be difficult at first but with practical knowledge, it can be implemented with a greater effect.  

This article first talks about why there is a technical review. There are technical reviews for the company’s higher-ups who may not be fully aware of the coding process and the difficulties that come with it. They have to understand the developer’s importance to the business because they are spending a lot of money with ineffective results. Many times deliveries aren’t are time and come in fault states having several bugs. This is where a technical review comes in handy it’s a deep dive that provides a suitable perspective. Their definition of a technical review is a deep dive assessment of your software that provides findings and recommendations that be later adapted or discussed amongst your team. Common finds inside a technical review include slow or late deliveries which are just not meeting the due date, random or persistent bugs an example would be fixing the same thing over and over again, and sleepless nights because of worrying too much. These aren’t the end be it all every technical review is different and should be focussed on your team’s goals. The main discussion should be of pain points the things that keep you up at night to make the software complete. Process and team review is another key ingredient that makes sure everyone is working on the right task or if there are changes that need to be made plus an idea to every team member’s contribution to the project. The last thing the team should do is an effective summary that can be graded with a brief description. Detailed findings and recommendations that can be read by people not in depth with coding so they can get an idea of what is being done behind the scenes and can tell the team what needs to change.

Reading this article gave me an idea as to why we do technical reviews because when doing mine I was stuck trying to figure out problems in the code. I didn’t want to nitpick and find small issues that would seem redundant because at times it is better to keep it clean and simple. But understanding that this needs to be done to prove to people on the other side of the business that work is being done is a great insight. It makes a lot of sense that other people in a company would want to know what is happening on other sides of the department.

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.