Interviews are about finding an excellent fit for a certain role/team/company. To improve our chances as a candidate, we can prepare - to a certain extent.
After all, the interviewer can always surprise us. And that should be fine.
The Limits of Preparation
For developer positions, there are websites like HackerRank and LeetCode that help us to prepare for technical interviews. Or pages like Glassdoor in which we can, with some luck, find questions other candidates were asked previously when interviewing for the role we're applying for.
But we can't prepare for everything. There are questions that for some reason, we might not have an answer for.
Some years ago, at a technical interview, I was asked:
“What would you do if a user tells you they have a problem with the rebimboca of the parafuseta?”
That wasn't the term he used, but it might as well have been. I had no idea what he meant, so I replied something like:
“I would tell them I am not yet familiar with that issue and would look into it and get back to them. I would then check if my colleagues knew about it and search online to figure out how to handle this rebimboca.”
Not Knowing Everything
In that interview, there were answers I knew right away. There were others I partially knew and the interviewer gave me hints - just like I might get from stack overflow or checking documentation - so I came up with the answer after all.
And there was the one question I definitely didn’t know. At the end, I felt it could go both ways. A few days later, I received a job offer from that company.
This interviewer believed we don't need to know the documentation by heart. And that we do online searches often - as is described in this amusing blog post about what a software engineer might google in a week.
Another interview in which I experienced a similar approach from the interviewer's side I wasn't asked specific technical questions. Instead, we went over some code I had written previously and talked about it. This prevented the infamous blank mind that can overcome anyone.
I had other interviews that had a very different flow: one technical question followed the other. If my answer was incomplete or I didn't have a clear solution, we moved on to the next question. It is great to have a new developer hit the ground running at a new job and I suppose they wanted to ensure that.
Growth Mindset Vs. Fixed Mindset
In situations where we change or update the tech stack, the team will be required to learn new languages, frameworks, databases, etc.
In those cases, it's essential that the developers are willing to learn, to admit they don't know things, ask for support and are ok with some uncertainty.
It's also essential that the employer knows people can learn, otherwise they would need to hire new developers each time they change their stack.
Therefore, the person doing the interviews should embody that when talking to candidates.
The concepts of 'growth mindset' and 'fixed mindset', coined by psychologist Carol Dweck, fit nicely here.
Growth mindset is about knowing our abilities aren't forever limited to how they are right now: “I can learn what the rebimboca of the parafuseta is!” The opposite is the fixed mindset, where we assume our abilities are fixed and we don't believe we can change that: "I don’t know what it means, I can't pronounce it, someone else should handle it."
Safety
Of course there are different levels in this spectrum - I doubt any company operates strictly in the fixed mindset in the tech world, especially these days.
However, clearly valuing and living the growth mindset gives the team psychological safety, which in turn, means healthier people and a more productive team.
As a side note, the Scrum framework, so often used in complex software development contexts, even has values that support this, like courage and respect.
We prepare as well as we can for an interview. If the interviewer signals they trust us to learn and not remain a snapshot of our current knowledge, we feel a little safer in an uncomfortable situation.
For all candidates, it’s a good interviewing experience with the company. For the successful candidate, it’s a great start at the new job.