Why learning to code is important for the talent function @Pusher
So before I begin, I want to be clear that I am in no way claiming to be a developer/software engineer (it would be an insult to true coding professionals). I genuinely wouldn’t last a day.
Having hired a large number of developers over the years, I have always had an intrigue and a desire to find out what it would be like to spend a day in the shoes of an engineer (this part is a key learning from my 1-day Python course).
I have been in technology hiring for almost 10 years now and naturally picked up some knowledge on my travels. As with anything, when you stop learning, you stand still. This particularly applies in the world of technology and hiring within it.
When I say knowledge, I mean I could describe what a Realtime Distributed System does, tell you what an API, SDK or Library is, and give you a run for your money at “Buzzword Bingo”.
My Coding Day:
20 talent professionals turn up with MacBooks in hand, coding terminals open and the latest version of Python 🐍 downloaded. At this point we are all feeling prepared 🤓.
This all soon changes when we embark on a pair programming task to draw our favourite cartoon characters using various Python commands that we just learnt.
To say it was challenging would be a huge understatement. Not one single pair got even close to finishing.
Why did I do it?
My main focus was to learn how to code (at a basic level). I thought this would help me have more technical conversations with the people I was trying to hire.
My key takeaways:
#1 First of all, I did not really learn to code. Sure, I learnt some fundamentals, most of which I have now forgotten, but coding is clearly something you have to do continuously.
#2 Learning to code helped me understand that interviewing engineers needs to be a two-way street. Working on solving engineering problems as a group or team is a huge part of the way we work at Pusher. Therefore, exploring ways of working in this scenario is important, as well as having a real-world problem to solve as a team for the interviewee. This helps us make really great hires that fit with our company culture and values.
Solving complex engineering problems is super challenging and stressful. At Pusher, we have a saying: “strong opinions loosely held”. This is really important for us, because no matter how smart you are, if you can’t solve problems as part of a team or be flexible in your thinking, then it could cause issues to our flow. This was also highlighted during the coding course and the pair-programming exercise. It showed just why cultural fit or enhancement is so vital to hiring.
#3 Having struggled through the day solving what to actual engineers would seem like basic problems gave me an empathy for just why development teams need quiet spaces to concentrate on what they are doing. Essentially, from it I understood that the life of an engineer is about constantly solving problems often created by themselves. Imagine having to do that with constant noise distractions.
#4 The course helped me understand the constant trade-off between commercial teams wanting, and often screaming to ship new products, and engineering teams knowing how important it is for something to be perfectly functional by the time it is in the hands of customers.
We spent around six hours trying to draw Eric Cartman from Southpark, a drawing that no one would ever see outside of the group, and it ended up being only 10% finished. This helped me understand just how long and why it takes time to build a scalable distributed system that can manage millions of concurrent connections without failing and is also reliable.
Some talent takeaways:
#1 As talent professionals it is our job to get out of the way and let the technical people talk shop. I often see talent people be more of a hinderance when hiring someone by trying to be more technical than they are.
#2 Software Development and building great products is really hard.
#3 I encourage commercial teams in technology companies to learn to code. If nothing else, it will create the understanding and empathy for why you don’t have that product right now. In fact, I encourage all departments of a company to learn more about the day-to-day of each other’s roles. It will make for a more collaborative environment.
#4 Hiring the super smart arsehole in an engineering team who doesn’t fit into your working culture or support your values is not a good idea. It’s OK to say no to talented people.
#5 Last but not least, I am not a developer👨💻 (yet😉).
