Do you do your homework before interview?

Błażej Adamczyk - Jun 16 - - Dev Community

Do you ever feel like doing the homework before every interview? Do you feel that there is some kind of test you have to pass and not only gain enough points but also outscore other candidates? But when you actually get the job, it has nothing to do with questions, requirements and responsibilities posted in the listing.

I think this is ridiculous. Recruitment process became detached from reality for a long time, and I've seen only few companies that actually make recruiting right. I have over 15 years of experience in the field, I've been on many recruiting processes, and I did some recruiting myself as well. I'm not saying my approach is bad, but we have to address elephant in the room.

The BAD

Let's start with how most interviews go. You show up. You have a ton of questions in regards to technical knowledge about tech that was listed in the job listing. But let's be hones, recruiters have a standard list of those questions. And the number of questions is limited to a degree, so most of them you can find online easily (yeah, recruiters take that questions from online sources as well). So, if you are determined you can just study answers for the questions, without really understanding the topic! In fact, there are many people that do so!

The problem starts to be visible when ability to answer questions, does not corelate with ability to solve problems in the job environment. Or in worst case scenario - it does, but the temper does not fit the team, and it ends up lowering efficiency of the whole team. Gaining 1 team member ends up loosing 200% productivity.

The Ugly

And the productivity is actually on the elitist approach to recruiting.
This is "the top 1%" of programmers. You either have to answer all questions perfectly and beyond, answer leetcode problems, take test on the coding exercise platforms within 2h timeframe, or make a full blown solution within 24h window.
This is not a problem with recruitment process. It's a problem with company culture. The grind mindset. You sacrifice everything for that company, if you don't we don't want you. Those type of companies expect ultimate loyalty from you, but don't return any loyalty back to you.
Let's be honest - companies are loyal as long as it benefits them, but no company is nowadays loyal to their employees, so you don't have any obligation to be loyal back.
Anyway, for the sake of your mental health - steer away from that type recruiting processes.

The Good

Now, the best recruiting processes are those who don't focus on the knowledge, but concepts and problem solving skills. Intricacies of a specific tech does not matter unless there are conceptual mindset behind it. Mindset and thinking process are the money saving skills. And heads up recruiters - any hard technical knowledge can be bridged very quickly with googling skills, or nowadays even prompting skills.
So prohibiting googling during interview is one of the stupidest rules ever. Why? Because the way someone is looking for information is one of the most important skills to have. People do that on the job anyway, and during interview you are pretending like it does not happen.
And one more aspect to consider - attitude and company culture fitness. Basically, check for soft skills like self-presentation, honesty, teamwork capabilities, communication. How to do that? By asking questions like: "what would you do, if you realize there is a bug on production", or "how would you handle conflict, if you have disagreement about implementation, and you are sure you represent better solution". But you have to be very sensitive to bullshit answers.

My protocol

I'm assuming that at this point you want to recruit some talent. You might have considered other approaches, you might have your own recruiting recipe, however you might think there is some room for improvement. Certainly, there is some room for that in my recruiting protocol - it's not bulletproof. But I think it's one that I like the most and whenever I'm being recruited in similar way, my green lights goes off. I suddenly know, that people on the other side actually know how to do it properly. So here's my process:

  • Introduction (~10 minutes)
  • Brief technical check (~10-20 minutes)
  • Problem solving check (~15 minutes)
  • Soft skills check and debrief (~15 minutes)

Of course if you have more time, or multiple step recruiting process, you can extend it, but apart from introduction, all the parts should take roughly same amount of time. Let me explain each part briefly.

Introduction

Standard who am I, who are you, why you left. Nothing outside of typical formula. You can explain the tech stack and team composition as well.

Technical Check

Yeah, I mentioned that in "the bad" section, that you can easily learn answer for these questions, but even so - you still need to check with simple questions, if that resume you got has anything to do with reality. But don't be tempted with very niche technical questions that you don't actually use in production. A datatype questions or common libraries are enough to see if someone is using the technology or not. If you are asking about something technical that you do not use on a daily basis, you cannot realistically expect an answer from someone else without being a jerk.

Problem Solving Check

This is the section, where you can ask, how someone would solve some technical issue. How would you design an API, or solution architecture, or consistency across multiple databases. Those questions ask about concepts and patterns, and does not focus on any specific technology. Of course, depending on skill level of candidate you can scale them up and down. You can ask a junior or mid about naming and linting problems, or clean code. Important thing is, that you have to check not the answer itself but how they got to the answer. Answer itself can be wrong (!) as long, as their thinking process is solid, and they are open for suggestions.

Soft Skills Check

That openness to suggestions is also a soft skill check. This is important, if not most important skill check. Emotional maturity can make or break your team. You are not hiring a freelancer, but someone who will be part of the social group. In group environment you need to keep in mind that there are couple situations where people have to know how to manage their emotions. And no, I don't mean they have to hide them by that.
What you have to have in mind is: how they handle constructive critique and suggestions, ideas rejection, giving feedback themselves, other people's feelings and social outings. This is emotional intelligence. It's part of the job, even though almost every company out there does not recognize it or cultivate it. And assuming yours does not have a program to improve emotional awareness of your employees, you have to look for those who have emotional self-regulation mechanism by themselves. What it means is:

  • candidate can take critique into account, does not reject it or does not shut down immediately
  • candidate can propose ideas and solutions in clear and easy to understand way
  • candidate knows how to communicate during conflict, and does not escalate
  • candidate is eager to participate in social outing of the team Based on that "metrics" you can come up with questions or provoke situation to check against it in non obvious way. Asking some of the questions directly can also help, but you are risking getting logical answer, not the actual behavior.

Conclusion

Recruitment process might be one of the most annoying processes in our line of work. Compared to other industries, software engineers and IT change jobs way more often. Not surprising, considering that switching jobs is one of the best ways to get a pay rise in a industry that wage changes happen also more often than any other industry. However, sometimes even though it is mostly intellectual and creative work, recruiters/companies seems to treat us like construction workers. But maybe there's better way? I would recommend anyone who participate in the recruitment process, to think this through a little bit more. If you have your own thoughts and suggestions, I'm happy to hear them in the comments.

. . . . . . . .