The 3 reasons why I ask about code patterns

Ville
3 min readJan 7, 2017

--

I’ve spent a lot of time interviewing Ruby and JavaScript developers in the past year and I always ask about code patterns. The responses I’ve received have been rather varied and also rather surprising.

I have three main reasons why I ask about patterns and why I think you should too.

Proven solutions for known problems

This is the obvious one. Lot of smart people spent a lot of time coming up with great ways to solve many of the problems you are likely to run into whilst you’re refactoring problematic code or building out new features.

Patterns often get a bad rap as it’s easy to over use them and shove them in places where they’re not appropriate making the code just more confusing rather than providing the good solution intended.

This stands true especially in certain younger programming communities where many of the developers have only seen the bad side of patterns and not where they have helped solve problems and tame code that would otherwise be wild and tricky to work with.

Even if you disagree with use of patterns or the language community shuns them I feel it would be good to learn about them and be aware of them.

Measure what you’ve learnt on your own

Many of the developers I interview are either entirely self taught or have spent a lot of time after their degrees or courses learning on their own and that’s fantastic!

As you might know I’m a big advocate for self improvement and I think every ambitious developer should dedicate some time to learning, if your company provides opportunities for this; Great!, if not you should be asking why not.

Self learning can be tricky though, what do you concentrate on learning and how do you find out about the thing you don’t yet know about? Most language books and courses stop a bit shy of patterns and so by asking about patterns I can get an idea of the depth of learning you’ve engaged in.

Have you just skimmed the surface of a thousand languages and frameworks or have you at some point dug a bit deeper to find out about the underlying patterns and paradigms that so many of them are built upon?

They make communication easier

Finally this might be one of the key reasons why I ask about them and am delighted if you do know at least some patterns: they make communication about the work much easier if you are to join my team.

Surprising amount of developers especially mid and senior level when asked about patterns answer with something along the lines of: “I use quite a few of them I just don’t know the names”. Unfortunately that makes talking about code a bit of a pain.

Say we are having an early chat and throwing around ideas about how to implement something, or we’re doing a code review and there’s some refactoring to do:

Compare these two exchanges:

“We could use a class here where we’ll restrict the use of the constructor by making it a private method and then creating a class method that will create a new instance of that class and then stores it as a static variable so if requested again we can return the same instance again”

or

“Singleton class could be good here”

Slightly tortured example off the top of my head but I think you get the point. Imagine people building houses but instead of using words like “brick” they’d have to somehow otherwise communicate across the concept of a rectangular baked piece of clay and other gunk…

If you are hiring developers I urge you to ask about patterns as the answers I found are often very enlightening and if you are a developer looking to up your game and improve your skill set I urge you to start looking at some well known patterns.

I promise you it will help you with your ever day work and could make that vital bit of difference in your next interview ;)

I would love to hear about your opinions so please do get in touch on Twitter @efexen and if you have any comments or questions I’d love to hear them too.

Finally if you enjoyed reading this post can I ask that you do recommend it, share it with others and follow me. Thanks

--

--

Ville

Freelance Developer • Founder of @CodeHalf • Rubyist • Elixir Alchemist • Wannabe Data Scientist • Dad