A good technical interview

Disclaimer

This short-read is just an opinion based on personal technical interviewing experience and the the idea is just to share my personal thoughts that may help others to make their interviews a bit more useful for all parties.

What is a technical interview?

A technical interview is an act of communication in a group of people where an every party has her/his personal goals and expected results.

Candidate goals:

• show and sell his/her skills and ambitions to a company as expensive as possible
• understand what a certain company or team could offer for his/her skills and ambitions
• understand the opportunity on how he/she can bring the value and apply his/her ambitions against company realities and goals

Company goals:

• reveal candidate’s skill-set and mindset
• match these aspects with company needs
• sell the company to a candidate as the place where he/she could be valuable and could grow as a pro

There are a lot of other aspects that might be valuable for a candidate such as benefits that company offer, how far the company office is placed but they are just details so let’s skip them since they are not relevant for the interview itself.

In general case by these points above every party makes a decision on should he/she stick with this partner or not.

The issue

By my _personal_ experience every party has a list of mistakes and misunderstandings on how he/she reaches his/her goals.

Usually a candidate:

• is not ready to tell a story about his/her professional experience and wishes
• has a pretty poor resume that does not explicitly describes his/her skills and ambitions
• does not have a list of requirements or questions to a company that can help him/her to match personal needs with company offers and benefits

In its turn a company:

• does not allow to tell a candidate his/her story
• just has a list of certain technical questions that does not reveal a real technical level of a candidate and his/her mindset
• poses a technical interview as a fight between two warriors where the technical expert attacks and the candidate responds to these attacks

How I try to fix these issues as a technical expert

Make a technical interview as a story of a candidate

Usually a technical expert has its own set of questions to ask for a candidate and this is the first and main mistake. When You as a technical expert start with such list of questions You try to reveal the area that is shown on the following picture:

But the overall goal is to discover the following area:

So the question here is: *how can You get to that area?*

The answer is: *obviously, make a candidate to guide You there!*

Usually, the first question I ask is something like the following:

*Please, could You tell me the most interesting story from your technical experience that reveals You as a professional engineer. It could be a great success or failure. It could be a bug that has been introduced ages ago and nobody except You could fix it. Any challenge that worth to tell your family near the fireplace.*

Your first thought might be: It sounds too broad and does not bring much value on his/her technical stack and knowledge!

Well, I think that the answer is: No. When a candidate indeed has something to say - he or she will do this, You just need to point the direction of the conversation and then step by step You as a tech expert will dive into that hidden area and by using such technics as clarifying questions will get You deeper and deeper.

Questions to do/don’t ask

The following questions usually do not help You:

• theoretical questions that require certain definition as an answer: having an understanding of something is much more valuable then knowing of a certain definition
• tricky questions regarding programming language or platform: in case You are interested in tricky things and aspects of language or platform, You expect that a candidate will produce tricky code as well which is not the right expectation though
• do not ask questions that require yes/no answer: such kind of questions could be guessed and require further clarification

And the list that usually brings a valuable output is the following:

• solve regular coding tasks from the field, for example: map/filter/reduce tasks, basic DB schema creation with all kinds of relations and so on. It helps to understand that candidate has basic experience from real world in a couple of minutes.
• give a piece of code for refactoring or code review. Usually, it gives quick feedback on a very wide variety of aspects of coding skills
• ask questions that reveal a mindset and a way of thinking rather than on knowing certain language/framework API: such kind of knowledge is much more useful and applicable in real day-to-day activities

Other tips and tricks

• try to see the mindset but not a current set of knowledge because of knowledge is much easier to gain in comparison with mindset
• know the company You are working on or looking talents for - this should help You to sell this company to a candidate
• know the resume, it shows that You are interested in a candidate and makes a conversation much more comfortable for all parties
• if there is an ability to take a walk during your conversation - just do it
• be a friend but not a examiner, in this case the overall communication context will be much more comfortable for You and for a candidate

Conclusion

So these thoughts above are just personal opinion and do not pretend to be a truth but could help someone to make such an interesting activity as a technical interview a bit more efficient and comfortable for every party.