Sunday, 3 February 2019

Interviewing - my approach, and what I get from doing them

Interviews

Introduction

I have been on the interview panel for technical roles a lot down the years, and recently have been interviewing for lead developers. This process always invokes a whole range of thoughts for me so wanted to explore them further with this post.

What I do

You always hear of the importance of first impressions when it comes to interviews. As the interviewer, I try to greet them warmly, look them in the eye and smile. I want them to be at ease as much as they can be; you'll only see the best of someone if they are relaxed enough to answer and demonstrate as they want to.
I make sure I am engaged at all times and listen intently to their answers. I encourage with positive speech and never react to an answer as if they are completely wrong - even if they are. I don't want to them to panic and lose their composure, as this will result in rushed, less detailed answers.
You often hear of the good cop/bad cop set up of an interview panel, and I am definitely the good cop - I couldn't do it any other way.
I will occasionally lead the candidate to an answer if I feel they are most of the way there anyway, as this builds rapport. Again, I want them to feel at ease as much as possible, so if they align with me more than the other members of the panel, that is OK - especially if the candidate has applied for a role in my team.

The benefits to me

I always come away from interviews feeling a little lucky and to a certain extent verified. The reasons for this are usually because of where the candidate is coming from, both organisationally and personally. At their organisation, candidates are usually forced to maintain the status quo rather than enjoy up to date technology and practices. For example, a candidate may state that they have tried to bring TDD into their team, only for their tech lead to state "that takes more time than it is worth", or they've pleaded to bring in a source control system other than Source Safe to no avail. How else can I feel when faced with these examples, other than sympathetic and fortunate?
Personally, then, the candidate is frustrated and desperate to find a way out. The purpose of the interview in this case then includes trying to pick out a diamond in the rough - generally a developer that is putting in work to improve themselves, despite being professionally hindered. Such work would include personal projects such as web sites or apps, but also personal blogs and evidence that they follow industry resources and training videos or courses.
For me, I feel lucky then to be able to be in the position of keeping my team up to date with newer technologies and giving opportunity to those who which to pursue it. I'm also pleased with the best practices we have in place and am validated on this by candidates wishing to utilise the very same.
So learning from this, I can take away a pointer as how to be a good lead. That is to encourage my team to go away and bring back best practices they wish to explore and new technologies that may solve a problem for us. I believe my team feel they can come to me with either and be given a fair shot. It is important for developers to be given room to do so.

Makes you realise what is important

In a lead role it is difficult to stay in the weeds of the codebase, but this isn't an absolutely vital aspect for me. As a lead you want to be operating at a higher level - understanding a changes' impact to the wider solution and ensuring approaches are discussed and planned before being executed. It can feel unsettling to be away from the code sometimes, but a good team with good devs you can trust makes this easier! You have to find a balance between knowing the codebase well enough so you can advise of a potential change and not knowing every line.
How do interviews fit into this? For me, they help me re-centre on what is important in my role. From candidates we learn what they want to be doing and how they want to work. You are getting a free insight into the mind of a dev outside of your organisation in terms of what they are looking for in a team and from a lead. I then try to facilitate these conditions for my team. A happy dev is someone who is listened to and respected. Make all opinions welcome and valuable.

Lead role - the importance of technical skill

How important is technical ability when interviewing for a lead role? It's important. Experience is the key here really. A good lead will have faced a vast array of different technical challenges in their career. Therefore, I'd say a lead needs 5 years + experience in Software Development before stepping up. I must also stress that in the interview you must get confidence in the candidate's technical ability. I deal in .NET, so have low level questions to tease out that knowledge. I also like to see enthusiasm for for the field and evidence of the candidate staying up to date. How can they encourage their team to go looking for ideas if they have no interest themselves? If the technical ability is lacking, the applicant must be unsuccessful. They will not have the necessary respect of the developers if they can't remember the L in SOLID 😉

Successful candidates

Successful candidates that join my team remain in my team. I believe this is because I create an environment that is open, encouraging and professional. I want to see my team approaching me with ideas on new technology and best practice. I also want to feel challenged by them to improve my understanding of a certain area. I give them room to improve themselves and try things. Keep it failsafe!
I strive to get the balance right between doing what will keep my team happy over what the organisation wants. Creative freedom over bureaucratic governance. Trying new things over keeping it safe and dull. Filling out pull requests over filling out forms!

tl;dr

  • Keep the candidate at ease, build rapport
  • Learn from the candidate as to what they want from a team and a lead
  • In a lead role, technical skill is important, as is enthusiasm for the field
  • Within your team, engender an open, failsafe and encouraging environment

No comments:

Post a comment