Know what you’re hiring for — How we customised our developer hiring practices for laser accuracy

When was the last time you had to write code to control a virtual robot? At Lexicon Digital, we build real-world applications for real-world clients.

Traditional coding challenges tend to focus on computer science basics (which are important) but lack a demonstration of working software principles. We decided to fix that.

The challenge with coding challenges

Popular challenges (like the classic FizzBuzz, Toy Robot or Mars Rover challenge) have known solutions and are very easy to find online.

You can outsource this to coding challenge companies, but they have mixed results and always seem inconsistent. You are also unsure if the challenge reflects a real-world environment and if they showcase all skills of a developer (e.g. problem solving, solution architecture, DevOps, full-stack)

Our solution: Make another coding challenge

The Goal:

Something relatable with a good narrative.

We wanted to ensure that it was designed to showcase the skills we would want to see, and the output was full-stack working software, which included:

• Simulated real-world concerns
• Presented as a briefing from a real-world client
• Provided APIs that are not perfect for solving the problem
• Made the provided APIs unreliable

Issues we faced:

Familiarity

One of the first issues we noticed turned into a strength. The issue with becoming familiar is a bias towards the known solutions (eg, command pattern for Toy Robot/Mars Rover), and anything outside that deemed wrong, instead of being assessed objectively for its merits.

As we built our own in collaboration it also made reviewing the submissions very easy as we know what to look out for and have a common framework for assessment. We are then able to discuss it quickly in a followup interview and relate this to our own experience.

Clarity

The next issue we came across is how clear the instructions are. As we would be sent off for our prospective candidates, we needed to ensure that it didn’t require any followup questions or explanation.

We also wanted to make the desired result clear, but be a little ambiguous with the details so you can see what concerns they think about and have them document assumptions.

Difficulty

Another challenge we faced was ensuring the problem could be completed by a graduate but also has enough substance for a senior to sink their teeth into. This wasn’t easy, and we did consider having different challenges for different skill levels. However, we feel as though the challenge we have come up with has many layers and depending on the candidate’s skills, we see a variety of exciting solutions to the presented problems.

Identity

Finally, we wanted to ensure that this gave the right developer experience and was one that reflected our engineers and us. This needed to reflect our principles and values, and above all add value to the interview process.

Did it work?

Hopefully…

Now that we have shipped our MVP version we have established the cadence to collect feedback and ensure that there is continuous improvement to continue to iterate on the design of the challenge.

Check back again here for more updates.

And…… If you are interested in taking the test — check out lexicon.com.au/careers