Reflecting on my first pair programming interview
For those who don’t know what is pair programming, it is basically a software development technique where two developers/software engineers work together on the same machine. At any one time, one would be doing the actual programming and the other would be reviewing the written code. In both cases, communication between the two developers/engineers is very important.
Pair programming is usually done at some companies who want shipped codes or software that has fewer defects. After all, defects on shipped code could mean higher cost in terms of quality checks and troubleshooting.
And for some companies pair programming is also done as one of the interview stages. One of the purpose is the interviewer to figure out if you are suitable for the position. Interviewees are judged on their soft skills such as communication, ability to problem solve, plan and think critically, and technical capabilities. Another purpose would be to determine if the interviewee is able to work with other developers in the company.
Pair programming interviews are also there for the interviewees to understand who they are working with and how they may have to work in the company. It’s a good chance to find out if he or she is suitable for the applied role.
For me, despite working as a software engineer for five years now, I have never done pair programming. Most of the time, I work alone or in a team. And when it comes to interviews, the toughest kind I get are those where you have to do technical quizzes, solve programming challenges or do whiteboard problem solving.
So having to do a pair programming interview for the first time is both exciting and scary. And sad to say, I didn’t pass the interview.
Towards the end of the interview, the interviewer gave some really honest and constructive feedbacks that are helpful for my personal growth. I thank him for that and for the time he spent on me.
At the same time, I feel really shitty about the interview failure, which is expected. But my mood is now about to fall off the cliff. For some context, I have been struggling with burnout for months, depression and forms of anxiety for the last four. My mood was only just stabilising after three weeks of anti-depressants.
Don’t get me wrong, I’m not looking for any sympathy nor trying to guilt trip anyone. I’m just sharing what I am feeling and have been through.
So what went wrong and could be better?
Low to average technical skills
My JavaScript fundamentals are weak. I was having issues with lambda and anonymous functions as well as some other fundamentals like passing of data. It prevented me from figuring out the solutions to some of the problems I encountered. The last time I did any decent amount of JavaScript was two years ago and even then, I only used the surface of what the language is capable of.
Making matters worse, I had to work with ReactJS, which is a JavaScript framework for developing UI. I also have to work with Redux, which is another JavaScript framework for state management. And it was no fault of the interviewer. I indicated that I want to do frontend development with ReactJS during the previous interview with one of the company’s employee.
At the end, a couple of hours spent every night for the past four days to learn ReactJS and Redux simply isn’t going to cut it.
But it doesn’t change anything. If I still want to be a frontend developer and be good with ReactJS/Redux, I have to keep learning and practice. And develop some apps using those frameworks along the way.
Failure to comprehend actual requirements
This is really on me. I was given the chance to read about the requirements and end goal of the exercise. The key focus areas were listed down in the document. But for some reason, I didn’t realise that I hadn’t really read and understand the whole thing before jumping in to come up with a solution. I could only attribute it to stress and anxiety.
Due to that, the solution I came up with was half-baked and caused major problems further down the development process.
Therefore, I really have to work on improving my resilience to stress and directing the brain to focus better. This is the only way for me to be able to understand future situations more clearly and come up with a better solution.
Overengineering
In software development, there are three principles that all developers should follow for higher productivity. They are:
- DRY => “Don’t repeat yourself”
- YAGNI => “You aren’t going to need it”
- KISS => “Keep it stupid simple or “keep it simple, stupid”
And because of my failure to comprehend the actual problem, my half-baked solutions caused me to violate principle 2 and 3. There were additional React components that I created that weren’t necessary and made the codebase more complex.
I’ll admit that I violated those two principles a lot of time during my five years of software development experience. It is because I like to provision for future uses. Breaking those principles served me well so far because I have experienced scope creep that requires components or functionalities that I thought of in advance and had implemented. That means, I didn’t need to spend extra effort to develop and refactor my code later.
Going forward, I really need to train myself on going for the simplest and fastest solution to any problem.
Took too long and prevented successful gauge of my skills
Because of overengineering, it took me more than twenty minutes to develop the application foundation. After which, I had to redo some of my codes in order to support certain functionalities that I have overlooked because of my failure to read and comprehend the requirements. More time was wasted.
Therefore, I was unable to implement the other features of the application that would have allowed the interviewer to determine my understanding of ReactJS and Redux.
Final thoughts
Self-awareness is actually a very important skill to have. With it, you might be able to determine if you are suitable for a given role or job.
In my case, the combination of my highly-sensitive nature, under-developed stress resilience, highly self-critical and low self-esteem meant that I hadn’t really been able to function at the level required for a so-called experienced software engineer who’s been at this job for at least five years. I’m simply not ready yet to take on roles that require me to be a consultant or a quick thinker.
The other thing that I figured out was that the number of years of experience isn’t really a good gauge of your skills. The interviewer did point out that despite my years of experience, I still wasn’t able to grasp ReactJS even after 24 hours (spread over four days) of reading and practice. He implied that he was able to pick up the framework within two days instead of four.
With that, it could mean that either my fundamentals are very weak or that I’m simply not smart enough to pick up something fast. Or maybe both. For the former, I could work on it by going to read and study the fundamentals again. For the latter, well, I can only work harder than most to achieve the same skill level.
Either way, I’m just glad that I’ve been through it and knows what’s out there. There are valuable lessons to be learnt here, which is all that matters.
