From my interactions with peers, I’ve found most of us (if not all) often dread interviews, especially when you realize that the hiring process across the industry is broken. This is due to events like bias, lack of proper feedback from organizations when you aren’t shortlisted or being 1 among 1000s of people that get generic recruiter messages everyday via email / LinkedIn.
Not only these occurrences are cliched but they also end up taking away genuine talent from an organization. There are due exceptions but it’s equivalent to finding a needle in the haystack.
Therefore when the opportunity to conduct interviews sprouted up at Bizongo, I took it head on as I was keen to see the other end of the spectrum. I had been included in the process with 1 of my previous employers in bits & pieces so tackling it with full responsibility was something novel and it immediately paid off dividends.
Let me illustrate both scenarios from a DevOps / Site Reliability Engineering perspective:
My Approach During Outward Interviews
- After the initial niceties, I begin with answering any questions (both technical & behavioral)
- Then I ask questions related to the organization’s principles and their employee culture, the challenges they face, why they use certain tools & frameworks among others.
- Since I’m perpetually curious to learn and improve, their answers help me determine if I’ve a potential chance to contribute in solving actual problems were I to be part of their team.
- Finally, I sign off on a courteous note with the question - "Could you please let me know as soon as you've an update on my candidature?"
A key learning I’ve had from following this is gives more clarity to both sides about the value proposition they could have on being associated with each other.
My Approach For Inward Interviews
- Here I kickstart the process by telling them what my current organization does and where does a DevOps / SRE fit in.
- Then, I ask questions to evaluate candidates on how good they are with their fundamentals, concise (not necessarily eloquent but clear) and know the why behind using technology X/Y/Z (of their own experience) along with observing them to understand their behavioral traits.
- Parallely, I answer all questions I’ve asked during the interview and note down well presented ones to enable bi-directional knowledge sharing.
- Finally I ensure that the candidate's is aware of the next steps (regardless of whether they clear or not) and thank them for their time.
Some insights I’ve got here post this activity is most people can have all the experience in the world but still falter to answer any from the above (i.e: the fundamentals and the why). Not recalling something is perfectly valid but unable to have coherent reasoning towards one's sense of purpose is surely a red flag since one might end up building a team that solely works in a mechanical manner.
Recently, an additional feedback I've received from multiple candidates during interviews at Bizongo was an interview with me felt like a natural conversation. This has been very re-assuring and extremely humbling to say the least. While there is still a long way to go but I believe I’ve made a good start.
Top comments (6)
The problem is with the fact that most people involved with the interview processes have no technical background. There are of course the exceptions from the successful companies but consider all the recruiters, HR and managers , especially old school, who cannot read one line of code and they are tasked to evaluate people on technology and potential.
When I ran the hiring processes with very high success ration, I mostly focused on the potential of the candidate. If there is potential then this person is a goldmine. I would also try to focus on extrapolating the potential even if the candidate was insecure or didn't evaluate himself well and I would try to raise his confidence in the interview.
It is the job of the experienced person to navigate through the background of the candidate because if the candidate is inexperienced then he doesn't really know what is relevant. Even experienced candidates don't know because often the descriptions are just a copy. But to do this, the interviewer needs to know and understand on a technical level what the role requires.
Brilliantly put Alex, couldn't be more concise than this!
In India, the part of non-technical people evaluating prospective candidates on technology is definitely true. For e.g: Most of them wouldn't be aware of what's the difference between AWS / GCP / Azure but ramble about it like they invented it.
My idea is to determine a candidate's logical thinking by asking them real-world scenario problems (to the best extent possible) and discuss what matters to them, their career motivation & their interest levels in the role they're applying (Good ones will usually be curious)
PS: I agree behavioral answers can be faked but if you ask the appropriate questions, people eventually spill enough information to make a decision.
You wrote the most important parts in your PS. The only requirement is that people know what are the appropriate questions and in our industry most don't, so we fabricate a ton of adjustment processes to in theory compensate but in practice makes things worse.
And it is not only India. There are basic indications to identify when things are wrong.
I believe in both cases, the more clear we're in our requirements as to what kind of role do we want / what type of person we'd like to hire - the smoother the process becomes.
It'll be tedious especially if it takes longer than expected but the end result will surely be satisfying.
Really great read Vinay. As someone who is a student, it was nice to read about the interview from the 'other side of the table'. I quite like your approach to outward interviews. 😊👌🏽
Glad to know my perspective & approach helps, Yusuf!
I've found it's an effective way to be impactful in a sea of candidates.