Is command of a specific programming language the most crucial skill we’re looking for among candidates? I would say no, especially when we’re considering a less experienced applicant. Regardless of someone’s skill, it takes time to gain domain knowledge and start delivering value to the product.
This post was sponsored by digital product consultancy DockYard to support the Elixir community and to encourage its members to share their stories.
Values as more important than the language skills
For example, in a recent hiring process my team had a little bit more time in our schedule and decided to look for someone less experienced. Choosing our new teammate, we focused on finding someone who shared the same mindset as we did. We wanted someone who wasn’t afraid of getting outside their comfort zone, seizing initiative, and who had a desire for continuous improvement.
Taking everything into consideration, we decided to hire a candidate who didn’t have professional experience in programming at all. He had only managed to get acquainted with some basics of Elixir before he applied. Since the command of Elixir wasn’t that important for us, we decided to give him a shot due to his motivation to learn and work.
We have experience in building and developing teams, so we knew we should support and mentor this newly hired person. We were ready to do anything so that he could achieve his potential in the shortest possible time. If he had failed, it would have been the whole team’s failure, not his alone.
So, what did we do?
Our approach to onboarding
We did our best to prepare everything required for the first day. We prioritized information that every developer appreciates regardless of their experience, e.g. tips connected with project setup, information about the team and the product, etc.
Thanks to all the above, our new teammate felt less stressed. We had given him a guide with the things he needed right at the beginning of his career.
Our team also loves pair programming sessions, so we spent part of our time doing that with him. It was a great opportunity to show him how each of us works. It doesn’t mean that we wrote code for him, though. We observed, sought things that could be improved, gave tips, and steered him towards a solution.
Besides pair programming sessions, we gave him time to learn on his own by reading books and articles, watching courses, and listening to podcasts. There are many highly-valuable materials on the internet as well as some great books (we think Elixir in Action by Saša Jurić is a great choice for a start!).
Finally, we challenged our new teammate by giving him some hands-on projects. For instance, we gave him tasks to code on his own in order to practice solving problems that were difficult for him but still attainable.
Mixing all these approaches, not only did we make him independent extremely fast, but also significantly valuable to the product from day one. Our goal was for him to make his first deployment to production within a week. He did it!
Tips to ensure healthy programmer development
We do know that a bad team atmosphere can sap a newly hired person of their skills, motivation, and willingness to work. Since the beginning, we clearly signaled to our new colleague that he could rely on us and ask about anything.
What’s more, we set some small goals each week to make sure that he developed in the right direction. It was a great way to boost his confidence, which was what we cared about the most. The more motivated and confident he was, the faster he learned.
Elixir features which helped this process succeed
This rapid progress was not only due to our involvement, but also the features that Elixir has.
On the one hand, the language is functional and it may be difficult to learn a new paradigm for some developers who already have a lot of experience in OOP. Nevertheless, that means all the application functionalities are built upon small functions that perform specific, well-defined, and simple operations. As a result, it was much easier for our new colleague to understand how the system works. The Elixir syntax is simple and explicit, with no magic underneath, which also helped him comprehend the code almost instantly even before he got fluent with it.
It’s worth noting that Elixir is immutable as opposed to many other languages that people use to build products. Due to that, both understanding and writing new tests were easier, as he mainly worked with functions that receive data and instantly return them without triggering side effects.
This immutability also made the process of debugging easier. He just needed to check the arguments of the function to figure out why the logic behaved a certain way. There was no need to jump between many parts of the application to understand why it worked the way it did. In Elixir, no data structure can be modified without recreating it from scratch. That’s why he didn’t need to be afraid that the logic from other parts of the system, executed concurrently, might change the data a specific function processed.
The success of values first, language second
Our new teammate became independent extremely fast. We still wanted to support his development, but that required less and less time. After a year of work, he had achieved more than anyone had expected. Great job to him and the team!
As you can see, it’s not all about the language itself. The team mindset is of the essence. If the team shares appropriate values, someone new will definitely grow fast. This is true even if they have no business experience and know little or nothing about the language you use. It is true, though, that in our case using Elixir definitely sped up the process of learning the technology. The ease of the language and the support of his team made our teammate feel confident and successful in a short time.