Episode — 5
It’s been a month hosting PK from KEC and the enthusiasm to continue it further increases day by day. This week, we had some candidates from the talent pipeline along with a couple of questions. Sharing the highlights below:
Do I need to be excellent in English for better communication?
During the internship, these thoughts used to be prominent for me, and to clear the concept of communication, we were given an exercise to perform by our mentors. The exercise involved me and my friend and we were to play two different roles, one of being a student and seeking leave for an internship, and the other role was of authority granting the leave. The task of the student was to convince the authority for 2 months leave from college to pursue an internship and the objective of the authority was to convince the student to pursue an internship being in college. The role play started and there were a lot of arguments both ways, but the conclusion came none. From that moment onwards, I realized communication is not all about English, it’s how you are conveying your thoughts to make things happen. Be it any medium, the delivery of thoughts should result in a win-win situation for the parties involved.
What is your perspective on Quality assurance, who should be doing it? Why the job is so less dignified?
As far as I have experienced, Quality assurance is the most sensitive profile as it includes the final checks over the delivery of a product. QA includes whether the code checking in is optimum or not. It also ensures that whether best practices have been followed while making the product. As per my experiences, the QA person is the most skilled and experienced person in the team. The job is less dignified because in bigger MNCs the people who know very little code, are placed in the particular department. Also, it is quite a trending topic, as when I was in my college and interacted with my seniors, they used to share similar thoughts about how people are placed in the QA department. But working in ColoredCow, I realized the actual role of a QA person and how it should be done.
What is the importance of code review on GitHub?
GitHub code reviews provide a different thought process in the implementation of the solution in a code. I have experienced it several times when I was a beginner in CII projects during my internship phase, where the code used to get reviewed by experts. The feedback I used to get in my code simply use to reduce the lines of code to a maximum level and giving a hell lot of a different shape from the optimization point of view. I learnt from my experience that whenever I used to get lost in the coding part and just focused on making things happen, I use to miss the out-of-the-box thought process, that’s where a second mind usually helps. Be it an expert on your team or be it your peer, a code review always give a different angle to the logic and its coding implementation.
What is the importance of creating a project architecture not directly implementing and changing things on the go?
I tried this approach several times, where I had been in urgency or hurry and needed to get things done fast. Without making a proper architecture for a particular solution has always landed me in the beginning loop of solving a problem. One of the stories was during the basic preparatory exercises where I started building software without building its architecture. The moment I started coding, I didn’t have an idea what to write and where to write. It was like what should be the very first line of my code and what should be displayed on my screen. How my application would be connected and which integrations it would have for different functionalities. The moment I realized that it was a blunder to get directly into things without dissecting the problem first, I took out my pen and paper, sketched a solution on that, and built the architecture of the project digitally. Presented it to the mentors for a different thought process and feedback, modified and optimized it, and then worked on that accordingly. From that moment onwards, the very basic step I take is always to understand the problem first, strategize the solution and build an architecture around that. Once I am confident enough about what to build, where to build, and how to build, then I get into the implementation part.
