The amateur juggler sits nervously at the dimly lit desk, knowing full well that his clumsy, shaking hands might at any moment knock the candle over, and set the whole tent office ablaze. Breathe, he tells himself. Get it together.
Across the table, the circus director looks over at the strapping young man before him and quickly gathers his notes for the standard interview questions.
“Ok, Mr… Beansley, is it?”
“Yes, sir.”
“Can you juggle more than three items at once?” the director asks, patiently scanning the candidate from behind his tiny, round spectacles.
Phew. He won’t have to lie for this one.
“Oh, yes, sir. Of course. I can juggle up to seven objects at once! I’ve been asked to perform at schools, birthday parties, talent sh—”
“Good, good” the director cuts him off. “And do you work with knives or anything of the sort?”
He gently pulls down his sleeves to hide the wound from where he nearly chopped off his finger last night, before surprisingly gracefully managing to say “sharp objects are my speciality! I’ve been practising since I was six.”
“Excellent! And how are you with flaming objects?”
Blast. This is it. He gulps down now, as he cannot seem to get the image of the entire circus on fire out of his head. Steady now…
“I’m like a dragon!” he finally blurts out, ferociously nodding as he does. “Or… a phoenix. Anything to do with fire, Mr. Barnum, I’ve got you covered.”
“Right, then!” Mr. Barnum gets up, smiles and tightly shakes the amateur’s hand. “You’re hired. I shall see you on Monday morning.”
“But sir!” the man belts out, as the director is already halfway out the door — “I haven’t even shown you my juggling!”
A Universal Problem
Believe it or not, the sort of exchange illustrated above not only is common in job interviews across the globe, but is particularly prevalent in software circles. For this reason, SPG would now like to introduce a few simple, but highly effective suggestions to assess potential vendors and bring aboard the best developers.
1. Evaluate portfolios
Like a picture worth a thousand words, a portfolio will always have a lot more to say about a team’s collective abilities than a simple job interview could ever convey. For this reason, when hiring, we recommend taking a good, long look at each candidate’s body of work.
On that note, by the way, a series of small, consistent projects tends to be far more significant than a single major achievement, as this will usually indicate greater knowledge, cases, experience and overall speed of development.
Yet to simplify things, as a rule of thumb, if a team’s portfolio has a minimum of 3 to 5 projects individually implemented over a period of two years, then you are likely to be fishing in promising waters.
2. Check Github accounts
Considering the fact that it is the largest host of source code in the world, odds are that at least a few of your potential hires have already uploaded their projects to Github. Thus, we recommend requesting from developers a link to their joint or personal Github accounts, as this will serve as an accurate representation of your team’s individual capabilities.
3. Request code snippets
Although many projects are protected by non-disclosure agreements, you can always ask vendors to provide your company with a helpful selection of insightful code snippets. These may then be evaluated by a technical specialist who should be able to let you know if the team lives up to your standards. But bear in mind: these snippets will always showcase the very best work that your candidates have to offer, so do not expect that the code used in your project will in any way be better than the samples which you have seen.
Some Other Fallacies
Unfortunately, however, a lack of focus on results is not the only thing standing in the way of more sensible hiring procedures.
1. Hourly rates
For example, customers are often tempted to compare providers by focusing solely on their hourly rates — but this is wrong on a number of levels. Imagine, for instance, that a team charges £60 an hour while its main competitor provides the same services at an hourly rate of just £40. Though it may seem obvious that one should go for the lowest price tag that is currently on display, in reality, this process is significantly more complex.
In addition to dealing with a global market with vast technical differences and wildly varying rates, perhaps the team that is charging more will also be equipped with superior performance. This, easily, would lead to better and faster results, and in the long run, would probably end up saving you a great deal of money.
At the same time, a less expensive but equally less experienced team will likely generate huge quantities of technical debt, and as a result, slow down development.
2. English fluency ≠ Intelligence
Yet another mistake is that candidates are frequently — unfairly — evaluated based on the level of their spoken and written English. But of course, a programming language is called that for a reason, and consequently, one’s native tongue has little to nothing to do with the quality of one’s code.
In fact, suboptimal English is more than made up for by the sheer robustness of the final solution. So while adequate communication skills are undoubtedly a must, never assume that just because you benefit from a well-versed team of Shakespearean volubility, that their standard of performance will somehow prove better.
The Show Must Go On
In the end, however, as we hope you have learned today, actions still speak louder than words — so whatever you do, moving forward, make sure you don’t behave like that foolish circus director!
Instead, by following Software Planet Group’s simple recommendations, you can turn your attention towards palpable results and guarantee the standing ovation that your product so deserves.
