I'm a member of the amazing Virtual Coffee online community. For about 2 1/2 years, I've watched aspiring developers discuss their struggles, wins/losses, ask for help, learn, and grow into professional developers.

In our many video and Slack discussions, we talk about job hunting, interview preparation, and the struggles of live coding and take home assignments during interviews. Many of the aspiring developers go to great lengths to create portfolio apps from boot camps, maintain an active Github a profile, and participate in "leet" code, kata, or code war challenges. I'm always very impressed by their tenacity and dedication to their craft.

WARNING: Opinions below. Take them with a grain of salt. YMMV.

I often see these aspiring developers spend so much time "preparing" that they have never actually produced anything that solves a real problem. I have often given the advice that scratching your own itch and building a useful product might be better than all this preparation. This "product" doesn't have to be a money making thing. Otherwise you might actually not need a job! It could just be some tool you've created for yourself to solve a simple problem. It could be an amazing spreadsheet you created for your accountant friend. It could be something to help a local charity process new food intakes. Perhaps you've created a website for a local business. It can literally be anything that solves a problem or entertains someone.

As anecdotal evidence, I present this quote from Tony Dinh, the creator of BlackMagic and TypingMind.

My technical skills: I can write code very fast. Coding is the easy part for me. I’ve been writing code since 15. I have written code almost every day over the past 8 years. I can’t solve medium Leetcode problems and don’t write the best clean code out there, but I still love writing code and putting code together to make something useful.

Personally, I have never even attempted any of these "code war" problems before. I don't do any of those katas or other type challenges. I bet most of you "junior developers" would run circles around me at those challenges.

My point is that you can create profitable, useful, and/or innovative products without being a particularly good programmer as long as you find something you like to work on and solve a problem that you or someone you know has.

If you enjoy doing these code challenges, that's great. I'm sure they can be very educational. Enjoy! However, if you're just doing them to "level up", I think you'd be better off just solving a real problem with code. Then in interviews, you'd have a real code base to demonstrate your skills to potential employers. They will see that you have the ability to solve actual problems. Your code base can demonstrate to them you have the technical skills, the initiative, and the tenacity to solve problems just like they will need you to do in their work environment.

Please understand, that I'm not discounting your struggles. Breaking into the tech industry is very hard to do. There are way too many hurdles and ridiculous hiring practices in this industry. However I believe a real product that you have created yourself and can demonstrate during interviews may do more to help you get the job you desire than some scorecard on a "coding wars" website. In the long run, you have to do what is best for you to get a job in the tech industry. Maybe the best thing is what you're already doing or maybe it's a combination of what you're doing now and what I'm suggesting.

But!!: Sometimes, I've suggested this approach and heard back from people that you shouldn't have to be a programmer in your spare time. Your hobby shouldn't have to be programming. You should be able to have a life outside of work! That is all 100% true. However, if you're trying to get your first developer job, you have the choice of either spending your spare time on code challenges that may not help you at all or spending that same time building something useful. I know which I would choose.

To Hiring Managers: Please stop using coding challenges, white boarding, and take home assignments as your default way of evaluating a candidate. Instead, find out if they have a project that they've created themselves from scratch. Get permission to access their git repo, review the code, evaluate their coding style, and see their growth over an extended period of time. In the interview have them walk through the code to make sure they truly understand it. Also ask them for an explanation of why they wrote a function a particular way and how they may change it now that they're more experienced. You're much more likely to find out how well somebody can code this way than from some random coding challenge or whiteboard problem.

Photo Credit: Nubelson Fernandes