Back in 2013, when I was about to pass out of my college, 1 thing that usually bothered us was getting placed in a good company. Some of us were focussed to the kind of roles we wanted and then there was a desperate bunch. There were also students who would appear for any company and face numerous rejections before making it somewhere.
Now, nearing the end of 2015, I am a Senior Software Developer leading a team with a responsibility to hire. The striking similarity I have noticed in both sides is worth mentioning. How difficult it is for us as Interviewers to ensure that we are making the right choice as we can not afford the luxury of desperation.
By now, I have met over a 100 interview candidates both experienced and first job hunters and consider that a fairly enough experience to say how to best hire a developer and at the same time – what companies want to see in a developer.
A Developer is far more than a Coder – The hackathons these days with a rage towards implementing ideas have ensured that everyone is writing their code from scratch. When I would write a code towards implementing my own idea, whatever exists in that code is my piece of work. Sounds easy, right? A Developer’s job if far more complex. Its un-learning, re-learning, re-building, improving and ensuring that we are kicking ass way better than how it has been done.
To ensure that we are able to translate our vision about a Developer to making the right hires, we introduced a two step process.
The Bugger Discussion
This was aimed at ensuring that coders we are evaluating are equipped with the ability to understand the existing things rather than reinventing. Coachability happens to be a key ingredient here and one can only judge it by a person’s ability to improvise.
Here, we have a code and we don’t know what does it do. We expect the person to jump into the logic of the code, tell us what it does and correct the same. Code penetration loudly suggests about a person’s ability to perform in a fast paced environment.
The Designer Discussion
By now, we have spent ample time with the coder and are way above with our confidence that he can code. This is our way of ensuring that how does a person fit better towards the product based ecosystem. Here, we would again provide the person a piece of code pertaining to an existing product and would want to see their approach in adding a feature to the same.
The coder shall be required to understand the logic and be able to change the same to make it scalable. The intricacies and complexities in this problem are immense and are able to bring to light a lot of attributes about the coder.
I can most definitely say that running coders through with the nuances of probabilities faced by Developers does make a righteous impact and is able to ensure that they be making the right decision for themselves. As interviewers, the more time we spend with people, the more confident we are of making the right decision and believe me – it’s never enough.
Evolution has been the most prolific game being run through all processes around us – and until this becomes redundant, we are happily ensuring that we reap the maximum and make good with our aspiring and aware friends.
PS – An Interviewer’s role does not incorporate judging the person on the other side of the table, but making him completely aware of what he is looking at and how seemingly the same is in line with what they term as their goals. The entire exercise is reading the feasibility of an alignment and in no scenario passing a judgement.
Go, chase thy dreams!
