During the last few weeks, we’ve been hiring for different roles at Wúru. Hiring is hard, and recently, this difficulty is being fueled by a trend I’m seeing crystal clear. The market is flooded with programmers, but these programmers are not engineers. On top of that, over the past year, massive layoffs took place, thus feeding the flood with even more people (most of them not engineers). Inspiration for these lines came from Joel Spolsky’s book Smart & Gets Things Done, which I found not only fun but really insightful. If you haven’t read it, go ahead, it’s a must for a technical manager. Additionally, the idea that finding great developers (engineers) is really, really hard also inspired me.
To begin with, let’s put forward some numbers I collected during my last recruiting sprint. I hosted 14 interviews, of which 12 had me virtually dismissing the candidate in the first 5 minutes. Even though the candidate was not fit for the task, I had to hold at least a 20-minute conversation with them for politeness. The common ground for all of these dismissals was the lack of ability to maintain a technical conversation.
Given this, we decided to steer clear of those kinds of profiles. As of right now, we’re only hiring engineers or students who are in their last year of engineering careers.
In my opinion, these non-engineer candidates, say, empirical programmers, are a good fit for big companies where the engineering and design are carried out by higher levels in the org chart. Services companies, where a profit is made by mixing senior workers with more junior or operative ones and selling them as a team. And in the third place, a rare group of product-oriented companies that don’t really care about their delivery quality. At all.
But, why all the fuss? Why does a product startup need engineers so much? The answer is quite simple. A great product is not just programming, but requires a long-term vision and an understanding of the compromise that you can have between executing fast and delivering quality. Bearing that in mind, knowing how to balance everything to achieve a market-changing result is ideal for quantitative thinkers, engineers.
Engineers can think about the problems as a whole and understand the impact of their piece of code within the higher-level process it takes part in. Programmers, on the other hand, tend to focus solely on the problem they’re solving and usually isolate it from the product, producing more integration errors.
To finish with, there’s one more relevant idea. Engineers are usually challenge-driven and really engage with the product, delivering a lot of value in its design iterations. Plain programmers, however, tend to be money-driven and harder to retain in the team, thus making the hire more difficult to justify.
This is an opinion, but in the near future, I will try to abide by what I’ve just written and report on the learnings of this process.