The Dreadful Timed-Coding Challenge

I’ve been applying to new software developer jobs recently, and getting some interviews which provide a code challenge to complete online. I’m able to complete those challenges, but still get rejected. However, no one ever tells you why they rejected your application, so it’s up to you to figure out what to improve, and how.

Upon reflection, I found I dreaded the timed coding challenge. I looked back on my programming experience for the last 5 years. I solved some pretty big problems at work and even on personal projects, all on a tight deadline. So why was there this lack of confidence? Looking at problems on HackerRank and LeetCode, I felt like I was back in my old CS classes, when data-structures and algorithms (DS & A) were fresh on my mind but still largely theoretical bits of information. My relationship to DS & A had changed over the years I’d been a practitioner in an enterprise company.

The data-structures I used at work were simply what aligned most closely to the manner in which the data was used, without being super-concerned about efficiency or optimization. I used Lists, Dictionaries, Sets and Generators in Python, and just Lists and HashMaps in Java. I sometimes needed to implement a custom class to encapsulate a set of behaviors and related data. But, oddly enough, I never needed my own linked list for any program at work, because there simply wasn’t the need for it.

Skill acquisition, from my own personal experience, is like a 3D spiral. In the horizontal dimension, you have the fundamentals of the craft and practical application at opposite ends. In the vertical dimension, you have your experience, going from nil to mastery, bottom to top. As time goes on, you go up in experience. The smooth spiral motion only occurs when you revisit fundamentals and practical application, over and over again, but with the insight of more experience.

Thinking about this, I finally realized what had happened and where the fear and the dread came from. My spiral was messed up because I didn’t revisit the fundamentals of my craft. I’d let my ego blind me from the harsh truth of it.

An Art Teacher’s Advice

The other day, I picked up a book on my art training bookshelf, The Natural Way to Draw, by Kimon Nikolaides. Whenever I’m not programming, or reading fiction, I like to spend my energy on improving my drawing skills.

This book was what I used for art training many years ago. I keep going back to its exercises and drawing schedule it provides. Each chapter contains 15 hours’ worth of drawing exercises, and even after all these years, I haven’t been able to get past the 3rd chapter. But giving up is not an option for me and I started all the way from the beginning, once again.

I’ve read the introduction over a dozen times, very carefully, in the years that I’ve had the book. As I’ve risen in the spiral of mastery, I started to better understand the seriousness of the meaning behind his words. Here’s the paragraph that really struck me this time.

There is a vast difference in drawing and making drawings. The things you will do - over and over again - are but practice. They should represent to you only the result of an effort to study, the by-product of your mental and physical activity. Your progress is charted, not on paper, but in the increased knowledge with which you look at life around you.

This is timeless. I know I’ve been guilty of putting too much stock on making quality stuff, even though I didn’t have enough practice of fundamentals to pull it off. What Kimon is saying here is so important that you should read and re-read the paragraph. Substitute programming for drawing. Then you’ll realize difference he’s talking about.

As programmers, we work at our day jobs building useful features and enhancements. Those project-based tasks come under making programs. Working on pure coding problems on online platforms like LeetCode or HackerRank, or even just reading about and practicing fundamental DS & A stuff, those come under programming. The beginner’s (or even the advanced) programmer’s mistake is confusing the latter with the former. When I was struggling with a coding challenge, I felt like I was not measuring up to my self image of constant excellence, which I’ve created and maintained in my workplace. This was so wrong of me to do, and something you’d never do to anyone but yourself.

I was so involved in making programs that I put off revisiting, and studying programming, erroneously thinking I didn’t need to. One should always be conscious of the difference and approach each with the appropriate mindset.

Past the Ego’s Fear

Everything in life is related. The most commonplace things can inspire contemplation into the greatest truths. By putting my fear of coding challenges under a microscope, I was able to uncover unpleasant truths about my unconscious lack of kindness towards my self.

In my art practice, I can never do a good drawing when I intend to show it off on Instagram for likes and appreciation, which makes my ego feel good. When I draw in my sketchbook for myself, I create strokes of genius which makes me wonder why I’m ever doing anything else at all. Here, I didn’t draw for my ego which is always hungry for rewards at the end of any task, but simply enjoyed the process of creating which is the only reward my deeper self ever needed.

The job application process makes it difficult to not be your ego. After all, you’re constantly describing your achievements, victories, accolades and skills. Your ego tends to flare up when you do that. You start to identify your Self with your work. I’ve found through both my art and programming practice, this is never healthy. You are never your work. You are not your resume or your achievements, or failures. You’re not even your name on the resume. You never were.

But for practicality’s sake, we have a body and need to function with it in the world. I want a job to live well, and maybe buy a PSVR2 and play Resident Evil 8 on it! To get the job, I need to present myself with confidence, which comes from skill. For building the skills as a programmer, I follow Kimon Nikolaides’ advice. I do coding practice as an effort to study the fundamentals of the craft. Whatever code I produce in that time, the quality doesn’t matter. Did I solve the coding challenge? Don’t care. Was the by-product of my time any good? Doesn’t matter. It was the experience that I walk away with that matters. The thoughts, the joy, the struggle, the lessons learned, all intangible but unmistakably real benefits, real memories and experience that I accumulate.

I now structure my programming study just like my art studies. I’m learning to put off the ego, and be comfortable being without it, and just put my attention on the process because that’s where it should be.

Being in the process of drawing in my sketchbook, painting on canvas, and pumping iron at the gym is where the fun is. I’m not afraid of coding problems anymore. I enjoy them, simply because I enjoy being in the process of programming. I know that if I simply focus on the problem to be solved instead of my ego’s reactions, I’ll be okay.