The final instalment of our mini-series about London Tech Week 2018, including our personal 'one to watch'.
Don’t worry if you didn’t get the memo about London Tech Week (or just completely forgot); we’ve got you covered with 20 of the best FREE talks and events taking place over the next six days.
London Tech Week (#LTW) 2018 has just kicked off, promising another week of intriguing deep-dives, wonderful round-tables and plenty of networking opportunities.
Every full stack .NET engineer who knows React and can build deployment pipelines for Azure, didn’t know these things in the not too distant past. When recruiting, it’s critical that we acknowledge this and build it into the career goals of those we wish to hire. To do this successfully though, we must screen on something recruiters don’t – potential. Potential in engineering terms is usually measured by proactive learning or involvement in communities.
In Part 1, we spoke about some of the extravagant interview processes tech giants go through to secure top talent. It works, they still have great engineers knocking at their door. However, are lesser known companies always going to lose out to the “Big Boys” for the best tech talent?
Rapidly scaling start-ups can sometimes be (mis)guided by following the mentality of hiring like the big tech giants – think Facebook, Google, Amazon. Their convoluted, seemingly cunning and lengthy interview process can be a real inhibitor to scaling and growing a company.
The only way technology start-ups can scale teams ahead of the competition is by creating their own unicorns and learning from the experience of failing to do so. Obsessive interview processes around an impossible to fill requirement will either kill most technology start-ups dead or at least ensure they fail to compete for talent.
Make your Technical test an enabler to show off a developer’s talent, not an inhibitor! A growing number of companies are using technical coding tests as a key part of interviewing new developers. However, in our experience the number of developers that fail these tests greatly outweigh the number who pass them... but does this make them bad developers?
Ruby on Rails was never marketed as a performance-first framework, it was marketed as a framework you chose when you wanted to get shit done and as quickly as possible. There is no denying that Rails delivered on that promise.