From The Challenges - JSON Parser

Common Mistakes With The JSON Parser Coding Challenge

Hi this is John with this week’s Coding Challenge.

🙏 Thank you for being one of the 61,973 software developers who have subscribed, I’m honoured to have you as a reader. 🎉

If there is a Coding Challenge you’d like to see, please let me know by replying to this email📧

Welcome To Coding Challenges - From The Challenges #2!

In this new format for the Coding Challenges newsletter I’m going to be sharing some of the generic common mistakes I see software engineers make when tackling the Coding Challenges.

I’ll be sharing what mistakes people make how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally.

Recapping The Build Your Own JSON Parser Coding Challenge

In the build your own json parser coding challenge the goal was to build your own JSON parser.

Building a JSON parser is an easy way to learn about parsing techniques which are useful for everything from parsing simple data formats through to building a fully featured compiler for a programming language.

Five Common Mistakes Software Engineers Make Solving the Build Your Own JSON Parser Coding Challenge

I’ve pulled together this list of common mistakes from the submissions I’ve been sent privately and those shared in the Coding Challenges Shared Solutions GitHub Repo.

Mistake 1 - Not Using Your Language’s Unit Testing Suite

Whether you approach this coding challenge using Test-Driven Development or you write your tests after your code, this is a project that benefits from automated testing. Why? Because this challenge has nearly 40 tests to run, not a huge number, but more than I’d want to run manually after every change.

So this coding challenge is a great project to learn how to use the automated/unit testing frameworks available for your programming language/tech stack of choice and to demonstrate (if you need to) that you have experience applying it to a real-world project.

Lesson: learn to use the commonly used tools for your tech stack. Automate your tests (so you can do more fun things).

Mistake 2 - Hard Coding Values And Minimum Tests

A number of solutions contained hard coded values for the input, so they weren’t actually useable programs.

Many of these hard-coded the four simple test cases provided in the text of the coding challenge and that’s all they ran.

Lessons:

1. Write useable solutions, the aim of Coding Challenges is to create real-world software.

2. Don’t hard code input.

3. Add your own tests, consider edge and error cases.

Mistake 3 - Naming

Naming is hard, but try to avoid generic names like utils or error in your code.

Lesson: Use the names of variable, types, functions, modules or packages to clearly convey what they do.

Mistake 4 - No README.md

You don’t need a README to complete the coding challenge, but if you’re going to share your Github repo as an example of your work it makes sense to include one. More importantly however it’s always good habit to store some documentation with you code. The documentation should explain how to do all of the following (as relevant): build, run, test and deploy the project.

Lesson: Get into the habit of writing some core documentation for each project your work on. It’ll help anyone else (i.e. your team) working on/with it and it’ll help you when you come back to your work at some point in the future and don’t remember the details.

Mistake 5 - Only Building Part Of A Solution

The idea of this coding challenge is to build a useable library or command line tool. Something that could be the basis of another project because it’s fully useable. Many of the solutions weren’t.

Lesson: To maximise your learning from a project like this, ensure it is complete. Don’t skip the harder bits

Bonus Points - Doing The Coding Challenge In Multiple Programming Languages

Several people deserve bonus points for having tackled this coding challenge in several programming languages. Especially the people who uses programming languages that support different paradigms, i.e. the people that implemented it in object-orient and functional programming languages.

Tackling the coding challenges this way is a great way to learn about both the challenge and the languages and paradigms you’re using. Learning where their strengths and weaknesses lie.

Request for Feedback

I’m writing these coding challenges and this new from the challenges series to help you develop your skills as a software engineer based on how I’ve approached my own personal learning and development.

What works for me, might not be the best way for you - so if you have suggestions for how I can make these challenges more useful to you and others, please get in touch and let me know. All feedback greatly appreciated.

You can reach me on Twitter, LinkedIn or through SubStack

Thanks and happy coding!

John

P.S. If You Enjoy Coding Challenges Here Are Three Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. Sign up for a paid subscription - think of it as buying me a coffee ☕️ twice a month, with the bonus that you also get 20% off any of my courses.

3. Buy one of my courses that walk you through a Coding Challenge.