About two interviews that made me find a good approach of technical interview

I like taking and conducting technical interviews. This is an incredible opportunity to meet new people and new approaches in programming as well. Some of the overheard practices were applied by me on my projects, some of them were not because I was finding another confirmation of why they do not work.

As a technical interviewer, I always try to conduct an interview useful as much as possible for both the candidate and me. First of all, I don’t want the candidate to feel like the interview was wasting his time. Second, I want the candidate to be excited and to want to join a company I work for. I have been following this way all my career, and I remember when I decided to do it.

I remember two technical interviews which become examples of:

• what an interview must contain,
• and what it must not contain at all.

Good things go first. When I was a junior developer, I was interviewed as a candidate every 2 or 3 months. Once, I tried to go to an interview in a foreign company that develop its own e-commerce product. The interview was awful: I could not answer questions related to .NET background and how CLR works. I was focused on the business part of the development: instead of thinking about making things right, I was making the right things. After the interview, I asked for immediate feedback. The interviewer said that I am an underskilled developer who has many gaps. I was upset, but nevertheless, I asked for recommendations on what I should read or learn. And the interviewer provided a list of books.

From this interview, I learned:

• Giving recommendations with feedback may help a candidate to improve his knowledge,
• Saying to a candidate that his skills are lower than they are supposed to be, is non-effective. You probably want to give feedback, but you should give it softly: gaps are not weaknesses but points of growing. Otherwise, the candidate will get a bad feeling about your company.
• Skipping reading programming books makes you build dirty architecture. If you skip basics, you build ineffective and unreliable solutions.

The second interview was in a local product company whose business was auto parts sales. At this time, I was still a junior developer who started to improve his skills by reading “CLR via C#.”

The office of the company was fantastic! Loft-like open space with a green zone with a glass ceiling at the center of the office. Nice chill zone. The interviews started with talking to a recruiter: my experience, education, etc. Then, head of the development joined in the conversation. He asked me several questions related to algorithms and data structures. I gave vague answers because I was not familiar with the topics. After the fourth or fifth question, he just went away from the meeting room without any word. It was really stunning to me. The recruiter asked some additional questions, and the interview finished.

After this case, I learned the following: as a technical interviewer, I have to pay respect to every candidate whatever skills he has. He has spent some time getting in the interview as you have done. As a company representative and candidate, you are both equal participants of the human resource market. Today candidate is a junior developer or intern, but tomorrow he may become a lead developer who interviews you.

If I see that candidate does not match to vacancy, I try to finish the interview softly. In addition, I always give some time to the candidate to ask questions to me. I want him to form a good feeling about the company where I work.

In conclusion, If you are a technical interviewer in your company, I’d like to recommend you the following:

• you should always pay respect to every candidate. You both are equal participants of the developer community;
• give recommendations after the interview. Candidate should know what he has to learn for joining your company;
• give feedback softly. Gaps are not weaknesses but points to grow;
• never stop learning. Candidates may have more experience with new technologies than you have, so you should listen to them carefully;
• Basics are essential. Knowing how to build things right is important as knowing how to make the right things.

Just try to do technical interviews to be useful for you and the candidate.