Don’t lose good candidates because of bad interview process

As a team-lead, I have a very good opportunity to be simultaneously on two sides of the hiring process: I’m hiring and I’m periodically participating in interviews as a candidate.

Being an interviewer and being interviewed at the same time allows me to compare this process from both sides to properly retrospect and build the most effective interview process (from my perspective) that should meet only 2 goals:

• make the interview process comfortable for the candidate
• make the interview process effective for finding required talents

As a result, I classified all processed interviews by the “interview satisfaction scale”. To make this comparison easy to read and technology agnostic I use “periodic table of the elements” knowledge as a metaphor here.

0: remind all elements in the fourth row of the “periodic table of the elements” in the correct order

Common, really? Do I need to memorize information that I can find in 10 seconds using my phone?

That is purely static and unlinked from real-world information. Have you ever used this info in practice except as an interview question?

Some interview processes I participated in are build to ask dozens of similar questions — non-stop questions and answers like you are part of some intellectual game. This annoying process — the result of such an interview process talks only about success in interview preparation (like exam preparation), but nothing about your experience and your further motivation.

As an interviewer, I also do not want candidates to feel themself on exams. First of all, this looks very unprofessional — questions with a single possible answer limit the possibility of conversation, so the chance to recognize a well-experienced engineer is very small. Also, the subconscious feeling that I’m on an exam puts me under stress. Every next wrong answer exponentially reduces the chance to align our relations — this is already a pre-build teacher-pupil state. All you want — complete the exam as soon as possible.

1: what was the possible reason for arranging elements in the periodic table?

Chemical as a science is very complicated. You can’t know everything and you should not. It is a science that evolving, consist of many sub-types, producing new discoveries each month. But the main goal of this science — understand the structure of our universe based on reaction and interaction between independent elements.

Being interviewed I want to put the focus not only on skills I’m investing in but also on reasons why I choose a particular evolution vector. You are not choosing Java language — you are choosing the ecosystem this language is part of.

If you are an engineer — you should understand the industry goals. You should understand different types of problems and common patterns to solve them. Why microservices pattern is not a silver bullet and how do specific data structures like a hashmap solve specific performance problems? Why blockchain is a good choice for security-critical systems?

Jamstack, Mean-stack, Mern-stack, ELK-stack, TIG-stack. All of them have the main reason to use. These are proven solutions for specific sub-set of problems. There is no need to know each of them, but high-level understanding is very important.

As an interviewer — such types of questions are asked to share your understanding of the changing world, how comfortable you are in this space. This allows discussing the current background and reason for choosing a particular direction to evolve.

2: what are the chemical differences between hydrogen and oxygen?

This sounds much interesting. Are you using some technology, utility, language, or framework because of hype, current trend, lack of domain, and context knowledge? Do you understand these differences and the types of problems each technology aims to solve? Are you planning to use hydrogen as the main element for any chemical reaction? Or probably there are already elements with required properties?

Low-code and no-code development is not a new buzzword for now. This is a natural evolution of PaaS, SaaS, IaaS providers, and open-source contributions into the technology stack. You don’t need to produce code for common problems — just use industry-proven solutions. Any code you produce has a price of its support, any library/solution you re-use has the benefit of supporting by someone else.

It is very positive if the interviewer has questions about solving common problems without writing code at all, e.g. using cloud managed services.

Interviewing, I want to find “lazy” candidates, who investing in finding solutions to common problems with as minimum code writing as possible. Solving business problems is not about coding only.

3: what would happen when mixing hydrogen and oxygen and why?

This is already a question with hidden complexity. It is very obvious based on the school chemical course, but very important at which conditions this reaction happens. If you know the only theory — you will not be able to recognize the main sense of this question. Only by having the experience you can reveal this complexity. As an engineer, you are expected to be prepared for real-world challenges, but not for theoretical battles.

Can I call a micro-frontend the solution when 2 pages are supported independently by React and Angular? Is my architecture respect the microservices mindset if a big monolith is deployed as 3 replicas with load balancer between? There are no strict yes/no answers here until you ask additional questions. There are no strict answers after answer questions as well.

Such types of questions allow revealing your experience in full power. Not only “what” to use, but “how”. Asking such questions — you, first of all, putting additional weight on the candidate, you align your positions. This is already partner discussions, but not interviewer-candidate relations.

4: sequence of such reactions should produce this result, but I get different. Why? Help me to find mistakes.

Detect issue fast — it is a really big talent. Understand that code smell — it is also big talent. Such experience allows you to produce solutions with a strong foundation and robust in a long-term perspective.

This is not only about code — you can be asked to find UX incorrect behavior or CD inconsistencies. This is not about QA skills — it is about motivation to produce clean code and architecture, detect possible mistakes earlier while they can be changed, convince others of the necessity to work on debt, etc.

These sorts of questions produce good conversation and sharing experience on both sides, because not always exists a single correct solution for the problem. Oftentimes any solution is a tradeoff or combination of different aspects that do not always go smoothly. And this is mostly 100% partner discussions — there is no feeling of untrust. You have received time to use your experience to solve the business issues, even when these are theoretical issues.

Conclusion

There is no other reason in the hiring process other than finding the right people at right time to solve current business challenges.

Knowledge, expertise, and other talents are just good indicators of such people, but not a primary requirement. Candidate — it’s, first of all, a future partner, who has a passion and strong desire to help the business grow by removing barriers on the road it moves. Don’t lose good people because of the bad interview process.