The second week of the phase finishes on this day, and with it the first challenge of this phase has concluded. During this week, we worked on an interesting exercise called Interviewmania, in which half of us would take the role of interviewer and the other half that of the interviewee. For this first round, which focused on the technical and more theoretical side of the interview process, I was assigned the role of interviewee, and as such my task during this first fortnight was to get ready for the interview itself, rather than preparing the questions or dynamic (roles will be reversed on the latter half of the month, so that will be my task the next couple of weeks).

In order to prepare for this mock interview, I spent the last couple of weeks both polishing the skills I’ve acquired during the last months, but also studying the theory and concepts that are fundamental to the base knowledge of any software engineer. The main difficulty I had during this phase has been the fact that I don’t have a formal background on computer science, so while a lot of concepts have been taught to me through practice and example, little by little I realized that a lot of the core concepts I should know by now weren’t all that consolidated in my mind, having some sort of understanding but lacking the theoretical foundations necessary to connect all of these ideas and cement them into a coherent knowledge floor.

With that in mind, these couple of weeks I’ve been studying the theory behind OOP, design patterns, testing, data structures, agile methodologies, JavaScript functionalities, as well as some concepts of the framework I selected, Angular. While I’ll be the first one to admit that I’ve never been great at studying theory for tests, I must say that the interview itself went surprisingly smoothly, and even though I was extremely nervous and was lacking confidence on my knowledge, once my interviewer started asking his questions and I realized that I actually knew the answer to them it boosted my confidence on both myself and on my knowledge regarding computer science theory and methodologies. I don’t want to get cocky, as I’m aware this was merely practice and there is a lot I still need to know and master in order to ensure success in a future interview, however this exercise has been quite revealing and insightful as a more accurate measure of my abilities, as least more accurate than the self-doubt and imposter syndrome we usually encounter when evaluating ourselves.

That was the interview itself, on the other hand, the rest of my week was spent working on the The HackerRank Interview Preparation Kit, an assortment of several programming exercises designed to practice the most common topics encountered during the technical portion of software position’s interviews (which will be the main focus of the second round of Interviewmania). So far, I’ve completed a little over 2/3 of the exercises provided, and by working on these I’ve been able to get some hands-on experience working with several data structures, such as stacks, queues, linked lists, binary trees and the like; as well as different programming techniques, such as dynamic programming, greedy algorithms, binary search and much more. The Interview kit has also been a great tool to practice both Java and JavaScript, as those are the languages, I’m doing the exercises on, and I’ve come to find it a great tool in getting more comfortable with the syntax and capabilities of these languages.

Finally, as for my You don’t know JS weekly progress, I wasn’t able to read a lot, other than some exceptions where the this keyword doesn’t follow the expected binding, mainly regarding the use of null as a parameter when binding the object in order to curry the parameters, which led to me learning the technique of creating a DMZ variable to pass a null parameter as such: var ø = Object.create( null ); . Other than that, during my preparation for the interview I discovered the fact that arrow functions introduced in ES6 don’t have the same this behavior as normal function declarations, behaving in a way more natural to other languages (meaning that this value refers to the object itself rather than being dependent on the call-site). This particularity of arrow functions is useful in some instances, such as constructors in classes, but harmful in other, such as methods in Vue (which is the reason why the use arrow functions isn’t recommended).

That would wrap up this week’s happenings. Let’s work towards another eventful week!

Interview