It sounds like an oxymoron; give me a chance to explain. Like almost everybody who has ever worked in software development, I have had my fair share of bad technical interviews. Almost everybody agrees they are necessary. I say almost everybody as I know some people see no value in them. I have been involved in the hiring process in at least one company where management did not believe in them and forbade us from asking anything but the most basic theoretical questions during the interview process.

Do we need them?

After my aforementioned experience, I would say: definitely! I hold an MSc in biology, love everything to do with medicine, have taught at a nursing school, and have seen many videos of actual surgeries being performed, and I can answer many questions (even technical) about how to perform surgery and the different steps involved. Would you trust me to remove your appendix?

Before you say comparing a complex medical procedure to writing software is not fair or relevant, I am not comparing the two. Instead, I’m trying to highlight the point that I can “talk my way” through an operation, but I can’t execute it. Similarly, someone can talk about all the right things to do while writing/designing code, but can they do it?

Going back to my experience with the hiring process with no technical interviews. I will give a glaring example of how things can go wrong. Sparing you from all the nitty gritty details, I was asked to interview a candidate that had already wowed two interviewers to the point where they asked for an accelerated hire process. After my interview I was skeptical. Abiding by the rules, I couldn’t ask very technical questions and the ones I did ask were answered at such a high level that anyone who knew the keywords would be able to give them. The candidate was hired and I was tasked with onboarding them to our backend development team.

The onboarding process involved learning a new programming language. All seemed to be going well and any offers of help were met with the “No need. This is such an easy language to learn!”. Maybe I was wrong about this person. Maybe they were that good. The first probing into their understanding level (couple weeks in) however revealed a different picture. All of a sudden it turns out that concepts such as variable scope, difference between input and output parameters, output parameter versus return value of a method needed to be explained. Digging deeper into the knowledge level, I realized that this person does not possess even the most basic programming skills. When I asked my interview questions again but this time without the shackles of “no deep technical questions as the candidate might be too nervous and we might miss on a good hire!”, I found out that our candidate knew as much about programming as I knew about surgery (maybe way less even). They knew all the libraries to be used in building websites and what each does. They knew about the latest backend development in .Net and knew what MVC and SPA stand for. However, they failed to even write an if statement in their language of choice that tests for a simple boolean variable.

One of the wowed interviewers (J) refused to believe that anyone could fool us this badly. An approximate and paraphrased excerpt from my conversation with J:

J: What about all the websites they built?
Me: Either static sites with copied JS/CSS or they only worked on the CSS part.
J: They talked about (a long list of libraries) and knew about (a list of web application frameworks)!
Me: They know all about the libraries and what they are used for but not how to actually use them. Same for the frameworks.
J: I can’t believe that! Give me a week with them. Maybe backend is not their thing.
Me: Just keep in mind that “if statement” I asked for and start from there.
J: When can I start working with them?
Me: Now!!! If it is up to me, I would send them home.

Few hours later:
J: I sent them home! I had to! I couldn’t take it!

This is an extreme case (other “talkers” will most likely have a better understanding of the basics and be less convincing in selling themselves). However I think this example illustrates the need for these interviews. People can train for interviews, learn all about libraries, maybe even explain the difference between some design patterns and make a good impression but their knowledge can be very shallow. On at least one occasion (that I was personally involved in at Vena) a technical interview gave us the ability to identify such a candidate who knew all the libraries/technologies/frameworks and what they do but could not put them to good use.

The dreaded technical interview

From my experience as well as others, the dread usually stems from two categories of grievances (I am sure there are more out there):

1. How is that relevant to what I will be doing (including the myriad of tests)
2. Being set up for failure instead of success (coding in a word processor with no documentation or internet access, unfairly undermining chances of success, etc).

The Vena way

Last June (2021), I was looking for a job, having just returned to Canada after years of living overseas. Part of almost every hiring process was the (now rapidly becoming dreaded) email that invites me to go to “OurTrustedTestingPartner.com” for a technical interview/evaluation. When interviewing with Vena I was invited to two separate Zoom calls with a couple of interviewers on each. I have heard of those panel-based horror shows though this would be my first.

One of them was a case study (designing without actual implementation) of a system that performs function X and has features A, B, etc. The question was clear, no wordplay or hidden traps. Looking at the question, I thought to myself, this is what I have been working on for the last few years. I know this system. Of course, the production systems I had worked on were far larger and had more complex business logic, but I saw all of my “lessons learnt” in the system I was asked to design. I drew on years of working on such systems, and the rest of the interview felt more like I was presenting a proposal to my department and they were asking me clarifying questions. I am sure I didn’t find the perfect solution to every point raised but obviously, that was not the point of the exercise. 

This is a design interview, I hear you saying. Of course, the really dreaded one is the coding one. So let me tell you about that one.

Before joining Vena, I had never used GitHub for code reviews. To my horror, the first step was to review some code in GitHub (to me, an unfamiliar UI). I thought to myself, “Well, this is it!”. I explained my situation expecting the interview to be effectively over. Instead, I was asked about the code review process that I am familiar with (I will spare you the ugly details of that system) and then one of the interviewers went on to explain the GitHub UI to me and offered me the chance to look at the code in the IDE, which if I preferred.

I immediately identified a couple of issues (low-hanging fruit left there on purpose, I later learned), then a couple more rather evident ones. With my nervousness receding in the rearview mirror, I got into a groove analyzing the code.

It has been years since I wrote anything in Java beyond a printing server made up of a few classes. That showed as I missed a simple NPE issue that C# syntax affords us a way around. The interviewers mentioned that slip while emphasizing that it was the only thing I missed and that I had done very well in that part of the interview to further alleviate my nervousness. “They care!” was my impression at the time. By now the interview was starting to feel more like a pairing session than an interview.

I was thinking they were saving the best (or worst) for last: the coding exercise. I was asked to add a new endpoint to the API. This new endpoint would actually use some of the code that I have just finished reviewing in the previous step (but cleaned up).

Having used Java sparingly for the last few years, I struggled to find the exact syntax of the Java equivalents of my C# constructs so I used a mixture of pseudo code and actual Java code to illustrate how I would do it. Once I finished (once again thinking, “I blew it, look at all those squiggly red lines!”), one of the interviewers asked: “Do you think you can use Google to find the right syntax?” In my nervousness, I had forgotten the “instructions” in the beginning: “You have full control of the machine and you can use whatever resource you need to complete the task!”. So I did. I found the correct syntax and was able to finish the task ahead of time.

Once I finished each of these interviews, family members asked the usual “How was it?” My answer was the same for both days, “It could have been a normal day at work!”. 

What did my interviewers get to know about me from these interviews?

In other words, can I do the job I was being interviewed for? Can I take out an appendix or just talk about it?
The interview process answered all these questions in a manner that left very little room for misinterpretation.

The enjoyable technical interview

Based on the above, my advice for making the technical interview enjoyable:

• Make it relevant to the job and make it as similar to a “day on the job” as you can.
• If you set your developers up for success, then set your interviewees up for success.
• Challenge their abilities to do the job, not their ability to navigate minefields, read minds or do things that are not part of their job description.

The interviewer is not there to make the interviewee’s job as hard as possible but to make it resemble a normal workday at your organization while maintaining the ability to test for the qualities you are looking for. The interview is the first process an employee goes through at your organization, be careful what image you want to project for their first impression.

I think the litmus test for an interview process is not the raving positive reviews you get from people who pass them (although it feels great to get those!) but what people who have failed them say (I said set them up for success, not give everyone a passing grade). How did they feel at the end? When such candidates give you good reviews and leave (at the end of an interview that they failed, even badly) feeling valued, dignified and maybe even that they have learned something, you know you are on the right track.

• Category: Vena Engineering
• Tag: culture, interview